WBS最佳实践

WBS概念

实际上WBS的概念很容易理解:为了管理整个项目,就应该管理和控制它的所有组成部分。一些出版物对于WBS的评价是:

WBS是项目管理或者项目计划工作的基础。

根据PMI的Practice standard for WBS定义,WBS具有以下功能特性:

Deliverables:可交付成果
Design:设计
Management:管理
Organizational:组织
Levels:层次

层级应该不难理解;设计实际上指的是对项目计划以及方案的规划与设计;管理则十分重要,即WBS是为管理服务的。它的分解方式、元素定义无不服从于管理需要,因此大多数WBS不会超过10个层级。另外break down也可以用来说明其管理特性,这种“解构”方式明显具有管理色彩;组织时常常被忽略的特性,任何项目都不能脱离特定的项目组织形式。WBS能够提供很好的结构用于连接项目的OBS及其RAM矩阵的链接,尽管DoD与PMI在WBS/OBS之间哪一个会决定另一个持有不同观点。但是重要的是WBS可以用于反映项目组织的工作范围和工作组织方式。可交付成果是另一个重要的特性,经过大量的实践和学术讨论,应该按照可交付成果分解WBS结构。这样做可以避免按照活动分解结构导致的不确定性和非结构特征,并且易于结构化分解和面向项目目标的控制。

基于以上观点,WBS应该是项目管理的核心工具,而不应被PMI当作范围管理工具来定义。
总结
WBS

1、定义project scope必要的工作、产品(可交付成果)
2、层次化、结构化
3、全生命周期
4、提供计划与成本衔接的平台
5、提供包含所有干系人的RAM
6、为项目报告和分析提供便利
7、为检查项目绩效提供平台

WBS的编制
高层次的WBS可以被模板化或者在项目前期编制,而低层次的WBS则需随着项目的深入而不断完善。
STEP:
1、识别项目最终产品,通过高层次的WBS的scope document来确认WBS框架(定义高层次的sow (工作说明书)和应执行的程序。
2、定义主要的产品可交付成果。
3、将可交付成果放入适当的管理和整体控制层次,WBS元素与这些独立的可交付成果。
4、审核并调整WBS,直到team认为项目计划的可行性和成功性。

WBS必须注意的事项
1、每个WBS节点必须是单一、独立和可测量的可交付成果。
2、每个WBS节点必须能够包含某子WBS的所有范围。
3、每个子WBS只能与父WBS范围相容。
4、可交付成果应按其产生过程分解,如设计、采购、分包、建造,从高层到低层的WBS必须具有一定的逻辑关系。

工程项目管理服务范围参考

参考《客户/咨询工程师(单位)协议书指南》,
FIDIC阐述了TOR(term of reference)委托服务范围的定义和scope of
service的相关论述,并在其附录中提供了一个(基于合同文本的)咨询服务范围。其内容来自Mr. Michael Lewis 的文章:
perparing the conslutant’s terms of reference. 作为协议书(agreement)的立场和角度,FIDIC认为TOR(term of reference)以及scope of service应该针对服务的时间和成本性质进行分类,以便与费用支付条款对应。

这里引用FIDIC的咨询服务范围scope of service论述和TOR(term of reference)委托服务范围的定义,主要是为大家提供研究咨询工程师工程项目管理服务范围的范例。

典型的正常服务内容:
1 inception stage of project 项目开始阶段
2 project definition stage 项目定义阶段
3 alternative proposals 被选建议书
4 feasibility anlysis 可行性分析
5 detailed design 详细设计
6 tender document 招标文件
7 tending and award 招标和授标
8 construction supervision 施工管理
9 take-over and commissioning移交和联合调试
10 defects liability period 缺陷责任期

典型附加服务内容(主要指环境、卫生、安全方面的管理):略

—————————————————————————————————–

阶段

fidic的对于服务阶段划分, 采用了典型的自然时间顺序分类法.
即:投资前\详细规划\设计\采购\实施\运行. 值得注意的是上述阶段数量恰好是大多数项目管理实践和理论所推荐的6个.
这些理论认为阶段划分与可交付成果和项目执行的程序有关, 过多的划分项目阶段有可能拆分可交付成果和项目程序及其对应的任务,
使具有多重目标的可交付成果和项目程序被人为地割裂而不便于管理. 因此个人认为上述典型正常服务阶段应将2,3,4 合并, 使其更加具有管理特性.
当然从提供菜单式服务和给予费用支付的角度考虑划分项目阶段也是非常实际的方法.

职责

FIDIC将职责分为3类:任务、建议和培训。培训被fidic作为单独的职责单独阐述,而且在传统上咨询工程师有为客户提供运营/维护培训的义务,这被视为一种惯例。对于任务和建议,《白皮书指南》指出

职责习惯被分为任务和建议,任务含有管理提供的服务绩效性质,建议则必须履行相应的任务建议义务。

这一点提醒了我们:项目管理职责除了基本的管理职责之外,项目管理经理/组织还应该具有一定的技术管理职责。根据duties of pm的论述,目前在英国已知的工程项目管理案例中关于项目经理的争议主要是项目经理是否应作为专业咨询工程师或履行专业顾问而提供相关服务。大多数判例明显支持项目经理应具有相应的专业素质,以满足工程整体管理的需要。

根据《白皮书指南》的论述:

…仅负责运用其技能、谨慎而勤奋地履行其服务。这就是检验标准

这将是司法层面界定项目管理职责的绝对准绳。