怎样有效制作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提醒一下作者,还有某某事没有做?那</