WBS分解指南

WBS有效的工作分解结构 引言 本文目的是为了满足对WBS概念及应用的全面、系统和实用性阐述的长期需要。旨在帮助项目经理和项目规划者改善项目结构，有效的启动项目，并在项目的全过程中都把WBS作为规划、控制和沟通的关键工具使用。 本书体现了多年来WBS、新项目的范围界定和计划的发展经历，介绍了已经被大家普遍认可的WBS及其在应用中的一些概念，其中许多更详尽的概念是我提出的。此外还提供了许多例子。 在项目管理中，WBS不是一个新概念，但是它经常被误解，没有得到正确使用，达不到其最大的有效性。像做任何计划一样，WBS的使用也需要训练与思考。开始做一项工作，看上去通常比做一个工作计划要简单些。 本书共分为六章： · 第一章，WBS的概念，定义了主题，简单介绍了WBS概念的历史，定义了一些术语，并明确了在项目管理过程中WBS概念的作用。 · 第二章，WBS逻辑基础，讨论了在有效的WBS开发中应考虑的各个方面的问题。 · 第三章，生命期计划：项目群和阶段，提出每一个生命期阶段都是一个单独的、有自己的WBS的项目。 · 第四章，项目运营中的WBS，阐述了PMBOK®①九大领域中的每一部分与WBS的关系及其应用。 · 第五章，WBS的例子与描述。包括对几个不同类型项目的WBS例子的描述，以及第二章中的WBS基本原理的普遍应用的方法。 · 第六章，WBS原理、步骤和审查表。包括对WBS原理以及推荐给项目经理用来开发项目的WBS的一系列特定的、注重实效的步骤的总结。 · PMBOK®是美国项目管理协会的商标，该商标在美国和其他一些国家注册。 第 章 WBS概论 本章提供了有关WBS的概念、背景以及WBS在项目管理过程中的地位的一些信息。 项目问题和解决 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 开始一个新的项目就像是要开始写一本书，你已经有了想要写些什么的思路，但还不确定怎样开始。就像许多项目计划者和经理们一样，许多作者发现写大纲通常是一种开始写作的最有效的方法。 大纲既是一种组织材料的方法也是一个写作计划。写大纲有许多方法，尤其是有一种基于研究的方法。一般地，规划一个调查研究或数据收集，并决定每一章要讨论的内容及附录是十分必要的。此外，起草章节、收集一批专家的关键评论、以及与评审证明和出版文件有关的实际步骤等，都是必要的。第5章中有一个简单的以WBS形式写书的大纲的例子。 有这样一个被经常使用的比喻，这是一个古老的问题，问：“你怎样吃掉一头大象？”回答当然是：“一次吃一口。”所以，准备大纲的第一步是对“每一口”进行定义和分类。“每一口”都是很重要的，因为有效的工作是一步一步完成的。对一个项目来说，头脑风暴法能够帮助我们自下而上的定义“每一口咬什么”的活动，或者采用自上而下的“分解”过程将一个项目（或整头大象）细分为几个主要部分（如图1-1所示）。无论用任何方法，目的都是开发一种项目所要进行的工作分解结构。 图1-1 大象分解结构图 显然，大象的每个部分还可以继续分解（细分）。例如，头部可以分解为脸、耳朵、象牙、象鼻，四条腿也可以分别独立识别，身体的各个部位可被确定；尾巴和尾巴上的毛也可以分别确定。项目的WBS结构遵从同一概念。WBS是工作的一个总结，而不是工作本身，工作是构成项目的许多活动的总合。 一个WBS既可以从一个非正式的活动列表开始，也可以从一种非常结构化的方法着手，这取决于项目及其约束，并且它可以在计划者希望结束的地方结束。WBS的目标就是建立一个有用的框架，以帮助定义和组织工作，然后开始做这项工作。 例如，在写书的大纲中，几乎总是会发生一些意想不到的事情，这些事情超出了大纲编写过程的规则。首先，要定好本书内容的边界，准备大纲时要让作者定义主题、各部分和各章节。开发项目的WBS是同样的事情。但人们经常会过多的考虑其假设和限制，而不是直接关注项目大纲。 建立一个WBS分为4个步骤： ① 确定项目目标，着重于项目产生的产品、服务以及提供给客户的结果。 ② 准确确认项目所产生的产品、服务或提供给客户的结果（可交付成果或最终产品）。 ③ 识别项目中的其他工作领域以确保覆盖100%的工作，识别若干可交付成果的领域、描述中间输出或可交付成果。 ④ 进一步细分步骤②和③的每一项，使其形成顺序的逻辑子分组，直到工作要素的复杂性和成本花费成为可计划和可控制的管理单元（工作包）。 关键定义 本书中经常使用的大多数项目管理术语都是在项目管理领域通用的。下面这些定义是项目管理协会（PMI）在PMBOK®中的定义。 活动（Activity）：在项目过程中实施的一项工作的组成部分，在标识描述中包含一个表示其动作的动词。一个活动通常有一个期望的持续时间、期望成本、期望资源需求。活动经常被细分为任务。 可交付成果（Deliverable）：任何 一项可以测量的、有形的、可证实的结果或可见效果，或者一件为完成整个部分的项目所必须产出的制品。当用于外部可交付成果时含义更加狭窄，必须是经项目发起人或客户接受的可交付成果。 最终产品（End Item）：通常指交付顾客或者构成项目经理对顾客承诺的一部分的硬件、服务、装备、设施、数据等。 组织分解结构（Organizational Breakdown Structure）：能够将工作包与项目组织单元联系起来的对组织安排的一种描述。 项目群（Program）：以一种协作的方式管理的一组相关的项目。项目群通常包括正在进行的工作元素。 项目（Project）：为了创造独一无二的产品、服务或结果而进行的一次性工作。 责任分配矩阵（Responsibility Assignment Matrix）：一种将项目组织结构与WBS联系起来的结构。可帮助确保项目工作范围中的每一个元素被分配到某个责任人。 子项目(Subproject)：PMBOK®将其定义为整个项目中的一个较小的部分。通常，一个子项目是能够作为半独立的项目元素来管理的一个WBS元素，可由一个人或一个组织负责。 任务(Task)：工作的一般内容，它没有被包括在WBS中，但可能是某项工作进一步分解的组成部分，这种分解是由对该项工作负责的个人来做的。其用来描述项目最底层的工作。 WBS字典（WBS Dictionary）：用来描述在每一个WBS元素中执行的工作的文档。 WBS元素（WBS Element）：WBS中的一个条目，在任何一级都可以存在，用一个名词或者名词加形容词来描述。 工作分解结构（Work Breakdown Sturcture）：一种面向可交付成果的项目元素分组，这个分组组织并定义了全部的项目工作范围。每下降一级都表示一个更加详细的项目工作的定义。 工作包（Work Package）：WBS中最低级的工作，为定义活动或特定的向个人和组织分配责任提供了逻辑基础。工作包也指要求完成的一项具体工作组成部分或过程，如一个报告、一个 设计 领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计 或一个文档的全部需求或其中的一部分、一个硬件或一项服务。 在项目的早期阶段，开发一个仅有二到三级的WBS是可行的，因为详细的工作可能还没有被定义。然而，随着项目进入项目定义阶段或者计划阶段，计划就变的详细多了。这时，WBS就能够被逐级细分到更低级别。在我们前面所说的“吃大象”或者进行项目工作中，最终的子项目或工作包就是“一口”。这个细分化过程的产品就是完成了的WBS。 · 第1步 定义项目目标：建造一个能停放一辆车的车库，并美化现有场地，车库里外都应该有灯，还有水管。 · 第2步 确定特定的产品、服务或结果（可交付成果或最终产品）：车库和美化的场地。 · 第3步 确定其他的工作范围以确保100%的工作被识别：这是一个需要完成如下事情的项目管理职能，如编制施工计划、获得许可、签定分包合同。 至此，该项目的WBS如图1-2所示。第一级是总项目，第二级是进一步分解成的最终产品（车库和美化场地）以及与项目相关的或辅助性的工作（如项目管理）。项目的总范围由第二级的三个部分工作之和来表示。 一级 二级 · 第4步 进一步细分元素，直到适于计划和控制的层级：图1-3表示每个二级元素的下一级细分。 有些三级元素还可以进一步分解。表1-1表示一个到达工作包 表格中的数据都是字典必须包含内容。然而在一些组织的实际应用中会收集到更多的数据，诸如预算数据、计划数据、交付数据、挣得值管理数据，都可能是特定的WBS元素中的一部分。这些数据对工作包是有用的，但是对总结或更高级的元素可能用不到。 下面是一个对一个名为“培训”的WBS的典型WBS字典描述，可能会在第二级中出现。 WBS1.4培训。这个元素包含可交付成果的培训服务、手册、附件、培训帮助和培训设备，用来指导客户最大效率地学习怎样操作和维护系统。这个元素包括所有与设计、开发、可交付成果、可交付的培训设备的生产，以及可交付成果列表中定义的师生指导和可交付培训服务。 WBS字典的优势之一是用文字描述每个元素的工作 规范 编程规范下载gsp规范下载钢格栅规范下载警徽规范下载建设厅规范下载 。简短、总结性的WBS元素描述经常是模糊的或容易引起误解的，而WBS字典能够消除可能产生的任何误解。 有些计划人员发现使用字典中已实施活动的术语来描述WBS元素十分有效。其优点是不需要WBS字典也能够明确元素中的工作。然而，活动术语的使用也会引起混乱，并可能会失去一个基于名词——产品WBS所需要的规范。使用基于活动的WBS元素描述的另一个缺点是很难评估是否违背了百分之百规则。 用来描述每个元素工作的WBS字典能够方便的转变为对项目或子项目的综合性工作陈述，字典的作者可以确信WBS字典涉及所有要执行的工作。因此，全部项目范围也就被清楚和易于理解地定义了。 工作包 WBS的最低级被定义为“工作包”级，这一级为定义活动或者 给特定的人或组织分配任务提供了一个逻辑基础。WBS结构的主要目的就是确保项目中要执行的所有工作都被确定。WBS只分解到工作包一级，但是，如果超出WBS的范围，工作就必须被细分到可以充分实施计划和控制的点。在工作包下面的活动级（作业级）是网络计划执行的层次。每一个活动都有特定的和预期的持续时间、资源、成本、绩效要求和产出，这些都被概括在工作包中。（这将在“使用WBS开发活动”部分详细讨论。）每一个工作包都应该有一个指定的个人或组织对所执行的工作负责。 工作包是一个特定组织所执行的活动的集合，通常一个特殊的WBS元素有一个特定的成本帐户号，这可能是一个大的分包工作包。工作授权表中要确定预算水平、起始和终止日期、责任组织和要执行的工作的简要陈述，工作授权表及其等价文件通常用来批准工作包中要执行的工作。图2-9说明了项目X的WBS、工作包以及活动之间的关系。 一级 二级 三级 四级： 工作包 TEST 五级：在计划表或网络图中 测试工作包的活动 图2-9 WBS、工作包和活动之间的关系 由于很难收集到实际成本数据，所以在活动级控制成本通常不太实际。然而，通常可以在实际成本数据能够累计的工作包级或更高级控制成本。成本帐户是一个术语，用来描绘实际成本能够被累计并能够与预算成本比较的管理控制点。这可以参考挣得值管理系统中的挣得值BCWS。 适当的细节水平 WBS中的内容需要有多详细？答案有很多。集中于产品的WBS部分通常分解到横向关联元素以下的更低级。雷泽（Raz）和格洛伯森（Globerson）已经开发出一系列用来判断WBS分解程度的 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 。这些标准的修订版本如表2-3所示。 表2-3 适当的细节水平 工作包应该被进一步分解吗 下述问题的肯定回答越多，进一步分解工作包的理由就越充分 是/否 问题 有必要提高估计成本和工期的精确性吗 是不是不只一人对工作内容负责 有必要准确的知道工作包中活动的时间安排吗 在工作包的活动中需要成本支出吗 中间活动和其他工作包之间有任何关联吗 在执行工作过程中的工作元素有任何重要时间的中断吗 过一定时间工作包中的资源需求变化吗 工作元素中的中间支付的前提有区别吗 在完成整个工作包之前有合适的可接受的准则吗 工作包中要执行的一部分工作能够被作为一个单元安排吗 有需要集中精力于一部分工作包的风险吗？这些工作包需要进一步的分解以使风险分散 工作包能够被清楚和完全地理解以满足不同的利益相关者吗 资料 新概念英语资料下载李居明饿命改运学pdf成本会计期末资料社会工作导论资料工程结算所需资料清单 来源：T Raz, S Globerson. Effective Sizing and Content Definition of Work Packages. Project Management Journal, 1998(9): 17-23 总之，工作包应该是离散的、容易定义和管理的，并且由活动来计划工作内容和安排进度。 用WBS导出活动 下面部分描述用于导出活动的具体过程方法和定义活动的一系列标准。 WBS和活动 在确保项目的全部范围得到关注之后，WBS的主要功能是帮助确认和定义需要执行的项目活动。在第1章中，WBS被描述为基于名词的分解结构。表示执行行为的活动是基于动词的。这在图2-9中有所反映。WBS为甘特图和网络计划提供了大纲结构，此外，它还概括要执行的工作。活动则描述执行工作所必需的行为，这在假设的“时间分享系统”项目（见表2-4）中有所说明。注意在这个表中，WBS元素是粗体字，并且以形容词/名词形式表达，活动是斜体字，并且以动词/形容词/名词形式表达。 这个例子阐述了WBS与网络计划和进度计划之间的关系。单独的活动被连接到网络优先的项目管理软件中，在屏幕上以甘特图的形式出现，并可被标准打印。 WBS的排列方式能够使计划易于理解和使用。表2-4中把项目管理元素放在WBS的顶端。如果在WBS的第二级有任何过程流，它就应该在WBS中从左到右流动或者在大纲中从上到下流动，结果是计划表被更加自然地显示。 在计划安排中有一个有用的方法，是在项目管理中为项目的开始和结束事件建立一个特殊的工作包。在工作包中包括活动的两个端点时间，以判断项目的开始和结束。 表2-4 WBS元素和活动的例子 时间共享系统（TSS）项目 1．0 项目管理 1．1 项目开始和结束 1．1．1 开始 1．1．2 完工 1．2 项目会议 1．2．1 准备启动会议 1．2．2 开始启动会议 1．3 项目报告 1．3．1 准备中期进展报告 1．3．2 交付中期进展报告 2．0 TSS需求说明书 2．1 初始TSS需求说明书 2．1．1 编写初始TSS需求说明书 2，1，2 审查初始TSS需求说明书 2．1．3 更新初始TSS需求说明书 2．2 最终的TSS需求说明书 2．2．1 审查最终TSS需求说明书 2．2．2 批复最终TSS需求说明书 3．0 TSS设计说明书 3．1 初始TSS设计说明书 3．1．1 编写初始TSS设计说明书 3．1．2 审查初始TSS设计说明书 3．1．3 更新初始TSS设计说明书 3．2 最终TSS设计说明书 3．2．1 审查最终TSS设计说明书 3．2．2 批复最终TSS设计说明书 4．0 TSS软件 4．1 TSS模块1 4．1．1 TSS模块1编码 4．1．2 TSS模块1单元测试 4．2 TSS模块2 4．2．1 TSS模块2编码 4．2．2 TSS模块2单元测试 4．3 集成模块 4．3．1 集成模块系统测试 4．3．2 完成TSS软件 资料来源：Cindy Berg , Kim Colenso . Work Break Sturcture Standard Project-WBS vs . Activities. PM Network . 2000(4): 71 在图2-10中，表2-4中的数据被输入到MS Project 98中，以举例说明WBS作为一个大纲在计划表中的应用。如果遵循百分之百规则，WBS被输入到项目管理软件中，可以很容易、快捷的识别项目的所有活动并在逻辑计划表中排列。活动是项目的基本模块。如前所说，需要说明WBS的目的是确保所有的这些基础构件被识别。 活动定义 经验表明，定义活动或任务不象看上去那么容易。经常会有导致沟通问题的不适当的定义和不好的计划。活动的定义十分重要，因为活动是项目计划和控制的基础构件。在PMBOK®中，活动被定义为在项目过程中执行工作的一个元素。一个活动通常有一个期望的持续时间、成本和资源需求。这个定义也应该体现对要求执行的工作唯一的责任人或责任组织的描述。 尽管在项目计划中很少在具体层级上明确列出活动，活动也有绩效要求和具体的输出或结果。如果活动是模糊不清的，就需要重新定义。 一个最重要的考虑是：如果活动不在计划中，它将可能不被执行。事实上，制定书面计划的目的是要保证与适当的利益相关者（包括那些对紧前或紧后活动的负责的人和对执行活动负责的人）进行沟通。 如果仔细查看表2-4和图2-10中时间共享（TSS）项目中已识别的活动，可能就会看到如何满足准则。TSS项目的需求说明书和设计说明书都被很好的定义，涉及的活动也都很明确。输出是有形的——文档中已经对一些事情作出了规定。 软件编码的活动被类似地定义。输出包括软件代码、可能的 图2-10 时间共享系统（TSS）项目[Project软件图表] 硬拷贝以及数码格式，这取决于组织的日常惯例。单元测试通常由质量控制组织提供的文档来定义，或者由一些人提供的类似的独立职能来定义。 活动的特点 · 把工作用动词、形容词和名词的形式进行描述——即要执行的活动。 · 一个人或组织对工作负责——分配到一项活动中的可能不止有一种资源，但只有一个人负责可交付成果输出。如果不是这样，该工作就需要进一步分解或者需要澄清连带责任。 · 定义开始和结束点——首先必须有一个确定的紧前活动或事件已经完成或者是有一个活动计划开始的确定日期；计划的结束日期是基于估计的持续时间、持续时间基准或活动的计划持续时间。 · 完工时通常有一个有形的输出或产品——项目偶尔有一些没有明确定义输出的平衡工作量的活动或支持活动，然而，主要的活动有已定义并可测量的输出。活动结束的那一点由输出产品（可用于紧后活动的输入）的可获得性所决定。 · 逻辑上符合现有的WBS元素的要求——如果不符合，活动就不是项目的一部分，WBS就需要修改，或者是活动模糊不清需要重新定义。 · 活动有一定的尺度和持续时间，能够进行控制——时间太长的活动在问题产生时不能提供足够的时间进行校正；时间太短的活动又使控制成本比较昂贵。科兹纳（Kerzner）建议，活动最好是80小时并少于2到4周；然而，这对非常大的项目不太可能。 · 能够收集活动的实际进度状态数据——用于控制进度，开始点和结束点必须被充分定义，以保证活动的开始点和结束点被报告。 · 能够收集活动或活动包含的工作包的实际成本（人——工时）数据——用于成本控制或资源控制，实际成本数据或资源的实际消费能够被收集，当然，如果不需要跟踪实际的花费，这项原则就可被忽略。 · 执行活动所必须的劳动和成本能够被估计——在计划阶段必须能够确定资源需求。 · 活动的输出已知并且可被识别——输出经常是几页纸或其他活动已经完成的确实的证明。 · 活动代表支持项目目标实现的一项重要的工作——不包括琐碎的或偶然性的活动。 · 零持续时间的活动是里程碑或重要事件，代表了另一项活动的开始或结束——它们应该贯穿于项目的全过程，也应该包括在关键的活动或活动群完成的标志中。 输入与输出——资源与可交付成果 理解项目的输入与输出产品之间的差异是很重要的。输出的概念或者面向可交付成果的结构的概念很难掌握。 输入与输出元素 数年来，计划要用实施项目的组织和工作所需资源（即输入）的语言来编制。WBS的使用要求一个不同的视角——注重输出。输出是将要生产的产品、服务或者结果。项目输入包括执行工作所必需的劳动和成本资源。当然，它们都是重要的，但是仅从这个视角理解项目计划会丢失主要的工作元素。典型的输入包括如表2-5所示的成本元素。 表2-5 典型的项目输入 · 计算机 · 施工劳动力（电工、木匠、油漆工、屋顶工等） · 数据处理支持 · 工程人员（绘图员、机械工程师、结构工程师、质量工程师、水力工程师、测试工程师等） · 设备租用 · 绘图员 · 单独的资源名称 · 制造劳动力（机械师、组装工、焊工、机修工、维护工等） · 办公室支持 · 组织名称 · 生产控制劳动力 · 编程劳动力 · 购买部件 · 质量控制 · 原材料 · 秘书支持 · 监督 · 电话与传真 · 加工工程劳动力 · 差旅 · 公共事业费 · 文书 在项目计划编制中不能忽视这些元素，要将这些输入分配到单个活动中。大多数流行的项目管理软件程序都包含项目输入清单和成本的资源表。这些元素从资源表中被挑选出来，分配到单独的活动中，用以进行成本估算和资源计划。此外，计划编制过程中还经常需要价格提案，这些价格会采用类似（资源表）成本结构再加上管理费率的方式计算。然而，WBS概念的主要目的是开发一个编制计划的框架，以保证所有的工作被识别。一旦完成了WBS开发，资源和成本元素的分配也能够在工作包或活动级完成。然后就可以安排工作的进度，并根据输入或（实施）组织沟通的必要性将其系统排列。 可交付成果与中间输出 如前面所定义，项目的可交付成果包括项目中任何一个可测量的、有形的、可检验的项目结果。可能是一个产品、一项服务或一个结果。一个大项目可能有几百个可交付成果，例如表1-3中的舰船系统，就属于需要许多数据以支持产品的情况。要将每一项成果和成果和相关的工作识别出来并包括进WBS中。可交付成果不仅仅代表了在项目结束时交给客户的产品。通常，中间输出也必须在WBS中显示，有些例子将进一步清楚的阐明中间可交付成果或中间输出究竟是什么意思。 例如修建车库这个样本项目，明显的输出或可交付成果是一个完工的车库。车库的WBS图以大纲形式在表2-6中表示出来，由第一级分解下来的第二级元素用粗体字表示，可见有许多中间输出。其中一类输出是那些项目管理办公室为支撑项目必须做的输出项，包括确定资金、准备分包、制定施工计划。当这些活动完成时，应该有一个完整的书面记录。中间输出的一类必须获得当地政府批准的许可证才能完成，每一项检查都需要检查官出具的证明或签发的检查单。实际上，项目管理的所有二级子项目都代表具有中间输出的工作包。 车库的WBS结构图——大纲形式 1．项目管理 1．1 建设计划 1．2 许可证 1．3 检查 1．4 筹资 1．5 分包 2．车库 2．1 材料 2．2 地基 2．3 墙体 2．4 屋顶 2．5 公用 2．5．1 电 2．5．2 水 3．美化地带 3．1 车道 3．2 美化带 表2-6 车库项目输出 另一个WBS头两层的例子如图2-11所示，是一个“写书项目”。该项目有四个二级输出，第一个是项目管理，包括会议、报告、和审查。第二个是（一个横向关联分析类型元素）研究，各章的写作都需要。第三个是写作，包括书的内容。研究不是一个输入资源，而是一类要传递给写作工作的中间工作输出。写作元素的输出不是一本完整的书，而是一系列完整的章节和其他项，如目录和封面。第四个输出——出版——包括该书完成手稿的审查、实际的打印和校对以及最终的印刷。（见第5章中一个完整的写书项目的WBS结构。） 上面列举的WBS结构都不包括劳动力和成本元素。如前所述，这两类元素由活动识别，是在工作包或活动级被识别的输入元素。 WBS编号 在开发一个WBS时，通过给各种元素和级别进行编码或编号，能够显著地改善WBS在各种相关应用中的功能。编码可以采用任何一种方法，但是保持一致性很重要。大多数组织都有标准的编码。这些编码能够被使用和修改，用一些数字或字母对每一项工作活动给出唯一的识别。由编码产生的识别为计划、预算、跟踪、再计划和分配提供说明，总之，为项目中的沟通提供了说明。许多项目管理软件包允许输入WBS编码，并可使用这些编码进行数据分类和准备特定的报告。 有许多可以为WBS元素进行编号的系统。所有编号系统的目的都是为了快速识别WBS工作元素，并确定其在整个项目层次结构中元素合适的位置。WBS元素经常有类似的名称，编号系统能清楚的识别每一个单个的元素。 一个常用的十进制编码系统如表2-7所示： 表2-7 一般的十进制的大纲编码 十进制大纲编码 1． [第一主要的分类] 1．1 [副标题] 1．2 [副标题] 2． [第二主要的分类] 2．1 [副标题] 2．1．1 [详细] 2．1．2 [详细] 2．1．2．1 [分解] 2．1．2．2 [分解] 2．2 [副标题] 3． [第三主要的分类] 十进制编码系统是精确的、完整的，能够精确到任意一个所需要的层级。车库项目的编码系统如图2-12所示。如果在一个组织中有几个项目，每一个项目中都有相似的WBS元素，可以把词首如GPI（车库项目1）加进来以辨别不同的项目。 图2-12 车库项目编码 这种编码应该被扩展到计划或网络图中所有的活动，这样，每一项活动都能被独立地确定。这种十进制的大纲编码方法与典型的会计系统编码相匹配，因而为成本计算、成本累计以及挣得值系统提供了便利。 其他的使用WBS作为组织框架的内部系统有： · 活动项的跟踪——关于会议和回顾的活动项的WBS编码。 · 物料清单——WBS编码能被包括进这部分编号中，反之依然。 · 变更管理——改变包括WBS在内的计划。 · 通讯控制——除日常文件和组织文件之外。 · 数据管理。 · 绘图编码——绘图的编码部分包括产品WBS元素的WBS编码。 · 报告编码。 · 风险管理——建立风险识别过程中的具体风险与WBS元素的联系。 · 分包编码。 其他的结构概念 本书已经强调了WBS作为一个大纲的概念。大纲既是对项目工作的有组织的描述，也是一个要完成工作的计划。在开发大纲的过程中，最初没有考虑的工作能够被识别，不属于项目一部分的工作也能够被消除。最终的WBS能够随着项目的进行而经历几个阶段。一个正常的WBS包含十分简洁的工作元素的描述——就象一个粗略的大纲。这需要在WBS的开发过程中定义工作，最终产品可能包括围绕着WBS构造的工作陈述。然而，在某些情况下，可能更倾向于用短语和句子识别工作元素。 你使用的这类大纲，即WBS，应该由项目本身的工作结构、组织文化和你自己的思考过程来确定。对绝大多数人而言，定义工作元素、思考和组织之间是相互作用的。在WBS的开发过程中可能会有不止一次的修改，工作元素的顺序要重排，工作内容有增有减。 开发WBS的可取方法是利用团队的共同努力。团队成员要严格按照工作描述来执行任务。这也是有助于确保所有的工作被识别，因为专业人员和专家都会确保WBS覆盖了他们的专业领域。 当通过一个团队开发WBS时，有2个主要规则： ⑴ 百分之百规则。 ⑵ 项目管理元素应该出现在WBS的第二级中 所有的其他规则，在第6章中有列举，能够被调整以适合组织文化，并作为指南使用。 对于什么是WBS的最好结构有不同的看法。沃克尔（walker）在《WBS结构》中认为，最好的组织规则是项目本身固有的，项目以这种方式被实施。例如，一个将要在几个不同的城市实施的项目通过二级的工作分解结构图被很好的组织，其他结构类型在第三级。 一个项目如果是这样的：一个企业完成了自己所有的工作，然后把它传递到另一个企业继续下一个步骤，则这样的项目最好在第二级按照过程步骤来组织。一个包括了紧密的整合设计、开发、和原型制造的项目最好按照可交付成果的结构来组织。例如一个个人电脑项目，不同的规则改变了WBS的结构，如图2-13和图2-14所示。 尽管产品的WBS主要集中于可交付成果上，这两个WBS结构都会产生相同的工作包和活动定义。这两个WBS结构呈现了不同的有关工作内容的观点，选择哪一个取决于组织的文化和结构、项目经理的经营方式以及其他因素。如果遵循百分之百规则，最终结果应该是相同的。 图2-13 基于产品的WBS 图2-14 基于过程的WBS 图2-14中的WBS不是一个结果类型的项目，尽管它有一个过程流。它是一个按过程构建的集中于产品的项目。 对如何构建WBS持一种开放态度是必要的。 PMBOK®描述了几种其他的提供项目信息的分解结构，如下： · 组织分解结构（OBS）是一种用来表示哪个工作组成被分配到哪个组织单元中的结构。如果目的是用OBS来定义工作，准备一个OBS将使人员混淆不清，因为它是面向组织或面向输入的。在开发WBS过程中，注意力必须集中于工作，而不是在人员组织上。开发WBS的困难之一是从按组织功能构建工作的范例中摆脱出来，并将注意力集中到可交付成果或输出产品上。在定义了项目的所有活动之后，开发OBS对于提供一份报告或特定组织（如工程设计组织）所负责的所有活动的进度计划是有用的。大多数项目管理软件系统可以使增加组织或用于识别组织的权责代码的工作变的非常容易。在一些软件包中，这些域被确定为OBS域。拉德（Rad）把OBS分为“最容易得到的结构”的一类，他提醒到：因为公司经历大的组织变动，所以“必须关注使用最近的数据，并且随组织内部连续发生的变化而进行更新。” · 资源分解结构（RBS）被描述为一种OBS的变化，当工作组成部分被分配到个人时，使用RBS是最常见的情况。拉德对于完成项目的目标所需资源在逻辑上的一种有用的分类。同时他建议开发一个资源库，作为项目中所有可用资源的目录。为实现跨项目的资源计划，资源库中的编码或分类设计对于每一个项目都应是相同的。 · 物料清单（BOM）在PMBOK®中介绍了制造产品所需的物理上的组装件、部装件和部件层次结构的观点。然而，如果BOM适用于一个项目的可交付成果，那么它对于构造WBS的产品部分就十分有用。事实上，对大多数有形的产品，一个概要或顶级BOM在开发WBS中是必要的。BOM本身不是一个WBS。 · PMBOK®也为项目分解结构（PBS）提供了参考。PBS是在20世纪60年代使用的一个术语，最后被WBS所取代。阿奇贝尔德（Archibald）在他的1976年写的一本书中描述了与WBS相同的PBS。 其他的分类 没有一个最好的项目分类或细分。因为环境和利益相关者的文化背景的缘故，有时候使用不同的结构更为合适。在顶层通常使用的各种分类设计架如下： · 要交付的产品或服务的组成部分：汽车——挡板，发动机，盖，座位，外形，油箱等。 · 子系统：飞机——液压，电子，结构，充气轮胎，动力等等。 · 项目：程序——项目A，项目B，项目C等。 · 过程阶段：软件——需求，设计，编码，测试等。 · 时间阶段：生命期——概念，计划，实施等。 · 地理区域：纽约城——布鲁克林，昆斯，曼哈顿等。 · 组织单元（阶段）：工程，建筑等。 表面上看起来有些分类是输入，如组织单元，然而事实上并非如此。代表项目阶段的各种个别细节以后再讨论。每一个分类下的WBS仍然是面向输出或面向可交付成果的。重要的一点是，要有一个计划的逻辑框架，这个框架是内在的一致的，并代表了项目中要执行的所有工作。WBS是面向输出的。 有时还提出一些其他的分类： · 组织：工程——机械设计、结构设计、系统分析等。 · 个人：小项目——约翰（John）、玛利（Mary）、奥齐（Ozzie）、大卫（David）等。 · 成本帐户：劳动力、差旅、办公室供应等。 这三个分类都是面向输入的，因此不适合WBS。组织名称和代码、成本帐户、个人以及其他输入适用于工作包和活动编码，以提供根据这些分类整理的报告或信息。 偶尔有人试图联结WBS元素或者使用WBS帮助排列工作。不管WBS是否以过程、系统或者产品结构为中心，工作的排列不是目的。重要的是，工作是否要求交付项目最终产品并满足项目目标，这些目标已经被足够详细地确认，以便于识别活动、资源和分配责任。 表面上看，WBS的分解很简单，也很直接。然而，可以采用几种不同的分解方法，取决于项目的类型和工作的类别。 一个应用于所有方法中的规则是，WBS元素分解的下一层元素之和必须能代表上一级的百分之百的工作，即“百分之百规则”。如果遵循这条规则，就能保证WBS包含项目的所有工作。 基于输出的类型，项目可分为三种类型：产品、服务或结果。每一种类型的WBS都有自己的特征和分解规则。“产品”的分解是基于相似的逻辑群体以及相关的工作元素、功能或技术。“结果”项目有一系列的计划和定义的步骤，是基于过程的。 此外，还有另外一种类型的WBS元素，即“横向关联”元素。横向关联元素在本质上通常是技术性和支持性的。四种基本类型是：综合性的、分析性的、过程性的以及项目管理。后者存在于所有项目的第二级元素中。从概念上讲，项目管理元素代表一个项目的管理费用。 第 章 生命期计划：项目群和阶段 所有项目都有阶段划分和项目生命期。随着项目中的资源的增多、持续时间的延长，这些阶段就变得更加明显了。各种行业都有特殊的语言或专用术语来描述项目群的不同阶段。大的项目经常会随着时间变成项目群，许多项目从一开始就被视为或计划为项目群。本章介绍了一个项目群WBS的概念，与项目的WBS相关。 生命期阶段 PMBOK®给出了一个一般项目生命期的例子，如图3-1所示。 开始 结束 图3-1 一般生命期的例子 一种流行的定义阶段的说法如下： ⑴ 可行性研究的、概念的或初始的阶段——进行可行性分析和经济分析；建立初始的WBS和项目目标；准备一个初始的工作陈述和项目章程。 ⑵ 计划阶段——确定项目目标和范围陈述；定义工作；开发WBS；制定工作、资源和预算计划；准备项目计划。 ⑶ 执行或实施阶段——执行工作，开发产品、服务或结果。 ⑷ 结尾阶段——获得最终可交付成果；完成所有的筹资、管理、合约以及个人活动（项目结束）。 ⑸ 运作和维护阶段——客户或项目发起人使用项目输出。 如果项目比较小或者已经被承包出去，许多项目经理就不用承担第一阶段的任务。一个项目可能会基于工作、或由组织高层制定的决策、或由资深经理的决策进行分配。组织可能是总承包商或分包商，客户需进行可行性研究并可能要编制计划，然后经过一个竞争的采购过程后签定合同。 一些小项目经常有一个非正规的初始阶段，尤其是那种办公室项目，可能就是一次会议的结果。对于这类项目，生命期式的考虑就不象大型项目那样重要了，然而，项目经理必须意识到项目规模有多大。表3-1是国防部获取大部分产品时所使用的简化的生命期形式。 表3-1 一般生命期的例子 国防部项目典型的生命期 概念和技术开发 系统开发和演示 生产和部署 支持 系统采购之前 系统采购 （工程、开发、演示、小批量试生产，生产） 支持和维护 PMBOK®中关于这些阶段的描述如下： · 概念和技术开发——满足使命需要的各种备选概念的书面研究；开发子系统/组件和新系统概念/技术的演示证明。该阶段以系统层次结构和一种成熟技术使用的选择作为结束。 · 系统开发和演示——系统集成；风险降低；工程开发模型的演示；开发及早期的运作测试和评估。以运作环境中的系统演示结束。 · 生产和开发——小批量试生产（LRIP）；完成制造能力的开发；与正在运行中的运作和支持阶段重叠。 · 支持——此阶段是产品（不是项目）生命期的一部分，代表了项目群中正在进行的活动。在此阶段可以指导项目以提高能力、纠正错误、改进技术等。 一个典型的建设项目的生命期阶段如表3-2所示。在可行性研究阶段的末期，决策者们做出了“实施”项目的决定。在计划与设计阶段的末期，通过对所有主要的合同条款的批准完成了对项目的陈述。在建设阶段的末期，施工工作顺利完成，完工之后，该设施被接收并投入全面运营中。 表3-2 建设项目典型的生命期 阶段Ⅰ 可行性研究 阶段Ⅱ 计划与设计 阶段Ⅲ 建设 阶段Ⅳ 完工 · 项目描述 · 可行性研究 · 战略设计与批 准 · 基础设计 · 成本与进度 · 合同条款和条件 · 详细计划 · 征求 · 制造及材料 · 交付 · 市政工作 · 安装 · 测试 · 最终测试 · 维修 如果把运营和维修或是支持阶段带入到国防部的例子中已经完成的阶段，那么该项目将参与到一个项目群中。记住，关于项目群的定义是：以相同方式管理的一组相关的项目。项目群通常包含一个持续工作的元素。 最后一个例子如表3-3中所描述。这是一个博物馆针对新举办的展览所做的阶段描述。因为它是正在工作状态中运营和维护阶段，所以将其称为项目群。 表3-3 博物馆展览项目群典型的生命期 项目前 A项目定义 B计划 C开发与生产 D收尾 E运作与维护 · 情况描述 · 想法及策略 · 概念开发 · 调研 · 评估 · 目的陈述 · 项目管理及计划 · 场地计划 · 展览计划 · 设计包装 · 包装描述 · 项目管理及计划 · 完成设计 · 完成描述 · 场地准备 · 布展 · 项目管理及计划 · 评估 · 尾项表 · 培训 · 管理 · 项目计划及计划 · 运作与维护 · 更新 · 项目管理 其他的产业都有不同的生命期结构。当这些结构在某些方面有一些共同的重要特点，即所有阶段的输出必须经过全面陈述之后才能够进入下一个阶段。实际上，每一个阶段对于它本身的而言就是一个小项目：为创造独特的产品或服务而进行的短期努力。在每一个例子中，每一个独立的阶段都是为了满足项目中的定义。 生命期WBS概念 一个具体的WBS应该为项目生命期的不同阶段而开发。表3-3是一个博物馆展览的例子。博物馆展览项目群各阶段的输出如表3-4所示。 项目群的WBS遵循第2章中“一个WBS的解剖”一节中的规则，只有项目群管理是一个横向关联元素。每个元素都有它自己的一系列可交付成果。每一个元素都是一个项目（正在运营和维修的元素除外），它们包含过程和项目的组合。项目群级被定义为零级，所以每个项目的最高级元素都在一级。 表3-4 生命期阶段输出 博物馆展览项目的阶段输出 1．项目立项前必须上交一个“想法陈述”文件并经专门的委员会批准。任何人都能提交这样的“想法陈述”文件，其内容是对想法的解释。 2．在项目定义阶段的最后，必须完成并批准一个更综合的“建议报告陈述”文件。这个文件主要解释要展览些什么，以及为谁举办这次展览。组成一个预备项目小组，并听取群众的意见，向协会组织、学者以及其他博物馆人员咨询。这个文件可能会几经修改，最后必须经由来自不同组织的成员组成一个“特许小组”批准。 3．计划阶段在“想法陈述”被批准之后开始，在批准了项目计划并建立了进度计划与预算基线后结束。此外，此阶段应完成设计的35%和草稿的60%。另外，还要确定50%的可视化的材料、实物和图。并确定所展示的百分比的准则。 4．开发和生产阶段实际上被再次细分为几个阶段，需要许多内部审批。另外，展览开放确定了该阶段的结束。 5．从展览期运营和维护工作的完成到博物馆恢复到日常运营期间被定义为终止阶段。 6．运营和维护阶段将一直延续到展览结束。 图3-2 博物馆展览项目的WBS 在一个按生命期阶段组织和管理的项目群中，有3类项目管理WBS元素： ① 在第一级的传统的项目管理活动（标注为项目群管理）用于覆盖整个项目群和横跨所有阶段的活动。 ② 与每一阶段（作为第二级独立项目）的管理有关的项目管理活动。 ③ 在一个阶段内执行但与后续阶段相关的项目管理活动；这些项目管理活动属大型项目群框架中生命期子项目群独有。 第一类项目群管理元素不可能总是存在。一个项目可能演化成为一个组合项目，所有的项目管理元素都在第二级。项目群管理级的存在也表明一些工作要在项目定义阶段之前执行。项目定义阶段的结果可能是建立一个组合项目管理职能部门，它在所有阶段都为多项目管理提供支持并执行项目管理职能。 第二类是正常的WBS项目管理元素，如第2章所述。 第三类有些不同，因为它包含与项目群后续阶段相关的项目管理元素中的特定的可交付成果。它不仅仅是一个费用类型的元素，而是包括第2章中“一个WBS解剖”部分中介绍的有与后续阶段的计划有关的WBS元素，并需要来自于该阶段其他工作的输入。例如，在项目定义阶段的项目管理元素的输出是计划阶段的WBS范围说明，以及初始WBS、进度计划和后面阶段的资源计划。 类似地，计划阶段的项目管理元素包括那些与计划阶段的管理有关的元素。它可能还包括计划活动的重要输出，这些计划活动产生了后续的项目开发和阶段生产计划，项目开发和生产阶段将花费绝大部分的资金和资源。 图3-3中的WBS说明了上述情况。完整的项目在第二级用6个标有从A到F的元素表示，这6个元素满足百分之百原则。这些元素中从A到E的5个元素也可以被识别为项目，或是项目群的阶段。一个项目阶段的定义为：一个逻辑相关的项目活动的集合，通常以一个主要可交付成果的完成为终结。正如我们所见，每一个这样的项目和/或阶段都满足这个定义。 图3-3 在生命期中项目管理的WBS 在第一级的项目管理元素既不是子项目，也不是一个阶段，它是一个正常的项目管理元素。这个元素可能的分解如图3-4所示，项目群包括全部的元素。 图3-4 大型项目管理分解 这不是唯一的分解；不同的组织可能有不同的构造WBS项目群管理元素的方法。例如，不同阶段的所有计划编制都包括在项目管理元素中，而不是每一个阶段的每一个项目管理元素的一部分。重要的是要识别出所有的工作。 计划阶段/子项目（B）分解如图3-3所示。元素B.1到B.6都是正常的二级WBS元素，B.7也是一个正常的项目管理元素，除非它包括这一阶段中产生的主要可交付成果。第3级项目管理计划的分解有四个主要元素，分别是B7.1到B7.4。这些元素的第四级分解如图3-3中第三级元素下相应编码的项。 第三级的WBS元素包括下列元素类型： B7.1 计划编制阶段的项目管理——正常的、分析性的项目管理工作，包括项目计划编制阶段的管理工作。 B7.2 开发和生产阶段的计划——一个集成的元素，从整个项目群的这一阶段生成一个主要的可交付成果或输出。这个元素本可能被安排在第二级，但是通常被认为是项目管理类元素中要执行的工作的一部分。这样，计划就是第二级和第三级的横向关联元素。 B7.3 收尾、运营和维护阶段的计划——也是一个分析性元素，在子项目计划编制阶段产生一个初始的可交付成果。这个可交付成果将在开发和生产阶段结束之前完成。 B7.4 项目管理办公室——另一个在B.7编制项目管理计划下的普通元素，它代表人力资源部来执行该项目的工作，这些也是项目管理办公室的工作。 这些描述说明了在WBS中一个单独项目与构成项目群生命期的一组项目或子项目之间的差别，这个差别是在整合不同级别的项目时项目管理任务的不同。尽管这些阶段根据在每个阶段执行的工作而有所不同，但它们都是由项目群经理和项目管理办公室整体规划的项目群的组成部分。 国防项目群WBS和生命期 在项目生命期计划方面，美国国防部（DoD）是首创者。表3-1阐述了系统获取的生命期。DoD的项目群WBS概念与前面描述的多阶段项目WBS不同。DoD的项目群WBS着重于获取阶段和项目群WBS随着系统工程和定义工作进展的演化。应该注意到DoD对项目群的定义较之PMBOK®中的多项目的定义更接近一个超级项目的定义，因为它仅包含获取阶段，不包括其他的生命期阶段。DoD的项目群WBS的目的是要在DoD规定的程序和规则下为计划和管理主要的DoD系统的获取提供一个框架。因此，DoD和MIL-HDBK-881的覆盖范围都比PMBOK®更窄。 根据DoD的观点，为了把WBS作为一个项目群技术目标的框架来使用（除了作为一个成本控制和计划控制的管理工具使用以外），WBS必须是面向产品的。元素必须代表可识别的工作产品，不管它们是设备、数据或相关的服务产品。DoD的方法确保完全定义了项目群的工作，以包含所有项目参加人（包括总承包商、承包商和分包商）所执行的工作。 DoD手册不排除用WBS提供一个服务或结果，如本书所述；然而，在获取主要的军事硬件和软件系统时，还应该遵循某种理论和术语。 项目中的阶段 有些组织在进行一个典型项目特殊阶段的工作时，采用标准的系列过程步骤进行操作。有时，这些过程步骤被错误地称为生命期步骤，对于一个硬件产品，包括如设计——采购——制造——测试等步骤。对于一个软件产品，步骤可能是需求——设计——编码——测试。 企业出于对自身生产流程的熟悉，即使输出只是一个产品，而非结果，也会相应地构建WBS。应该记住结果项目在第二级有过程元素。确保WBS着重于输出产品和可交付成果是很重要的，分解也应该是从输出产品或可交付成果那里开始。用本章前面讨论的采用生命期阶段构造项目群的WBS不会有问题。这与本章所讨论的问题是不同的。 图3-5展示了一个污水厂项目的本分WBS结构。尽管有一些WBS元素没有显示（如一些横向关联元素），这个WBS与本书所讨论的原则是一致的。原因是它们在设计和建设阶段结束时，都有具体的且不相同的输出产品或可交付成果，不代表工作于同一产品元素上的组织。每一个阶段代表着有不同输出产品的不同工作，满足PMBOK®对于一个阶段的定义：一个逻辑相关的项目活动的集合，通常以一个主要可交付成果的完成为结束。 图3-5 污水厂项目的部分WBS结构 资料来源：PMBOK®Guide：60 另一方面，图3-6表示一个不正确的WBS。问题出在第二级的元素上；产品需求——详细设计——施工——集成与测试都不是阶