精彩专题 |
如何做好项目沟通计划
软件项目质量管理
国际工程索赔与反索赔
|
更多:
|
|
联系社区管理员 |
咨询电话 010-82273401/11
斑竹申请 admin@mypm.net
版权所有 © 2003-2004
京ICP证070584号
BBS业务许可2007第353号
最佳显示模式:1024*768像素
|
|
 |
有效的工作分解结构 [发表于 2010/4/11] 状态 开放帖 浏览量 4548 |
|
有效的 工作分解结构 Effective Work Breakdown Structures ① PMBOK®是美国项目管理协会的商标,该商标在美国和其他一些国家注册。 前 言 本书的写作目的是为了满足对WBS 概念及应用的全面、系 统和实用性阐述的长期需要。本书旨在帮助项目经理和项目规划 者改善项目结构,有效的启动项目,并在项目的全过程中都把 WBS 作为规划、控制和沟通的关键工具使用。 本书体现了多年来WBS、新项目的范围界定和计划的发展经 历,介绍了已经被大家普遍认可的WBS 及其在应用中的一些概 念,其中许多更详尽的概念是我提出的。此外还提供了许多例子。 在项目管理中,WBS 不是一个新概念,但是它经常被误解, 没有得到正确使用,达不到其最大的有效性。像做任何计划一样, WBS 的使用也需要训练与思考。开始做一项工作,看上去通常比 做一个工作计划要简单些。 本书共分为六章: 第一章,WBS 的概念,定义了主题,简单介绍了WBS 概念的历 史,定义了一些术语,并明确了在项目管理过程中WBS 概念的作用。 第二章,WBS 逻辑基础,讨论了在有效的WBS 开发中应考虑的 各个方面的问题。 第三章,生命期计划:项目群和阶段,提出每一个生命期阶段都 是一个单独的、有自己的WBS 的项目。 第四章,项目运营中的WBS,阐述了PMBOK®①九大领域中的每 一部分与WBS 的关系及其应用。 第五章,WBS 的例子与描述。包括对几个不同类型项目 的WBS 例子的描述,以及第二章中的WBS 基本原理的普遍应用的 方法。 第六章,WBS 原理、步骤和审查表。包括对WBS 原理以 及推荐给项目经理用来开发项目的WBS 的一系列特定的、注重实效 的步骤的总结。 本书是我 40 多年来从事项目管理工作经验的总结,包括我在20 世纪60 年代作为马丁公司(现名为洛克希德·马丁公司)的代表参 加政府—工业任务时的收获。现在全世界许多日常使用的项目管理 工具在那个时候都刚刚开发出来。作为一名项目经理、项目经理咨 询顾问以及培训者和课程开发者,我参加过几百个WBS 的开发,这 些经历在本书中都有所体现。 最后,感谢管理概念公司的卡西·克雷切(Cathy Kreyche)以 及我的业务合作伙伴金格·莱文(Ginger Levin)博士,是他们鼓励 我完成本书的写作,并提供了许多有价值的批评和建议。 格雷戈里T.豪根 作者简介 格雷戈里 T.豪根博士,PMP®,在过去的16 年中是GLH 股份有 限公司副主席,专门从事项目管理咨询和培训工作。作为咨询顾 问、政府和私营企业的官员,他在计划、调度、管理和运营各种 规模的项目,以及开发和实施项目管理和信息系统方面有40 多 年的经验。 豪根博士是一位应用和实施项目管理系统的专家。他早年在 美国国防部(DoD)参加了WBS 和C/SCS(挣得值)概念的开 发,并参加了最初的PERT 成本控制软件的开发。他作为马丁·玛 丽埃塔公司(洛克希德·马丁公司的前身)的代表参与了美国陆 军、海军、国家航空航天局联合委员会开发的C/SCS 概念。他是 范围管理、成本管理和进度管理、发起新项目、准备建议书等领 域的专家。 豪根博士在美洲大学获博士学位,在圣路易斯大学获MBA, 在伊利诺斯理工学院获学士学位。 目录 译者序 中文版序 英文版序 前言 作者简介 第 1 章 WBS概论……………………………………………………………….1 项目问题和解决方案………………………………………………………...1 WBS概念的背景……………………………………………………………..9 早期美国政府的活动………………………………………………………………….9 PMI 和PMBOK………………………………………………………………………13 项目管理过程中的WBS…………………………………………………...16 第2 章 WBS 逻辑基础………………………………………………………..19 百分之百规则……………………………………………………………….19 一个WBS 的解剖…………………………………………………………..22 产品项目分解…………………………………………………………………………23 服务项目分解…………………………………………………………………………24 结果项目分解…………………………………………………………………………26 横向关联因素…………………………………………………………………………27 项目管理………………………………………………………………………………30 WBS字典……………………………………………………………………33 工作包……………………………………………………………………….34 适当的细节水平…………………………………………………………….36 用WBS 导出活动…………………………………………………………...37 WBS 和活动……………………………………………………………………………37 活动定义…………………………………………………………………………………39 输入与输出——资源与可交付成果………………………………………..42 输入与输出元素………………………………………………………………………...42 可交付成果与中间输出………………………………………………………………...44 WBS 编号……………………………………………………………………..46 其他的结构概念………………………………………………………………48 其他的分类……………………………………………………………………51 第3 章生命期计划:项目群和阶段…………………………………………55 生命期阶段……………………………………………………………………55 生命期WBS 概念…………………………………………………………….58 国防项目群WBS 和生命期………………………………………………….62 项目中的阶段…………………………………………………………………63 第4 章项目运营中的WBS…………………………………………………..67 范围管理………………………………………………………………………67 项目章程 ……………………………………………………………………67 工作陈述…………………………………………………………………………………68 时间管理………………………………………………………………………69 成本管理………………………………………………………………………72 自下而上的成本估计……………………………………………………………………72 历史数据的收集…………………………………………………………………………73 帐户连接图………………………………………………………………………………74 挣得值管理系统的实施…………………………………………………………………74 预算………………………………………………………………………………………75 沟通……………………………………………………………………………75 采购管理………………………………………………………………………76 质量与专业绩效管理…………………………………………………………77 人力资源管理…………………………………………………………………78 项目集成管理……………………………………………………………………79 项目计划…………………………………………………………………………………..79 配置管理…………………………………………………………………………………..80 第5 章 WBS 的例子与描述………………………………………………………83 例1:实施一种新的企业级别管理理念的WBS……………………………...83 例2:应对跨文化和国界挑战的WBS………………………………………...83 例3:写书项目的WBS…………………………………………………………85 例4:晚宴项目的WBS…………………………………………………………88 例5:博物馆展览项目(项目定义阶段)的WBS……………………………89 第6 章 WBS 原理、步骤和审查表………………………………………………93 WBS 原理………………………………………………………………………..93 顶层………………………………………………………………………………………..94 产品项目…………………………………………………………………………………..94 服务项目…………………………………………………………………………………..94 结果项目…………………………………………………………………………………..94 通用原理…………………………………………………………………………………..95 开发一个WBS 的步骤………………………………………………………….96 审查表……………………………………………………………………………97 参考文献……………………………………………………………………………..99 第章 WBS 概论 本章提供了有关WBS 的概念、背景以及WBS 在项目管理 过程中的地位的一些信息。 项目问题和解决方案 开始一个新的项目就像是要开始写一本书,你已经有了想要 写些什么的思路,但还不确定怎样开始。就像许多项目计划者和 经理们一样,许多作者发现写大纲通常是一种开始写作的最有效 的方法。 大纲既是一种组织材料的方法也是一个写作计划。写大纲有 许多方法,尤其是有一种基于研究的方法。一般地,规划一个调 查研究或数据收集,并决定每一章要讨论的内容及附录是十分必 要的。此外,起草章节、收集一批专家的关键评论、以及与评审 证明和出版文件有关的实际步骤等,都是必要的。第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 中最低级的工作,为定义活动 或特定的向个人和组织分配责任提供了逻辑基础。工作包也指要求 完成的一项具体工作组成部分或过程,如一个报告、一个设计或一 个文档的全部需求或其中的一部分、一个硬件或一项服务。 在项目的早期阶段,开发一个仅有二到三级的WBS 是可行的, 因为详细的工作可能还没有被定义。然而,随着项目进入项目定义 阶段或者计划阶段,计划就变的详细多了。这时,WBS 就能够被 逐级细分到更低级别。在我们前面所说的“吃大象”或者进行项目 工作中,最终的子项目或工作包就是“一口”。这个细分化过程的 产品就是完成了的WBS。 第 1 步定义项目目标:建造一个能停放一辆车的车库, 并美化现有场地,车库里外都应该有灯,还有水管。 第 2 步确定特定的产品、服务或结果(可交付成果或最 终产品):车库和美化的场地。 第 3 步确定其他的工作范围以确保100%的工作被识别: 这是一个需要完成如下事情的项目管理职能,如编制施工计划、获 得许可、签定分包合同。 至此,该项目的WBS 如图1-2 所示。第一级是总项目,第二 级是进一步分解成的最终产品(车库和美化场地)以及与项目相关 的或辅助性的工作(如项目管理)。项目的总范围由第二级的三个 部分工作之和来表示。 一级 二级 第 4 步进一步细分元素,直到适于计划和控制的层级: 图1-3 表示每个二级元素的下一级细分。 有些三级元素还可以进一步分解。表1-1 表示一个到达工作包 车库项目 美化场地车库 项目管理 一级 二级 三级 图1-3 三级WBS 结构图 级的完整的WBS,工作包足以适用于计划和控制。在这个表中, WBS 是一种大纲形式,而不是以前用的占用空间的图的形式。这 两种形式都是可以使用的。在把WBS 数据输入项目管理软件,或 者为了节约文档空间时,通常使用大纲形式的WBS。 表1-1 车库项目的WBS 结构 一级 二级 三级 四级 美化场地 车道 美化 材料 地基 墙面 窗户 车库门 检修门 墙体 组装 构架 屋顶 遮盖物 排水槽 电 车库 公用工程 水 施工计划 许可证 检验 筹资 车库项目 项目管理 分包 车库项目 美化场地车库 项目管理 车道 美化 材料 地基 墙体 屋顶 公用设施 施工计划 许可证 检验 分包 工作包下面的一级是单独的任务或活动,通常它们不作为 WBS 的一部分。事实上,(如在第2 章中讨论的那样)WBS 的主 要作用就是提供一个框架用来帮助定义项目中的活动。一个完成 了的WBS 应该覆盖项目的全部范围。 一个十分重要的项目管理准则提请我们关注:WBS 中没有包 括的工作不在项目管理范围之内。例如,在表1-1 中,没有标明 取暖(Heating)、通风(Ventilating)、空调(Air Conditioning) (HVAC)系统,因此,HVAC 系统不是这个项目的一部分。 一旦建立了WBS,必须进行维护更新,以反映项目的变化。 每一个项目的WBS 的排列以及具体的工作包都不一样,这取决 于以下几个因素: 项目的规模和复杂程度。 项目所在的组织的结构。 项目所处的阶段。 项目经理对分包给分包商的工作的判断。 项目所涉及的不确定性和风险的程度。 用于计划的时间。 WBS 是一种用标准形式表示项目范围,并在项目团队内部、 项目团队与利益相关者之间进行协调的巧妙的沟通工具。在计划 阶段的最后,计划和进度计划被冻结或确定为“基线”,成为执 行项目工作的基础。同时,WBS 也将作为一个基线成为变更管理 的关键机制之一。不包括在WBS 中的工作需要通过正规的变更 控制程序添加到项目和WBS 中。 下面是WBS 的另外两个例子,集中于项目产出的产品或可 交付成果。图1-4 是一个民用飞机项目,该项目拟将客用飞机改 装为运输机。输出的产品是一个保证飞行性能良好的改装飞机、 技术手册和一系列需要的备件。 这个 WBS 包含一个名叫“系统工程”的、涉及所有项目内 ATP 改装项目 图1-4 WBS 例子——飞机改装项目 容的工作活动集,他包括对改装所必需工作的说明。这是WBS 元素中 一种常见的类型。 第二个例子(如图1-5 所示)是一个软件开发项目,它的主要可 交付成果是软件系统,次要的可交付成果是培训材料和用户文档。软 件系统中也有名为“系统分析”的涉及所有项目内容的工作活动集, 它表示诸如项目定义、工作流分析或者结构分析等工作。 图1-5 WBS 例子——软件项目 ATP 改装项目 1.项目管理2.系统工程3.集成后勤支持4.ATP 飞机 4.1MOD 4.2 测试与交付 1.1 项目办公室 1.2 风险分析 1.3 项目计划 1.4 项目审查 2.1 系统分析 2.2 初步设计 3.1 技术手册 3.2 备件需求 4.1.1 乘客系统 4.1.2 工具 4.1.3 飞机修改 4.1.4 运输机改装 4.1.5 安装 4.2.1 地面测试 4.2.2 鉴定及交付 软件项目 培训材料用户文档软件系统系统分析项目管理 模块 1 模块2 模块3 系统测试 编码 测试 WBS 能够全部或部分用于进行任务分配、预算、解释项目的 范围和性质。责任的分配是在WBS 的最底层——工作包层—— 或者再下一层——任务或活动层。WBS 可以作为描述项目整体的 一个公共的焦点。 WBS 概念的背景 WBS 在项目管理中不是一个新概念,一些背景资料将有助于 理解其重要作用。 早期美国政府的活动 1959 年,马尔科姆(Malcolm)、罗斯布姆(Roseboom)、克 拉克(Clark)和法扎尔(Fazar)发表了一篇经典的论文,阐述一 种叫做“计划评审技术”(即PERT)的成功实施。尽管其中没有 直接介绍WBS,但包含了分解的图形,说明该概念在当时就已有 一定的发展(见表1-2 所示)。 表 1-2 早期的北极星项目工作子系统 舰队弹道导弹项目子系统 导弹 重返体 制导 弹道外壳 推进器 飞行控制 发射装置 导航系统 发射控制 舰艇 指挥通讯 PERT 和WBS 的概念被广泛而迅速的传播。在1958~1965 年间发展起来的这些管理系统及其应用是今天我们使用的项目 管理知识体系中许多内容的基础。到1961 年,“工作分解结构” 这一词已被广泛使用。在通用电气公司内部出版的一篇文章 中有一个WBS 的例子。这个WBS 例子的一部分是“FBM 维 护训练设施”,如图1-6 所示。 图1-6 工作分解结构——1961 年 这个输出的产品包括政府供应装备、设备修改、文件、培训教员 以及仿真机。其他的管理和安装元素是横向关联或支持元素。 1962 年6 月,美国国防部(DoD)在与国家宇航局(NASA) 及航天工业的合作中,出版了一个用于指导PERT 成本系统的 系统设计文件。这个文件包含有关WBS 的大量描述,与现在 的描述基本相同。 1962 年10 月,国家宇航局(NASA)又出版了另一个文 件,该文件拓展了NASA DoD PERT 成本指南中有关WBS 的 讨论。NASA 强调使用自上而下的WBS 分解方法,以保证整 个项目得到全面的计划,且派生出的计划能直接为最终目标 服务。同时,在任何一个完整的时间/成本管理系统中,成本 和时间都需要从一个共同的框架中记性计划和控制。 在航天工业中,不同的公司都迅速地将WBS 的概念融合 到他们内部的项目计划运做中。作者一直在利用WBS 制定马 FBM 维护训练设施 管理政府供应装备 设备修改文件 安装 培训教员 仿真机 动态指导 系统 S-1 系统S-2 丁·玛丽埃塔公司(现在的洛克希德·马丁)巴尔的摩部和奥兰 多分部的计划,并出版了一个文件,该文件包括在使用PERT 时 项目计划中需要的WBS 开发方法。 1964 年8 月,美国政府出版了PERT 实施手册,其中包括对 WBS 的讨论。这个文件是供政府部门、私人企业或公共机构使用 的。文件中也赞成采用自上而下地开展WBS 的方法,使得“脱 离了公共的框架就不能制定出详细的计划”。文件指出,计划、 进度计划和网络计划可以在没有WBS 的情况下开发,但是这样 的计划和进度计划可能不完全,或者与项目目标或输出产品的要 求不一致。 大多数政府和航天工业中的WBS 开发文件都遵循相同的方 式,计划从项目的最高层开始,,始于对目标和最终产品的确认。 为一些大的军事系统(如那些20 世纪60 年代建成的系统)开发 WBS 时,很明显可以看出,每个系统家族的上两层或上三层都十 分相似,即最终产品和其下一层的分解是相同的。例如,所有的 飞行器(不管是运输机、战斗机还是轰炸机)都有机翼、发动机、 机身、尾翼、起落装置等。 1968 年,国防部为自身系统开发了一个WBS 顶层分解的标 准,要求所有使用研究、开发、试验和工程基金预算的超过一千 万美元的国防项目都要强制使用这个标准。1998 年1 月2 日, MID-HDBK-881 文件被更新,并取代MIL-STD-881 文件。但是 由于国防部后来理念的转变,这个手册不能引用作为合同责任。 然而,其他的国防部文件都特别地要求使用WBS。 MIL-HDBK-881 仍旧针对于国防物资。这本手册中仍然包括 七个相同的国防部系统的WBS 模版,这些模版属于最初的标准。 这本手册包括下列系统的WBS 头三层结构及其相关的描述 (WBS 字典): (1)飞行系统。 ⑵ 导弹系统。 ⑶ 武器系统。 ⑷ 舰船系统。 ⑸ 电子/自动化软件系统。 ⑹ 太空系统。 ⑺ 地面车辆系统。 表 1-3 给出了手册中舰船系统的WBS 结构图。 表1-3 舰船系统的WBS 一级二级 三级 船体结构 推进设备 电力设备 指挥与监控设备 辅助系统 用具和家具 武器 综合/工程 舰船 舰船装备和支持服务 开发测试和评估 系统工程/项目管理运作测试和评估 实体模型 系统测试和评估测试和评估支持 测试设备 装备 培训 服务 设备 技术出版物 工程数据 数据 管理数据 数据存放 特殊的支持设备测试和测量设备 支持和处理设备 现场系统组装、安装和检验 承包商技术支持 运作/现场的启动现场施工 现场/舰船/车辆转换 施工/转换/扩展 设备获得或现代化 工业设备 维修 舰船系统 初始备件和物理部件 资料来源:Department of Defense, MIL-STD-881 Work Breakdown Sturcture for Defense Matenial Items( Washington D.C.: Headquarter, Air Force Systems Command, Directorate of Cost Analysis, 1 November 1968). 手册中描述的层次以下的部分通常由承包商定义,并且在 每一个项目中都不同。通常,在这些类型的大系统中还要识别 五到八个追加的层级。 PMI®和PMBOK® 随着航空项目削减、冷战结束和项目管理学会的快速成长, 项目管理实践中的监控和文档管理的领先地位从公共部门转移 到私人部门。 PMI®的职能 PMI®,一个拥有超过70000 成员的专业协会,通过会议、 分会议、月刊“PM Network(项目管理网络)”和季刊“Project Management Journal(项目管理杂志)”为项目管理实践的成长 和发展提供了一个平台。1987 年秋,PMI®出版了一个重要的 文件,名为“PMBOK®”。这个文件在1996 年被重新修订, 并在2000 年再次更新。 PNBOK®反映了美国国防部、国家宇航局、其他政府组织 和宇航工业从20 世纪60 年代以来30 年的项目管理经验。 PMBOK® PMBOK®包括广泛应用的、经过证明的、传统的实践经 验,还包括虽然有较大局限性、但是被广泛接受的创新和先进 实践经验的新知识。 PMBOK®不是一个指明“怎样去做”的文件,而是提供 ㈠ “PM Network” is a trademark of the Project Management Institute, Inc., which is registered in United States and other nations. ㈡ “Project Management Journal” is a trademark of the Project Management Institue, Inc., which is registered in the United States and other nations. 一个结构性的纲要和项目管理专业概念的基本参考。PMBOK® 强调项目管理的过程。 PMBOK®不象MIL-HDBK-881 和其他的美国政府有关 WBS 开发的文件那样明确,因为有了后面三十年的经验,二者有 些不同。PMBOK® 关注比国防部文件更广泛的用户,包括20 世纪60 年代以来的所有商业应用和实践。除了讨论PMBOK®中 的WBS 以外,PMI®正在开发一个工作分解结构的实践标准,以 获得比国防部手册中更广泛的应用。实践标准计划在2001 年公 开出版,本书将补充这方面的内容,如同PMBOK®在项目管理方 面对其他书做出的补充一样。 PMBOK®遵循了在项目分解方面早期的政府经验,该项目分 解表述为:“把主要的项目可交付成果或子可交付成果细分成更 小的、更易管理的部分,直到可交付成果可以被足以详细地定义, 以支持项目活动的开展(计划、执行、控制、终止)。” PMBOK®与国防部手册 表面上,PMBOK®和国防部手册的主要区别在于如何完成项 目的分解的理论上。PMBOK®指出“.......主要元素永远要根 据项目实际的组织方式进行定义。”国防部手册指出:“一个WBS 不应影响或以任何方式干扰承包商的组合项目组织。”开发WBS 的普遍性原则之一是:WBS 不是一个组织结构图。PMBOK®指 出,应该根据工作的组织方式,而不是人力资源组织结构来说明 工作。 ㈠ PMI-Standards Committee, PMI Practice Standard for Work Breakdown Sturcture, Exposure Draft Version (Newtown Square, PA: Project Management Institue, October 2000). ㈡此书已于 2001 年10 月1 日由PMI 在美国出版,Project Management Institute Practice Standard for Work Breakdown Stuctures, ISBN: 1880410818 此外,PMBOK®把项目生命期阶段的例子作为分解的第一 层。另一方面,国防部的手册中指出:“项目群的阶段……不适 于作为工作分解结构中的元素。”同样,国防部手册不允许以项 目的生命周期阶段作为WBS 的元素,这其实是一个国防部特有 的限制,与国防部的多项目WBS 定义和使用有关。第3 章讨论 将项目群阶段作为WBS 顶层元素的情况,并将弥和PMBOK® 与国防部方法之间的差异。 WBS 元素描述 WBS 的经典方法通常是用名词或修饰语描述来定义WBS 中的元素。进一步,可以将WBS 视为对“项目中要完成什么?” 问题的回答。根据活动的定义和关系绘制的网络图可以回答“如 何完成?”的问题,根据网络图计算得到的进度计划可以回答 “什么时候完成?”的问题。 已经有人向PMI®提出了建议:WBS 中的活动的描述应该 包括动词。但是,基本的传统方法仍然是健全并经过验证的, “活动”一词的应用来自于一种习惯性理念,即其他的方法都 是无效的。根据定义,活动是动作实体,在它的标识描述中包 括动词。 本书遵从这样的理念,即WBS 结构必须与项目目标有关, 并因此像PMI®定义项目一样产生独有的产品、服务或用PMI 方法定义的项目结果。WBS 必须是一个最终产品或面向可交付 成果,WBS 更适宜由那些用形容词修饰(如果必须使用才能表 述清楚)的名词来描述的元素组成。更倾向于使用这种描述类 型是因为描述要遵循集中于输出产品的原则,这些输出产品通 常用名词描述。使用动词隐含着活动,活动是在WBS 结构中最 底层以下的作业层执行的。 为了使WBS 能被开发者之外的人充分理解,通常需要另一 个定义每一个元素内容的独立文件(叫做WBS 字典,将在第2 章中讨论)。但是,随着在WBS 元素的描述中经常使用较长的短 语和大量的动词,将WBS 元素的工作内容充分地描述出来,就 不必去查WBS 词典了。项目环境以及项目本身将确定用于WBS 元素的描述信息的性质。有必要建立一套WBS 描述信息集,以 帮助利益相关者了解每一个元素所代表的工作。 WBS 的主要目的之一是沟通。因此有必要形成一个易于识别 的形式。于是,有可能在WBS 结构中包括用动词描述的活动。 然而,有一点很重要,即不管怎样描述元素,WBS 都是基于可交 付成果(项目的输出产品)的。(见第2 章WBS 元素与工作包和 活动的关系。) 本书中的资料遵循PMBOK®,或更准确的说,PMBOK®反 映了本书所用的WBS 知识体系。 项目管理过程中的WBS 项目管理是一个连续的过程。图1-7 表示了基本的项目管理 过程,它强调在时间—成本—质量(绩效)约束和目标的三元素 组合中达到项目目标。 A. 开始 B.计划 C。执行 D。控制 E。终止 1. 建 立 项 目目标 2.定义工作 3.强调工作和 资源 4.执行工作 5.提供报告 6.跟踪实际执行 情况 7.分析项目进展 8.开始正确的行 动 9.根据需要重新 计划 10.项目完成 这10 个步骤中每一步都有一个特定的、定义过的并有文 件记载的输出。这些步骤频繁重复,也就是说,在后面的步 骤中出现的情况可能需要用到前面的步骤和其后所有或部分 连续步骤的重复执行来加以修正。这些经常发生的重复和再 计划是项目经理和项目团队日常工作的特点。 基本的项目管理过程有五类活动:开始、计划、执行、 控制、终止(如图1-7 所示)。这种分类强调了在宽泛的项目 工作开始之前的计划工作的重要性,以及在完成所有的项目 后终止项目的重要性。 WBS 是在项目佳话定义和完成阶段(此时包括WBS 的 计划将成为基线)所应用的一个重要工具。第4 章将讨论WBS 事实上在项目管理的每一个方面都无所不在。因此,及早并 正确的准备WBS 对项目是十分重要的。 工作分解结构: 由项目目标和项目产品、服务或结果导出。 提供了一种定义工作全部范围的工具。 确保工作元素被定义,并且仅仅与一个具体工作有关, 这样,活动就不会被忽略或者重复。 作为定义项目任务或活动的一个框架。 WBS 是一个重要工具,用来帮助项目经理定义要执行的 工作以达到项目目标。开发WBS 是一个四步骤的过程,重点 是要交付顾客或最终用户的产品、服务或结果。它为将工作组 织和分解到一个适当详细的层级提供了一个框架,从而便于计 划和控制。WBS 这一概念最初是在20 世纪60 年代初由美国 国防部和航天局开发的,从那时起,WBS 就成了项目管理中 一个关键的组成部分。 第章 WBS 逻辑基础 WBS 表示要执行的工作的一种合理分解,集中于对产品、 服务或最终成果的再细分。它是所要执行工作的大纲。开发一 个WBS 需要有关输出或可交付成果的零部件如何被装配成或 集成为最终产品的知识,或者有关工作的主要领域的知识。不 管最终产品是一个报告、一架飞机、一座建筑、一个电子系统、 一段计算机程序、一场婚礼、一次会议、一种文化的改变,还 是其他的项目输出,都需要这样的知识。了解要做的工作,或 者为了使项目团队和其他利益相关者加入WBS 的开发都需要 获取这一专业知识。 本章讨论了项目工作分解和细分的不同算法。然而,首先 必须阐述一个重要的规则,即应用于所有WBS 的所有层级的百 分之百规则。 百分之百规则 在建立一个WBS 和评估分解逻辑时,百分之百规则是最重 要的标准。该规则是指: 一个 WBS 元素的下一层分解(子层)必须百分之百的表示 上一层(父层)元素的工作。 在图2-1 中,百分之百规则意味着美化场地加车库加项目 管理等于车库项目中百分之百要执行的工作,不存在上述某个 范畴以外的项目活动。在自上而下的分解过程中,大多数计划 人员都会自觉遵守这一规则,至少在第二层时。然而,要注意, 在所有层都要遵循这个规则。 一级 二级 三级 图2-1 车库项目 在第三层,百分之百规则意味着“车库”元素中的工作由 “材料+地基+墙体+屋顶+公用设施”组成。不存在不属于上述 任何元素之一的工作。回顾表1-1,“墙体”元素百分之百地由 第四层中的“墙面和挡板+窗户+车库门+检修门+组装”表示。 这五个元素包含了墙体的全部工作内容。注意,“组装”元素对 于说明安装或集成其他独立元素的工作是必要的。 记住,使用WBS 的一个主要原因是要确保识别完成一个成 功的项目所必须进行的所有工作包和活动。百分之百规则也适 用于活动层:每一个工作包中的活动所代表的工作加总必须等 于完成该工作包所必须的百分之百的工作。用这种方式,项目 经理能够合理的保证对所有为了成功完成项目所必需的工作已 车库项目 美化场地 车库 项目管理 车道 美化 材料 地基 墙体 屋顶 公用设施 建设计划 许可证 检验 筹资 分包合同 经做出规划和进度安排。这是一条重要的原则,因为该规则 能够帮助开发WBS的人员经常的问自己是否理解了有关项目 工作的广度和深度。 项目小组应共同开发WBS,或者至少共同详细地检查 WBS,这是一个普遍的建议。一些相关专家总是注重确保工 作中要包括他们的专长,他们能够保证WBS 的完整性以及尽 可能准确。例如,对于制造项目而言,从制造工程师或工艺 工程师那里得到的信息有助于识别可能的部件;在软件项目 中,从系统分析员、程序员或者数据库专家那里得到信息是 十分有用的。在车库项目中,从有经验的木匠或者车库修建 者那里得到信息也是有用的。 并不是所有的WBS 都是基于产品的(第6 章将会讨论这 个问题)。百分之百规则还适用于:子元素中所有工作的总和 必须等于父元素所代表的百分之百的工作,即使父级元素是 一个像“系统工程”或“研究”这类一般的术语。自下而上 的成本估计方法(即估计每一个活动或者工作包的成本,然 后沿着WBS 的层次汇总所有的项目成本)的使用,是基于 WBS 的开发遵循了百分之百规则这一关键假设的。 一种通用的开发WBS 的方法是自下而上,如果项目的输 出产品是服务,这种方法尤其有效。所有的项目活动先是在 头脑风暴会议中被列举出来,然后分组到逻辑工作包或者较 低层WBS 元素中,然后再依次汇总到较高层元素中。每一层 都遵循百分之百原则。 在每一层中都要问到的下列问题: 每一个子级元素表示的工作的总和是否等于父级元 素中汇总的百分之百的工作? 是否有遗漏的工作? 经验表明,问过这些问题后,总会导致活动的增加,WBS 结构开发可能要反复几次,直到开发出一个可靠的WBS 结构。 不必夸大百分之百规则在WBS 作为计划框架使用时的重要 性。如果每一层的分解都遵循百分之百规则直到活动层,那么在 准备项目进度计划时,百分之百的相关活动才会被确定,同时百 分之百的成本或资源需求才能在计划阶段被识别。 一个 WBS 的解剖 有不同类型的项目,就有不同类型的WBS,每一个WBS 又 有独有的元素。但是,所有的WBS 结构都有图2-2 所示的5 种 类型中的两种或更多种第二层元素。 第一层 第二级 图2-2 一般的工作分解结构 图中前三种类型的元素是由三种类型的项目得来的,在 PMBOK®中关于项目的定义为:“一种临时的努力活动,产生一 个独特的产品、服务或结果。”所有类型的项目都有一个或多个 可交付成果或输出,它们是开发WBS 的基础。图中后两个元素 是支持性元素,是完全地定义项目范围和满足百分之百规则所必 需的。 这 5 种类型的元素如下: ⑴ 产品分解元素——对可交付产品物理结构的细分是最通 用和最容易开发的WBS。所有这类项目都有一个有形的输出产 品:软件、建筑物、水坝、飞机、用户手册等,所有这些都有一 整个项目 1. 产品分 解元素 3.结果分 解元素 4.横向关 联元素 2.服务分 解元素 5.项目管 理元素 个自然结构。 ⑵ 服务分解元素——服务项目没有有形的、结构性的可交 付成果。它的输出是一个为别人做的工作实体:会议、宴会、 婚礼、假期旅行等。工作分解是关于相关工作领域的一个逻辑 集合。 ⑶ 结果分解元素——结果性的项目也没有一个有形的、结 构性的可交付成果。它的输出是一个过程的结果,这个过程产 生一个产品或一个结论:癌症研究、新药物开发、文化变革等。 该工作分解是一系列可接受的步骤。 ⑷ 横向关联元素——这是横跨产品所有内容的一种分解, 如建筑设计、安装或系统测试。这些元素通常是技术性的或支 持性的。在第二级中可能有不止一个这种类型的元素。虽然没 有什么限制,但这种类型的横向关联元素在服务性项目或结果 性项目中很少见。 ⑸ 项目管理元素——这是一个项目的管理责任和管理活 动的分解。它包括这么一些内容,如报告、项目审查以及项目 经理或他们的团队成员的一些活动(从概念上来说,这些都属 于项目的上层活动)。通常,仅有一个这种类型的WBS 元素, 但是在所有的项目中它都属于第二级。 产品项目分解 产品的分解是对即将输出的产品的自然物理结果的分解, 就象图1-1 中对大象进行结构分解一样。对于车库建设项目, 如表1-1 所示,第二级中可能是车库,第三级中是材料、地基、 墙体、屋顶、公用工程。第二级中可能有不止一个输出产品或 主要可交付成果。对车库项目,美化场地是二级项目或可交付 成果,直到按照工作合同说明或图纸规定已经种植完全部植物, 并且平整完场地,这个项目才算完成。如果项目中还有一项是 高速除草机,则工作者手册会多出一项输出与之对应。例如写这本 书时,本书就是可交付成果;如果开发软件,文件源代码、操作手 册和执行程序、安装软件的CD-ROM 都是可交付成果。 产品分解通常比横向关联因素或项目管理元素有更多的级别, 某些产品的分解需要分为很多层次,这是由产品及其组件的性质决 定的,这一点可以在表1-1 车库项目的WBS 中看出来。如果车库 的一个主要组件(例如地基)被分包,它就变成了一个工作包,而 且位于WBS 的最低级。WBS 的进一步分解则成为分包商的责任, 地基也就可以看作是一个子项目。在多项目中,例如建设一个新的 体育场,分包商的WBS 可能有很多级别。在产品分解中,工作包 被分配到组织或个人,但是一些特定的资源只能被分配到作业级。 服务项目分解 没有一个有形的产品、但其目的是向个人或团体提供服务的项 目的WBS 结构有另一种WBS 元素并采用另一种分解方法。这种 分解是基于一种对相似的和相关的工作元素、职能或技术进行逻辑 分组的方法。例如,在一个目的是组织去亚洲度假旅行的项目中, 所有与投宿有关的工作都可以放在“投宿”元素下,该元素可以进 一步分解到要投宿的那个城市,活动可能包括预定、确认、交押金、 拿到地图或详细说明等。通常诸如婚礼、聚餐、会议这类项目都有 一个主要事件或目标。在这种类型的项目中,除项目管理之外的所 有WBS 元素都表示要提供的、执行的或安排的一种服务。图2-3 给出了服务性项目WBS 的结构。 这种类型项目的WBS 通常都是最初自下而上开发的,以一系 列的活动作为开始,并把这些活动按逻辑范畴或职能分组。每一个 二级元素都表示任务的一个逻辑分组,可以分开描述。进一步,每 一级的每一个元素都可以被分配到单独的人员或企业中,在元素描 述的工作群中进行实施或协调工作。 一级 二级 三级 四级 图2-3 服务性项目的WBS——国际会议项目 第二级的分解和更低层的元素是基于子元素关联父元素的 准则,关键字是“分组”。例如,“运输”可分解为:①飞机场; ② 会议宾馆的汽车;③ 旅游巴士等。这些关联于运输。同样, 注意第三级中“报告”的分解包括第四级中与报告相关的所有元 素。这点与产品WBS 不同,产品WBS 中下一级分解是“报告” 的组成部分,而不是相关事项。 在第二级中填写元素时也将注意力集中在职能上,从而对计 划进行改善。例如,在图2-3 中,如果安全是一项关注点,要在 第二级中增加安全,而不是在第三级或更低级中的其他元素中展 开。以此方式,有关安全的所有方面都被编组、集中,安全的所 有重要工作就更可能被识别。 记住百分之百规则在此适用十分重要,为了完整性,项目团 队需要对WBS 的每一级进行分析。每一项任务都需要一个WBS 父元素;在应用头脑风暴法产生任务列表的过程中,可能还需要 增加额外的WBS 元素。请利益相关者参与新项目的WBS 开发对 于一个服务性项目来说,比产品项目或结果项目更为重要,因为 会议项目 出席者 运输 设备 程序 展览 项目管理 接待 联宜活动报告 游览 论文 报告人翻译人员 没有自然的结构或元素的序列可为我们提供一个层级结构。 然而,假如一个人为一家事物管理公司工作,他就会有一个 基于原来做过的项目的模版或规范的层次。 许多详细的活动经常需要在每个工作包下执行,如审查 表。计划和进度文件可能包括:① 一个用来判断主要任务 的连续关系的网络;② 审查表,以确保所有细节任务都被 识别和分配。服务性项目的WBS 可以作为今后相似项目的 模版使用。如,所有的大型婚礼都具有相似的主要功能:需 要一个教堂(或会堂,寺院等)、出席者、接待、展示、请 柬等。同样,所有的会议、聚会、假期旅行等项目的WBS 至少在第二级是相似的,甚至可能第三级都相似。 结果项目分解 与服务性项目类似,结果类型的项目没有一个结构性很 好的主要产品作为最终可交付成果,但是可能有几个产品共 同达到理想的结果。一个结果型项目有一系列计划过的、准 确定义的步骤,是一种基于过程的项目。 图 2-4 是一个结果为在一家食品加工厂实施危险分析关 键控制点(HACCP)系统项目的WBS 结构图。此项目的目 的是将传统的依靠对最终产品进行检验来达到质量标准的 加工生产线,转变为通过实施于各关键控制点的进程控制来 达到对设计的质量进行检验的加工线。 一级 图2-4 结果型项目的WBS——HACCP 实施项目 HACCP 项目 1.工作 计划 2.产品及 工艺分析 3.危险 分析 4.质量 保证过程 5 . HACCP 计划过程 6.HACCP 实施 7.项目 管理 在这种类型的项目中,结果是成功地实施HACCP 系统,每 一条加工生产线或项目都执行同样的6 个步骤。不管是冷冻鱼虾 肉饼,还是包装鸡块或罐装汤,步骤都一样。在第三级及以下各 级也有一系列预先规定和要执行的步骤。因为每一个加工厂都不 同,而且每个项目都具有唯一性,每个步骤的中间输出的名称虽 然相似,但内容有很大差别。因此,对于相似的结果型项目,如 果要达到相同的结果,例如实施HACCP 系统以得到安全加工的 食品,最高层的WBS 是相同或相似的。 另外一个例子是开发一种新药以得到食品和药物管理部门 批准的项目,就象许多第三级元素一样。该项目的第二级和第三 级元素(或步骤)都同样重要并须受到控制,每一类项目都要遵 循的可接受的或要求的过程建立了第二级元素,第三级元素可能 也要预先规定。项目的分解是基于为达到项目目标所必需的过程 步骤。 百分之百规则适用于此,项目小组必须仔细地审查每一级中 每个父元素的子元素,以确保所有的工作都被识别。在审查中, 应使用对过程熟悉的人或专家。对任何一个WBS 审查的目的都 是相同的:确保所有的工作被识别,要满足项目目标就必须执行 这些工作。 横向关联元素 横向关联元素将WBS 横向截断,将每一层的同级元素都联 结起来,并代表如下的工作:支持产品大类的开发或内容;导致 产品生成的下一个步骤。前者的一个例子是建筑设计元素;后者 的例子是某些产品的最终检验系统测试。在第二级中可能有不止 一个这样的元素。总之,项目越复杂,越可能有多个横向关联元 素。通常,所有项目中都有“项目管理”这个横向关联元素。 横向关联元素经常包括次要的或中间的可交付成果,如支持产 品可交付成果的分析报告。支持主要的硬件(或软件)产品可交付 成果的数据经常被识别为一个横向关联元素的子部分或工作包。 对许多不同的WBS 的分析确定了横向关联元素的4 种类型: ⑴ 集成的。 ⑵ 分析的。 ⑶ 过程。 ⑷ 项目管理。 前三种类型的横向关联元素在WBS 的第二级或更低级出现, 项目管理通常属于第二级元素。 集成元素代表集成了两个或更多同级的WBS 元素的工作。这 在图2-5 组装工作的元素结构图中有所表现。 在图 2-5 所示的简化例子中,自行车产品的分解包括构架、座 位、脚蹬和车轮、车把。组装工作元素是集成元素,因为它代表合 并其他四个元素的工作。这个工作元素在第一次建立WBS 时经常 被漏掉或者被暗中假设为上一级或父元素中的一部分,这种假设违 背了百分之百规则中的“子级工作元素的总和是父级元素的百分之 百”。该工作元素是从其他WBS 同级元素流向集成元素的。在表 1-1 中,三级元素“墙体”之下的四级元素“组装”也是WBS 中 图2-5 有集成元素的WS 例子 新技术的自行车项目 项目管理 自行车初步设计 构架 座位 脚蹬和车轮车把 组装 的集成元素。 分析元素代表对同一个父级元素的所有工作元素的分析活动。 这在图2-6 个人电脑开发项目中的WBS 结构图中有所体现。 图2-6 有分析元素的WBS 的例子 在图 2-6 中,系统分析是WBS 中的一个横向关联元素。这个 元素贯穿了WBS 中的同一级和以下的所有其他元素,影响其他 WBS 元素的开发和内容。信息从分析元素流向其他元素,并影响 它们的设计、开发和内容。如果项目是写一本书或准备一个报告, 在该项目WBS 的第二级中的元素研究可能就是一个分析类型的元 素,信息从要执行的研究工作流向并影响其他元素的内容。 分析元素下一级的分解通常是与父元素类型相似的工作元素 集,服务项目中的父元素中会出现这种情况。例如,在一个系统工 程元素的下一级可能是一组相似的工程职能,如可靠性工程、可维 护工程、价值工程。这些功能的输出交付物,如一个可靠性计划或 一个可靠性分析,并且在工作陈述或合同数据需求表中都有明确说 明。 根据项目的性质,第二级元素可能会非常通用化,如简单的分 析,包括这样的内容:必要性分析、经济分析和需求分析。这类元 素与服务项目中的元素相似,代表了项目必需的按照相似性将工作 分组的方法。 新 PC 项目开发 项目管理 结构 电路板 硬盘 电源 组装 文件 个人电脑系统测试 系统分析 一个过程元素代表了工作进展的下一步。它与集成元素相 似,但是比几个元素构成的元素组或组合更贴近工作流。图2-7 说明了这一点。 图2-7 有过程元素的WBS 例子 WBS 元素中的“检测与评估”是横向关联元素,也是开发 过程的下一个步骤。如图2-7 所示,“测试与评估”元素中的执 行的工作“贯穿”了同一级中的其他元素,手册和数据、支持 设备、飞行器(飞机)、维修设施都需要做测试工作。工作流按 过程的顺序方向流动。注意,第二级中的其它4 项元素是产品 可交付成果。 在图 2-8 中,系统测试是一个过程元素,因为它是准备一 台个人计算机交付给顾客这个过程中的下一个步骤。工作沿着 过程的步骤流动。父级电路板的所有加阴影的工作包也都是过 程WBS 元素,产生电路板的中间可交付成果。 项目管理 虽然所有的WBS 结构都包括前面四种类型的WBS 元素中 的一个或多个,但在每一个WBS 结构中这些元素并不总是出 现。然而,项目管理是一种特殊类型的横向关联元素,永远出 现并且在较低级中具有集成、分析或过程元素的特征。因为所 有的项目都有项目经理,项目经理起到支持项目的作用。 飞机系统 项目管理手册和数据支持设备飞行器 维修设施 检测与评估 图2-8 有过程元素的WBS 的例子 百分之百规则要求每一级WBS 元素的总和要代表其父元 素的百分之百的工作。因为项目经理要消耗资源,所以项目管 理要涉及到的工作必须被包括进去。项目经理和项目管理办公 室的人工成本和其他费用可能计入或不计入项目的直接成本; 结果是资源被消耗了,项目管理活动也执行了。 表 2-1 包含了在项目管理执行中的典型工作包和活动的列 表。表中第四级绝大多数由工作包组成。此外还有两个零持续 时间的活动,合同授予和项目完成,它们是进度计划中十分有 用的里程碑。将它们包括在这个列表中的优点和它们的用途将 在本章后面的“WBS 编号”部分中说明。 表 2-1 项目管理WBS 元素分解 项目管理(第二级) 第三级第四级 项目起始和完成合同授予 项目完成 会议和审查 启动会议 月/季项目审查 当局的审查 新 PC 电路板硬盘 电力系统 文件PC 系统测试 结构 采购 组装 项目管理 系统分析 设计 制造 子系统测试 项目管理(第二级) 第三级 第四级 会议和审查 过程审查 结束会议 行动内容跟踪系统 报告 月度进展报告 年度报告 预算/财务状况报告 计划 项目许可证 主进度计划 项目计划(当前阶段和今后阶段) 风险管理和其他计划 项目财务和预算 控制 进度计划跟踪 成本跟踪 挣得值管理分析 偏差分析 矫正分析 周围工作 行政管理 项目管理办公室 空间/重新布置 相应的控制系统 项目支持 采购/购买 分包管理 合同管理 第三级第四级 第四级中的一些工作内容经常由上一级组织完成,可能不会出 现在项目的WBS 中。此外,如果某元素有很多的工作要执行,则 该元素可以获得第二级的地位以使其通过WBS 获得对它的注意 力。在任何情况下,如果一个元素涉及了工作和资源,这些资源和 工作将会在项目计划中有所反映。此外,编制计划的规则之一是计 划中要包含那些不能自动执行的工作内容。 百分之百规则可以应用于第三级和第四级的所有工作中,所 有重要的工作包或活动都必须被包括。计划和资源分配必须涵盖 项目管理中的大量工作。 WBS 字典 WBS 字典是用来定义和描述每一个WBS 元素中将要执行的 工作的文档。它提供的信息不必很长,但应该充分地描述所做的 工作。许多组织都发现,使用一个表格来集中WBS 字典的信息 是十分有用的。表2-2 就是这样一个典型的表格。 表2-2 WBS 字典格式示例 WBS 字典表格 项目名称: 日期: WBS 号码: 父级 WBS 号码: WBS 名称: 父级 WBS 名称: 责任人/组织(如有必要): 工作描述: 子级 WBS 号码: 子级 WBS 名称: 子级 WBS 号码: 子级 WBS 名称: 子级 WBS 号码: 子级 WBS 名称: 子级 WBS 号码: 子级 WBS 名称: 制定人: 批准人: 日期: 职务: 职务: 表格中的数据都是字典必须包含内容。然而在一些组织的实际 应用中会收集到更多的数据,诸如预算数据、计划数据、交付数据、 挣得值管理数据,都可能是特定的WBS 元素中的一部分。这些数 据对工作包是有用的,但是对总结或更高级的元素可能用不到。 下面是一个对一个名为“培训”的WBS 的典型WBS 字典描述, 可能会在第二级中出现。 WBS1.4 培训。这个元素包含可交付成果的培训服务、手册、 附件、培训帮助和培训设备,用来指导客户最大效率地学习怎样操 作和维护系统。这个元素包括所有与设计、开发、可交付成果、可 交付的培训设备的生产,以及可交付成果列表中定义的师生指导和 可交付培训服务。 WBS 字典的优势之一是用文字描述每个元素的工作规范。简 短、总结性的WBS 元素描述经常是模糊的或容易引起误解的,而 WBS 字典能够消除可能产生的任何误解。 有些计划人员发现使用字典中已实施活动的术语来描述WBS 元素十分有效。其优点是不需要WBS 字典也能够明确元素中的工 作。然而,活动术语的使用也会引起混乱,并可能会失去一个基于 名词——产品WBS 所需要的规范。使用基于活动的WBS 元素描述 的另一个缺点是很难评估是否违背了百分之百规则。 用来描述每个元素工作的WBS 字典能够方便的转变为对项目 或子项目的综合性工作陈述,字典的作者可以确信WBS 字典涉及 所有要执行的工作。因此,全部项目范围也就被清楚和易于理解地 定义了。 工作包 WBS 的最低级被定义为“工作包”级,这一级为定义活动或者 给特定的人或组织分配任务提供了一个逻辑基础。WBS 结构的 主要目的就是确保项目中要执行的所有工作都被确定。WBS 只 分解到工作包一级,但是,如果超出WBS 的范围,工作就必须 被细分到可以充分实施计划和控制的点。在工作包下面的活动级 (作业级)是网络计划执行的层次。每一个活动都有特定的和预 期的持续时间、资源、成本、绩效要求和产出,这些都被概括在 工作包中。(这将在“使用WBS 开发活动”部分详细讨论。)每 一个工作包都应该有一个指定的个人或组织对所执行的工作负 责。 工作包是一个特定组织所执行的活动的集合,通常一个特殊 的WBS 元素有一个特定的成本帐户号,这可能是一个大的分包 工作包。工作授权表中要确定预算水平、起始和终止日期、责任 组织和要执行的工作的简要陈述,工作授权表及其等价文件通常 用来批准工作包中要执行的工作。图2-9 说明了项目X 的WBS、 工作包以及活动之间的关系。 一级 二级 三 级 四级: 工作包 TEST 五级:在计划表或网络图中 测试工作包的活动 图2-9 WBS、工作包和活动之间的关系 制定测试计划 翻新电路板测试设备 安装自动测试机械 进行电路板测试 QA 通过测试结果 项目 X 项目管理文件PC 系统测试系统分析 结构 电路板 硬盘 电力系统 组装 子系统测试 设计 采购 制造 组装 由于很难收集到实际成本数据,所以在活动级控制成本通常不太 实际。然而,通常可以在实际成本数据能够累计的工作包级或更 高级控制成本。成本帐户是一个术语,用来描绘实际成本能够被 累计并能够与预算成本比较的管理控制点。这可以参考挣得值管 理系统中的挣得值BCWS。 适当的细节水平 WBS 中的内容需要有多详细?答案有很多。集中于产品的 WBS 部分通常分解到横向关联元素以下的更低级。雷泽(Raz) 和格洛伯森(Globerson)已经开发出一系列用来判断WBS 分解 程度的标准。这些标准的修订版本如表2-3 所示。 表2-3 适当的细节水平 工作包应该被进一步分解吗 下述问题的肯定回答越多,进一步分解工作包的理由就越充分 是/否 问题 有必要提高估计成本和工期的精确性吗 是不是不只一人对工作内容负责 有必要准确的知道工作包中活动的时间安排吗 在工作包的活动中需要成本支出吗 中间活动和其他工作包之间有任何关联吗 在执行工作过程中的工作元素有任何重要时间的中断吗 过一定时间工作包中的资源需求变化吗 工作元素中的中间支付的前提有区别吗 在完成整个工作包之前有合适的可接受的准则吗 工作包中要执行的一部分工作能够被作为一个单元安排吗 有需要集中精力于一部分工作包的风险吗?这些工作包需要进一步的 分解以使风险分散 工作包能够被清楚和完全地理解以满足不同的利益相关者吗 资料来源: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 中表示出来, 由第一级分解下来的第二级元素用粗体字表示,可见有许多中间 输出。其中一类输出是那些项目管理办公室为支撑项目必须做的 输出项,包括确定资金、准备分包、制定施工计划。当这些活动 完成时,应该有一个完整的书面记录。中间输出的一类必须获得 当地政府批准的许可证才能完成,每一项检查都需要检查官出具 的证明或签发的检查单。实际上,项目管理的所有二级子项目都 代表具有中间输出的工作包。 表2-6 车库项目输出 另一个WBS 头两层的例子如图2-11 所示,是一个“写书项 目”。该项目有四个二级输出,第一个是项目管理,包括会议、报 告、和审查。第二个是(一个横向关联分析类型元素)研究,各 章的写作都需要。第三个是写作,包括书的内容。研究不是一个 输入资源,而是一类要传递给写作工作的中间工作输出。写作元 素的输出不是一本完整的书,而是一系列完整的章节和其他项, 如目录和封面。第四个输出——出版——包括该书完成手稿的审 查、实际的打印和校对以及最终的印刷。(见第5 章中一个完整的 写书项目的WBS 结构。) 车库的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 美化带 书 项目管理研究 写作出版 上面列举的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 编码。 车库项目 1 1.美化场地2.车库3.项目管理 1.1 车道 1.2 美化 2.1 材料 2.2 地基 2.3 墙体 2.4 屋顶 2.5 公用设施 3.1 建设计划 3.2 许可证 3.3 检查 3.4 筹资 3.5 分包合同 报告编码。 风险管理——建立风险识别过程中的具体风险与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 个元素也可以被识别为项目,或是项目群 的阶段。一个项目阶段的定义为:一个逻辑相关的项目活动的集 合,通常以一个主要可交付成果的完成为终结。正如我们所见, 每一个这样的项目和/或阶段都满足这个定义。 一般博物馆展览项目群 项目定义 阶段 计划阶段开发和生 产阶段 收 尾 阶 段 运营和维 护阶段 项目群 管理 场地计划 展览计划 设计包装 草案包装 造型的评估 和原型制作 教育和公共 关系计划 编制项目 管理计划 计划阶段的项 目管理 开发和生产阶 段计划 收尾、运营和 维护 项目管理办公 室 仅 仅 是 所有的 项目群 元素 1.进度和预算 跟踪 2.报告 3.风险管理 4.项目审查 1.项目计划 2.项目计划审 查批准 1.初始WBS 和范围 2.初始资源、 进度和预算 1.核心小组及 扩展的小组 2.项目支持办 公室 零级 一级 A 二级 三级 图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。问题出在第二级 的元素上;产品需求——详细设计——施工——集成与测试都不 污水处理计划 设计施工 土建图 建筑图 结构图 机械图 HVAC 图 管道设备图 仪器图 电气图 拱顶 曝气塘 废水泵站 调节建筑 排污建筑 前期阶段后期阶段 是阶段,而是工作包。它们下面的第三级元素是等同的,实际上 是项目的主要输出产品。 图3-6 不正确的WBS 结构 资料来源:PMBOK® Guide: 59 通常,当一个WBS 用其所有的下一级元素来表示时,应该 对这个WBS 进行审查,看看使用垂直表示方式对产品进行分解 是否有代表性。例外的情况是,一般化的分解被用于作为一个模 版,用户被希望能够从一系列可能的元素中挑选出合适的元素。 软件产品5.0 版的首选的WBS 如图3-7 所示。在这个首选的WBS 中,有必要改变某些WBS 元素的名称,以便与要执行的工作一 致。 图3-7 由输出产品组织的WBS 举例——更适宜的WBS 结构 软件产品5.0 版 项目管理产品需求 详细设计 施工 集成与测试 计划 会议 行政管理 软件 用户文档 培训材料 软件 用户文档 培训材料 软件 用户文档 培训材料 软件 用户文档 培训材料 软件产品 5.0 版 项目管理软件 用户文档培训材料 系统集成与测试 计划 会议 行政管理 产品需求 详细设计 编码 测试 文档需求 草稿 确认 公布 培训需求 起草材料 测试 最终材料 系统集成 系统测试 着重于输出产品(软件、用户文档以及培训课程材料)的 WBS 将与其最低级的工作包更一致。 WBS 被用来组织和定义项目中的工作。然而,所有的项目都 分阶段,都有生命期,随着项目规模的增长,这些阶段就变得重 要,并需要对阶段本身进行计划。项目群包含一系列的项目,通 常有一个进行中的活动的元素。对于这些项目群,要开发一个项 目群的WBS,使得能够整合这些项目的计划。项目群的WBS 可 能在第一级有一个多项目管理元素,在每一个下一级项目中有项 目管理元素。 第章 项目运营中的WBS WBS 能够用于PMBOK®中描述的九大项目管理知识领域的 每个领域。 范围管理 范围管理包括了必需的过程,以确保项目范围包括所有为成 功完成项目所需要的并且唯一的工作。许多用于范围管理的工具 都涉及WBS。 项目章程 项目章程是用来定义项目、项目目标、输出,以及为项目实 施建立总体框架的主要文档之一。通常使用的一个类似的变形是 项目经理章程,作为项目经理和项目发起人之间的合同使用,并 建立了分配任务的参数,包括资源和职权。通常它要遵从一种委 托将资源用到项目上,它可能还包括工作陈述。 项目经理准备这个文档,然后由高层管理者检查、审批,有 时是由客户审查。在一个矩阵式结构的组织中,那些支撑组织也 必须同意。章程内容的多少和详细程度不同,取决于项目的规模, 长度通常在3 到10 页不等。对于一些小项目,项目章程可能就是 一个口头协议;然而,项目经理应该把口头协议做成文档以作为 自己的参考。 一个项目章程的段落和章节可能随着项目的不同而不同,但 是要陈述的主要领域如表4-1 中的大纲所示。这个大纲应根据项 目和项目环境有所调整。章程应该包括为获得资源所需要的所有 信息和指南,首先要建立WBS 和详细的项目计划。就本书的目 的(介绍WBS)而言,重要的内容是可交付的产品、服务或结果, 因为这些信息提供了开发WBS 的基础。 表4-1 项目章程大纲 项目目的 项目目标 项目描述概要 工作的总体描述 最终产品、服务或结果以及期望质量或性能的描述 进度和预算 要提供的资源 项目经理 职权 责任 协调要求 报告要求 设备及环境 支撑活动/组织 要供应的资源 客户与客户关系 最终产品、服务或结果的转移或交付 最终可接受的标准 WBS 提供了书面的工作陈述或范围陈述的大纲,同时提供了 用来描述项目的相关内容的框架。 工作陈述 工作陈述(SOW)是一个用清楚、可理解的术语来描述要完 成什么项目工作、要交付什么产品以及要提供什么样的服务的文 档。准备一个有效的工作陈述需要充分理解满足一个特定需求的 产品和服务。因为WBS 是基于要执行的为交付最终产品所做的 工作而建立的,所以可用来作为工作陈述的概要。对WBS 字典 仅做很小的改动就能转化为合同文本中的SOW 语言。用准确的 术语表达的工作陈述有利于在计划阶段有效的沟通,以及在实施 阶段有效的项目评价,这时SOW 就是测量项目绩效的标准。 当编写一个项目的工作陈述时,使用标准化的WBS 作为模 版有助于理顺流程。使用WBS 也有利于SOW 元素的逻辑排列。 提供一个方便的审查表以确保SOW 涵盖了所有必要的项目元素, 并引导项目满足可交付成果需要特定的合同报告或数据可交付文 档的需要。 时间管理 WBS 被用于作为计划和进度安排的框架。在应用项目管理软 件或进度计划表时,计划编制过程如表4-2 所示。 表4-2 进度计划编制过程 从 WBS 开始: 1. 把 WBS 输入到项目管理软件中 2. 在适当的WBS 下列出所有的可交付最终产品或服务;如果需要,确定 需要的进度周期 3. 在每一个最低级WBS 元素(即工作包)下定义并列出活动;如果需要, 确定活动持续时间和活动资源 4. 确定活动间的紧前——紧后关系 5. 重复步骤2~3 直到获得一个工作进度表 图 4-1 体现了第2 章“用WBS 导出活动”一节中一个的WBS 例子,并被输入到Microsoft Project 98®中。WBS 被作为活动定 义的主要输入:表4-2 过程列表的步骤1。图4-2 说明的是同一个 WBS,但它是用增加零持续时间活动的可交付成果的识别来进行 说明的。图4-3 表示在加入了活动和它们的持续时间,并且根据 逻辑关系将这些活动串联起来之后的最终进度计划。一旦完成了 WBS,这个过程就是合乎逻辑、有序和容易的。 图4-1 进度计划过程的第一步 图4-2 进度计划过程的第二步 图 4-3 用完成了的进度计划说明了步骤3 和4 的结果。这里加入 并连接了第2 章中识别的活动,识别了紧前和紧后关系。(见表 2-4 中的最终进度计划,包括项目管理活动的增加。) 图4-3 完成进度计划过程的第三步和第四步 经验表明,一旦WBS 以甘特图的形式输入到软件中,大多 数人的活动定义工作会完成得比打出描述性的活动名称快得多。 持续时间信息、资源信息和连接不需要按任何特殊的顺序来执行, 它们通常与活动定义一起执行。重要的一步是将完全的WBS 输 入到计算机程序中,直到工作包级;然后其余的活动定义就进行 得很快、很全面。经验还表明,在对活动定义的过程中要对WBS 进行修改。 成本管理 WBS 在成本管理中有5 个特殊的应用: ⑴ 自下而上的成本估计。 ⑵ 历史数据的收集。 ⑶ 科目连接图。 ⑷ 挣得值管理系统实施。 ⑸ 预算。 自下而上的成本估计 在估计项目的总成本时,自下而上的成本估计是最普遍使用 的技术。如其名称所示,它是项目的所有活动或工作包成本估计 的总和。通常,WBS 用做准备最初的综合估计和随后的预算框架。 估算过程相对简单,用在时间管理中讨论的方法识别每一项 活动,要求责任人或责任组织提供其对将要执行工作的估算。收 集这些活动级的估算并加总,就产生了总的项目估算。对一个较 大的项目,工作包或成本帐户被用做成本估算的基本组成部分。 表 4-3 是一个关于WBS 描述符收集工作包数据的典型表格, 用于自下而上的成本估算。同样的表格稍做改动就可用于活动级 的估算。这个表是一个正确的WBS 的综合,WBS 可以确保所有 的成本。然后,这个表格用于将数据输入到计算机系统中。当然, 一些有经验的人可以在进度计划制定过程中直接将这些数据输入 到计算机中。 表4-3 工作包成本估算 工作包成本估算 项目名称: WBS: 名称: 组织代码: 进度开始: 估计持续时间: 工作日: 每天所需工时数 资源名称 总工时 旅行: 起始: 日期: 人数: 其他直接成本 目的地: 目的: 咨询费: 材料: 备注与说明: 意见: 日期: 意见: 日期 历史数据的收集 DoD 用于国防产品的WBS 的目的之一,是在一个普通框架 下为7 种类型的军事系统收集数据。为了达到这个目的,对于每 个系统的上三层需要使用一种特定的WBS。“使用可获得的数据 构建历史文件,用于帮助在未来开发相似的国防产品,这是十分 有价值的资源。”WBS 的1~3 级中的每个元素都要定义(一个 WBS 字典),这些定义将进一步帮助确保所有项目的每个对应元 素的内容说明都是一致的。 在许多组织中,产品和项目都是类似的——例如,一个工程 公司专门从事设计和建设高架桥,一个软件公司专门从事相关数 据库的开发。它们的优势是开发出标准的WBS 结构和模版,至 少是在最高级,并能够收集历史成本数据和可能的其他数据。这 些数据能够用于新项目的可行性研究,帮助估算成本,并可为任 何一个新的类似项目提供最初的估算。很多有经验的组织都能够 使用多元回归技术开发出成本估算关系(CERs)。 帐户连接图 由会计部门制作的帐户图与WBS 通常没有直接的关系。WBS 是面向输出的,帐户图则确认了输入组织的费用和成本类型。典 型的例子如人工、材料以及其他直接成本帐户。对于直接成本项 与适当的项目、成本帐户、和/或工作包相联系的能力,以正确地 分配发生的成本。联系的广度取决于控制项目成本的需要、需要 的控制级别以及会计系统的能力。 挣得值管理系统的实施 挣得值管理(EVM)系统需要一个详细的WBS 和在工作包 级的WBS 与会计系统的紧密关系。通常情况下,特定企业的成 本帐户位于收集实际成本数据的WBS 的最低级,并可与预算成 本进行比较。在成本帐户内,工作包被识别、计划、预算。 在实施一个EVM 系统时,组织必须能按月明确的表述并确 定WBS 中每一个成本帐户的状况。 挣得值/绩效测量需要4 种类型的数据: ⑴ 项目拟完成工作的预算成本(BCWS)——计划值。 ⑵ 项目已完成工作的实际成本(ACWP)——实际成本。 ⑶ 项目已完成工作的预算成本(BCWP)——挣得值。 ⑷ 完工预算(EAC)。 在一个EVM 系统中,用于绩效分析的主要报告称做成本/进 度状况报告。该报告包括每个WBS 元素的从成本帐目直至整个 项目级的已计算出的成本进度的差异数据,还包括上述四类数据。 预算 就想成本估算是以WBS 为框架进行准备一样,预算也是这 样开发并与成本和谐共存的。如前所述,预算是用工作授权表的 形式来计划和向组织发布的。然后,预算就成为测量绩效的成本 基线的一部分。 沟通 WBS 为确定和组织项目中的使用的沟通机制提供了一个框 架。如果用WBS 作为一个大纲来确定讨论主题,并建立具体的 WBS 元素与项目总体工作之间的关系,将使关于项目、项目的一 部分、以及项目工作说明的讨论非常方便。所有的项目报告要求 都应与WBS 以及WBS 编号系统保持一致。通常,顾客或项目发 起人都要求用WBS 的第二级或第三级元素组织进展报告。 项目审查经常由对具体的WBS 元素的讨论构成,因为大多 数成本和进度报告都与WBS 元素有关,所以WBS 是一个公共框 架。另一个框架是组织分解结构(OBS)。活动元素和问题跟踪系 统经常使用WBS 编号作为分类的数据元素之一,并建立WBS 元 素与具体可交付成果的联系。 在讨论项目工作领域时,人们希望项目统一编码参考WBS 编号,统一编码参照编号经常是基于WBS 的。统一编码跟踪系 统有一个WBS 域,用于企业统一编码。文件系统包括按日期归 档的文件副本和用WBS 编号的主题文件。在一些大型复杂项目 中,合同内容、配置内容、工作任务的合同陈述、合同说明书, 技术和管理报告以及潜在的分包合同回件都与WBS 编号系统相 关联。 为了达到团队构建和开发一个精确的WBS 的目的,WBS 的 开发应该是团队努力的结果。优点在于:团队共同讨论WBS 元 素加深了大家对所做工作的理解,每个团队成员都将主动使自己 适应整个项目。一些地理位置分散的组织使用视频会议技术来开 发新项目的WBS,因此,可以充分发挥全公司范围内最有经验的 人能力。 采购管理 当采购一项产品或服务时,顾客通常提供某建议请求书 (RFP)中产品或服务的顶层WBS。原因之一是不同的投标者要 用相同的框架来编制计划、估算成本以及回应RFP,以利于评估 和资料来源选择。如果只外包项目中的一部分,这部分通常是项 目WBS 中一个分立的工作包。例如,房屋建筑项目中可能有 HVAC(取暖、通风和空调)系统,就是一个分立的元素,该元 素能够被清楚的识别和方便的定义。在一个可能有许多工作元素 要分包出去的项目群中,WBS 为沟通提供了方便,而且简化了项 目群的计划和控制。 单独的来自用于打算分包出去的项目WBS 元素要由项目经 理挑选,并包括进RFP 草稿中。这是客户和潜在承包商之间的首 次公开对话。创新的想法或备选方案都被收集到最终的WBS 和 RFP 中,它们包含外购产品和服务的分包WBS 和初始WBS 字典。 RFP 会引导潜在承包商选择分包WBS 元素,以定义完整的分包 范围。 承包商将分包WBS 延伸到既能满足关键的明晰的要求,又 不给管理控制系统带来负担的(WBS)层次。承包商提交的建议 应该基于RFP 中的WBS,尽管承包商可能提出必要的变更建议 以满足主要的RFP 关键需求或提高分包WBS 在满足项目群目标 中的效果。 质量与专业绩效管理 在质量管理与专业绩效管理和WBS 之间只存在有限的相互 作用,但使用WBS 元素识别系统与项目中和质量或专业绩效有 关的项目领域进行沟通的活动除外。 一个例外是编号系统被用来作为大型复杂系统项目的工作细 节(设计)。工作细节(设计)为系统或将要被开发成规范系列或 层次结构的系统构造了绩效参数。它把系统细分为组件元素,并 识别系统及其元素的绩效目标,明确的识别和量化绩效特点,这 种细分与产品WBS 分解相同。 完整的工作细节(设计)代表针对系统中分派了设计责任的 每个组件元素的绩效要求的层次结构,WBS 编号通常能识别这些 需要绩效规范的元素。由于工作细节(设计)可能不针对WBS 中的每一个元素,所以它仅对应于WBS 中与产品相关的元素。 人力资源管理 项目的人力资源管理包括能有效的使用项目人员的过程。这 样,与WBS 就存在一个有限制的界面。 开发一个有效的WBS 不象第一眼看上去那么直接。例如, 在第2 章讨论的“其他的结构概念”,在许多章节中都提供了有关 优先考虑的开发WBS 方法所需的信息。组织中一个主要的故障 是组织文化,尤其当组织和面向输入的WBS 都变得很常见时。 组织开发出一种做业务的特定方法,变更——尽管显然是很重要 的——并不总是很容易完成的。科特(Kotter)提出的战略对于将 变革引入组织文化是必要的。 开始构建项目团队的最好方法是把初始项目WBS 的开发作 为一种推进工具。这样做的好处有3 个: ① 新团队很快融入定义项目和项目范围的工作中,使项目成 为团队自身的一部分。 ② 利用团队专业技能来帮助确保所有要执行的工作都包括 在WBS 中,换句话说即WBS 是完整的。 ③ WBS 成为沟通有关有关项目信息的框架。 资源分配矩阵是用来计划人力资源使用的工具之一,企业通 过它对WBS 和工作包进行交叉参考,以明确谁应该为项目中具 体任务负责以及具体的责任类型,如绩效、批准、审查以及协调。 风险管理 项目风险管理是识别、分析、响应项目风险的系统过程,WBS 为这一过程提供了一个逻辑结构。在项目风险管理中,有两个非 常重要的WBS 领域。第一个领域是风险管理计划的输入,此时 WBS 作为编制风险管理计划的工具。这个计划描述了在整个项目 生命期中风险识别、定性与定量分析、响应计划、监控等的组织 和实施。WBS 的作用是为涉及项目风险提供一个路线图。 第二个领域是将WBS 应用于风险识别过程的输入。WBS 作 为项目中所有工作领域的审查表来使用,以识别可能的、需要分 析和监控的风险项目领域。PMBOK®中简单的描述了对风险进行 定性分析的各种技术。其中一种方法涉及到将WBS 作为框架, 并识别选定元素的风险概率及其对项目风险的影响。将这两个因 子的乘积按大小顺序排列以确定较高的风险领域。 这种评估风险的定性方法可用于任何类型的项目:简单的、 复杂的、小型的、大型的、产品、服务或结果。项目团队通过这 一过程实现对潜在问题的理解和有关团队响应的共始。 项目集成管理 在 PMBOK®中,项目集成管理是指为了确保项目中各部分高 效的协同作用所需要的过程。显然,WBS 是一种有助于实现这一 职能的工具。在PMBOK®中有两个方面涉及到WBS:①项目计 划;②配置管理。 项目计划 项目计划是一个用于指导项目执行和项目控制的文档,一个 定义至其管理控制的实施级别的WBS 被包含于项目计划中用于 底线的文档,表4-4 是一个项目计划大纲的例子。一个基于项目 计划的工作授权系统,运用WBS 的编码系统从相关的工作中获 取关联信息,它通常用于项目工作授权的批准。 表4-4 项目计划大纲的例子 Ⅰ。项目概述 Ⅱ。范围陈述 A. 项目理由 B. 项目目标 C. 假设 D. 关键成功因素 E. 主要里程碑 Ⅲ。工作分解结构 Ⅳ。项目进度 Ⅴ。详细工作计划 Ⅵ。资源计划 Ⅶ。风险管理计划 Ⅷ。质量计划 Ⅸ。沟通计划 Ⅹ。变更管理计划 Ⅺ。项目跟踪与控制 Ⅻ。项目结束 配置管理 配置管理是管理正在开发的、其需求已被明确定义的工作项 的技术配置项目范围的过程。可交付成果是在WBS、进度表、工 作陈述以及其他项目文档中指定的。 配置管理涉及定义配置项的基准配置,控制关于已交底线基 准的变更,负责并解释已获批准的变更。在建立项目的配置管理 需求时,项目经理需要指明哪一个可交付成果要服从配置管理控 制并正式描述这些可交付成果的文档。当通过合同完成项目时, 通常所有的可交付成果都受到控制,为配置管理指明的一项合同 可交付成果称为配置项。对于软件而言,这个配置项通常称作计 算机软件配置项(CSCI)。 除了可交付成果,工作合同陈述和WBS 也要服从配置管理 的控制,以控制那些会影响到工作合同陈述和WBS 的变更。WBS 和WBS 字典、范围陈述或工作陈述都载入文档以定义项目范围。 如果定义了WBS 并且项目团队和客户或发起人认为WBS 是完整 的,WBS 就成为了项目整个基准的一部分。WBS 没有覆盖的工 作不属于项目的一部分。 在项目中增加工作就是变更项目范围。项目应有一个正式的 变更管理过程,通过增加或删除工作陈述中的工作并改变项目相 应的进度计划和预算,来修改WBS 和支撑工作陈述的文档。于 是,WBS 就成为控制被称为“范围蔓延”现象的主要工具。范围 蔓延是由于在项目工作中没有经费支持的、非正式的追加工作而 产生的。阿布拉莫维奇(Abramovici)建议:“控制范围蔓延是项 目经理的一项主要任务,甚至于在编制工作的项目陈述之前他/ 她就必须要开始关注这个问题。” 当收到一个变更请求时,无论该请求是正式的还是非正式的, 分析的第一步就是确定这种变更是否影响了项目范围。如果要执 行的工作被涵盖在WBS 中,并且在WBS 字典或工作陈述中有描 述,那么这项工作就在范围之内,否则这项工作就在范围之外。 如果变更被批准,项目经理必须正式评估变更对于成本、进度、 技术性能的影响,并对合同文档和计划进行必要的改变,以实施 变更。 在 PMBOK®的九大项目管理知识领域中,WBS 是一个十分 有用的工具。它为联系所有的项目管理功能和具体的项目工作领 域提供了一个框架。 第5 章 WBS 的例子与描述 本章介绍并分析了几个不同类型的WBS 例子,分析说明本 书介绍的原理如何应用。这些例子为前面章节提到的一些相对简 单的项目例子做了补充。 这些例子包括下列5 个项目: ⑴ 一种新的管理理念的实施。 ⑵ 应对跨文化和跨国界的挑战。 ⑶ 图书写作项目。 ⑷ 宴会项目。 ⑸ 博物馆展览项目(项目定义阶段)。 例 1:实施一种新的企业级别管理理念的WBS 图 5-1 是一个WBS 的例子,该WBS 描述了在组织内实施企 业项目管理(EPM)的工作,这个WBS 是由丁斯莫尔(Dinsmore) 开发的,在此作为一个应用实例。 丁斯莫尔指出:“需要一个整体观念描绘出一条成功实施企业 项目管理的道路,所有这些都是从WBS 开始的。” 丁斯莫尔将第二级中的WBS 元素定义如下: ⑴ EPM 项目群管理——覆盖了管理EPM 项目群的关键元 素,以确保足够的管理工作集中在这个项目群上。 ⑵ 与公司目标一致的战略——执行的工作要确保项目与公 司目标一致。 ⑶ 文化改变——执行的工作要改变做事的方法。 图5-1 详细WBS——EPM 大项目 ⑷ 沟通——沟通战略和培养变更意识是必要的工作领域。 ⑸ 公司组织与流程——涉及在组织范围内进行调整和改变 流程的工作。 ⑹ 人——与人员问题有关的工作。 EPM 项目 群管理 与公司目标 一致的战略 文化改变沟通 公司的组 织与流程 人 接口领域 EPM 大项目 EPM 项目 群组织 方法论 附加程序 PMBOK® 项目领域 项目群战 略计划 项目群详细 计划、管理 与控制 项目群变 更管理 短期可交 付成果 利益相关者 分析 战略联盟 正 式声明 (EPM 许可) 运作前提 竞争中所处 位置 战略分解面 期望的 改变的描 述 现有的 组织风气 理想的 组织风气 沟通 策略 选择 渠道 创造 意识 监视 沟通成 效 财务 系统 角色 和责任 过程 技术 等级 附加界 面 共同 组织设 计 运营 工程 IT 管理 市场 质量 采购 培训 和开发 战略 团队 建设 人员 分配 能力 评估 基于 报酬的 能力 指 导 委员 会 ⑺ 接口领域——与那些存在与EPM 的接口的职能领域相关 联的工作。 分析这个WBS,这是一个服务项目,目的是通过WBS 元素表 示以下4 个主要领域: ⑴ 战略目标对位。 ⑵ 文化改变。 ⑶ 公司组织与流程。 ⑷ 人。 以上每一项都有自己的可交付成果或输出,这些可交付成果 或输出共同产生了最终产品:转化为组织内部特征的文档化和集 成了的EPM 系统。 其中有两个横向关联元素:沟通和接口领域。沟通元素是一 个分析性元素,因为它跨越了其他工作元素,并基于该分析产生 输出。接口领域下的元素是集成性元素,因为它们代表那些将其 他元素中的工作合成起来输入到九个在第三级列出的职能领域。 最后一个WBS 元素,EPM 项目群管理,是一个普通的项目管 理元素,该元素确认了项目管理办公室的管理职责与活动。 例2:应对跨文化和跨国界挑战的WBS 由于在文化、法律、期望以及沟通等方面的不同,国际间的 项目经常会遇到困难。不是每一个人都按美国人的方式进行思考 和管理的。格罗夫(Grove)、哈罗威尔(Hallowell)、史密斯 ( Smith)建议为国际项目开发一种类似的WBS,实际上,这是 一个项目中的另一个项目。其目的是管理项目的国际性方面以减 少对主要项目的影响。 其中一个不一般的特性是WBS 表述的格式。该项目的WBS 结 构如表5-1 所示。 这个WBS 表面上看是“活动”的形式,但实际上在每一个WBS 元素中都包括部分WBS 字典的内容。第三级元素是工作包,描述 表5-1 用类活动描述的WBS 举例 应对跨文化和跨国界挑战的项目的WBS 1.确定、分配、资助和掌管“文化风险 管理(CRM)团队” 1.1 CRM 团队的责任(见下面2~9) 1.2 CRM 团队在项目单元中的结构上和 功能上的地位。 1.2.1 分配的预算及责任编号:报 告确定的关系 1.2.2 项目经理及项目成员的分 派条件、轮换和确定 1.2.3 来自于CRM 团队的正式的情 况报告:时间及发布计划 2.跨文化和跨国界的信息收集 2.1 识别收集相关信息的方法 2.1.1 公司内现有的方法:HR、 T&D、图书馆、法律部门等 2.1.2 出版材料:书籍、期刊和杂 志文章、网址 2.1.3 信息提供者:国内的、“有 经验者”、跨文化顾问 2.2 相关信息的收集与分类 2.2.1 商业、规章、法律、国际贸 易 2.2.2 宗教、家庭、教育、经济、 政治等 2.2.3 工作关系、工作风格、激励、 沟通、决策等 2.2.4 与当地受训者及社会有关 的技术传递问题 2.3 研究并评估收集到的最相关的信 息 2.4 在整个项目团队中发布所选择的 信息,如有必要,翻译成母语 3.项目计划与公司业务实践风险评估 3.1 评估项目目标、WBS、预算以及时 间基准内的跨文化和跨国界风险 3.2 评估在国外的公司业务、质量、员 工实践能力中的风险 3.3 准备一个正式的风险评估陈述 4.提供给项目经理的战略和建议 4.1 开发战略,包括为避免/减少重大 的、已识别到的风险而建立的具体 的WBS 4.2 给高层管理者的具体的降低风险 战略的建议 5.适应和支持国外的项目人员 5.1 确定国外项目负责人在项目现场通常会遇 到的困难 5.2 确定公司内外部合作与帮助的来源 5.3 直接或通过顾问为项目负责人开发并提供 支持性服务 5.3.1 建立并分发指导手册 5.3.2 亲自处理项目负责人在实践中的变 更并增加所关心的其他内容 5.3.3 提供出发前在国内的文化、语言培 训 5.3.4 确定保健/安全、R&R、危机支持、 紧急事件的处理步骤 6.国内、国外项目负责人及公司总部人员的整合 6.1 比较国外与国内的工作风格与关系模式 6.2 评估总部/现场的关系及沟通障碍 6.3 比较国外与国内的社会风俗与娱乐传统 6.4 确定工作安排及活动,以逐渐整合不同的团 队 6.4.1 工作风格及同事关系预期,报告安 排 6.4.2 公司总部/现场之间的关系,沟通措 施 6.4.3 对新同事的欢迎;庆祝成功的里程碑 6.4.4 针对不同文化团队传统的社交及假 期安排 7.提供跨文化和跨国界的培训 7.1 确定项目成员关心的跨国界和跨文化问题 7.2 比较国内外培训和教育的传统 7.3 开发和提供对项目成员的培训和指导 8.文化冲突破坏了开发的遏止战略 8.1 预测最可能出现的跨文化冲突/误解情形 8.2 开发CRM 团队责任的战略以缓解冲突 9.基于CRM 团队实际经验的组织学习 9.1 包括质量方面的跨国界/跨文化风险的降 低 9.2 准备并周期性发布CRM 团队的正式情况报 告 9.3 换上有高潜能的人员作为文化风险管理者 和CRM 团队成员 9.4 听取高层政策制定人员和团队成员的报告 9.5 广泛分发CRM 全部工作的总结报告 资料来源:C Grove, W Hallowell. C Smith. A Ponallel WBS for International Project. PM Network®, 1993(3):37~42 了每一个元素将要完成“什么”工作。真正的活动是在第四和第 五级。此WBS 描述了一个成功完成的项目,所以它很好的实现了 其工作目标。 有几个主要的领域具有要获得的输出产品或结果。包括:项 目风险评估及战略的开发、国外项目人员的定位和支持、国内人 员与国外项目负责人以及总公司人员的整合、跨文化跨边界培训 的提供、伤害防止战略的开发等。这种复杂项目的WBS 开发人员 要确保遵循百分之百规则,这是非常重要的。 在横向关联领域中,信息收集是一个分析性元素,为许多其 他领域提供输入。横向关联的项目管理元素分为两个部分:元素 选拔、分配、资助和督导CRM 团队以及元素组织学习。 同一个项目的另外一种WBS 可构造成如图5-2 所示的形式。 每一个二级WBS 元素上的数字都应对于原始版本WBS 中的WBS 元 素,这些原始版本中的元素可能被转移或合并到新版本的元素中, 以简化WBS 各项。“调研和信息”元素是一个横向关联分析性元素, “项目风险”和“人员”只为主要可交付成果的产品分解提供了 基础。“项目风险”元素涉及到跨文化和跨国界元素对主要项目工 作的影响。“人员”元素的输出与针对国外项目人员、国内以及总 公司人员的计划的产品、服务和结果有关。 图5-2 应对跨文化和跨国界挑战项目的另一种WBS 2 3,4 跨文化和跨国界项目 项目管理 调研与信息项目风险 人员 一级 二级 CRM 团队 预算 报告 组织学习 数据收集 分发 风险评 估 风险缓 解策略 国外项目 集成 培训 冲突策略 1,9 5,6,7,8 例3:写书项目的WBS 写一本书或准备一个需要研究的报告是一项普通的活动。如 果主要产品是实际出版的书,有一种趋势认为研究或写作与主要 输出是一致的。图5-3 包括了比前面讨论这个例子时更详细的内 容。 图5-3 写书项目举例 “调研”元素既是一个分析元素,又是一个过程元素。“写作” 元素是一个过程元素,代表了这个项目的写作阶段。一旦写作完 成,各章节被编辑,就进入到下一个也是最后一个阶段——出版。 注意,第二级的“调研”元素通常覆盖了应用到全书的工作,第 四级的调研工作与具体各章的调研有关联。 写书项目 调研写作 出版 项目管理 数据收集 书目调研审查已完 成书稿 最 终 校对 打 印 书稿 第一章 第二章第三章 书前页 书后页 一级 二级 三级 面谈 调查 图书馆 互联网 会议 报告 审查 调研 草稿 编辑 调研 草稿 编辑 调研 草稿 编辑 封皮 序 TOP 附录 术语 索引 参考书 目 四级 例4:晚餐宴会项目的WBS 图5-4 所示的宴会项目是一个服务型项目。项目管理是第二 级中唯一的横向关联元素。这个WBS 最初是采用自下而上的方法 构造的,先列出所有的活动,然后再把它们按逻辑归类,如第二 级所示。 图5-4 宴会项目的自下而上的WBS 这个WBS 包含第一级和第二级的工作元素以及第三级的活 动。注意,食品和饮料可以在第三级中分开,分开后每一项下面 的活动应该在第四级。类似的,房间分类可以分在与清洁和宴会 环境相关的工作区域。在每一个WBS 元素下列出的活动都不存在 逻辑顺序。 构建自上而下的WBS 如图5-5 所示,最初的焦点集中在目标 和输出上。主要实际输出是宴会、邀请和房间准备。无论如何, WBS 元素(除项目管理外)都是服务型元素并代表活动的逻辑分 类,这样有利于编制计划。 一个没有具体产品服务型项目的WBS 中,通常除了项目管理 宴会1.0 客人名单1.1 房间准备1.2 食品和饮料1.3 项目管理1.4 制作请柬 邀请客人 准备客人名单 清扫楼下 清扫楼上 宴会后的整理 摆放桌子 选择音乐 清洗桌布 擦亮餐具 制作中心装饰 品 播放音乐 准备食物 选择菜单 冷藏葡萄酒 购买饮料 购买食物 制冰块 准备咖啡 进餐 列购物清单 制作任务清单 编制预算 元素之外没有横向关联元素。原因在于项目通常只有一个主要事 件,如宴会本身,但是要素没有内在的物理结构,只有逻辑上的 分类。其他的元素是补充主要事件的工作的逻辑分类。 图5-5 宴会项目的自上而下的WBS 例5:博物馆展览项目(项目定义阶段)的WBS 表5-2 是表3-3、表3-4、和图3-2、图3-3 中介绍的博物馆 展览项目群在项目群定义阶段的WBS 结构。这个WBS 是由组织中 负责这个展览项目的团队共同努力开发的,并被指定作为未来项 目的模版。项目群中的每个阶段都被视为一个独立的项目来计划, 每一个阶段都有其自己的WBS。 表5-2 博物馆展览项目群——项目群定义阶段的WBS A.1 概念及内容开发 A.1.1 中心问题 A.1.2 主题开发 A.1.3 教育目标 A.1.4 交流 A.1.5 关键设计方法及展览内容组织 A.1.6 关键的延伸部分 A.1.7 计划取消 A.2 调研与评估 A.2.1 调研 A.2.1.1 调查 A.2.1.2 相关产品回顾 A.2.1.3 听取专家意见 A.2.1.4 核心小组/扩展小组 A.2.2 评估 A.2.2.1 前后评估 宴会项目 邀请 房间准备宴会 项目管理 桌子 食品及饮料 环境 A.2.2.2 委员会小组讨论会 A.2.2.3 观众定义 A.2.2.3.1 调查 A.2.2.3.2 分析 A.2.2.3.3 报告 A.2.2.4 焦点群体 A.3 目的陈述报告 A.3.1 最初草案 A.3.2 重新拟订的草案 A.3.3 扩展的团队审查草案 A.3.4 批准草案并进行演示 A.3.5 批准的SOP(目的陈述)报告 A.4 开发与市场 A.4.1 市场概念 A.4.2 筹款的可行性 A.5 项目管理 A.5.1 定义阶段 A.5.1.1 进度计划及预算的制定与跟踪 A.5.1.2 核心及扩展团队组织的建立 A.5.1.3 风险管理 A.5.1.3.1 项目风险管理 A.5.1.3.2 权力、影响、职权分析 A.5.1.4 项目审查 A.5.1.4.1 项目进展 A.5.1.4.2 批准审查 A.5.1.5 项目报告 A.5.2 计划阶段 A.5.2.1 WBS 和范围 A.5.2.2 资源、进度计划和预算的制定 A.5.3 其他阶段 A.5.3.1 最初的WBS 和范围 A.5.3.2 最初的资源、进度计划和预算的制定 A.5.4 项目管理办公室 A.5.4.1 核心与扩展团队 A.5.4.2 项目支持办公室 项目生命期中的项目定义阶段开始于建议被批准,以及收到 继续进行项目定义的信号。这个项目的主要输出是一个被批准的 具有支持文档的目的陈述。次要输出是计划阶段的WBS 和范围陈 述、进度计划和预算,以及项目群后面阶段的初始WBS、范围描 述、进度计划和预算。 这个产品类型的项目在A.1。概念及内容开发和A.2 调研与 评估中都有横向关联的分析型WBS 元素。主要产品是A.3 目的报 告陈述,还有A.4 的A.5 开发与市场以及项目管理。第3 章曾经 讨论过项目管理元素的工作,不仅包括A.5.1 和A.5.4 中这个阶 段(项目)的项目管理工作,还包括未来阶段A.5.2 和A.5.3 中 的工作和可交付成果。 该编号系统有别于前面讨论的精确的编号系统,每一个项目 阶段都分配了一个字母前缀,这个前缀用于该阶段的所有元素。 本书所阐述的WBS 原理普遍适用于各种类型的项目,不管输 出 是产品、服务还是结果。如果要执行的工作满足项目的定义, 那么WBS 就是管理该项目的一个十分有用的工具。 第6 章 WBS 原理、步骤和审查表 本章包括3 部分内容,总结了本书前面的所有内容:①WBS 原理;②项目经理在开发WBS 时要遵循的实际步骤;③项目经理 在审查WBS 时可使用的一个推荐的审查表。 审查表,就象前面章节讲述的WBS 模版,不是代表思考,它 的使用是要方便对某些元素的思考。 图6-1 重复了第2 章中的一般WBS,但是将其扩展为包括附 加信息的结构。这个图展现了不同类型的项目和典型的下一级元 素类型,以及不同类型的横向关联元素。 产品结构 分组 分步 综合的,分析的或过 程的 图6-1 一般的工作分解结构元素 WBS 原理 下面是一组WBS 原理集,分别讨论了每一个原理。 项目群 项目群管理项目 A 项目B 正在进行的工作 1.产品分解元素2.服务分解元素3.结果分解元素4.横向关联元素5.项目管理元素 零级 一级 二级 支持与管理 顶层 一个项目群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 应该成为基准。 成为基准的WBS 应该有一个正式的变更过程。 WBS 应集中于项目输出或可交付成果,它不是一个组织 图,也不是一个进度计划或资源表。 最低级WBS 元素应该是在活动以上的那一级——工作包 级。 最低级WBS 元素应该允许对项目管理的足够的控制和可 见度。 所有WBS 的分支的最低级不必是一样的。 最低级不必太详细,否则会增加管理负担。 WBS 不反映元素间的时间关系或横向关系;所有的结构关 系都是纵向的。 开发一个WBS 的步骤 开发一个WBS 的推荐步骤如下: 步骤1:识别项目目标。(这将支持步骤2 和步骤3。) 步骤2:通过明确的识别主要输出是产品、服务或是结果来 确定项目的类型。 步骤3A:如果项目的输出是产品,第二级将包括产品名称、 次要产品名称和横向关联元素。确保所有的项目输出都与第二级 元素有关。(接第4 步。) 步骤3B:如果项目的输出是服务,第二级将包括不同类型工 作的顶级分组以及项目管理元素。识别尽可能多的活动,并将它 们按与工作领域相关的逻辑关系进行分类。(自下而上的综合。) (接第5 步。) 步骤3C:如果项目的输出是结果,第二级将包括为实现结果 所采取的必要的、公认的主要步骤以及项目管理元素。(接第6 步。) 步骤4:对于产品的WBS,将产品元素分解为产品的逻辑物理 结构。把横向关联元素分解为支持工作。(接第7 步。) 步骤5:对于服务型WBS,把第二级WBS 元素分解为逻辑职能 工作领域。(接第7 步。) 步骤6:对于结果型WBS,把第二级WBS 元素分解为要达到元 素的目标或输出所采取的特定的标准过程。(接第7 步。) 步骤7:审查每一级工作元素,以保证确认了全部的工作; 加上必要的元素。在产品型WBS 中,确保加上了必要的集成元素。 步骤8:继续将元素分解到工作包级。进一步分解可能会违 背上述原理。当下一级可能是活动或未知时停止分解,直到完成 了进一步的分析或计划。 步骤9:与项目利益相关者一起审查WBS,并进行必要的调整, 以确保覆盖了项目的所有工作。 审查表 表6-1 展示了一个项目团队用来评估WBS 充分性的审查表。 表6-1 WBS 审查表 项目小组和其他利益相关者参加WBS 的开发了吗?有专家参与吗? WBS 能反映组织是怎样工作的吗? 每一个元素的描述都能清楚地表明什么工作将要做吗? 所有的最终产品或交付都能在WBS 中被明确识别吗? 在第二级中有项目管理元素吗? 在第二级所有元素代表的工作的总和是项目的全部工作吗? 每一个父级元素下的所有子级元素所代表的工作总和是父级的全部工作吗? 有没有在需要代表“组装”类型的工作的地方加上综合元素呢? 看上去工作包的大小合理吗? WBS 元素编码与其他组织编码相关吗? 有任何父级元素代表组织的吗?如果有,要考虑重新分解那部分WBS 如果存在外包或分包,是不是一个具体组织的所有承包的工作都在一个单独的、 离散的元素下呢? 每一个元素的名字是不是都能被理解呢?或者是不是需要一个WBS 字典呢? 将WBS 简单的想象为项目工作的大纲和帮助编制一种“一次 咬一口”的计划和进度计划的工具。
|
>>> 由论坛统一发布的广告:
|
|
楼主
yijiapiaoxue

职务 无
军衔 一等兵
来自 广西壮族自治区
发帖 35篇
注册 2010/4/11
PM币 31
经验
|
|
Re:有效的工作分解结构
[回复于 2011/7/18]
|
谢谢分享
|
|
|
1楼
kirov

职务 无
军衔 一等兵
来自 黑龙江省
发帖 93篇
注册 2011/6/2
PM币 2
经验
|
|
Re:有效的工作分解结构
[回复于 2011/8/4]
|
谢谢楼住。:(刚攒下的银子,没了。
|
|
|
2楼
faning

职务 无
军衔 二等兵
来自 广东省
发帖 49篇
注册 2011/7/27
PM币 50
经验
|
|
|