项目管理过程：制定工作分解结构

工作分解结构（Work Breakdown Structure），简称WBS，是归纳和定义项目范围最常用的一种方法。WBS是为了将项目分解成可以管理和控制的工作单元，从而可以更为容易且准确地确定它们的进度，成本以及质量要求。说得通俗一点，WBS就是将项目进行分解的一种方法。它使得项目目标从抽象的表述转化成了详细、明确且实在的工作内容。这些工作内容就变成了项目目标的具体体现。这样来说，WBS有3个主要目的：

l          制定WBS的过程中，更加深了对项目的认识和理解；

l         项目目标被分解成小颗粒度的、可被执行的任务，消除了项目的神秘感；

l         作为后续管理活动计划和控制的基础；

WBS的表述方法通常有3种。上面那种是树形图表示方法，其优点是直观，结构清晰。缺点是不易修改，对于大型项目来说图会变得很复杂。

第二种方法是气泡图表示法，如下图所示。其优点是添加修改比较容易，缺点是不直观，大项目会变得复杂。

 

图 - 2.    气泡图WBS表示法

第三种方法是最常用的表示方法，列表法。

列表法被广泛采用的主要原因是由于项目管理软件的普及。这类软件大都是利用列表法来创建WBS。我们也可以像上面一样对WBS中的每一项进行编码，其目的在于和后面的管理活动有一个很好的参照对应关系。当然这主要是针对大型项目来说，小项目也可以不做编码。

 

我们可以看到生成的WBS是一个典型的分层结构。最上面一层代表整个项目，通常称之为0层，向下逐级分解直到最底层

虽然WBS非常重要，但是如何生成一个高质量的WBS却并没有一个明确的方法。因为WBS往往是对项目产品所处工程技术领域的活动进行分解，所以分解的方法与其具体的应用领域高度相关。因此我们很难为所有项目制定一个统一的工作分解结构的要求。从另外一个角度来说，WBS事实上是项目管理活动和工程活动的接口点，两个部分的活动在WBS中得到了有效的关联。后续的项目管理活动都是针对WBS上的工程活动来进行的。

 

理论上来说，我们可以采用3种方法来创建WBS。这3种方法分别是：类比法，自上而下法，自下而上法。

类比法，顾名思义就是利用一个类似项目的WBS作为构建本项目WBS的起点。很多专业领域的项目都有约定俗成的WBS模板供参考。一个组织也可以从自己过去积累的项目中提炼和归纳出一个项目的通用WBS来作为今后项目的标准。

自上而下法，被认为是最常规的创建WBS的方法。它从项目最大的单位开始，逐步将它们分解成下一级的多个子项。这个过程就是不断增加级数，细化工作任务。一般对于经验丰富的项目经理和项目组来说，由于他们具备广泛的技术知识和整体的视角，这种方法是最好的。

自下而上法，则要让项目组人员一开始就尽可能地确定项目有关的各项具体任务，然后再将各项具体任务进行整合，并归总到一个整体活动或WBS的上一级内容当中。

 

这3种方法各有特点和其特定的适应性。一个高质量的工作分解结构对项目后续工作至关重要，下面我们以“自上而下法”为例来介绍一种推荐的分解方法，并且展示其中的要点。

步骤一：建立0层，也就是以整个项目作为分解的基础。对单个项目来说这并没有什么特别意义，但是对于大型项目来说，其中的子项目这样做便于项目分解结构的合并操作。

 

步骤二：建立项目的可交付成果列表。

 

步骤三：对每个可交付成果进行分解，得到细分的子可交付成果。这一过程可以循环做下去，直到适当的颗粒度为止。

 

以上我们得到了一个全部由名词组成的工作分解结构（WBS）。它代表了项目最后完成的所有产出物及其分解。

 

步骤四：对每个子成果进一步分解出完成它的所需活动。也就是说经历了这些活动，我们就可以构造一个子成果。

 

步骤五：某些子成果的简单相加就可以构成其上一级的父成果。但是某些父成果的完成不仅仅是简单需要这些子成果，还需要额外的活动来实施才能使那些子成果构成父成果。这些活动被称为横向关联活动。

 

横向关联活动的例子，如子产品的集成活动，验收活动等等。

最终我们就得到了一个完整的项目WBS。纵观整个WBS，我们可以看到以下一些特点：

 

第一，项目分解从可交付结果开始进行逐步分解，这样看起来整个WBS的上半部分都是名词。所有这些工作结果就构成了项目的产品范围。它意味着项目最终或者进行中间都会产生哪些工作产品。这些产品最终会转化成交付给客户的交付结果。

这种分解方式体现了以客户为中心的原则。因为项目实施方和项目最终交付客户两者之间对待项目的关注点是不一样。前者关心如何完成项目，后者关心完成的是什么，是不是我期望的。所以表现来看，前者在意实施活动，后者在意实施结果。现实中大多数项目的WBS是由项目实施方来完成的，所以我们经常发现WBS是以实施活动为主线进行的分解。这一方面体现了实施方作为实施领域的专家对活动细节的理解，但同时也反映了其对目标效率因素的关注，而可能会对效果的忽视。至少客户方看到这样的WBS无法理解项目结束后他可以得到什么。这也是我们今天很多项目出现问题的根源之一。因为客户方关心我能得到什么，而实施方只关心我该做什么。需要消除这种差异才能避免做所谓“有效率没效果”的事情。所以这种WBS分解方式特别强调了以交付结果为核心，在某种程度上它是从客户的期望为上层目标，然后逐步向下分解。这样做可以有效避免前述的问题。

 

第二，WBS的叶子节点几乎都是动词，也就是活动。它表明了所有这些活动的完成，就代表了项目的全部工作。这些活动就构成了项目的工作范围。后续的项目计划工作主要是围绕着如何为这些活动分配相应的资源，以及如何优化资源的分配来提高项目实施效率。

 

第三，在进行分解的过程中，存在3种构成模式：

第一种：父节点是名词，子节点全部由名词构成。

 

第二种：父节点是名词，子节点全部由动词构成。

 

第三种：父节点是名词，子节点由名词和动词共同构成。

 

 

虽然上面给出一种普适WBS分解方法，但创建一个高质量的WBS并不容易，往往需要反复多次进行。同时，实现一个好的WBS所需要的技能却并不是管理技能，而是需要工程领域方面的专业技能。也就是说工作分解结构的质量和完成这项工作的人对该项目所处工程技术领域的理解和经验高度相关。有时甚至可以说，WBS的创建甚至是一项创造性工作。它凝结了项目实施人员对项目范围的充分理解，也包含了大量的来自于过去实践的经验总结。所以如果一个组织实施的相类似项目很多，完全应该总结出一个WBS模板为所有项目制定标准的计划基础。这个模板实际上是企业过去经验的总结，代表了企业的核心能力。所以前述的3种构建WBS的方法中，最有价值的是类比法。

 

以一些基本原则可以帮助确定一个WBS的基本要求：

l         WBS中的产品范围应该包含你所有的中间和最终工作产品；

l         WBS中的工作范围应该包含你所有的项目任务和活动。那些没有被包含在WBS中的活动和任务都不会被分配相应的资源，其实施也无法得到保证；

l         分解的颗粒度大小由项目特征和管理幅度来决定，没有一定的规则。一般来说，最下层的活动从1人天到1人周的大小都合理。太小了管理成本太高，太大了则不宜于有效管理；

l          在WBS的某一层节点上，可以分配相应的责任人，建立责任分配矩阵。意味着其下所有结果或者活动由该责任人负责；

l          在WBS的每一个节点上，可以建立帐目编码（Code of Accounts）系统，来唯一标识和确定每一项工作单元。一方面可以提高沟通的效率和准确度，从而减少管理成本；另一方面这个编码可以和进度及成本管理产生对应关系，特别有利于对项目进行非常准确而详细的成本预算及核算管理。虽然这可能更有利于大项目，但养成这种习惯是很有效的；

 

项目的工作分解结构确定下来后，将作为很多后续工作的基础：

l          项目的时间资源被具体分配到WBS的工作单元上；

l          项目的资源投入和成本计划都被分配到WBS的工作单元上；

l         项目的范围变更必须基于WBS进行；