WBS汇总

怎样有效制作WBS

既然没有WBS，就没有项目管理，如何制定正确的WBS就成为项目经理管理项目的核心了。每个项目管理比较成熟的公司，针对不同类型的项目都有一定的WBS的模版，供项目经理参考。对于复杂的大项目，IBM公司建议的WBS制作流程如下：

    1、制定工作产品清单（PL）。工作产品（Working Product）是项目需要产出的工作结果，可以是项目最终交付成果的组成部分，也可以是项目中间过程的产出结果。以软件开发为例，软件中的用户管理模块是最中软件产品的一部分，软件的需求分析文档是软床过程中的文件，都是软件开发这个项目的工作产品。工作产品有大有小，有的相互关联，有隶属的关系。列出工作产品清单的过程，可以是头脑风暴的方法，项目组共同完成。

    2、制定工作产品分解结构（PBS）。工作产品大大小小列出了很多，大型项目有几百项，几千项。工作这些工作产品的属性和关系，用结构化的方法组织这些工作产品，形成一个自顶向下的逐级细分的工作产品分解结构（PBS：Product Breakdown Structure）。这就是制造业内的产品物料表（BOM），说明一个产品有多少个零件组成。

    3、制定工作任务分解结构（WBS）。有了PBS，只要把获得工作产品的任务明确，就可用根据PBS的结构，得到WBS了。注意同样的PBS，可用有不同的WBS，因为获得同样工作产品的任务可以是不同的。例如软件开发中的用户管理模块，是PBS中的工作产品，对于到WBS中，可以是不同的任务，一种是采购一个用户管理模块，另一种可以是项目小组开发一个用户管理模块。

    4、制定组织分解结构（OBS）。WBS中的任务确定了，完成任务的责任人也就可以明确了。因此由WBS则可以形成整个项目的组织分解结构，由那些人来完成项目的任务，得到工作产品，并完成项目。

     其中的关键是分解的结构，PBS、WBS和OBS是同一个结构，只是从不同的角度来阐述这个结构。关于这个结构的分解方法，常用的有组件分解方法和过程分解方法。典型的组件方法就是制造业中把一个完整的产品，逐级分解到零件。典型的过程分解方法可以是软件开发从需求到设计、编码、测试的一个过程。项目分解中，这两种方法往往交替使用，其最终是把项目分解到一个个具体和细小的工作任务。

     结构化，是WBS的另一特点，是为了对任务进行管理。

 

有关WBS的三个基本问题

 

wbs（work breakdown structures）即工程项目工作分解结构。2000版的 pmbok guide 将其定义为“wbs编码是一组以可交付项目产品为导向的项目分解元素，它可以用以组织和定义整个项目范围内的所有工作内容。编码每下降一个层次就能更加细致的表现项目工作的细节 。” 这一定义体现了wbs（work breakdown structures）的几下几个特征：
1）它能代表项目的工作活动，并且这一项目工作活动能产生一个切实的结果。
2）它分布于一系列有序的层次结构之中
3）它能代表一项有目标和切实的结果，并且能作为一项可交付的项目成果。
wbs作为一项全面系统的分析工程项目的有效方法和项目管理的基础性工作，其概念已为项目管理者所熟悉，内容也容易理解，但在实际实施中却会遇到很多困难，甚至难以推行。造成wbs方法实现困难的基本原因笔者总结为以下三个涉及wbs本质思想和作用方面的问题。

Ø         wbs应该如何分解？

Ø         不同分解方法之间的矛盾如何解决？

Ø         如何理解wbs在项目代码体系中的地位？

1、 wbs应该如何分解？
关于wbs分解的方法，任何一本项目管理的书籍都有介绍，但大多都是经验性的。在实际应用中仍然会遇到问题：

第一，wbs到底应该分解到多细？很明显由于项目管理的自身特点，在项目计划阶段，没有人能够项目所涉及的所有事情都写出来，那么wbs要分解几层，到多细呢？如果分细不容易，那么就分粗一点吧。每个wbs都只有三层。前两层是概要，后一层是任务。这时，问题也出来了。有可能同一个项目责任人第一阶段与第二阶段所过的工作都针对于wbs上的一个叶节点。看起来他只是在做一个工作。这种也是不合理的。

第二，wbs究竟有什么用？wbs把工作按一定格式，分类来填写，难道只是用wbs提醒一下作者，还有某某事没有做？那wbs与备忘录有什么区别吗？如此看来，只记住几个方法是不能做好项目分解工作的，最重要的是要发现做wbs分解的本质意义所在。

wbs分解的实质思想之一是要体现在项目过程中的项目职责的落实和明确划分。这个思想可以解答上面出现的两种疑问。从工程项目管理的特点可以发现，工程项目实施过程相对松散灵活，但是在责权确认的认证流程上却是相当严谨的，每一项可交付的项目成果都有严格的多方层层确认过程，以保证其项目成果达到各方标准要求。“责任到人”是项目管理的核心，实际工作中项目管理最怕的就是“事情出了没人认账，没人负责”。要避免这个问题的出现，就要在每一层次wbs分解过程中都考虑到项目责任划分和归属，尽可能每一个最底层的节点都有唯一责任人（或部门）相对应，其分解的粒度是“可以分配,可以交付”。

2、不同分解方法之间的矛盾如何解决？
工程项目的分解就是把一个已知的工程项目的任务目标，工作范围和合同要求，按照工程项目的客观规律和系统原理分解成若干个便于管理的，相对独立但又相互联系的项目单元（工作任务），以其分解结果——项目单元作为项目的计划、管理控制和工程项目内部信息传递等一系列工程项目管理的对象。原理是容易理解的，但是实际中的问题是, 每个人的解决问题思路不同，同一个项目不同的人有很多种分类, 因为可以按照工作的流程分解,也可以按照系统论的方法进行结构上的分解。不同分解方法侧重点不同，相互之间难以统一，这就造成了wbs方法在理论上容易理解但是在实际中操作实施的难度。
针对工程建设项目，造成这一矛盾的最大原因是，我国工程建设项目推行的是合同实物清单报价体系，工程项目的费用支付和工程实物的完成情况是按照合同清单完成情况来核定的，而且我国还专门编定了一系列用于合同概预算的代码规范，例如在交通建设工程中就有1~900章详细的针对交通工程建设施工过程中每一项可能会涉及到的内容的编码规范。合同清单分解工程和wbs分解在思路上有本质不同：合同清单分解是按工程实物来划分，不考虑项目工作的联系和结构关系；而 wbs是以工艺流程来划分工程项目，每一个分解单元节点其要素上不仅包括本节点的定义，还包括与其他项目节点之间的逻辑关系，这些节点合在一起要能共同反映项目的工作结构。这种分解思想上的不同造成了wbs最底层的单元节点（一个工作包）与合同清单项目形成了多对多的关系，即某一个wbs工作包中包含若干个清单项目的部分内容，同时一个清单项目的内容也可能分布于不同的wbs工作任务包中，这个实际的问题给工程项目实施wbs带来困难。
解决这一矛盾首先要理解wbs方法的实质作用。wbs思想的最本质的作用之一：它是在实现工程项目的进度/费用的联合控制的基础，如果没有这个功能， wbs编码就没有任何特殊的意义，成了上提到的工作备忘录。如何进行工程项目的进度/费用的联合控制，这个涉及到赢得值原理（evc），具体使用方法暂不在本文介绍。
既然理解wbs本质作用，就可以针对问题提出对策。项目业主方在应用wbs方法的时候，不妨首先将其分为两个部分。
（一）上层部分可称做项目大项工作分解结构（project summary work breakdown structure 简称pswbs），把整个项目按级别划分为若干大项和单项，以便于进行管理和控制。

（二）wbs的下层部分可称做工程公司标准工作分解结构（contractor’s standard work breakdown structure,简称cswbs）。它是工程承建公司为实现各自项目费用/进度综合控制而建立的标准工作分解结构模式。
业主方应着重做好pswbs的划分工作，并与工程承建方共同协商做好cswbs的上几层的划分工作，而对于cswbs的底层的划分则可以交给工程承建方自己灵活处理。需要注意的是，工程承建方在编制cswbs的时候，较高层次cswbs最好按项目的生命周期各个阶段，各个里程碑控制点等原则来划分；而其底层也并不一定要细到合同清单项目，尽可能每个划分能有一个相对完整的项目交付成果。虽然这还是不能消除wbs单元（准确地说是cswbs层的分解单元）与对应的合同清单项目之间的多对多关系，但cswbs层的最终分解单元的层次关系是位于合同清单项目之上的，就可以避免两种分解编码同一层次出现而产生的混乱。同时，这样做既利于实物工作量和费用的衡量统计，也体现出了控制的作用。
3、如何理解wbs在项目代码体系中的地位作用？
wbs在很多工程项目管理教材中似乎被夸大了，似乎只要有了它项目管理就一定会产生高效率，高效益。而在实际的工程现场单位，wbs却常常被束之高阁，远没有合同概清单，文件编码系统等用得多。工程分解的工作成了工程工作备忘录，给工程管理人员带来了工作上的冗余。出现这种情况笔者认为是没有正确的认识 wbs在项目中的地位，没有把它放到项目中系统的看待其关联。
必须认识到wbs不是孤立存在的，它也不是一套大而全的可覆盖整个项目分解结构，很多信息，如概算、合同以及管理部门的组织结构等都不能在wbs中完整地表现。于是，作为wbs的补充，又出现了obs（组织分解结构），rbs（资源分解结构）以及文档图纸编码系统等等。而且，在项目信息编码与代码系统中 wbs要与其他的编码系统关联起来作用。比如，wbs和obs结合就可以进行职责配置：把项目工作分解结构wbs看作纵轴，组织分解结构obs为横轴，通过两者的整合确定部门或个人的工作任务和责任。同理，wbs还可以与其他编码体系结合体现其相对应的配置关系。
同时，wbs在不同阶段也有不同的侧重作用：
wbs初期的作用：确认项目范围。

项目计划时，根据wbs估算项目进度/成本。
项目执行时，检查项目是否按时按量完成；整体项目路径的调整；项目进度/费用的联合控制。
项目结束时，项目绩效衡量。
总的说来，wbs只是项目编码体系中的一部分，但却是重要的一部分，它可与其他编码体系配合体现不同的配置关系；它是贯穿项目管理全过程的一条主线，将项目管理各个阶段的工作串联起来，形成项目的集成管理。
4 小结
上面提到的三个问题，不是孤立的出现的，往往是在项目工作分解的过程中综合体现的，只是为了讨论的方便，笔者才把它们分解开来论述。最后，对这三个问题做一个整体的回顾。
1） wbs是要体现项目内容、职责的明确划分和责任落实。
2） wbs是实现工程项目的进度/费用联合控制的核心和基础。
3） 它是贯穿工程项目全过程的一条主线，能将计划、实施控制、业绩评价串联起来，形成项目的集成管理。
4） 真正使工程项目管理以项目任务（工作）为中心，更加强化目标管理方法。
wbs的使用方法，应注意如下原则问题：
1） 在wbs分解前要认真研究合同，了解项目的范围和任务。
2） wbs是把一个比较复杂的事情逐步分解为比较简单的过程, 让原来看起来不可控的一件事情变得清晰和可控, 分解的粒度是“可以分配,可以交付”。
3） 分解中要结合责任体系和任务，把握各责任人的管理深度。
4） wbs不应孤立存在，它可以和项目中其他的编码体系结合起来以体现出不同的管理意义。

 

 

如何建立有效的WBS结构？

        在项目管理过程中，项目规划和控制是非常重要的一个环节，良好的项目规划能同时对项目进度、质量和投资起到很好的控制作用，失败的项目规划则有可能带来混乱、失控甚至项目的最终失败。在项目规划的过程中，人们往往会求助于WBS（Work Breakdown Structure ）方法进行项目工作内容的分解。在此基础之上再进行资源的分配、进度计划并估计项目的成本。

        划分项目的WBS结构有许多方法，如按照专业划分、按照子系统、子工程划分、按照项目不同的阶段划分等，以上每一种方法度有其优缺点。一般情况下，确定项目的WBS结构需要组合以上几种方法进行，在WBS的不同层次使用不同的方法。那么，确定项目的WBS结构需要遵循何种方法和原则呢？         

        首先是按照专业划分项目，应当说这是一种最自然的划分方法，优点是容易让人接受，缺点是不易协调。比如，在进行地铁建设时，假定在WBS的顶层按照专业将建设分为土建和安装，并按照这种划分确定一个土建分项目经理和一个安装分项目经理。按照这种划分方法在画项目的网络图时就会出现一系列的土建作业和一系列的安装作业。因为某一个车站即包括土建工程又包括安装工程，这样在两组作业组之间就会出现非常复杂的关系，分项目经理之间也很难协调工作。

        按照系统划分方法容易界定项目范围，但有时候显得不那么直观。系统是人们在长期实践中确定的一种分类方法，其特点是系统与系统之间的联系往往是比较简单的，这种联系通常被称为系统界面或接口。正由于系统之间的界面比较清楚，所以按照系统对项目进行划分更容易界定子项目或子工程的范围，在项目实施过程中更容易控制结果。   

        按照项目的不同阶段划分WBS结构有利于项目管理者控制中间结果。对那些不确定性比较大的项目来说，项目最后的结果往往是未知的，控制项目的唯一方法就是控制中间结果的进度和质量，当然阶段的划分应该是可测量的。按照阶段划分项目有助于管理者在不同阶段控制中间成果同时不至于使项目管理者陷入到项目细节中去。不同的项目，其范围、性质可能都不一样，项目管理的目标和重点不尽相同，项目的WBS结构也并不一样。但无论对何种项目进行WBS划分，都必须兼顾WBS的三种不同层次的作用。划分项目的WBS结构还必须遵循一定的方法论。具体说来，划分项目的WBS结构必须遵循以下步骤：

        确定项目特性并确定WBS层次，比如项目的不确定有多大？项目的规模又是多大？
        确定项目管理的重点，为项目管理目标划分优先级别，比如，项目质量是放在第一位的，还是项目进度居于首位？
        针对项目管理目标的优先级别确定每级WBS划分方法确定WBS结构。

 

没有WBS，就没有项目管理

WBS（工作任务分解结构）是项目管理计划的基础，项目管理计划是项目管理的根本，项目管理的所有方面都直接与WBS相关。我在培训授课中，反复强调WBS的重要性，没有WBS，就没有项目管理。

    WBS是项目范围最准确的定义。制作WBS的前提是项目的目标，没有项目的目标，任务分解就没有了源头。如果项目的目标定义的不完整，所分解的任务也不全。WBS这个工具可用帮助项目经理从任务分解的角度，来验证项目的目标。其实这正是项目范围管理中，通过制定项目的WBS来准确定义项目范围的方法。WBS所分解的最末端的任务，是项目所有工作的总和。

     能否制作项目的WBS，又反映了项目组是否又能力和经验完成这个项目。只有你懂得和了解项目的工作，你才能够进行工作任务分解。如果不能进行工作任务分解，你也无法完成项目。跨国公司的知识管理中，包括总结不同项目的WBS。例如为中国某移动公司开发BOSS系统，如果我们能拿到为美国AT&T公司开发类似系统的WBS，可以很好地帮助我们进行项目的计划。

     每个WBS最末端的任务，都要完成一个结果，又叫工作产品，或工作包。整个项目计划的工作，就是确定有多少工作任务，定义每个任务完成的结果，然后确定由谁来完成？完成的标准是什么？什么时间完成？项目的成本有多少？。

     所以，项目经理要充分重视WBS，把握WBS。记住：没有WBS，就没有项目管理。

 

Work Breakdown Structure(WBS)

摘自《CMMI软硬件模式过程域的概述》

WBS是项目工作包的一个逻辑层，它是项目计划过程中不可缺少的工具。

 

WBS的目的

WBS可以帮助定义项目需求，并将这些需求划分出来归入到每个称为work package的功能区块里。

一个好的WBS可以帮助开发进度、预算和资源需求。

WBS是一个身分激活与责任分配的好工具

WBS图解实例

 

WBS例子小结

1. retail web site

2.项目管理

3.收集需求

4.分析设计

5.站点软件开发

 5.1 HTML设计与实现

 5.2后台软件

    5.2.1数据库建立

    5.2.2中间件开发

    5.2.3安全控制系统

    5.2.4目录引擎

    5.2.5事务处理

 5.3图形界面

 5.4content creation

6.测试发布

 

WBS类型

WBS流程：a.k.a Activity-oriented。如：需求管理、分析、设计、测试

 

项目管理有条件地使用：product WBS。a.k.a. Entity-oriented。如：功能引擎、接口系统、数据库。项目经理有条件地使用

Hybrid WBS:both above：详细请看“Melding Problem and Process”(合并问题与过程)。Rationale: processes produce products

 

WBS产品

 

WBS流程

 

WBS开发入门

自上而下地开发WBS，而不是自底向上

在一个WBS中不能超过5个级别

List of items can come from many sources