PMP/PMBOK 可交付成果

虽然项目是临时性工作，但其可交付成果可能会在项目的终止后依然存在。项目可能产生与社会、经济、材料或环境相关的可交付成果。例如，国家纪念碑建设项目就是要创造一个流传百世的可交付成果。

在每个交叉点，可交付成果及知识在项目与运营之间转移，以完成工作交接。在这一过程中，将转移项目资源或知识到运营中，或转移运营资源到项目中。

OPM 旨在确保组织开展正确的项目并合适地分配关键资源。OPM 有助于确保组织的各个层级都了解组织的战略愿景、支持愿景的举措、目标以及可交付成果。图 1-4 展示了战略、项目组合、项目集、项目和运营相互作用的组织环境。

项目生命周期指项目从启动到完成所经历的一系列阶段。它为项目管理提供了一个基本框架。不论项目涉及的具体工作是什么，这个基本框架都适用。这些阶段之间的关系可以顺序、迭代或交叠进行。所有项目都呈现图 1-5 所示的通用的生命周期。

项目生命周期可以是预测型或适应型。项目生命周期内通常有一个或多个阶段与产品、服务或成果的开发相关，这些阶段称为开发生命周期。开发生命周期可以是预测型、迭代型、增量型、适应型或混合型的模式：

预测型生命周期，在生命周期的早期阶段确定项目范围、时间和成本。对任何范围的变更都要进行仔细管理。预测型生命周期也称为瀑布型生命周期。
迭代型生命周期，项目范围通常于项目生命周期的早期确定，但时间及成本估算将随着项目团队对产品理解的不断深入而定期修改。迭代方法是通过一系列重复的循环活动来开发产品，而增量方法是渐进地增加产品的功能。
增量型生命周期是通过在预定的时间区间内渐进增加产品功能的一系列迭代来产出可交付成果。只有在最后一次迭代之后，可交付成果具有了必要和足够的能力，才能被视为完整的。
适应型生命周期属于敏捷型、迭代型或增量型。详细范围在迭代开始之前就得到了定义和批准。适应型生命周期也称为敏捷或变更驱动型生命周期。请参见附录 X3。
混合型生命周期是预测型生命周期和适应型生命周期的组合。充分了解或有确定需求的项目要素遵循预测型开发生命周期，而仍在发展中的要素遵循适应型开发生命周期。

由项目管理团队确定各个项目最适合的生命周期。项目生命周期需要足够灵活，能够应对项目包含的各种因素。可以通过以下方法实现生命周期的灵活性：

确定需要在各个阶段实施的一个或多个过程；
在合适的阶段实施确定的一个或多个过程；
调整阶段的各种属性（例如名称、持续时间、退出标准和准入标准）。

项目生命周期与产品生命周期相互独立，后者可能由项目产生。产品生命周期指一个产品从概念、交付、成长、成熟到衰退的整个演变过程的一系列阶段。

项目阶段是一组具有逻辑关系的项目活动的集合，通常以一个或多个可交付成果的完成为结束。

生命周期的各个阶段可以通过各种不同的属性来描述。对于特定阶段，属性是可测量且独特的。属性可能包括（但不限于）：

名称（例如阶段 A、阶段 B、阶段 1、阶段 2、提建议阶段）；
数量（例如项目的三个阶段、项目的五个阶段）；
持续时间（例如一个星期、一个月、一个季度）；
资源需求（例如人力、建筑、设备）；
项目进入某一阶段的准入标准（例如已获得特定批准文件、已完成特定文件）；
项目完成某一阶段的退出标准（例如已获得批准文件、已完成文件、已达成可交付成果）。

项目可以分解为不同的阶段或子组件，这些阶段或子组件的名称通常说明了该阶段完成的工作类型。阶段名称的例子包括（但不限于）：

概念开发；
可行性研究；
客户要求；
解决方案开发；
设计；
原型法；
建造；
测试；
转换；
试运行；
里程碑审查；
经验教训。

项目阶段可基于各种因素而建立，其中包括（但不限于）：

管理需求；
项目性质；
组织、行业或技术的独特性；
项目的组成要素，包括但不限于技术、工程、业务、过程或法律；
决策点（例如资金、继续/终止项目，里程碑审查）。

分为多个阶段的方式有助于更好地掌控项目管理，同时还提供了评估项目绩效并在后续阶段采取必要的纠正或预防措施的机会。项目阶段的其中一个关键组成部分是阶段审查（见 1.2.4.3 节）。

项目生命周期是通过一系列项目管理活动进行的，即项目管理过程。每个项目管理过程通过合适的项目管理工具和技术将一个或多个输入转化成一个或多个输出。输出可以是可交付成果或结果。

结果是过程的最终成果。项目管理过程适用于全球各个行业。

各项目管理过程通过它们所产生的输出建立逻辑联系。过程可能包含了在整个项目期间相互重叠的活动。一个过程的输出通常成为以下二者之一：

另一个过程的输入；
项目或项目阶段的可交付成果。

图 1-6 的示例说明了一个过程的输入、工具、技术和输出的关系以及与其他过程的关系。

图 1-6过程示例：输入、工具与技术和输出

过程迭代的次数和过程间的相互作用因具体项目的需求而不同。过程通常分为三类：

仅开展一次或仅在项目预定义点开展的过程。例如制定项目章程以及结束项目或阶段。
根据需要定期开展的过程。在需要资源时执行获取资源。在需要采购之前执行实施采购。
贯穿项目始终执行的过程。在整个项目生命周期中可能执行的过程定义活动，特别是当项目使用滚动式规划或适应型开发方法时。从项目开始到项目结束需要持续开展许多监控过程。

项目管理通过合理运用与整合按逻辑分组的项目管理过程而得以实现。过程分类方法有很多种，但《PMBOK® 指南》把过程归纳为五大类，即五大过程组。

整个项目生命周期需要收集、分析和转化大量的数据。从各个过程收集项目数据，并在项目团队内共享。在各个过程中所收集的数据经过结合相关背景的分析、汇总，并加工成项目信息。信息通过口头形式进行传达，或以各种格式的报告存储和分发。关于这一主题的更多信息，请参见 4.3 节。

在整个项目生命周期中需要定期收集和分析项目数据。关于项目数据和信息的主要术语定义如下：

工作绩效数据。在执行项目工作的过程中，从每个正在执行的活动中收集到的原始观察结果和测量值。例如包括工作完成百分比、质量和技术绩效测量结果、进度计划活动的开始和结束日期、变更请求的数量、缺陷的数量、实际成本和实际持续时间等。项目数据通常记录在项目管理信息系统 (PMIS)（见 4.3.2.2 节）和项目文件中。
工作绩效信息。从各控制过程收集，并结合相关背景和跨领域关系进行整合分析而得到的绩效数据。绩效信息的例子包括可交付成果的状态、变更请求的落实情况及预测的完工尚需估算。
工作绩效报告。为制定决策、提出问题、采取行动或引起关注，而汇编工作绩效信息所形成的实物或电子项目文件。例如包括状况报告、备忘录、论证报告、信息札记、电子仪表盘、推荐意见和情况更新。

图 1-7 展示了项目管理各个过程中的项目信息流。

图 1-7项目数据、信息和报告流向

确定项目是否成功是项目管理中最常见的挑战之一。

时间、成本、范围和质量等项目管理测量指标历来被视为确定项目是否成功的最重要的因素。

最近，从业者和学者提出，确定项目是否成功还应考虑项目目标的实现情况。

关于项目成功的定义和最重要的因素，项目相关方可能有不同的看法。明确记录项目目标并选择可测量的目标是项目成功的关键。主要相关方和项目经理应思考以下三个问题：

怎样才是项目成功？
如何评估项目成功？
哪些因素会影响项目成功？

主要相关方和项目经理应就这些问题达成共识并予以记录。

项目成功可能涉及与组织战略和业务成果交付有关的其他标准。这些项目目标可能包括（但不限于）：

完成项目效益管理计划；
达到商业论证中记录的已商定的财务测量指标。这些财务测量指标可能包括（但不限于）：
净现值 (NPV)；
投资回报率 (ROI)；
内部报酬率 (IRR)；
回收期 (PBP)；
效益成本比率 (BCR)。
达到商业论证的非财务目标；
完成组织从“当前状态”转到“将来状态”；
履行合同条款和条件；
达到组织战略、目的和目标；
使相关方满意；
可接受的客户/最终用户的采纳度；
将可交付成果整合到组织的运营环境中；
满足商定的交付质量；
遵循治理规则；
满足商定的其他成功标准或准则（例如过程产出率）。

为了取得项目成功，项目团队必须能够正确评估项目状况，平衡项目要求，并与相关方保持积极主动的沟通。

但在业务环境中，如果项目能够与组织的战略方向持续保持一致，那么项目成功的概率就会显著提高。

有可能一个项目从范围/进度/预算来看是成功的，但从商业角度来看并不成功。这是因为业务需要和市场环境在项目完成之前发生了变化。

组织用于执行项目工作的流程与程序，包括（但不限于）：

启动和规划nn指南和标准，用于裁剪组织标准流程和程序以满足项目的特定要求；
特定的组织标准，例如政策（如人力资源政策、健康与安全政策、安保与保密政策、质量政策、采购政策和环境政策）；
产品和项目生命周期，以及方法和程序（如项目管理方法、评估指标、过程审计、改进目标、核对单、组织内使用的标准化的过程定义）；
模板（如项目管理计划、项目文件、项目登记册、报告格式、合同模板、风险分类、风险描述模板、概率与影响的定义、概率和影响矩阵，以及相关方登记册模板）；
预先批准的供应商清单和各种合同协议类型（如总价合同、成本补偿合同和工料合同）。
执行、监控：
变更控制程序，包括修改组织标准、政策、计划和程序（或任何项目文件）所须遵循的步骤，以及如何批准和确认变更；
跟踪矩阵；
财务控制程序（如定期报告、必需的费用与支付审查、会计编码及标准合同条款等）；
问题与缺陷管理程序（如定义问题和缺陷控制、识别与解决问题和缺陷，以及跟踪行动方案）。
资源的可用性控制和分配管理；
组织对沟通的要求（如可用的沟通技术、许可的沟通媒介、记录保存政策、视频会议、协同工具和安全要求）；
确定工作优先顺序、批准工作与签发工作授权的程序；
模板（如风险登记册、问题日志和变更日志）；
标准化的指南、工作指示、建议书评价准则和绩效测量准则；
产品、服务或成果的核实和确认程序。
收尾项目收尾指南或要求（如项目终期审计、项目评价、可交付成果验收、合同收尾、资源分配，以及向生产和（或）运营部门转移知识）

与其他项目经理互动有助于产生积极的影响，以满足项目的各种需求。这些需求可能是团队为完成项目而需要的人力、技术或财力资源和可交付成果。项目经理需要寻求各种方法来培养人际关系，从而帮助团队实现项目目的和目标。

战略和商务管理技能包括纵览组织概况并有效协商和执行有利于战略调整和创新的决策和行动的能力。这项能力可能涉及其他职能部门的工作知识，例如财务部、市场部和运营部。战略和商务管理技能可能还包括发展和运用相关的产品和行业专业知识。这种业务知识也被称为领域知识。项目经理应掌握足够的业务知识，以：

向其他人解释关于项目的必要商业信息；
与项目发起人、团队和主题专家合作制定合适的项目交付策略；
以实现项目商业价值最大化的方式执行策略。

为制定关于项目成功交付的最佳决策，项目经理应咨询具备关于组织运营的专业知识的运营经理。这些经理应了解组织的工作以及项目计划会对工作造成的影响。对项目经理而言，对项目主题的了解越多越好，至少应能够向其他人说明关于组织的以下方面：

战略；
使命；
目的和目标；
产品和服务；
运营（例如位置、类型、技术）；
市场和市场条件，例如客户、市场状况（发展或萎缩）和上市时间因素等；
竞争（例如什么、谁、市场地位）。

为确保一致性，项目经理应将以下关于组织的知识和信息运用到项目中：

战略；
使命；
目的和目标；
优先级；
策略；
产品或服务（例如可交付成果）。

战略和商业技能有助于项目经理确定应为其项目考虑哪些商业因素。项目经理应确定这些商业和战略因素会对项目造成的影响，同时了解项目与组织之间的相互关系。这些因素包括（但不限于）：

风险和问题；
财务影响；
成本效益分析（例如净现值、投资回报率），包括各种可选方案；
商业价值；
效益预期实现情况和战略；
范围、预算、进度和质量。

通过运用这些商务知识，项目经理能够为项目提出合适的决策和建议。随着条件的变化，项目经理应与项目发起人持续合作，使业务战略和项目策略保持一致。

4.6 实施整体变更控制 — 审查所有变更请求，批准变更，管理对可交付成果、组织过程资产、项目文件和项目管理计划的变更，并对变更处理结果进行沟通的过程。

在本过程中，与关键相关方举行会议的目的是识别项目目标、成功标准、主要可交付成果、高层级需求、总体里程碑和其他概述信息。

项目章程确保相关方在总体上就主要可交付成果、里程碑以及每个项目参与者的角色和职责达成共识。

在项目执行过程中，收集工作绩效数据并传达给合适的控制过程做进一步分析。通过分析工作绩效数据，得到关于可交付成果的完成情况以及与项目绩效相关的其他细节，工作绩效数据也用作监控过程组的输入，并可作为反馈输入到经验教训库，以改善未来工作包的绩效。

可作为本过程输入的项目文件包括（但不限于）：

变更日志。见 4.6.3.3 节。变更日志记录所有变更请求的状态。
经验教训登记册。见 4.4.3.1 节。经验教训用于改进项目绩效，以免重犯错误。登记册有助于确定针对哪些方面设定规则或指南，以使团队行动保持一致。
里程碑清单。见 6.2.3.3 节。里程碑清单列出特定里程碑的计划实现日期。
项目沟通记录。见 10.2.3.1 节。项目沟通记录包含绩效报告、可交付成果的状态，以及项目生成的其他信息。
项目进度计划。见 6.5.3.2 节。进度计划至少包含工作活动清单、持续时间、资源，以及计划的开始与完成日期。
需求跟踪矩阵。见 5.2.3.2 节。需求跟踪矩阵把产品需求连接到相应的可交付成果，有助于把关注点放在最终结果上。
风险登记册。见 11.2.3.1 节。风险登记册提供可能影响项目执行的各种威胁和机会的信息。
风险报告。见 11.2.3.2 节。风险报告提供关于整体项目风险来源的信息，以及关于已识别单个项目风险的概括信息。

一旦完成了可交付成果的第一个版本，就应该执行变更控制。用配置管理工具和程序来支持对可交付成果（如文件、软件和构件）的多个版本的控制。

例如，工作绩效数据包括已完成的工作、关键绩效指标 (KPI)、技术绩效测量结果、进度活动的实际开始日期和完成日期、已完成的故事点、可交付成果状态、进度进展情况、变更请求的数量、缺陷的数量、实际发生的成本、实际持续时间等。

变更请求是关于修改任何文件、可交付成果或基准的正式提议。如果在开展项目工作时发现问题，就可提出变更请求，对项目政策或程序、项目或产品范围、项目成本或预算、项目进度计划、项目或产品结果的质量进行修改。其他变更请求包括必要的预防措施或纠正措施，用来防止以后的不利后果。任何项目相关方都可以提出变更请求，应该通过实施整体变更控制过程（见 4.6 节）对变更请求进行审查和处理。变更请求源自项目内部或外部，是可选或由法律（合同）强制的。变更请求可能包括：

可交付成果是在某一过程、阶段或项目完成时，必须产出的任何独特并可核实的产品、成果或服务能力。它通常是为实现项目目标而完成的有形的组成部分，并可包括项目管理计划的组成部分。

所有项目都会生成新知识。有些知识应该被编撰，并在管理项目知识过程中被嵌入可交付成果，或者被用于改进过程和程序。在本过程中，也可以首次编撰或使用现有知识，例如，关于新程序的现有想法在本项目中试用并获得成功。

见 4.3.3.4 节。通过比较实际情况与计划要求，可能需要提出变更请求，来扩大、调整或缩小项目范围与产品范围，或者提高、调整或降低质量要求和进度或成本基准。变更请求可能导致需要收集和记录新的需求。变更可能会影响项目管理计划、项目文件或产品可交付成果。应该通过实施整体变更控制过程（见 4.6 节）对变更请求进行审查和处理。变更可能包括（但不限于）：

实施整体变更控制是审查所有变更请求、批准变更，管理对可交付成果、项目文件和项目管理计划的变更，并对变更处理结果进行沟通的过程。本过程审查对项目文件、可交付成果或项目管理计划的所有变更请求，并决定对变更请求的处置方案。本过程的主要作用是确保对项目中已记录在案的变更做综合评审。如果不考虑变更对整体项目目标或计划的影响就开展变更，往往会加剧整体项目风险。本过程需要在整个项目期间开展。图 4-12 描述本过程的输入、工具与技术和输出。图 4-13 是本过程的数据流向图。

很多过程都会输出变更请求。变更请求（见 4.3.3.4 节）可能包含纠正措施、预防措施、缺陷补救，以及对正式受控的项目文件或可交付成果的更新，以反映修改或增加的意见或内容。变更可能影响项目基准，也可能不影响项目基准，而只影响相对于基准的项目绩效。变更决定通常由项目经理做出。

为了便于开展配置和变更管理，可以使用一些手动或自动化的工具。配置控制重点关注可交付成果及各个过程的技术规范，而变更控制则着眼于识别、记录、批准或否决对项目文件、可交付成果或基准的变更。

工具的选择应基于项目相关方的需要，包括考虑组织和环境情况和（或）制约因素。工具应支持以下配置管理活动：

识别配置项。识别与选择配置项，从而为定义与核实产品配置、标记产品和文件、管理变更和明确责任提供基础。
记录并报告配置项状态。关于各个配置项的信息记录和报告。
进行配置项核实与审计。通过配置核实与审计，确保项目的配置项组成的正确性，以及相应的变更都被登记、评估、批准、跟踪和正确实施，从而确保配置文件所规定的功能要求都已实现。

工具还应支持以下变更管理活动：

识别变更。识别并选择过程或项目文件的变更项。
记录变更。将变更记录为合适的变更请求。
做出变更决定。审查变更，批准、否决、推迟对项目文件、可交付成果或基准的变更或做出其他决定。
跟踪变更。确认变更被登记、评估、批准、跟踪并向相关方传达最终结果。

也可以使用工具来管理变更请求和后续的决策，同时还要格外关注沟通，以帮助变更控制委员会的成员履行职责，以及向相关方传达决定。

结束项目或阶段是终结项目、阶段或合同的所有活动的过程。本过程的主要作用是，存档项目或阶段信息，完成计划的工作，释放组织团队资源以展开新的工作。它仅开展一次或仅在项目的预定义点开展。图 4-14 描述本过程的输入、工具与技术和输出。图 4-15 是本过程的数据流向图。

图 4-14结束项目或阶段：输入、工具与技术和输出

图 4-15结束项目或阶段：数据流向图

• Projectcharter在结束项目时，项目经理需要回顾项目管理计划，确保所有项目工作都已完成以及项目目标均已实现。项目或阶段行政收尾所需的必要活动包括（但不限于）：

为达到阶段或项目的完工或退出标准所必须的行动和活动，例如：
确保所有文件和可交付成果都已是最新版本，且所有问题都已得到解决；
确认可交付成果已交付给客户并已获得客户的正式验收；
确保所有成本都已记入项目成本账；
关闭项目账户；
重新分配人员；
处理多余的项目材料；
重新分配项目设施、设备和其他资源；
根据组织政策编制详尽的最终项目报告。
为关闭项目合同协议或项目阶段合同协议所必须开展的活动，例如nn确认卖方的工作已通过正式验收；
最终处置未决索赔；
更新记录以反映最后的结果；
存档相关信息供未来使用。
为完成下列工作所必须开展的活动：
收集项目或阶段记录；
审计项目成败；
管理知识分享和传递；
总结经验教训；
存档项目信息以供组织未来使用。
为向下一个阶段，或者向生产和（或）运营部门移交项目的产品、服务或成果所必须开展的行动和活动。
收集关于改进或更新组织政策和程序的建议，并将它们发送给相应的组织部门。
测量相关方的满意程度。

如果项目在完工前就提前终止，结束项目或阶段过程还需要制定程序，来调查和记录提前终止的原因。为了实现上述目的，项目经理应该引导所有合适的相关方参与本过程。

可用于本过程输入的项目文件包括（但不限于）：

假设日志。见 4.1.3.2 节。假设日志记录了与技术规范、估算、进度和风险等有关的全部假设条件和制约因素。
估算依据。见 6.4.3.2 节和 7.2.3.2 节。估算依据用于根据实际结果来评估持续时间、成本和资源估算，以及成本控制。
变更日志。见 4.6.3.3 节。变更日志包含了整个项目或阶段期间的所有变更请求的状态。
问题日志。见 4.3.3.3 节。问题日志用于确认没有未决问题。
经验教训登记册。见 4.3.3.1 节。在归入经验教训知识库之前，完成对阶段或项目经验教训的总结。
里程碑清单。见 6.2.3.3 节。里程碑清单列出了完成项目里程碑的最终日期。
项目沟通记录。见 10.2.3.1 节。项目沟通记录包含整个项目期间所有的沟通。
质量控制测量结果。见 8.3.3.1 节。质量控制测量结果记录了控制质量活动的结果，证明符合质量要求。
质量报告。见 8.2.3.1 节。质量报告的内容可包括由团队管理或需上报的全部质量保证事项、改进建议，以及在控制质量过程中发现的情况的概述。
需求文件。见 5.2.3.1 节。需求文件用于证明符合项目范围。
风险登记册。见 11.2.3.1 节。风险登记册提供了有关项目期间发生的风险的信息。
风险报告。见 11.2.3.2 节。风险报告提供了有关风险状态的信息，用于确认项目结束时没有未关闭的风险。

见 5.5.3.1 节。验收的可交付成果可包括批准的产品规范、交货收据和工作绩效文件。对于分阶段实施的项目或提前取消的项目，还可能包括部分完成或中间的可交付成果。

会议用于确认可交付成果已通过验收，确定已达到退出标准，正式关闭合同，评估相关方满意度，收集经验教训，传递项目知识和信息，以及庆祝成功。参会者可包括项目团队成员，以及参与项目或受项目影响的其他相关方。会议可以是面对面或虚拟会议，正式或非正式会议。会议的类型包括（但不限于）：收尾报告会、客户总结会、经验教训总结会，以及庆祝会。

如果项目在完工前提前终止，则需要在正式的收尾文件中说明项目终止的原因，并规定正式程序，把该项目的已完成和未完成的可交付成果移交他人。

确认范围是正式验收已完成的项目可交付成果的过程。从控制质量过程输出的核实的可交付成果是确认范围过程的输入，而验收的可交付成果是确认范围过程的输出之一，由获得授权的相关方正式签字批准。因此，相关方需要在规划阶段早期介入（有时需要在启动阶段就介入），对可交付成果的质量提出意见，以便控制质量过程能够据此评估绩效并提出必要的变更建议。

范围管理计划是项目管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。范围管理计划要对将用于下列工作的管理过程做出规定：

制定项目范围说明书；
根据详细项目范围说明书创建 WBS；
确定如何审批和维护范围基准；
正式验收已完成的项目可交付成果。

根据项目需要，范围管理计划可以是正式或非正式的，非常详细或高度概括的。

可用于本过程的数据收集技术包括（但不限于）：

头脑风暴。见 4.1.2.2 节。头脑风暴是一种用来产生和收集对项目需求与产品需求的多种创意的技术。
访谈。访谈是通过与相关方直接交谈，来获取信息的正式或非正式的方法。访谈的典型做法是向被访者提出预设和即兴的问题，并记录他们的回答。访谈经常是一个访谈者和一个被访者之间的“一对一”谈话，但也可以包括多个访谈者和/或多个被访者。访谈有经验的项目参与者、发起人和其他高管，以及主题专家，有助于识别和定义所需产品可交付成果的特征和功能。访谈也可用于获取机密信息。
焦点小组。焦点小组是召集预定的相关方和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点小组往往比“一对一”的访谈更热烈。
问卷调查。问卷调查是指设计一系列书面问题，向众多受访者快速收集信息。问卷调查方法非常适用于以下情况：受众多样化，需要快速完成调查，受访者地理位置分散，并且适合开展统计分析。
标杆对照见。 8.1.2.2 节。标杆对照将实际或计划的产品、过程和实践，与其他可比组织的实践进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。标杆对照所采用的可比组织可以是内部的，也可以是外部的。

需求文件描述各种单一需求将如何满足与项目相关的业务需求。一开始可能只有高层级的需求，然后随着有关需求信息的增加而逐步细化。只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要相关方愿意认可的需求，才能作为基准。需求文件的格式多种多样，既可以是一份按相关方和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等的详细文件。

许多组织把需求分为不同的种类，如业务解决方案和技术解决方案。前者是相关方的需要，后者是指如何实现这些需要。把需求分成不同的类别，有利于对需求进行进一步完善和细化。需求的类别包括：

业务需求。整个组织的高层级需要，例如，解决业务问题或抓住业务机会，以及实施项目的原因。
相关方需求。相关方或相关方群体的需要。
解决方案需求。为满足业务需求和相关方需求，产品、服务或成果必须具备的特性、功能和特征。解决方案需求又进一步分为功能需求和非功能需求：
功能需求。功能需求描述产品应具备的功能，例如，产品应该执行的行动、流程、数据和交互。
非功能需求。非功能需求是对功能需求的补充，是产品正常运行所需的环境条件或质量要求，例如，可靠性、保密性、性能、安全性、服务水平、可支持性、保留或清除等。
过渡和就绪需求。这些需求描述了从“当前状态”过渡到“将来状态”所需的临时能力，如数据转换和培训需求。
项目需求。项目需要满足的行动、过程或其他条件，例如里程碑日期、合同责任、制约因素等。
质量需求。用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准，例如测试、认证、确认等。

需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。使用需求跟踪矩阵，把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有商业价值。需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。最后，需求跟踪矩阵还为管理产品范围变更提供了框架。

跟踪需求包括（但不限于）：

业务需要、机会、目的和目标；
项目目标；
项目范围和 WBS 可交付成果；
产品设计；
产品开发；
测试策略和测试场景；
高层级需求到详细需求。

应在需求跟踪矩阵中记录每个需求的相关属性，这些属性有助于明确每个需求的关键信息。需求跟踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态（如进行中、已取消、已推迟、新增加、已批准、被分配和已完成）和状态日期。为确保相关方满意，可能需要增加一些补充属性，如稳定性、复杂性和验收标准。图 5-7是需求跟踪矩阵示例，其中列有相关的需求属性。

图 5-7需求跟踪矩阵示例

Programs Portfolios

此外，还需要分析现有风险、假设条件和制约因素的完整性，并做必要的增补或更新。需要多次反复开展定义范围过程：在迭代型生命周期的项目中，先为整个项目确定一个高层级的愿景，再一次针对一个迭代期明确详细范围。通常，随着当前迭代期的项目范围和可交付成果的进展，而详细规划下一个迭代期的工作。

见 4.1.2.3 节。人际关系与团队技能的一个示例是引导。在研讨会和座谈会中使用引导技能来协调具有不同期望或不同专业知识的关键相关方，使他们就项目可交付成果以及项目和产品边界达成跨职能的共识。

每个应用领域都有一种或几种普遍公认的方法，用以把高层级的产品或服务描述转变为有意义的可交付成果。首先获取高层级的需求，然后将其细化到最终产品设计所需的详细程度。产品分析技术包括（但不限于）：

项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。它记录了整个范围，包括项目和产品范围；详细描述了项目的可交付成果；还代表项目相关方之间就项目范围所达成的共识。为便于管理相关方的期望，项目范围说明书可明确指出哪些工作不属于本项目范围。

项目范围说明书使项目团队能进行更详细的规划，在执行过程中指导项目团队的工作，并为评价变更请求或额外工作是否超过项目边界提供基准。

项目范围说明书描述要做和不要做的工作的详细程度，决定着项目管理团队控制整个项目范围的有效程度。详细的项目范围说明书包括以下内容（可能直接列出或参引其他文件）：

产品范围描述。逐步细化在项目章程和需求文件中所述的产品、服务或成果的特征。
可交付成果。为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、成果或服务能力，可交付成果也包括各种辅助成果，如项目管理报告和文件。对可交付成果的描述可略可详。
验收标准。可交付成果通过验收前必须满足的一系列条件。
项目的除外责任。识别排除在项目之外的内容。明确说明哪些内容不属于项目范围，有助于管理相关方的期望及减少范围蔓延。

虽然项目章程和项目范围说明书的内容存在一定程度的重叠，但它们的详细程度完全不同。项目章程包含高层级的信息，而项目范围说明书则是对范围组成部分的详细描述，这些组成部分需要在项目过程中渐进明细。表 5-1 显示了这两个文件的一些关键内容。

表 5-1项目章程与项目范围说明书的内容

WBS 最低层的组成部分称为工作包，其中包括计划的工作。工作包对相关活动进行归类，以便对工作安排进度、进行估算、开展监督与控制。在“工作分解结构”这个词语中，“工作”是指作为活动结果的工作产品或可交付成果，而不是活动本身。

要在未来远期才完成的可交付成果或组件，当前可能无法分解。项目管理团队因而通常需要等待对该可交付成果或组成部分达成一致意见，才能够制定出 WBS 中的相应细节。这种技术有时称做滚动式规划。

范围基准是经过批准的范围说明书、WBS 和相应的 WBS 词典，只有通过正式的变更控制程序才能进行变更，它被用作比较的基础。范围基准是项目管理计划的组成部分，包括：

项目范围说明书。项目范围说明书包括对项目范围、主要可交付成果、假设条件和制约因素的描述（见 5.3.3.1 节）。
WBS。WBS 是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。工作分解结构每向下分解一层，代表对项目工作更详细的定义。
工作包。WBS 的最低层级是带有独特标识号的工作包。这些标识号为进行成本、进度和资源信息的逐层汇总提供了层级结构，构成账户编码。每个工作包都是控制账户的一部分，而控制账户则是一个管理控制点。在该控制点上，把范围、预算和进度加以整合，并与挣值相比较，以测量绩效。控制账户拥有两个或更多工作包，但每个工作包只与一个控制账户关联。
规划包。一个控制账户可以包含一个或多个规划包，其是一种低于控制账户而高于工作包的工作分解结构组件，工作内容已知，但详细的进度活动未知。
WBS 词典。WBS 词典是针对 WBS 中的每个组件，详细描述可交付成果、活动和进度信息的文件。WBS 词典对 WBS 提供支持，其中大部分信息由其他过程创建，然后在后期添加到词典中。WBS 词典中的内容可能包括（但不限于）：
账户编码标识；
工作描述；
假设条件和制约因素；
负责的组织；
进度里程碑；
相关的进度活动；
所需资源；
成本估算；
质量要求；
验收标准；
技术参考文献；
协议信息。

确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量要求。控制质量过程通常先于确认范围过程，但二者也可同时进行。

见 4.2.3.1 节。项目管理计划组件包括（但不限于）：

范围管理计划。见 5.1.3.1 节。项目管理计划定义了如何正式验收已经完成的可交付成果。
需求管理计划。见 5.1.3.2 节。需求管理计划描述了如何确认项目需求。
范围基准。见 5.4.3.1 节。用范围基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。

可作为本过程输入的项目文件包括（但不限于）：

经验教训登记册。见 4.4.3.1 节。在项目早期获得的经验教训可以运用到后期阶段，以提高验收可交付成果的效率与效果。
质量报告。见 8.2.3.1 节。质量报告的内容可包括由团队管理或需上报的全部质量保证事项、改进建议，以及在控制质量过程中发现的情况的概述。在验收产品之前，需要查看所有这些内容。
需求文件。见 5.2.3.1 节。将需求与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。
需求跟踪矩阵。见 5.2.3.2 节。需求跟踪矩阵含有与需求相关的信息，包括如何确认需求。

核实的可交付成果是指已经完成，并被控制质量过程检查为正确的可交付成果。

见 8.3.2.3 节。检查是指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。检查有时也被称为审查、产品审查和巡检等。在某些应用领域，这些术语具有独特和具体的含义。

符合验收标准的可交付成果应该由客户或发起人正式签字批准。应该从客户或发起人那里获得正式文件，证明相关方对项目可交付成果的正式验收。这些文件将提交给结束项目或阶段过程（见 4.7 节）。

工作绩效信息包括项目进展信息，例如，哪些可交付成果已经被验收，哪些未通过验收以及原因。这些信息应该被记录下来（见 10.3.3.1 节）并传递给相关方。

对已经完成但未通过正式验收的可交付成果及其未通过验收的原因，应该记录在案。可能需要针对这些可交付成果提出变更请求，开展缺陷补救。变更请求（见 4.3.3.4 节）应该由实施整体变更控制过程（见 4.6 节）进行审查与处理。

可在本过程更新的项目文件包括（但不限于）：

经验教训登记册。见 4.4.3.1 节。更新经验教训登记册，以记录所遇到的挑战、本应如何避免该挑战，以及良好的可交付成果验收方法。
需求文件。见 5.2.3.1 节。记录实际的验收结果，更新需求文件。需要特别注意实际结果比原定需求更好的情况，或者原定需求已经被放弃的情况。
需求跟踪矩阵。见 5.2.3.2 节。根据验收结果更新需求跟踪矩阵，包括所采用的验收方法及其使用结果。

工作绩效数据可能包括收到的变更请求的数量、接受的变更请求的数量，或者核实、确认和完成的可交付成果的数量。

关于敏捷/适应型环境的考虑因素适应型方法采用短周期来开展工作、审查结果，并在必要时做出调整。这些周期可针对方法和可交付成果的适用性提供快速反馈，通常表现为迭代型进度计划和拉动式按需进度计划，具体参见“项目进度管理的发展趋势和新兴实践”一节。

定义活动是识别和记录为完成项目可交付成果而须采取的具体行动的过程。本过程的主要作用是，将工作包分解为进度活动，作为对项目工作进行进度估算、规划、执行、监督和控制的基础。

见 4.2.3.1 节。项目管理计划组件包括（但不限于）：

进度管理计划。见 6.1.3.1 节。进度管理计划定义进度计划方法、滚动式规划的持续时间，以及管理工作所需的详细程度。
范围基准。见 5.4.3.1 节。在定义活动时，需明确考虑范围基准中的项目 WBS、可交付成果、制约因素和假设条件。

WBS、WBS 词典和活动清单可依次或同时编制，其中 WBS 和 WBS 词典是制定最终活动清单的基础。WBS 中的每个工作包都需分解成活动，以便通过这些活动来完成相应的可交付成果。让团队成员参与分解过程，有助于得到更好、更准确的结果。

见 4.3.3.4 节。一旦定义项目的基准后，在将可交付成果渐进明细为活动的过程中，可能会发现原本不属于项目基准的工作，这样就会提出变更请求。在这情况下，应该通过实施整体变更控制过程（见 4.6 节）对变更请求进行审查和处理。

见 4.2.3.1 节。项目管理计划组件包括（但不限于）：

进度管理计划。见 6.1.3.1 节。进度管理计划规定了排列活动顺序的方法和准确度，以及所需的其他标准。
范围基准。见 5.4.3.1 节。在排列活动顺序时，需明确考虑范围基准中的项目 WBS、可交付成果、制约因素和假设条件。

见 4.2.3.1 节。项目管理计划组件包括（但不限于）：

进度管理计划。见 6.1.3.1 节。进度管理计划规定了用于制定进度计划的进度计划编制方法和工具，以及推算进度计划的方法。
范围基准。见 5.4.3.1 节。范围说明书、WBS 和 WBS 词典包含了项目可交付成果的详细信息，供创建进度模型时借鉴。

项目进度计划是进度模型的输出，为各个相互关联的活动标注了计划日期、持续时间、里程碑和所需资源等星系。项目进度计划中至少要包括每个活动的计划开始日期与计划完成日期。即使在早期阶段就进行了资源规划，但在未确认资源分配和计划开始与完成日期之前，项目进度计划都只是初步的。一般要在项目管理计划（见 4.2.3.1 节）编制完成之前进行这些确认。还可以编制一份目标项目进度模型，规定每个活动的目标开始日期与目标完成日期。项目进度计划可以是概括（有时称为主进度计划或里程碑进度计划）或详细的。虽然项目进度计划可用列表形式，但图形方式更常见。可以采用以下一种或多种图形来呈现：

横道图。横道图也称为“甘特图”，是展示进度信息的一种图表方式。在横道图中，纵向列示活动，横向列示日期，用横条表示活动自开始日期至完成日期的持续时间。横道图相对易读，比较常用。它可能会包括浮动时间，也可能不包括，具体取决于受众。为了便于控制，以及与管理层进行沟通，可在里程碑或横跨多个相关联的工作包之间，列出内容更广、更综合的概括性活动，并在横道图报告中显示。见图 6-21 中的“概括性进度计划”部分，它按 WBS 的结构罗列相关活动。
里程碑图。与横道图类似，但仅标示出主要可交付成果和关键外部接口的计划开始或完成日期，见图 6-21 的“里程碑进度计划”部分。
项目进度网络图。这些图形通常用活动节点法绘制，没有时间刻度，纯粹显示活动及其相互关系，有时也称为“纯逻辑图”，如图 6-11 所示。项目进度网络图也可以是包含时间刻度的进度网络图，有时称为“逻辑横道图”，如图 6-21 中的详细进度计划所示。这些图形中有活动日期，通常会同时展示项目网络逻辑和项目关键路径活动等信息。本例子也显示了如何通过一系列相关活动来对每个工作包进行规划。项目进度网络图的另一种呈现形式是“时标逻辑图”，其中包含时间刻度和表示活动持续时间的横条，以及活动之间的逻辑关系。它们用于优化展现活动之间的关系，许多活动都可以按顺序出现在图的同一行中。

图 6-21 是一个正在执行的示例项目的进度计划，工作进展是通过截止日期或状态日期表示的。针对

一个简单的项目，图 6-21 给出了进度计划的三种形式：（1）里程碑进度计划，也叫里程碑图；（2）概括性进度计划，也叫横道图；（3）详细进度计划，也叫项目进度关联横道图。图 6-21 还直观地显示出项目进度计划不同详细程度的关系。

图 6-21项目进度计划示例

控制进度是监督项目状态，以更新项目进度和管理进度基准变更的过程。本过程的主要作用是在整个项目期间保持对进度基准的维护，且需要在整个项目期间开展。图 6-22 描述本过程的输入、工具与技术和输出，图 6-23 是本过程的数据流程图。

图 6-22控制进度：输入、工具与技术和输出

图 6-23控制进度：数据流程图

要更新进度模型，就需要了解迄今为止的实际绩效。进度基准的任何变更都必须经过实施整体变更控制过程的审批（见 4.6 节）。控制进度作为实施整体变更控制过程的一部分，关注如下内容：

判断项目进度的当前状态；
对引起进度变更的因素施加影响；
重新考虑必要的进度储备；
判断项目进度是否已经发生变更；
在变更实际发生时对其进行管理。

如果采用敏捷方法，控制进度要关注如下内容：

通过比较上一个时间周期中已交付并验收的工作总量与已完成的工作估算值，来判断项目进度的当前状态；
实施回顾性审查（定期审查，记录经验教训），以便纠正与改进过程（如果需要的话）；
对剩余工作计划（未完项）重新进行优先级排序；
确定每次迭代时间（约定的工作周期持续时间，通常是两周或一个月）内可交付成果的生成、核实和验收的速度；
确定项目进度已经发生变更；
在变更实际发生时对其进行管理。

将工作外包时，定期向承包商和供应商了解里程碑的状态更新是确保工作按商定进度进行的一种途径，有助于确保进度受控。同时，应执行进度状态评审和巡检，确保承包商报告准确且完整。

见 4.2.3.1 节。项目管理计划组件包括（但不限于）：

进度管理计划。见 6.1.3.1 节。进度管理计划描述了进度的更新频率、进度储备的使用方式，以及进度的控制方式。
进度基准。见 6.5.3.1 节。把进度基准与实际结果相比，以判断是否需要进行变更或采取纠正或预防措施。
范围基准。见 5.4.3.1 节。在监控进度基准时，需明确考虑范围基准中的项目 WBS、可交付成果、制约因素和假设条件。
绩效测量基准。见 4.2.3.1 节。使用挣值分析时，将绩效测量基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。

见 4.2.3.1 节。项目管理计划组件包括（但不限于）：

成本管理计划。见 7.1.3.1 节。成本管理计划描述了可使用的估算方法以及成本估算需要达到的准确度和精确度。
质量管理计划。见 8.1.3.1 节。质量管理计划描述了项目管理团队为实现一系列项目质量目标所需的活动和资源。
范围基准。见 5.4.3.1 节。范围基准包括项目范围说明书、WBS 和 WBS 词典：
项目范围说明书。范围说明书（见 5.3.3.1 节）反映了因项目资金支出的周期而产生的资金制约因素，或其他财务假设条件和制约因素。
工作分解结构。WBS（见 5.4.3.1 节）指明了项目全部可交付成果及其各组成部分之间的相互关系。
WBS 词典。在 WBS 词典（见 5.4.3 节）和相关的详细工作说明书中，列明了可交付成果，并描述了为产出可交付成果，WBS 各组成部分所需进行的工作。

应急储备是包含在成本基准内的一部分预算，用来应对已识别的风险；应急储备还通常是预算的一部分，用来应对那些会影响项目的“已知 — 未知”风险。例如，可以预知有些项目可交付成果需要返工，却不知道返工的工作量是多少。可以预留应急储备来应对这些未知数量的返工工作。小至某个具体活动，大到整个项目，任何层级都可有其应急储备。应急储备可取成本估算值的某一百分比、某个固定值，或者通过定量分析来确定；

为促进频繁的増量交付，敏捷方法关注于小批量工作，纳入尽可能多的项目可交付成果的要素。

质量规划应与其他规划过程并行开展。例如，为满足既定的质量标准而对可交付成果提出变更，可能需要调整成本或进度计划，并就该变更对相关计划的影响进行详细风险分析。

见 4.2.3.1 节。项目管理计划组件包括（但不限于）：

需求管理计划。见 5.1.3.2 节。需求管理计划提供了识别、分析和管理需求的方法，以供质量管理计划和质量测量指标借鉴。
风险管理计划。见 11.1.3.1 节。风险管理计划提供了识别、分析和监督风险的方法。将风险管理计划和质量管理计划的信息相结合，有助于成功交付产品和项目。
相关方参与计划。见 13.2.3.1 节。相关方参与计划提供了记录相关方需求和期望的方法，为质量管理奠定了基础。
范围基准。见 5.4.3.1 节。在确定适用于项目的质量标准和目标时，以及在确定要求质量审查的项目可交付成果和过程时，需要考虑WBS和项目范围说明书中记录的可交付成果。范围说明书包含可交付成果的验收标准。该标准的界定可能导致质量成本并进而导致项目成本的显著升高或降低。满足所有的验收标准意味着满足相关方的需求。

可作为本过程输入的项目文件包括（但不限于）：

假设日志。见 4.1.3.2 节。假设日志记录与质量要求和标准合规性有关的所有假设条件和制约因素。
需求文件。见 5.2.3.1 节。需求文件记录项目和产品为满足相关方的期望应达到的要求，它包括（但不限于）针对项目和产品的质量要求。这些需求有助于项目团队规划将如何实施项目质量控制。
需求跟踪矩阵。见 5.2.3.2 节。需求跟踪矩阵将产品需求连接到可交付成果，有助于确保需求文件中的各项需求都得到测试。矩阵提供了核实需求时所需测试的概述。
风险登记册。见 11.2.3.1 节。风险登记册包含可能影响质量要求的各种威胁和机会的信息。
相关方登记册。见 13.1.3.1 节。相关方登记册有助于识别对质量有特别兴趣或影响的相关方，尤其注重客户和项目发起人的需求和期望。

能够影响规划质量管理过程的事业环境因素包括（但不限于）：

政府法规；
特定应用领域的相关规则、标准和指南；
地理分布；
组织结构。
市场条件；
项目或可交付成果的工作条件或运行条件；
文化观念。

适用于本过程的数据分析技术包括（但不限于）：

成本效益分析。成本效益分析是用来估算备选方案优势和劣势的财务分析工具，以确定可以创造最佳效益的备选方案。成本效益分析可帮助项目经理确定规划的质量活动是否有效利用了成本。达到质量要求的主要效益包括减少返工、提高生产率、降低成本、提升相关方满意度及提升赢利能力。对每个质量活动进行成本效益分析，就是要比较其可能成本与预期效益。
质量成本。与项目有关的质量成本 (COQ) 包含以下一种或多种成本（图 8-5 提供了各组成本的例子）：
预防成本。预防特定项目的产品、可交付成果或服务质量低劣所带来的相关成本。
评估成本。评估、测量、审计和测试特定项目的产品、可交付成果或服务所带来的相关成本。
失败成本（内部/外部）。因产品、可交付成果或服务与相关方需求或期望不一致而导致的相关成本。

最优 COQ 能够在预防成本和评估成本之间找到恰当的投资平衡点，以规避失败成本。有关模型表明，最优项目质量成本，指在投资额外的预防/评估成本时，既无益处又不具备成本效益。

图 8-5质量成本

在规划阶段，项目经理和项目团队决定如何测试或检查产品、可交付成果或服务，以满足相关方的需求和期望，以及如何满足产品的绩效和可靠性目标。不同行业有不同的测试与检查，可能包括软件项目的 α 测试和 β 测试、建筑项目的强度测试、制造和实地测试的检查，以及工程的无损伤测试。

质量管理计划是项目管理计划的组成部分，描述如何实施适用的政策、程序和指南以实现质量目标。它描述了项目管理团队为实现一系列项目质量目标所需的活动和资源。质量管理计划可以是正式或非正式的，非常详细或高度概括的，其风格与详细程度取决于项目的具体需要。应该在项目早期就对质量管理计划进行评审，以确保决策是基于准确信息的。这样做的好处是，更加关注项目的价值定位，降低因返工而造成的成本超支金额和进度延误次数。

质量管理计划包括（但不限于）以下组成部分：

项目采用的质量标准；
项目的质量目标；
质量角色与职责；
需要质量审查的项目可交付成果和过程；
为项目规划的质量控制和质量管理活动；
项目使用的质量工具；
与项目有关的主要程序，例如处理不符合要求的情况、纠正措施程序，以及持续改进程序。

见 4.2.3.1 节。项目管理计划组件包括（但不限于）质量管理计划。如 8.1.3.1 节所述，质量管理计划定义了项目和产品质量的可接受水平，并描述了如何确保可交付成果和过程达到这一质量水平。

可作为本过程输入的项目文件包括（但不限于）：

经验教训登记册。见 4.4.3.1 节。项目早期与质量管理有关的经验教训，可以运用到项目后期阶段，以提高质量管理的效率与效果。
质量控制测量结果。见 8.3.3.1 节。质量控制测量结果用于分析和评估项目过程和可交付成果的质量是否符合执行组织的标准或特定要求。质量控制测量结果也有助于分析这些测量结果的产生过程，以确定实际测量结果的正确程度。
质量测量指标。见 8.1.3.2 节。核实质量测量指标是控制质量过程的一个环节。管理质量过程依据这些质量测量指标设定项目的测试场景和可交付成果，用作改进举措的依据。
风险报告。见 11.2.3.2 节。管理质量过程使用风险报告识别整体项目风险的来源以及整体风险敞口的最重要的驱动因素，这些因素能够影响项目的质量目标。

适用于本过程的数据表现技术包括（但不限于）：

亲和图。见 5.2.2.5 节。亲和图可以对潜在缺陷成因进行分类，展示最应关注的领域。
因果图。因果图，又称“鱼骨图”、“why-why分析图”和“石川图”，将问题陈述的原因分解为离散的分支，有助于识别问题的主要原因或根本原因。图 8-9 是因果图的一个例子。
流程图。见 8.1.2.5 节。流程图展示了引发缺陷的一系列步骤。
直方图。直方图是一种展示数字数据的条形图，可以展示每个可交付成果的缺陷数量、缺陷成因的排列、各个过程的不合规次数，或项目或产品缺陷的其他表现形式。
矩阵图。见 8.1.2.5 节。矩阵图在行列交叉的位置展示因素、原因和目标之间的关系强弱。
散点图。散点图是一种展示两个变量之间的关系的图形，它能够展示两支轴的关系，一支轴表示过程、环境或活动的任何要素，另一支轴表示质量缺陷。

图 8-9因果图

问题解决发现解决问题或应对挑战的解决方案。它包括收集其他信息、具有批判性思维的、创造性的、量化的和/或逻辑性的解决方法。有效和系统化地解决问题是质量保证和质量改进的基本要素。问题可能在控制质量过程或质量审计中发现，也可能与过程或可交付成果有关。使用结构化的问题解决方法有助于消除问题和制定长久有效的解决方案。问题解决方法通常包括以下要素：

控制质量是为了评估绩效，确保项目输出完整、正确且满足客户期望，而监督和记录质量管理活动执行结果的过程。本过程的主要作用是，核实项目可交付成果和工作已经达到主要相关方的质量要求，可供最终验收。控制质量过程确定项目输出是否达到预期目的，这些输出需要满足所有适用标准、要求、法规和规范。本过程需要在整个项目期间开展。

可交付成果指的是在某一过程、阶段或项目完成时，必须产出的任何独特并可核实的产品、成果或服务能力。作为指导与管理项目工作过程的输出的可交付成果将得到检查，并与项目范围说明书定义的验收标准作比较。

能够影响控制质量过程的事业环境因素包括（但不限于）：

项目管理信息系统；质量管理软件可用于跟进过程或可交付成果中的错误和差异；
政府法规；
特定应用领域的相关规则、标准和指南。

测试是一种有组织的、结构化的调查，旨在根据项目需求提供有关被测产品或服务质量的客观信息。测试的目的是找出产品或服务中存在的错误、缺陷、漏洞或其他不合规问题。用于评估各项需求的测试的类型、数量和程度是项目质量计划的一部分，具体取决于项目的性质、时间、预算或其他制约因素。测试可以贯穿于整个项目，可以随着项目的不同组成部分变得可用时进行，也可以在项目结束（即交付最终可交付成果）时进行。早期测试有助于识别不合规问题，帮助减少修补不合规组件的成本。

控制质量过程的一个目的就是确定可交付成果的正确性。开展控制质量过程的结果是核实的可交付成果，后者又是确认范围过程的一项输入（见 5.5 节），以便正式验收。如果存在任何与可交付成果有关的变更请求或改进事项，可能会执行变更、开展检查并重新核实。

可在本过程更新的项目文件包括（但不限于）：

问题日志。见 4.3.3.3 节。多次不符合质量要求的可交付成果通常被记录为问题。
经验教训登记册。见 4.4.3.1 节。质量缺陷的来源、本应可以规避它们的方法，以及有效的处理方式，都应该记录到经验教训登记册中。
风险登记册。见 11.2.3.1 节。在本过程中识别的新风险记录在风险登记册中，并通过风险管理过程进行管理。
测试与评估文件。见 8.2.3.2 节。本过程可能导致测试与评估文件修改，使未来的测试更加有效。

见 4.2.3.1 节。项目管理计划组件包括（但不限于）：

质量管理计划。见 8.1.3.1 节。质量管理计划有助于定义项目所需的资源水平，以实现和维护已定义的质量水平并达到项目测量指标。
范围基准。见 5.4.3.1 节。范围基准识别了可交付成果，决定了需要管理的资源的类型和数量。

适用于本过程的数据表现技术包括（但不限于）图表。数据表现有多种格式来记录和阐明团队成员的角色与职责。大多数格式属于层级型、矩阵型或文本型。有些项目人员安排可以在子计划（如风险、质量或沟通管理计划）中列出。无论使用什么方法来记录团队成员的角色，目的都是要确保每个工作包都有明确的责任人，确保全体团队成员都清楚地理解其角色和职责。层级型可用于表示高层级角色，而文本型则更适合用于记录详细职责。

层级型。可以采用传统的组织结构图，自上而下地显示各种职位及其相互关系。
工作分解结构 (WBS)。WBS 用来显示如何把项目可交付成果分解为工作包，有助于明确高层级的职责。
组织分解结构 (OBS)。WBS 显示项目可交付成果的分解，而 OBS 则按照组织现有的部门、单元或团队排列，并在每个部门下列出项目活动或工作包。运营部门（如信息技术部或采购部）只需要找到其所在的 OBS 位置，就能看到自己的全部项目职责。
资源分解结构。资源分解结构是按资源类别和类型，对团队和实物资源的层级列表，用于规划、管理和控制项目工作。每向下一个层次都代表对资源的更详细描述，直到信息细到可以与工作分解结构（WBS）相结合，用来规划和监控项目工作。
责任分配矩阵。责任分配矩阵展示项目资源在各个工作包中的任务分配。矩阵型图表的一个例子是职责分配矩阵(RAM)，它显示了分配给每个工作包的项目资源，用于说明工作包或活动与项目团队成员之间的关系。在大型项目中，可以制定多个层次的 RAM。例如，高层次的RAM 可定义项目团队、小组或部门负责 WBS 中的哪部分工作，而低层次的 RAM 则可在各小组内为具体活动分配角色、职责和职权。矩阵图能反映与每个人相关的所有活动，以及与每项活动相关的所有人员，它也可确保任何一项任务都只有一个人负责，从而避免职权不清。RAM的一个例子是 RACI（执行、负责、咨询和知情）矩阵，如图 9-4 所示。图中最左边的一列表示有待完成的工作（活动）。分配给每项工作的资源可以是个人或小组，项目经理也可根据项目需要，选择“领导”或“资源”等适用词汇，来分配项目责任。如果团队是由内部和外部人员组成，RACI 矩阵对明确划分角色和职责特别有用。
文本型。如果需要详细描述团队成员的职责，就可以采用文本型。文本型文件通常以概述的形式，提供诸如职责、职权、能力和资格等方面的信息。这种文件有多种名称，如职位描述、角色 — 职责 — 职权表，该文件可作为未来项目的模板，特别是在根据当前项目的经验教训对其内容进行更新之后。

图 9-4 RACI 矩阵示例

作为项目管理计划的一部分，资源管理计划提供了关于如何分类、分配、管理和释放项目资源的指南。资源管理计划可以根据项目的具体情况分为团队管理计划和实物资源管理计划。资源管理计划可能包括（但不限于）：

识别资源。用于识别和量化项目所需的团队和实物资源的方法。
获取资源。关于如何获取项目所需的团队和实物资源的指南。
角色与职责。
角色。在项目中，某人承担的职务或分配给某人的职务，如土木工程师、商业分析师和测试协调员。
职权。使用项目资源、做出决策、签字批准、验收可交付成果并影响他人开展项目工作的权力。例如，下列事项都需要由具有明确职权的人来做决策：选择活动的实施方法，质量验收标准，以及如何应对项目偏差等。当个人的职权水平与职责相匹配时，团队成员就能最好地开展工作。
职责。为完成项目活动，项目团队成员必须履行的职责和工作。
能力。为完成项目活动，项目团队成员需具备的技能和才干。如果项目团队成员不具备所需的能力，就不能有效地履行职责。一旦发现成员的能力与职责不匹配，就应主动采取措施，如安排培训、招募新成员、调整进度计划或工作范围。
项目组织图。项目组织图以图形方式展示项目团队成员及其报告关系。基于项目的需要，项目组织图可以是正式或非正式的，非常详细或高度概括的。例如，一个 3000 人的灾害应急团队的项目组织图，要比仅有 20 人的内部项目的组织图详尽得多。
项目团队资源管理。关于如何定义、配备、管理和最终遣散项目团队资源的指南。
培训。针对项目成员的培训策略。
团队建设。建设项目团队的方法。
资源控制。依据需要确保实物资源充足可用、并为项目需求优化实物资源采购，而采用的方法。包括有关整个项目生命周期期间的库存、设备和用品管理的信息。
认可计划。将给予团队成员哪些认可和奖励，以及何时给予。

建设团队是提高工作能力，促进团队成员互动，改善团队整体氛围，以提高项目绩效的过程。

本过程的主要作用是，改进团队协作、增强人际关系技能、激励员工、减少摩擦以及提升整体项目绩效。本过程需要在整个项目期间开展。

图 9-10 描述本过程的输入、工具与技术和输出。图 9-11 是本过程的数据流向图。

图 9-10建设团队：输入、工具与技术和输出

• Projectcharter图 9-11建设团队：数据流向图

项目经理应该能够定义、建立、维护、激励、领导和鼓舞项目团队，使团队高效运行，并实现项目目标。团队协作是项目成功的关键因素，而建设高效的项目团队是项目经理的主要职责之一。

项目经理应创建一个能促进团队协作的环境，并通过给予挑战与机会、提供及时反馈与所需支持，以及认可与奖励优秀绩效，不断激励团队。通过以下行为可以实现团队的高效运行：

使用开放与有效的沟通；
创造团队建设机遇；
建立团队成员间的信任；
以建设性方式管理冲突；
鼓励合作型的问题解决方法；
鼓励合作型的决策方法。

项目经理在全球化环境和富有文化多样性的项目中工作：团队成员经常来自不同的行业，讲不同的语言，有时甚至会在工作中使用一种特别的“团队语言”或文化规范，而不是使用他们的母语；

项目管理团队应该利用文化差异，在整个项目生命周期中致力于发展和维护项目团队，并促进在相互信任的氛围中充分协作；通过建设项目团队，可以改进人际技巧、技术能力、团队环境及项目绩效。在整个项目生命周期中，团队成员之间都要保持明确、及时、有效（包括效果和效率两个方面）的沟通。建设项目团队的目标包括（但不限于）：

提高团队成员的知识和技能，以提高他们完成项目可交付成果的能力，并降低成本、缩短工期和提高质量；
提高团队成员之间的信任和认同感，以提高士气、减少冲突和增进团队协作；
创建富有生气、凝聚力和协作性的团队文化，从而：（1）提高个人和团队生产率，振奋团队精神，促进团队合作；（2）促进团队成员之间的交叉培训和辅导，以分享知识和经验；
提高团队参与决策的能力，使他们承担起对解决方案的责任，从而提高团队的生产效率，获得更有效和高效的成果。

有一种关于团队发展的模型叫塔克曼阶梯理论 [19，20]，其中包括团队建设通常要经过的五个阶段。尽管这些阶段通常按顺序进行，然而，团队停滞在某个阶段或退回到较早阶段的情况也并非罕见；而如果团队成员曾经共事过，项目团队建设也可跳过某个阶段。

形成阶段。在本阶段，团队成员相互认识，并了解项目情况及他们在项目中的正式角色与职责。在这一阶段，团队成员倾向于相互独立，不一定开诚布公。
震荡阶段。在本阶段，团队开始从事项目工作、制定技术决策和讨论项目管理方法。如果团队成员不能用合作和开放的态度对待不同观点和意见，团队环境可能变得事与愿违。
规范阶段。在规范阶段，团队成员开始协同工作，并调整各自的工作习惯和行为来支持团队，团队成员会学习相互信任。
成熟阶段。进入这一阶段后，团队就像一个组织有序的单位那样工作，团队成员之间相互依靠，平稳高效地解决问题。
解散阶段。在解散阶段，团队完成所有工作，团队成员离开项目。通常在项目可交付成果完成之后，或者，在结束项目或阶段过程中，释放人员，解散团队。

某个阶段持续时间的长短，取决于团队活力、团队规模和团队领导力。项目经理应该对团队活力有较好的理解，以便有效地带领团队经历所有阶段。

见 4.1.2.1 节。应征求具备以下专业知识或接受过相关培训的个人或小组的意见：

组织内的政治和权力结构；
组织及其他客户组织的环境和文化；
组织变革管理方法和实践；
项目可交付成果所属的行业或类型；
组织沟通技术；
关于遵守与企业沟通有关的法律要求的组织政策与程序；
与安全有关的组织政策与程序；
相关方，包括客户或发起人。

适用于本过程的沟通技能包括（但不限于）：

沟通胜任力。经过裁剪的沟通技能的组合，有助于明确关键信息的目的、建立有效关系、实现信息共享和采取领导行为。
反馈。反馈是关于沟通、可交付成果或情况的反应信息。反馈支持项目经理和团队及所有其他项目相关方之间的互动沟通。例如，指导、辅导和磋商。
非口头技能。例如，通过示意、语调和面部表情等适当的肢体语言来表达意思。镜像模仿和眼神交流也是重要的技能。团队成员应该知道如何通过说什么和不说什么来表达自己的想法。
演示。演示是信息和/或文档的正式交付。向项目相关方明确有效地演示项目信息可包括（但不限于）：
向相关方报告项目进度和信息更新；
提供背景信息以支持决策制定；
提供关于项目及其目标的通用信息，以提升项目工作和项目团队的形象；
提供具体信息，以提升对项目工作和目标的理解和支持力度。

为获得演示成功，应该从内容和形式上考虑以下因素：

受众及其期望和需求；
项目和项目团队的需求及目标。

项目沟通工件可包括（但不限于）：绩效报告、可交付成果的状态、进度进展、产生的成本、演示，以及相关方需要的其他信息。

可在本过程更新的项目文件包括（但不限于）：

问题日志。见 4.3.3.3 节。更新问题日志，反映项目的沟通问题，或如何通过沟通来解决实际问题。
经验教训登记册。见 4.3.3.1 节。更新经验教训登记册，记录在项目中遇到的挑战、本可采取的规避方法，以及适用和不适用于管理沟通的方法。
项目进度计划。见 6.5.3.2 节。可能需要更新项目进度计划，以反映沟通活动的状态。
风险登记册。见 11.2.3.1 节。更新风险登记册，记录与管理沟通相关的风险。
相关方登记册。见 13.1.3.1 节。更新相关方登记册，记录关于项目相关方沟通活动的信息。

通过监督沟通过程，来确定规划的沟通工件和沟通活动是否如预期提高或保持了相关方对项目可交付成果与预计结果的支持力度。项目沟通的影响和结果应该接受认真的评估和监督，以确保在正确的时间，通过正确的渠道，将正确的内容（发送方和接收方对其理解一致）传递给正确的受众。

见 4.2.3.1 节。项目管理计划组件包括（但不限于）：

需求管理计划。见 5.1.3.2 节。需求管理计划可能指出了特别有风险的项目目标。
进度管理计划。见 6.1.3.1 节。进度管理计划可能列出了受不确定性或模糊性影响的一些领域。
成本管理计划。见 7.1.3.1 节。成本管理计划可能列出了受不确定性或模糊性影响的一些领域。
质量管理计划。见 8.1.3.1 节。质量管理计划可能列出了受不确定性或模糊性影响的一些领域，或者关键假设可能引发风险的一些领域。
资源管理计划。见 9.1.3.1 节。资源管理计划可能列出了受不确定性或模糊性影响的一些领域，或者关键假设可能引发风险的一些领域。
风险管理计划。见 11.1.3.1 节。风险管理计划规定了风险管理的角色和职责，说明了如何将风险管理活动纳入预算和进度计划，并描述了风险类别（可用风险分解结构表述）。
范围基准。见 5.4.3.1 节。范围基准包括可交付成果及其验收标准，其中有些可能引发风险；

还包括工作分解结构，可用作安排风险识别工作的框架。

进度基准。见 6.5.3.1 节。可以查看进度基准，找出存在不确定性或模糊性的里程碑日期和可交付成果交付日期，或者可能引发风险的关键假设条件。
成本基准。见 7.3.3.1 节。可以查看成本基准，找出存在不确定性或模糊性的成本估算或资金需求，或者关键假设可能引发风险的方面。

在大型项目上，可能针对某些可交付成果采用适应型方法，而对其他部分则采用更稳定的方法。

可作为本过程输入的项目文件包括（但不限于）：

里程碑清单。见 6.2.3.3 节。重要里程碑清单说明卖方需要在何时交付成果。
项目团队派工单。见 9.3.3.2 节。项目团队派工单包含关于项目团队技能和能力的信息，以及他们可用于支持采购活动的时间。如果项目团队不具备开展采购活动的能力，则需要外聘人员或对现有人员进行培训，或者二者同时进行。
需求文件。见 5.2.3.1 节。需求文件可能包括：
卖方需要满足的技术要求；
具有合同和法律意义的需求，如健康、安全、安保、绩效、环境、保险、知识产权、同等就业机会、执照、许可证，以及其他非技术要求。
需求跟踪矩阵。见 5.2.3.2 节。需求跟踪矩阵将产品需求从其来源连接到能满足需求的可交付成果。
资源需求。见 9.2.3.1 节。资源需求包含关于某些特定需求的信息，例如，可能需要采购的团队及实物资源。
风险登记册。见 11.2.3.1 节。风险登记册列明风险清单，以及风险分析和风险应对规划的结果。有些风险应通过采购协议转移给第三方。
相关方登记册。见 13.1.3.1 节。相关方登记册提供有关项目参与者及其项目利益的详细信息，包括监管机构、合同签署人员和法务人员。

适用于本过程的数据分析技术包括（但不限于）自制或外购分析。自制或外购分析用于确定某项工作或可交付成果最好由项目团队自行完成，还是应该从外部采购。制定自制或外购决策时应考虑的因素包括；组织当前的资源配置及其技能和能力，对专业技术的需求，不愿承担永久雇用的义务，以及对独特技术专长的需求；还要评估与每个自制或外购决策相关的风险。

可在本过程更新的项目文件包括（但不限于）：

经验教训登记册。见 4.4.3.1 节。更新经验教训登记册，记录任何与法规和合规性、数据收集、数据分析和供方选择分析相关的经验教训。
里程碑清单。见 6.2.3.3 节。重要里程碑清单说明卖方需要在何时交付成果。
需求文件。见 5.2.3.1 节。需求文件可能包括：
卖方需要满足的技术要求；
具有合同和法律意义的需求，如健康、安全、安保、绩效、环境、保险、知识产权、同等就业机会、执照、许可证，以及其他非技术要求。
需求跟踪矩阵。见 5.2.3.2 节。需求跟踪矩阵将产品需求从其来源连接到能满足需求的可交付成果。
风险登记册。见 11.2.3.1 节。取决于卖方的组织、合同的持续时间、外部环境、项目交付方法、所选合同类型，以及最终商定的价格，任何被选中的卖方都会带来特殊的风险。
相关方登记册。见 13.1.3.1 节。更新相关方登记册，记录任何关于相关方的补充信息，尤其是监管机构、合同签署人员，以及法务人员的信息。

合同是对双方都有约束力的协议。它强制卖方提供规定的产品、服务或成果，强制买方向卖方支付相应的报酬。合同建立了受法律保护的买卖双方的关系。协议文本的主要内容会有所不同，可包括（但不限于）：

采购工作说明书或主要的可交付成果；
进度计划、里程碑，或进度计划中规定的日期；
绩效报告；
定价和支付条款；
检查、质量和验收标准；
担保和后续产品支持；
激励和惩罚；
保险和履约保函；
下属分包商批准；
一般条款和条件；
变更请求处理；
终止条款和替代争议解决方法。

项目管理计划的任何变更都以变更请求的形式提出，且通过组织的变更控制过程进行处理。可能需要变更的项目管理计划组件包括（但不限于）：

需求管理计划。见 5.1.3.2 节。项目需求可能因卖方的要求而变更。
质量管理计划。见 8.1.3.1 节。卖方可能提出备选质量标准或备选解决方案，从而影响质量管理计划中规定的质量管理方法。
沟通管理计划。见 10.1.3.1 节。在选定卖方后，需要更新沟通管理计划，记录卖方的沟通需求和方法。
风险管理计划。见 11.1.3.1 节。每个协议和卖方都会带来独特的风险，从而需要更新风险管理计划。具体的风险应该记录到风险登记册中。
采购管理计划。见 12.1.3.1 节。可能需要基于合同谈判和签署的结果，而更新采购管理计划。
范围基准。见 5.4.3.1 节。在执行采购活动时，需明确考虑范围基准中的项目工作分解结构和可交付成果。本过程可能导致对任何一个或全部可交付成果的变更。
进度基准。见 6.5.3.1 节。如果卖方交付成果方面的变更影响了项目的整体进度绩效，则可能需要更新并审批基准进度计划，以反映当前的期望。
成本基准。见 7.3.3.1 节。在项目交付期间，承包商的材料价格和人力价格可能随外部经济环境而频繁变动。这种变动需要反映到成本基准中。

在控制采购过程中，需要开展财务管理工作，包括监督向卖方付款。这是要确保合同中的支付条款得到遵循，确保按合同规定，把付款与卖方的工作进展联系起来。需要重点关注的一点是，确保向卖方的付款与卖方实际已经完成的工作量之间有密切的关系。如果合同规定了基于项目输出及可交付成果来付款，而不是基于项目输入（如工时），那么就可以更有效地开展采购控制。

可作为本过程输入的项目文件包括（但不限于）：

假设日志。见 4.1.3.2 节。假设日志记录了采购过程中做出的假设。
经验教训登记册。见 4.4.3.1 节。在项目早期获取的经验教训可供项目未来使用，以改进承包商绩效和采购过程。
里程碑清单。见 6.2.3.3 节。重要里程碑清单说明卖方需要在何时交付成果。
质量报告。见 8.2.3.1 节。质量报告用于识别不合规的卖方过程、程序或产品。
需求文件。见 5.2.3.1 节。需求文件可能包括：
卖方需要满足的技术要求；
具有合同和法律意义的需求，如健康、安全、安保、绩效、环境、保险、知识产权、同等就业机会、执照、许可证，以及其他非技术要求。
需求跟踪矩阵。见 5.2.3.2 节。需求跟踪矩阵将产品需求从其来源连接到能满足需求的可交付成果。
风险登记册。见 11.2.3.1 节。取决于卖方的组织、合同的持续时间、外部环境、项目交付方法、所选合同类型，以及最终商定的价格，每个被选中的卖方都会带来特殊的风险。
相关方登记册。见 13.1.3.1 节。相关方登记册包括关于已识别相关方的信息，例如，合同团队成员、选定的卖方、签署合同的专员，以及参与采购的其他相关方。

检查是指对承包商正在执行的工作进行结构化审查，可能涉及对可交付成果的简单审查，或对工作本身的实地审查。在施工、工程和基础设施建设项目中，检查包括买方和承包商联合巡检现场，以确保双方对正在进行的工作有共同的认识。

项目管理团队应该在关闭采购之前批准所有的可交付成果。

见 4.5.1.3 节。工作绩效信息是卖方正在履行的工作的绩效情况，包括与合同要求相比较的可交付成果完成情况和技术绩效达成情况，以及与SOW预算相比较的已完工作的成本产生和认可情况。

采购文档更新可包括用于支持合同的全部进度计划、已提出但未批准的合同变更，以及已批准的变更请求。采购文档还包括由卖方编制的技术文件，以及其他工作绩效信息，例如，可交付成果的状况、卖方绩效报告和担保、财务文件（包括发票和支付记录），以及与合同相关的检查结果。

见 4.1.2.1 节。应征求具备以下专业知识或接受过相关培训的个人或小组的意见：

理解组织内的政治和权力结构；
了解所在组织和其他受影响组织（包括客户及其他组织）的环境和文化；
了解项目所在行业或项目可交付成果类型；
了解个体团队成员的贡献和专长。

可在本过程更新的项目文件包括（但不限于）：

问题日志。见 4.3.3.3 节。可能需要更新问题日志中与相关方态度有关的信息。
经验教训登记册。见 4.3.3.1 节。在质量规划过程中遇到的挑战及其本可采取的规避方法需要更新在经验教训登记册中。调动相关方参与效果好以及效果不佳的方法也要更新在经验教训登记册中。
风险登记册。见 11.2.3.1 节。可能需要更新风险登记册，以记录相关方风险应对措施。
相关方登记册。见 13.1.12-13.1 节。更新相关方登记册，以记录从监督相关方参与中得到的信息。

参考文献[1] Project Management Institute. 2017. The Standard for Project Management. Newtown Square, PA: Author.

[2] Project Management Institute. 2013. The Standard for Portfolio Management – Third Edition. Newtown Square,PA: Author.

[3] Project Management Institute. 2017. The Standard for Program Management – Fourth Edition. NewtownSquare, PA: Author.

[4] Project Management Institute. 2016. The PMI Lexicon of Project Management Terms. Available fromhttp://www.pmi.org/lexiconterms[5] Project Management Institute. Code of Ethics and Professional Conduct. Available fromhttp://www.pmi.org/codeofethics[6] Project Management Institute. 2013. Managing Change in Organizations: A Practice Guide. Newtown Square,PA: Author.

[7] Project Management Institute. 2015. Business Analysis for Practitioners: A Practice Guide. Newtown Square,PA: Author.

[8] Project Management Institute. 2014. Implementing Organizational Project Management: A Practice Guide.

Newtown Square, PA: Author.

[9] Project Management Institute. 2014. Project Management Institute Excellence in Practice-ResearchCollaboration, PMI-RI Standards Program: Making Sense of PPP Governance, December 19, 2014. NewtownSquare, PA: Author[10] Project Management Institute. 2016. Governance of Portfolios, Programs, and Projects: A Practice Guide.

Newtown Square, PA: Author.

[11] Project Management Institute. (2013). PMI’s Pulse of the Profession® In-Depth Report: The CompetitiveAdvantage of Effective Talent Management. Available from http://www.pmi.org[12] Project Management Institute. 2015. White Paper, Complexity Management for Projects, Programmes,and Portfolios: An Engineering Systems Perspective, March 2015. Newtown Square, PA: Author.

[13] Project Management Institute. 2014. Navigating Complexity: A Practice Guide. Newtown Square, PA: Author.

[14] Project Management Institute. 2016. Requirements Management: A Practice Guide. Newtown Square, PA: Author.

[15] Project Management Institute. 2006. Practice Standard for Work Breakdown Structures (WBS). NewtownSquare, PA: Author.

[16] Project Management Institute. 2011. Practice Standard for Scheduling – Second Edition. Newtown Square,PA: Author.

[17] Project Management Institute. 2011. Practice Standard for Earned Value Management – Second Edition[18] International Standards Organization. 2015. ISO 9000:2015 Quality Management Systems—Fundamentalsand Vocabulary. Geneva: Author.

项目生命周期指项目从开始到完成所经历的一系列阶段。项目阶段是一组具有逻辑关系的项目活动的集合，通常以一个或多个可交付成果的完成为结束。这些阶段之间可能是顺序、迭代或交叠的关系。项目阶段的名称、数量和持续时间取决于参与项目的一个或多个组织的管理与控制需要、项目本身的特征及其所在的应用领域。阶段都有时限，有一个起始点、结束点或控制点（有时称为阶段审查、阶段关口或控制关口，也可以用其他类似名称）。在控制点，需要根据当前环境，重新审查项目章程和商业文件。在该时点，把项目绩效与项目管理计划进行比较，以确定项目是否应该变更、终止或按计划继续。

项目生命周期会受组织、行业、开发方法或所用技术的独特性质的影响。虽然每个项目都有起点和终点，但具体的可交付成果及工作会因项目的不同而有很大差异。不论项目涉及的具体工作是什么，生命周期都可以为管理项目提供基本框架。

虽然项目规模及复杂程度各不相同，但是典型项目都呈现下列项目生命周期结构（见图 1-2）：

开始项目；
组织与准备；
执行项目工作；
结束项目。

图 1-2项目生命周期的通用结构

通用的生命周期结构一般具有以下特征：

成本与人力投入在开始时较低，在工作执行期间逐渐增加，并在项目快要结束时迅速回落。
项目开始时风险最大，如图 1-3 所示。在项目的整个生命周期中，随着决策的制定与可交付成果的验收，风险会逐步降低。
在不显著影响成本和进度的前提下，相关方改变项目产品最终特性的能力在项目开始时最大，并随项目进展而减弱。图 1-3 表明，做出变更和纠正错误的成本，通常会随着项目越来越接近完成而显著增高。

图 1-3随时间而变化的变量影响

一个过程的输出通常成为另一个过程的输入，或者成为项目或项目阶段的可交付成果。例如，需要把规划过程组编制的项目管理计划和项目文件（如风险登记册、责任分配矩阵等）及其更新，提供给执行过程组作为输入。图 1-4 是各过程组在项目或阶段期间的重叠关系示例。

发起人、客户和其他相关方参与项目启动，有助于促进他们对项目成功标准达成一致，也有助于提升项目完成时可交付成果通过验收的可能性，以及在整个项目期间相关方的满意程度。

创建工作分解结构 (WBS) 是把项目可交付成果和项目工作分解为较小的、更易于管理的组件的过程。本过程的主要作用是，为所要交付的内容提供架构。本过程仅开展一次或仅在项目的预定义点开展。图 3-6 描述了本过程的输入和输出。

定义活动是识别和记录为完成项目可交付成果而须采取的具体行动的过程。本过程的主要作用是，将工作包分解为进度活动，作为对项目工作进行进度估算、规划、执行、监督和控制的基础。

规划质量管理是识别项目及其可交付成果的质量要求和（或）标准，并书面描述项目将如何证明符合质量要求和（或）标准的过程。本过程的主要作用是，为在整个项目期间如何管理和核实质量提供指南和方向。本过程仅开展一次或仅在项目的预定义点开展。图 3-15 描述了本过程的输入和输出。

指导与管理项目工作是为实现项目目标而领导和执行项目管理计划中所确定的工作，并实施已批准变更的过程。本过程的主要作用是，对项目工作和可交付成果开展综合管理，以提高项目成功的可能性。本过程需要在整个项目期间开展。图 4-2 描述了本过程的输入和输出。

实施整体变更控制是指审查所有变更请求，批准变更，管理对可交付成果、组织过程资产、项目文件和项目管理计划的变更，并对变更处理结果进行沟通的过程。本过程审查对项目文件、可交付成果或项目管理计划的所有变更请求，并决定对变更请求的处置方案。本过程的主要作用是，确保对项目中已记录在案的变更做综合评审。如果不考虑变更对整体项目目标或计划的影响就开展变更，往往会加剧整体项目风险。本过程需要在整个项目期间开展。图 5-3 描述了本过程的输入和输出。

确认范围是正式验收已完成的项目可交付成果的过程。本过程的主要作用是，使验收过程具有客观性；同时通过确认每个可交付成果，来提高最终产品、服务或成果获得验收的可能性。本过程应根据需要在整个项目期间定期开展。图 5-4 描述了本过程的输入和输出。

控制质量是为了评估绩效，确保项目输出完整、正确并满足客户期望，而监督和记录质量管理活动执行结果的过程。本过程的主要作用是，核实项目可交付成果和工作已经达到主要相关方的质量要求，可供最终验收。本过程需要在整个项目期间开展。图 5-8 描述了本过程的输入和输出。

《PMBOK® 指南》的 1.2.4.2 节将阶段定义为“一组具有逻辑关系的项目活动的集合，通常以一个或多个可交付成果的完成为结束”，过程组中的各个过程会在每个阶段按需要重复开展，直到达到该阶段的完工标准。

适应型项目非常依赖知识丰富的客户或客户代表，他们要能够持续地表达需要和意愿，并不断针对新形成的可交付成果提出反馈意见。应该在项目开始时就识别出这个相关方或其他相关方，以便在开展执行和监控过程组时与他们频繁互动。有关的反馈意见则能够确保项目交付出正确的成果。

项目整合管理的核心概念包括：

项目整合管理是项目经理的具体职责，不能委托或转移。项目经理要整合所有其他知识领域的成果，以提供与项目总体情况有关的信息。项目经理必须对整个项目承担最终责任。
项目和项目管理具有整合性质，大多数任务涉及不止一个知识领域。
项目管理过程组内部和项目管理过程组之间的过程存在迭代型关系。
项目整合管理指的是：
确保项目可交付成果的最终交付日期、项目生命周期及效益实现计划保持一致；
提供可实现项目目标的项目管理计划；
确保创造合适的知识以运用到项目中，并从项目中汲取知识；
管理项目绩效和项目活动的变更；
做出针对影响项目的关键变更的综合决策；
衡量和监督进展，并采取适当的措施；
收集、分析项目信息，并将其传递给有关的相关方；
完成全部项目工作，正式关闭各个阶段、合同以及整个项目；
管理可能需要的阶段过渡。

项目范围管理的核心概念包括：

范围可以指产品范围（产品、服务或成果具有的特性和功能），或项目范围（为交付具有特定特性和功能产品、服务或成果而开展的工作）。
项目生命周期的连续区间涵盖预测型、适应型或敏捷型。在预测型生命周期中，项目开始时就对项目可交付成果进行定义，对任何范围变化都要进行渐进管理；而在适应型或敏捷型生命周期中，可交付成果经过多次迭代，详细范围得到了定义，并且在每次迭代开始时完成审批。
应该根据项目管理计划来衡量项目范围的完成情况，根据产品需求来衡量产品范围的完成情况。

项目成本管理的核心概念包括：

项目成本管理主要关注完成项目活动所需的资源成本，但它也要考虑到项目决策对后续多次使用、维护和支持项目可交付成果所需成本的影响。
不同的相关方会在不同的时间、用不同的方法测算项目成本，因此应明确考虑管理成本的相关方需求。
预测和分析项目产品的潜在财务绩效可能在项目以外进行，或作为项目成本管理的一部分。

项目质量管理的核心概念包括：

项目质量管理需要兼顾项目管理与项目可交付成果两个方面，它适用于所有项目，无论项目的可交付成果具有何种特性。质量的测量方法和技术则需视专门针对项目所产生的可交付成果类型而定。
质量和等级是不同的概念。质量是“一系列内在特性满足要求的程度”（ISO 9000）1，而等级是对用途相同但技术特性不同的可交付成果的级别分类。项目经理及团队要负责权衡，以便同时达到所要求的质量与等级水平。
预防胜于检查。最好是在设计时考虑可交付成果的质量，而不是在检查时发现质量问题。预防错误的成本通常远低于在检查或使用中发现并纠正错误的成本。
项目经理可能需要熟悉抽样。属性抽样的结果为合格或不合格，而变量抽样指的是在连续的量表上标明结果所处的位置，以表明合格的程度。
很多项目会为项目和产品衡量确立公差（结果的可接受范围）和控制界限（在统计意义上稳定的过程或过程绩效的普通差异的边界）。
质量成本 (COQ) 包括在产品生命周期中为预防不符合要求、为评价产品或服务是否符合要求，以及因未达到要求（返工）而发生的所有成本。质量成本通常关注项目集管理、项目组合管理、PMO 或运营。
当质量整合到项目和产品规划和设计中时，以及组织文化意识致力于提高质量时，就能达成最有效的质量管理。

X4.6项目资源管理的核心概念项目资源管理的核心概念包括：

项目资源包括物质资源（设备、材料、设施和基础设施）和团队资源（担任项目角色及承担相关职责的人员）。
管理团队资源和物质资源需要不同的技能和能力。
项目经理应同时是项目团队的主管和经理，而且应在聘用、管理、激励和授权团队成员方面做出适当的努力。
项目经理应了解影响团队的因素，例如，团队环境、团队成员所在的地理位置、相关方之间的沟通、组织变更管理、内部和外部政治、文化问题，以及组织的独特性，uu项目经理还负责积极培养团队技能和能力，同时提高并保持团队的满意度和积极性。
物质资源管理着眼于以有效和高效的方式，分配和使用成功完成项目所需的物质资源，而无法有效管理和控制资源可能会降低项目顺利完工的概率。

市场调查结果显示，实际上很少由项目经理负责结束采购。而是通常由合同、采购或法务部门中拥有此项职权的相关人员负责。因此，结束采购中关于评估所有已完成的可交付成果以及将其与合同比较的信息，已合并到控制采购中；与行政、沟通和记录有关的信息也移到结束项目或阶段。

4.3.3.1 可交付成果