如何运用WBS真正读透一本书

2016-07-09胡晶晶

项目管理评论 2016年5期

胡晶晶

作为一名项目经理，工作分解结构（WBS）是我日常使用的工具。通过《项目管理评论》这一平台，我有幸参加了由中国电力出版社举办的《工作分解结构实操秘诀（第2版）》新书分享活动。活动后，我开始反思平日里对于这一常见又易被忽视的工具的应用情况，并找出正在跟进的一个项目，本着阅读指导实践的想法，查找优化WBS的方案。

在翻开新鲜出炉的《工作分解结构实操秘诀（第2版）》之前，我结合实际工作情景，列出来以下几个亟待解答的问题。

场景一：项目的工作分解结构和项目集的工作分解结构概念混淆。更进一步说，这种混淆可能造成项目经理和项目集经理之间工作内容出现重叠，浪费资源。①项目的工作分解结构与项目集的工作分解结构应怎样区分？

场景二：样本项目工作分解结构的制定过程如下：通过对业务、技术和项目管理三个方面进行需求发现会议，形成需求发现报告，并获得客户签署。在客户签署的基础上，项目经理开发工作分解结构。整个项目范围被分解为项目启动、需求发现、配置、测试、上线和项目收尾几个阶段。每一阶段为第一层级的工作分解结构。第二层级是业务顾问根据项目需求访谈成果（项目范围）抽象出的业务模块。每一阶段都根据业务模块进行分解。技术工作经过技术顾问评估，穿拆在对应的项目阶段中。针对每一阶段，项目进度计划中都罗列出了对应的可交付成果。这个过程和当中的步骤是否还可优化？即②需要了解项目范围与工作分解结构之间存在怎样的关联？④样本项目所使用的工作分解结构是否完整？⑧样本项目的工作分解结构是否还有更优的组织方式？

场景三：样本项目定义项目进度计划的过程是先通过会议，由业务顾问负责人、技术顾问负责人和项目管理团队共同定义工作分解结构。经过多次复审，形成最终版本的工作分解结构。通过对每一项活动定义时间，汇总形成项目进度计划。在过程中，实施团队会与客户进行各种形式的沟通，力求沟通充分。内部形成一致意见的项目进度计划最终经由客户复审和批准。由于研发工作是由研发部门而非交付部门安排，在项目进度计划中根据研发部门的输入，描述了软件发布时间，没有进行进一步的分解。这个过程和当中的步骤是否还可优化？即③工作分解结构对项目进度计划有怎样的作用？⑨对于由研发部门负责的工作，怎样通过优化工作分解结构来更好地控制项目进度？

场景四：工作分解结构在实际工作中依据渐进明细的原则滚动更新。需要更新的内容有可能是对某些任务进行更加细化的分解，也有可能对已经批准的范围进行调整。而由于项目进度计划经过严格的审批，甲乙双方对于更新已有的项目计划心有顾虑。有时在决策是否调整进度计划的过程中，事实已经发生。项目经理再根据事实的发生被动更新项目计划。⑤项目进度计划是经过签字批准的项目关键文件。工作分解结构作为一个关键输入，对它进行更新时，有哪些注意事项？

场景五：经过上述评估，样本项目的工作分解结构大体符合书中提出的要求。但是，如何对工作分解结构的好坏做出评价呢？即⑥当前所使用的工作分解结构好不好？可以怎样改进？

除上述5个场景中涉及的问题外，我还总结出另外两个日常工作中遇到的问题：⑦在面向不同的利益相关方时，怎样更好地展示工作分解结构，使利益相关方更好地了解我想表达的内容，从而支持我的工作？⑩如何在虚拟团队背景下优化工作分解结构的使用？

受到活动中汪小金老师的启发，我将《工作分解结构实操秘诀》（第2版）使用分解技术，用思维导图的方式配合理解。这张思维导图并不是一份完整的工作分解结构，我只以目录为脉络，分解到第二层级。根据不同的侧重点，可能您会有一张不同的思维导图（扫描文末二维码，查看思维导图）。

通过拆解阅读，在书中的相应版块找到了自己想要解决问题的答案。书中“第1章 1.2 什么是项目集WBS和项目组合WBS”，解答了我的第一个疑惑。项目层面的WBS与项目集或项目组合层面的WBS的相同点在于基本概念相同，工具和技术相同。而所包含的内容和责任人不同。回到案例，相同之处暂且不言，就不同之处，项目集经理负责项目之间的边界和关系界定。项目经理负责确定项目内部的工作。

书中“第9章把WBS应用于进度和成本管理”一章提到了将WBS与进度计划联系起来的必要性：“确保WBS中所定义的全部工作都有对应的计划，都将得到执行。确保只执行经过批准的工作，范围之外的任何工作都必须不做。”样本项目中制定项目进度计划的过程是科学的。

解答了心中的疑惑，我开始尝试反思实际编制的WBS是否完美，并结合项目的具体信息做出了修改。这是一个IT管理软件的产品实施项目。项目范围包括产品配置和研发，整个业务范围涉及承保、理赔、账单管理、财务结算、预估业务等多个模块。从实施方的角度讲，项目实施周期为3年。合同下包含财产险和寿险两个独立的项目，这两个项目作为项目集来统一管理。两个项目的实施周期存在一定时间上的重叠，并且实施团队核心人员为同一批人员。实施团队和研发中心在实施方的组织中是并行存在的两个团队。项目组织架构如图1所示。

在编制样本项目的工作分解结构之前，实施团队与客户团队组织了业务、技术和项目管理三方面的访谈。根据访谈报告，项目经理组织会议。由首席业务顾问、首席技术顾问和项目管理团队共同定义工作分解结构。经过多次复审，形成最终的工作分解结构，如表1所示。通过对每一项活动定义时间，汇总形成项目进度计划。在过程中，实施团队会与客户进行各种形式的沟通。力求沟通充分。在提交客户审批之前，工作分解结构经过公司内部的项目指导委员会审批。内部正式批准的版本，最终经由客户评审和批准。就研发工作而言，在项目计划中根据研发中心的输入，描述了软件的发布时间。而对于每一次发布的内容未在工作分解结构中进行更加细致的定义和追踪。

但更为重要的是通过这次检查，我识别到了样本项目的WBS值得优化之处。研发中心隶属于项目执行团队之外，而研发中心每次软件包的工作分解结构没有集成到实施项目的WBS之内。实践证明，这给客户方的利益相关方造成了研发中心工作不可控的错觉，造成了不必要的担心。但是通过读书后我发现，样本案例中的研发工作遵从标准的敏捷管理思路。每一次版本发布作为一个Sprint。书中“第12章在敏捷项目中使用WBS” 从管理项目范围、管理产品范围和如何创建WBS三个方面解释了敏捷方法（产品管理）与《PMBOK？指南》（项目管理）的区别。经过思考，如果将每一次版本发布的内容根据功能模块进行进一步的分解，并展示在项目进度计划中，这将是对当前项目进度计划的优化，更加有利于控制项目进度，获得更高的客户满意度。这让我对样本项目的成功更有信心。因此，我将工作分解结构中的下述内容作了修改，如图2所示。

这样一来，将开发工作视同为由项目组向研发中心（R&D）的外包项目。整合研发中心的信息，将开发工作的WBS汇总到整个项目的WBS中，并尽可能细化具体任务，完善项目进度计划。在工作分解结构的第四层，展示了更加具体的分解，如功能一、功能二、功能三。更新后的工作分解结构更加完整。对于客户所关心的新功能发布一目了然。在实战中，客户对实施方的整体满意度也因此而提升了。

在阅读《工作分解结构实操秘诀》的过程中，我对如何判断工作分解结构的好坏有了更加结构化的认识。书中“第5章有助于掌握WBS的关键问题”中“5.10 什么是判断WBS好坏的标准”是很好的总结。我发现书中的十六条标准修改后完全可以作为用来判断和检验WBS是否能进一步优化的标准，甚至能够用作检查表。这十六条标准分别是：

（1）它以可交付成果为导向。

（2）它定义了项目范围。

（3）它向所有利益相关方明确了项目工作。

（4）它涵盖了100%的工作。

（5）它包含所有可交付成果，包括项目管理。

（6）每个下级分解层级都包含了上级层级的100%工作。

（7）工作包有利于识别为交付工作包所需开展的任务。

（8）它以图形、文本或表格来呈现对项目范围的逐层分解。

（9）WBS组建用名词或形容词命名。

（10）它是全部可交付成果的层级结构。

（11）每个组件都有一个WBS标识（编码）。

（12）它至少有两层，其中至少有一个分解层。