9.6创建WBS 284
创建工作分解结构(WBS)是把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程。
本过程的主要作用是为所要交付的内容提供架构。它仅开展一次或仅在项目的预定义点开展。创建WBS过程的数据流向如图9-5所示。
WBS是对项目团队为实现项目目标，创建所需可交付成果而需要实施的全部工作范围的层级分解。WBS组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中所规定的工作。
WBS最低层的组成部分称为工作包，其中包括计划的工作。工作包对相关活动进行归类，
以便对工作安排进度，进行估算，开展监督与控制。在“工作分解结构”这个词语中，“工作”是指作为活动结果的工作产品或可交付成果，而不是活动本身。
9.6.1输入285
项目管理计划
创建WBS中使用的项目管理计划组件是范围管理计划。范围管理计划定义了如何根据项目范围说明书创建WBS。
项目文件
可作为创建WBS过程输入的项目文件主要包括：
需求文件：
详细描述了各种单一需求如何满足项目的业务需要。
项目范围说明书：
描述了需要实施的工作以及不包含在项目中的工作。
事业环境因素
会影响创建WBS过程的事业环境因素包括项目所在行业的WBS标准，这些标准可以作为创建WBS的外部参考资料。
组织过程资产
能够影响创建WBS过程的组织过程资产主要包括：
用于创建WBS的政策、程序和模板;以往项目的项目档案;以往项目的经验教训等。
9.6.2工具与技术285
专家判断
创建WBS过程中，应征求具备类似项目知识或经验的个人或小组的意见。
分解
分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术。工作包是WBS最低层的工作，可对其成本和持续时间进行估算和管理。分解的程度取决于所需的控制程度，以实现对项目的高效管理。工作包的详细程度则因项目规模和复杂程度而异。创建WBS的方法多种多样，常用的方法包括自上而下的方法、使用组织特定的指南、使用WBS模板。自下而上的方法可用于归并较低层次的组件。
1)分解活动
要把整个项目工作分解为工作包，通常需要开展如下活动：
①识别和分析可交付成果及相关工作;
②确定WBS的结构和编排方法;
③自上而下逐层细化分解;
④为WBS组成部分制定和分配标识编码;
⑤核实可交付成果分解的程度是否恰当。
如图9-6所示，某工作分解结构的一部分，若干分支已经向下分解到工作包层次。
2)WBS结构
WBS的结构可以采用多种形式：
以项目生命周期的各阶段作为分解的第二层，把产品和项目可交付成果放在第三层，如图9-7所示。
以主要可交付成果作为分解的第二层，如图9-8所示。
纳入由项目团队以外的组织开发的各种较低层次组件(如外包工作)。随后，作为外包工作的一部分，卖方须制定相应的合同WBS。
对WBS较高层组件进行分解，就是要把每个可交付成果或组件分解为最基本的组成部分，
即可核实的产品、服务或成果。如果采用敏捷或适应型方法，可以将长篇故事分解成用户故事。WBS可以采用提纲式、组织结构图或能说明层级结构的其他形式。
确认WBS较低层组件是完成上层相应可交付成果的必要且充分的工作，以此来核实分解的正确性。不同的可交付成果可以分解到不同的层次。某些可交付成果只需分解到下一层，即可到达工作包的层次，而另一些则须分解更多层。工作分解得越细致，对工作的规划、管理和控制就越有力。但是，过细的分解会造成管理努力的无效耗费、资源使用效率低下、工作实施效率降低，同时造成WBS各层级的数据汇总困难。
要在未来远期才完成的可交付成果或组件，当前可能无法分解。项目管理团队因而通常需要等待对该可交付成果或组成部分达成一致意见，才能够制定出WBS中的相应细节。这种技术又称为滚动式规划。
3)注意事项
在分解的过程中，应该注意以下8个方面。
WBS必须是面向可交付成果的：
项目的目标是提供产品或服务，WBS中的各项工作是为提供可交付的成果服务的。WBS并没有明确地要求重复循环的工作，但为了达到里程碑，有些工作可能要进行多次。最明显的例子是软件测试，软件必须经过多次测试后才能作为可交付成果。
WBS必须符合项目的范围：
WBS必须包括也仅包括为了完成项目的可交付成果的活动。100%原则(包含原则)认为，在WBS中，所有下一级的元素之和必须100%代表上一级的元素。如果WBS没有覆盖全部的项目可交付成果，那么最后提交的产品或服务是无法让用户满意的。
WBS的底层应该支持计划和控制：
WBS是项目管理计划和项目范围之间的桥梁，WBS的底层不但要支持项目管理计划，而且要让管理层能够监视和控制项目的进度和预算。
WBS中的元素必须有人负责，而且只有一个人负责：
如果存在没有人负责的内容，那么WBS发布后，项目团队成员将很少能够意识到自己和其中内容上的联系。WBS和责任人可以使用工作责任矩阵来描述。在一些参考文献中，这个规定又称为独立责任原则。
WBS应控制在46层：
如果项目规模比较大，以至于WBS要超过6层，此时，可以使用项目分解结构将大项目分解成子项目，然后针对子项目来做WBS。每个级别的WBS将上一级的一个元素分为47个新元素，同一级元素的大小应该相似。一个工作单元只能从属于某个上层单元，避免交叉从属。
WBS应包括项目管理工作(因为管理是项目具体工作的一部分)，也要包括分包出去的工作。
WBS的编制需要所有(主要)项目干系人的参与：
各项目干系人站在自己的立场上，对同一个项目可能编制出差别较大的WBS。项目经理应该组织他们进行讨论，以便编制出一份大家都能接受的WBS。
WBS并非是一成不变的：
在完成了WBS之后的工作中，仍然有可能需要对WBS进行修改。如果没有合理的范围控制，仅仅依靠WBS会使得后面的工作僵化。
9.6.3输出288
范围基准
范围基准是经过批准的范围说明书、WBS和相应的WBS词典，只有通过正式的变更控制程序才能进行变更，它被用作比较的基础。范围基准是项目管理计划的组成部分。
1)项目范围说明书
项目范围说明书包括对项目范围、主要可交付成果、假设条件和制约因素的描述。
2)WBS
WBS是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。工作分解结构每向下分解一层，代表对项目工作更详细的定义。
3)工作包
WBS的最低层是带有独特标识号的工作包。这些标识号为成本、进度和资源信息的逐层汇总提供了层级结构，即账户编码。每个工作包都是控制账户的一部分，而控制账户则是一个管理控制点。在该控制点上，把范围、预算和进度加以整合，并与挣值相比较来测量绩效。控制账户包含两个或更多工作包，每个工作包只与一个控制账户关联。
4)规划包
规划包是一种低于控制账户而高于工作包的工作分解结构组件，工作内容已知，但详细的进度活动未知，一个控制账户可以包含一个或多个规划包。
5)WBS字典
WBS字典是针对WBS中的每个组件，详细描述可交付成果、活动和进度信息的文件。WBS字典对WBS提供支持，其中大部分信息由其他过程创建，然后在后期添加到字典中。WBS字典中的内容一般包括：
账户编码标识、工作描述、假设条件和制约因素、负责的组织、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息等。
项目文件(更新)
可在创建WBS过程更新的项目文件主要包括：
假设日志：
随着创建WBS过程识别出更多假设条件或制约因素而更新。
需求文件：
可以更新需求文件，以反映在创建WBS过程提出并已被批准的变更。
9.7确认范围289
确认范围是正式验收已完成的项目可交付成果的过程。本过程的主要作用：
①使验收过程具有客观性;
②通过确认每个可交付成果来提高最终产品、服务或成果获得验收的可能性。确认范围过程应根据需要在整个项目期间定期开展。确认范围过程的数据流向如图9-9所示。
由主要干系人，尤其是客户或发起人审查从控制质量过程输出的核实的可交付成果，确认这些可交付成果已经圆满完成并通过正式验收。确认范围过程依据从项目范围管理知识领域的相应过程获得的输出(如需求文件或范围基准)，以及从其他知识领域的执行过程获得的工作绩效数据，对可交付成果的确认和最终验收。
确认范围的步骤
确认范围应该贯穿项目的始终。如果是在项目的各个阶段对项目的范围进行确认工作，则还要考虑如何通过项目协调来降低项目范围改变的频率，以保证项目范围的改变是有效率和适时的。确认范围的一般步骤包括：
①确定需要进行范围确认的时间;
②识别范围确认需要哪些投入;
③确定范围正式被接受的标准和要素;
④确定范围确认会议的组织步骤;
⑤组织范围确认会议。
通常情况下，在确认范围前，项目团队需要先进行质量控制工作，例如，在确认软件项目的范围之前，需要进行系统测试等工作，以确保确认工作的顺利完成。
确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量要求。控制质量过程通常先于确认范围过程，但二者也可同时进行。
需要检查的问题
项目干系人进行范围确认时，一般需要检查以下6个方面的问题：
可交付成果是否是确定的、可确认的。
每个可交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件，例如，客户的书面认可等。
是否有明确的质量标准：
可交付成果的交付不但要有明确的标准标志，而且要有是否按照要求完成的标准，可交付成果和其标准之间是否有明确联系。
审核和承诺是否有清晰的表达：
项目发起人必须正式同意项目的边界，项目完成的产品或者服务，以及项目相关的可交付成果。项目团队必须清楚地了解可交付成果是什么。所有的这些表达必须清晰，并取得一致的同意。
项目范围是否覆盖了需要完成的产品或服务的所有活动，有没有遗漏或错误。
项目范围的风险是否太高：
管理层是否能够降低风险发生时对项目的影响。
干系人关注点的不同
确认范围主要是项目干系人(例如，客户、发起人等)对项目的范围进行确认和接受的工作，每个人对项目范围所关注的方面是不同的：
管理层主要关注项目范围：
是指范围对项目的进度、资金和资源的影响，这些因素是否超过了组织承受范围，是否在投入产出上具有合理性。在确认范围工作进行之后，管理层可能会取消该项目，可能是因为项目范围太大，造成对时间、资金和资源的占有远远大于管理层的预计或者组织的承受能力。更多的情况是要求项目团队压缩范围以满足进度、资金和资源的限制。
客户主要关注产品范围：
关心项目的可交付成果是否足够完成产品或服务。有些项目的产品经理就是客户，这种情况下，可减少项目团队对产品理解失误的可能性，降低目的风险。在项目中，客户往往有在当前版本中加入所有功能和特征的意愿，这对于项目来说是一种潜在的风险，会给组织和客户带来危害和损失。
项目管理人员主要关注项目制约因素：
关心项目可交付成果是否足够和必须完成，时间、资金和资源是否足够，主要的潜在风险和预备解决的方法。
项目团队成员主要关注项目范围中自己参与的元素和负责的元素：
通过定义范围中的时间检查自己的工作时间是否足够，自己在项目范围中是否有多项工作，而这些工作是否有冲突的地方。如果项目团队成员估计某些可交付成果无法在确定的时间完成，需要提出自己的意见。
9.7.1输入291
项目管理计划
确认范围中使用的项目管理计划组件主要包括：
范围管理计划：
定义了如何正式验收已经完成的可交付成果。
需求管理计划：
描述了如何确认项目需求。
范围基准：
用范围基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。
项目文件
可作为确认范围过程输入的项目文件主要包括：
需求文件：
将需求与实际结果比较，以决定是否有必要进行变更，采取纠正措施或预防措施。
需求跟踪矩阵：
含有与需求相关的信息，包括如何确认需求。
质量报告：
该报告内容可包括由团队管理或需上报的全部质量保证事项、改进建议，以及在控制质量过程中发现的情况的概述。在验收产品之前，需要查看所有这些内容。
经验教训登记册：
在项目早期获得的经验教训可以运用到后期阶段，以提高验收可交付成果的效率与效果。
工作绩效数据
工作绩效数据可能包括符合需求的程度、不一致的数量、不一致的严重性或在某时间段内开展确认的次数。
核实的可交付成果
核实的可交付成果是指已经完成，并被控制质量过程检查为正确的可交付成果。
9.7.2工具与技术292
检查
检查是指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。检查有时也被称为审查、产品审查和巡检等。
决策
可用于确认范围过程的决策技术是投票，当由项目团队和其他干系人进行验收时，使用投票来形成结论。
9.7.3输出292
验收的可交付成果
符合验收标准的可交付成果应该由客户或发起人正式签字批准。应该从客户或发起人那里获得正式文件，证明干系人对项目可交付成果的正式验收。这些文件将提交给结束项目或阶段过程。
变更请求
对已经完成但未通过正式验收的可交付成果及其未通过验收的原因，应该记录在案。可能需要针对这些可交付成果提出变更请求，开展相应的缺陷补救工作。变更请求应该由实施整体变更控制过程进行审查与处理。
工作绩效信息
工作绩效信息包括项目进展信息，例如，哪些可交付成果已经被验收，哪些未通过验收以及原因。这些信息应该被记录下来并传递给干系人。
项目文件(更新)
可在确认范围过程更新的项目文件主要包括：
需求文件：
记录实际的验收结果，更新需求文件。需要特别注意实际结果比原定需求更好的情况，或者原定需求已经被放弃的情况。
需求跟踪矩阵：
根据验收结果更新需求跟踪矩阵，包括所采用的验收方法及其使用结果。
经验教训登记册：
更新经验教训登记册，以记录所遇到的挑战、本应如何避免该挑战的方法，以及良好的可交付成果验收的方法。
9.8控制范围292
控制范围是监督项目和产品的范围状态，管理范围基准变更的过程。本过程的主要作用是在整个项目期间保持对范围基准的维护。本过程需要在整个项目期间开展。控制范围过程的数据流向如图9-10所示。
控制项目范围确保所有变更请求、推荐的纠正措施或预防措施都通过实施整体变更控制过程进行处理。在变更实际发生时，也需要采用控制范围过程来管理这些变更。控制范围过程应该与其他项目管理知识领域的控制过程协调开展。未经控制的产品或项目范围的扩大(未对时间、成本和资源做相应调整)被称为范围蔓延。
9.8.1输入293
项目管理计划
控制范围中使用的项目管理计划组件主要包括：
范围管理计划：
记录了如何控制项目和产品范围。
需求管理计划：
记录了如何管理项目需求。
变更管理计划：
定义了管理项目变更的过程。
配置管理计划：
定义了哪些是配置项，哪些配置项需要正式变更控制，以及针对这些配置项的变更控制过程。
范围基准：
用范围基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。
绩效测量基准：
使用挣值分析时，将绩效测量基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。
项目文件
可作为控制范围过程输入的项目文件主要包括：
需求文件：
用于发现任何对商定的项目或产品范围的偏离。
需求跟踪矩阵：
有助于探查任何变更或对范围基准的任何偏离对项目目标的影响，它还可以提供受控需求的状态。
经验教训登记册：
项目早期的经验教训可以运用到后期阶段，以改进范围控制。
工作绩效数据
工作绩效数据可能包括收到的变更请求的数量，接受的变更请求的数量或者核实、确认和完成的可交付成果的数量。
组织过程资产
能够影响控制范围过程的组织过程资产主要包括：
现有的、正式的和非正式的与范围控制相关的政策、程序和指南;可用的监督和报告的方法与模板等。
9.8.2工具与技术294
数据分析
可用于控制范围过程的数据分析技术主要包括：
偏差分析：
用于将基准与实际结果进行比较，以确定偏差是否处于临界值区间内或是否有必要采取纠正或预防措施。
趋势分析：
旨在审查项目绩效随时间的变化情况，以判断绩效是正在改善还是正在恶化。
确定偏离范围基准的原因和程度，并决定是否需要采取纠正或预防措施，是项目范围控制的重要工作。
9.8.3输出294
工作绩效信息
控制范围过程产生的工作绩效信息是有关项目和产品范围实施情况(对照范围基准)的相互关联且与各种背景相结合的信息，包括收到的变更的分类、识别的范围偏差和原因、偏差对进度和成本的影响，以及对将来范围绩效的预测。
变更请求
分析项目绩效后，可能会就范围基准和进度基准，或项目管理计划的其他组成部分提出变更请求。变更请求需要经过实施整体变更控制过程的审查和处理。
项目管理计划(更新)
项目管理计划的任何变更都以变更请求的形式提出，且通过组织的变更控制过程进行处理。可能需要变更请求的项目管理计划组成部分包括：
范围管理计划：
更新范围管理计划，以反映范围管理方式的变更。
范围基准：
在针对范围、范围说明书、WBS或WBS词典的变更获得批准后，需要对范围基准做出相应的变更。有时范围偏差太过严重，以至于需要修订范围基准，以便为绩效测量提供现实可行的依据。
进度基准：
在针对范围、资源或进度估算的变更获得批准后，需要对进度基准做出相应的变更。有时进度偏差太过严重，以至于需要修订进度基准，以便为绩效测量提供现实可行的依据。
成本基准：
在针对范围、资源或成本估算的变更获得批准后，需要对成本基准做出相应的变更。有时成本偏差太过严重，以至于需要修订成本基准，以便为绩效测量提供现实可行的依据。
绩效测量基准：
在针对范围、进度绩效或成本估算的变更获得批准后，需要对绩效测量基准做出相应的变更。有时绩效偏差太过严重，需要提出变更请求来修订绩效测量基准，以便为绩效测量提供现实可行的依据。
项目文件(更新)
可在控制范围过程更新的项目文件主要包括：
需求文件：
可以通过增加或修改需求而更新需求文件。
需求跟踪矩阵：
应该随同需求文件的更新而更新需求跟踪矩阵。
经验教训登记册：
更新经验教训登记册，以记录控制范围的有效技术，以及造成偏差的原因和选择的纠正措施。
