X1.9 敏捷型
自从第五版《PMBOK® 指南》出版以来，项目越来越多地采纳敏捷型和适应型管理方法。在第六版中，我们收录了名为“关于适应型环境的考虑因素”，并将此小章节置于第 4 至 13 章的开头部分。
部分敏捷型专用的工具和技术已引入《PMBOK® 指南》，例如，敏捷交付周期与迭代计划等。附录 X3从项目管理过程组的角度，对敏捷型、适应型、迭代型和混合型方法的使用进行了描述。
项目生命周期指项目从启动到完成所经历的一系列阶段。它为项目管理提供了一个基本框架。不论项目涉及的具体工作是什么，这个基本框架都适用。这些阶段之间的关系可以顺序、迭代或交叠进行。所有项目都呈现图 1-5 所示的通用的生命周期。
项目生命周期可以是预测型或适应型。项目生命周期内通常有一个或多个阶段与产品、服务或成果的开发相关，这些阶段称为开发生命周期。开发生命周期可以是预测型、迭代型、增量型、适应型或混合型的模式：
- 预测型生命周期，在生命周期的早期阶段确定项目范围、时间和成本。对任何范围的变更都要进行仔细管理。预测型生命周期也称为瀑布型生命周期。
- 迭代型生命周期，项目范围通常于项目生命周期的早期确定，但时间及成本估算将随着项目团队对产品理解的不断深入而定期修改。迭代方法是通过一系列重复的循环活动来开发产品，而增量方法是渐进地增加产品的功能。
- 增量型生命周期是通过在预定的时间区间内渐进增加产品功能的一系列迭代来产出可交付成果。只有在最后一次迭代之后，可交付成果具有了必要和足够的能力，才能被视为完整的。
- 适应型生命周期属于敏捷型、迭代型或增量型。详细范围在迭代开始之前就得到了定义和批准。适应型生命周期也称为敏捷或变更驱动型生命周期。请参见附录 X3。
- 混合型生命周期是预测型生命周期和适应型生命周期的组合。充分了解或有确定需求的项目要素遵循预测型开发生命周期，而仍在发展中的要素遵循适应型开发生命周期。
由项目管理团队确定各个项目最适合的生命周期。项目生命周期需要足够灵活，能够应对项目包含的各种因素。可以通过以下方法实现生命周期的灵活性：
- 确定需要在各个阶段实施的一个或多个过程；
- 在合适的阶段实施确定的一个或多个过程；
- 调整阶段的各种属性（例如名称、持续时间、退出标准和准入标准）。
项目生命周期与产品生命周期相互独立，后者可能由项目产生。产品生命周期指一个产品从概念、交付、成长、成熟到衰退的整个演变过程的一系列阶段。
项目范围管理包括确保项目做且只做所需的全部工作，以成功完成项目的各个过程。管理项目范围主要在于定义和控制哪些工作应该包括在项目内，哪些不应该包括在项目内。
项目范围管理过程包括：
5.1 规划范围管理 — 为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。
5.2 收集需求 — 为实现项目目标而确定、记录并管理相关方的需要和需求的过程。
5.3 定义范围 — 制定项目和产品详细描述的过程。
5.4 创建 WBS — 将项目可交付成果和项目工作分解为较小的、更易于管理的组件的过程。
5.5 确认范围 — 正式验收已完成的项目可交付成果的过程。
5.6 控制范围 — 监督项目和产品的范围状态，管理范围基准变更的过程。
图 5-1 概括了项目范围管理的各个过程。虽然各项目范围管理过程以界限分明、相互独立的形式出
现，但在实践中它们会以《PMBOK® 指南》无法全面叙述的方式相互交叠、相互作用。
图 5-1项目范围管理概述
项目范围管理的核心概念在项目环境中，“范围”这一术语有两种含义：
- 产品范围。某项产品、服务或成果所具有的特征和功能。
- 项目范围 。为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。项目范围有时也包括产品范围。
从预测型方法到适应型或敏捷型方法，项目生命周期可以处于这个连续区间内的任何位置。在预测型生命周期中，在项目开始时就对项目可交付成果进行定义，对任何范围变化都要进行渐进管理。而在适应型或敏捷型生命周期中，通过多次迭代来开发可交付成果，并在每次迭代开始时定义和批准详细的范围。
采用适应型生命周期，旨在应对大量变更，需要相关方持续参与项目；因此，应将适应型项目的整体范围分解为一系列拟实现的需求和拟执行的工作（有时称为产品未完项）。在一个迭代开始时，团队将努力确定产品未完项中，哪些最优先项应在下一次迭代中交付。在每次迭代中，都会重复开展三个过程：收集需求、定义范围和创建 WBS。相反，在预测型项目中，这些过程在项目开始时开展，并在必要时通过实施整体变更控制过程进行更新。
在适应型或敏捷型生命周期中，发起人和客户代表应该持续参与项目，随同可交付成果的创建提供反馈意见，并确保产品未完项反映他们的当前需求。在每次迭代中，都会重复开展两个过程：确认范围和控制范围。相反，在预测型项目中，确认范围在每个可交付成果生成时或者在阶段审查点开展，而控制范围则是一个持续性的过程。
在预测型项目中，经过批准的项目范围说明书、工作分解结构（WBS）和相应的 WBS 词典构成项目范围基准。只有通过正式变更控制程序，才能进行基准变更。在开展确认范围、控制范围及其他控制过程时，基准被用作比较的基础。而采用适应型生命周期的项目，则使用未完项（包括产品需求和用户故事）反映当前需求。
项目范围的完成情况是根据项目管理计划来衡量的，而产品范围的完成情况是根据产品需求来衡量的。在这里，“需求”是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。
确认范围是正式验收已完成的项目可交付成果的过程。从控制质量过程输出的核实的可交付成果是确认范围过程的输入，而验收的可交付成果是确认范围过程的输出之一，由获得授权的相关方正式签字批准。因此，相关方需要在规划阶段早期介入（有时需要在启动阶段就介入），对可交付成果的质量提出意见，以便控制质量过程能够据此评估绩效并提出必要的变更建议。
目范围管理的发展趋势和新兴实践需求一直是项目管理中的重点，并且还将继续得到项目管理从业者的更多关注。随着全球环境变得日益复杂，组织开始认识到如何运用商业分析，通过定义、管理和控制需求活动来提高竞争优势。商业分析活动可在项目启动和项目经理任命之前就开始。根据《需求管理：实践指南》[14]，需求管理过程始于需要评估，而需要评估又可能始于项目组合规划、项目集规划或单个项目。
在项目范围管理过程中，收集、记录和管理相关方需求。项目范围管理的范围趋势和新兴实践包括（但不限于）注重与商业分析专业人士的合作，以便：
- 确定问题并识别商业需要；
- 识别并推荐能够满足这些需要的可行解决方案；
- 收集、记录并管理相关方需求，以满足商业和项目目标；
- 推动项目集或项目的产品、服务或最终成果的成功应用 [7]。
需求管理过程结束于需求关闭，即把产品、服务或成果移交给接收方，以便长期测量、监控、实现和维持效益。
应该将商业分析的角色连同职责分配给具有足够商业分析技能和专业知识的人员。如果项目已配备商业分析师，那么，与需求管理相关的活动便是该角色的职责。而项目经理则负责确保这些活动在项目管理计划有所安排，并且在预算内按时完成，同时能够创造价值。
项目经理与商业分析师之间应该是伙伴式合作关系。如果项目经理和商业分析师能够理解彼此在促进项目目标实现过程中的角色和职责，项目成功的可能性就更大。
裁剪时需要考虑的因素因为每个项目都是独特的，所以项目经理需要裁剪项目范围管理过程。裁剪时应考虑的因素包括（但不限于）：
- 知识和需求管理。组织是否拥有正式或非正式的知识和需求管理体系？为了在未来项目中重复使用需求，项目经理应建立哪些指南？
- 确认和控制。组织是否拥有正式或非正式的与确认和控制相关的政策、程序和指南？
- 开发方法。组织是否采用敏捷方法管理项目？开发方法属于迭代型还是增量型？是否采用预测型方法？混合型方法是否有效？
- 需求的稳定性。项目中是否存在需求不稳定的领域？是否有必要采用精益、敏捷或其他适应型技术来处理不稳定的需求，直至需求稳定且定义明确？
- 治理。组织是否拥有正式或非正式的审计和治理政策、程序和指南？
在敏捷或适应型环境中需要考虑的因素对于需求不断变化、风险大或不确定性高的项目，在项目开始时通常无法明确项目的范围，而需要在项目期间逐渐明确。敏捷方法特意在项目早期缩短定义和协商范围的时间，并为持续探索和明确范围而延长创建相应过程的时间。在许多情况下，不断涌现的需求往往导致真实的业务需求与最初所述的业务需求之间存在差异。因此，敏捷方法有目的地构建和审查原型，并通过多次发布版本来明确需求。这样一来，范围会在在整个项目期间被定义和再定义。在敏捷方法中，把需求列入未完项。
见 4.2.3.1 节。项目管理计划组件包括（但不限于）：
- 质量管理计划。见 8.1.3.1 节。在项目中实施组织的质量政策、方法和标准的方式会影响管理项目和产品范围的方式。
- 项目生命周期描述。项目生命周期定义了项目从开始到完成所经历的一系列阶段。
- 开发方法。开发方法定义了项目是采用瀑布式、迭代型、适应型、敏捷型还是混合型开发方法。
项目风险管理包括规划风险管理、识别风险、开展风险分析、规划风险应对、实施风险应对和监督风险的各个过程。项目风险管理的目标在于提高正面风险的概率和（或）影响，降低负面风险的概率和（或）影响，从而提高项目成功的可能性。
项目风险管理的过程是：
11.1 规划风险管理 — 定义如何实施项目风险管理活动的过程。
11.2 识别风险 — 识别单个项目风险，以及整体项目风险的来源，并记录风险特征的过程。
11.3 实施定性风险分析 — 通过评估单个项目风险发生的概率和影响以及其他特征，对风险进行优先级排序，从而为后续分析或行动提供基础的过程。
11.4 实施定量风险分析 — 就已识别的单个项目风险和其他不确定性的来源对整体项目目标的综合影响进行定量分析的过程。
11.5 规划风险应对 — 为处理整体项目风险敞口，以及应对单个项目风险，而制定可选方案、选择应对策略并商定应对行动的过程。
11.6 实施风险应对 — 执行商定的风险应对计划的过程。
11.7 监督风险 — 在整个项目期间，监督商定的风险应对计划的实施、跟踪已识别风险、识别和分析新风险，以及评估风险管理有效性的过程。
图 11-1 概括了项目风险管理的各个过程。虽然在本《PMBOK® 指南》中，各项目管理风险过程
以界限分明和相互独立的形式出现，但在实践中它们会以本指南无法全面详述的方式相互交叠和相互作用。
图 11-1项目风险管理概述
项目风险管理的核心概念既然项目是为交付收益而开展的、具有不同复杂程度的独特性工作，那自然就会充满风险。
开展项目，不仅要面对各种制约因素和假设条件，而且还要应对可能相互冲突和不断变化的相关方期望。组织应该有目的地以可控方式去冒项目风险，以便平衡风险和回报，并创造价值。
项目风险管理旨在识别和管理未被其他项目管理过程所管理的风险。如果不妥善管理，这些风险有可能导致项目偏离计划，无法达成既定的项目目标。因此，项目风险管理的有效性直接关乎项目成功与否。
每个项目都在两个层面上存在风险。每个项目都有会影响项目达成目标的单个风险，以及由单个项目风险和不确定性的其他来源联合导致的整体项目风险。考虑整体项目风险，也非常重要。项目风险管理过程同时兼顾这两个层面的风险。它们的定义如下：
- 单个项目风险是一旦发生，会对一个或多个项目目标产生正面或负面影响的不确定事件或条件。
- 整体项目风险是不确定性对项目整体的影响，是相关方面临的项目结果正面和负面变异区间。
它源于包括单个风险在内的所有不确定性。
一旦发生，单个项目风险会对项目目标产生正面或负面的影响。项目风险管理旨在利用或强化正面风险（机会），规避或减轻负面风险（威胁）。未妥善管理的威胁可能引发各种问题，如工期延误、成本超支、绩效不佳或声誉受损。把握好机会则能够获得众多好处，如工期缩短、成本节约、绩效改善或声誉提升。
整体项目风险也有正面或负面之分。管理整体项目风险旨在通过削弱负面变异的驱动因素，加强正面变异的驱动因素，以及最大化实现整体项目目标的概率，把项目风险敞口保持在可接受的范围之内。
因为风险会在项目生命周期内持续发生，所以，项目风险管理过程也应不断迭代开展。在项目规划期间，就应该通过调整项目策略对风险做初步处理。接着，应该随着项目进展，监督和管理风险，确保项目处于正轨，并且突发性风险也得到处理。
为有效管理特定项目的风险，项目团队需要知道，相对于要追求的项目目标，可接受的风险敞口究竟是多大。这通常用可测量的风险临界值来定义。风险临界值反映了组织与项目相关方的风险偏好程度，是项目目标的可接受的变异程度。应该明确规定风险临界，并传达给项目团队，同时反映在项目的风险影响级别定义中。
项目风险管理的发展趋势和新兴实践项目风险管理的关注面正在扩大，以便确保考虑所有类型的风险，并在更广泛的背景中理解项目风险。项目风险管理的发展趋势和新兴实践包括（但不限于）：
- 非事件类风险。大多数项目只关注作为可能发生或不发生的不确定性未来事件的风险。例如：
关键卖方可能在项目期间停业，客户可能在设计完成后变更需求，或分包商可能要求对标准化操作流程进行优化。
不过，识别并管理非事件类风险的意识正在不断加强。非事件类风险有两种主要类型：
- 变异性风险。已规划事件、活动或决策的某些关键方面存在不确定性，就导致变异性风险。例如，生产率可能高于或低于目标值，测试发现的错误数量可能多于或少于预期，或施工阶段可能出现反常的天气情况。
- 模糊性风险。对未来可能发生什么，存在不确定性。知识不足可能影响项目达成目标的能力，例如，不太了解需求或技术解决方案的要素、法规框架的未来发展，或项目内在的系统复杂性。
变异性风险可通过蒙特卡洛分析加以处理，即：用概率分布表示变异的可能区间，然后采取行动去缩小可能结果的区间。管理模糊性风险，则需要先定义认知或理解不足之处，进而通过获取外部专家意见或以最佳实践为标杆来填补差距。也可以采用增量开发、原型搭建或模拟等方法来处理模糊性风险。
- 项目韧性。随着对所谓“未知-未知”因素的意识的增强，人们也越来越明确地知道确实存在突发性风险。这种风险只有在发生后才能被发现。可以通过加强项目韧性来应对突发性风险。
这就要求每个项目：
- 除了为已知风险列出具体风险预算，还要为突发性风险预留合理的应急预算和时间；
- 采用灵活的项目过程，包括强有力的变更管理，以便在保持朝项目目标推进的正确方向的同时，应对突发性风险；
- 授权目标明确且值得信赖的项目团队在商定限制范围内完成工作；
- 经常留意早期预警信号，以尽早识别突发性风险；
- 明确征求相关方的意见，以明确为应对突发性风险而可以调整项目范围或策略的领域。
- 整合式风险管理。项目存在于组织背景中，可能是项目集或项目组合的一部分。在项目、项目集、项目组合和组织这些层面上，都存在风险。应该在适当的层面上承担和管理风险。在较高层面识别出的某些风险，将被授权给项目团队去管理；而在较低层面识别出的某些风险，又可能上交给较高层面去管理（如果在项目之外管理最有效）。应该采用协调式企业级风险管理方法，来确保所有层面的风险管理工作的一致性和连贯性。这样就能使项目集和项目组合的结构具有风险效率，有利于在给定的风险敞口水平下创造最大的整体价值。
裁剪时需要考虑的因素因为每个项目都是独特的，所以有必要对项目风险管理过程的应用方式进行裁剪。裁剪时应考虑的因素包括（但不限于）：
- 项目规模。由预算、持续时间、范围或团队人数所体现的项目规模，要求采取更详细的风险管理方法吗？或者项目小到只需要用简化的风险管理过程吗？
- 项目复杂性。由高水平创新、新技术采用、商务安排、界面或外部依赖关系导致的项目复杂性提高，是否要求采用更稳健的风险管理方法？或者项目是否简单到只需要用简化的风险管理过程？
- 项目重要性。项目的战略重要性有多大？项目的风险级别因旨在创造突破性机会、克服组织经营的重大障碍或涉及重大产品创新而提高了吗？
- 开发方法。它是否是瀑布式项目，风险管理过程可以相继或重复开展；或者此项目是否采取敏捷型方法，需在每个重复过程的开始阶段以及执行期间处理风险？
根据上述需考虑的因素来裁剪项目风险管理过程，这是规划风险管理过程的一部分工作。裁剪结果将被记录在风险管理计划中。
在敏捷或适应型环境中需要考虑的因素从本质上讲，越是变化的环境就存在越多的不确定性和风险。要应对快速变化，就需要采用适应型方法管理项目，即：通过跨职能项目团队和经常审查增量式工作产品，来加快知识分享，确保对风险的认知和管理。在选择每个迭代期的工作内容时，应该考虑风险；在每个迭代期间应该识别、分析和管理风险。
此外，应该根据对当前风险敞口的理解的加深，定期更新需求文件，并随项目进展重新排列工作优先级。
项目采购管理包括从项目团队外部采购或获取所需产品、服务或成果的各个过程。项目采购管理包括编制和管理协议所需的管理和控制过程，例如，合同、订购单、协议备忘录 (MOA)，或服务水平协议 (SLA)。被授权采购项目所需货物和（或）服务的人员可以是项目团队、管理层或组织采购部（如果有）的成员。
项目采购管理过程包括：
12.1 规划采购管理 — 记录项目采购决策、明确采购方法，及识别潜在卖方的过程。
12.2 实施采购 — 获取卖方应答、选择卖方并授予合同的过程。
12.3 控制采购 — 管理采购关系、监督合同绩效、实施必要的变更和纠偏，以及关闭合同的过程。
虽然在本指南中，采购过程以界限分明和相互独立的形式出现，但在实践中，采购过程相当复杂且相互作用，还与其他知识领域的过程相互作用。本指南无法全面详述这些相互作用。本章以从项目外部获取货物或服务的视角来叙述采购过程。
图 12-1 概括了项目采购管理的各个过程。虽然在本《PMBOK® 指南》中，各项目采购管理过程
以界限分明和相互独立的形式出现，但在实践中它们会以本指南无法全面详述的方式相互交叠和相互作用。
图 12-1项目采购管理概述
项目采购管理的核心概念与采购过程相关的重大法律义务和惩罚，通常超出大多数其他的项目管理过程。虽然项目经理不必成为采购管理法律法规领域的专家，但应该对采购过程有足够了解，以便做出与合同及合同关系相关的明智决定。通常情况下，项目经理无权签署对组织有约束力的法律协议，这项工作仅由具备相关职权的人员执行。
项目采购管理过程涉及到用协议来描述买卖双方之间的关系。协议可以很简单，如以特定人工单价购买所需的工时，也可以很复杂，如多年的国际施工合同。合同签署的方法和合同本身应体现可交付成果或所需人力投入的简单性或复杂性，其书写形式也应符合当地、所在国或国际法中关于合同签署的规定。
合同应明确说明预期的可交付成果和结果，包括从卖方到买方的任何知识转移。合同中未规定的任何事项则不具法律强制力。开展国际合作的项目经理应牢记，无论合同规定如何详尽，文化和当地法律对合同及其可执行性均有影响。
采购合同中包括条款和条件，也可包括买方就卖方应实施工作或应交付产品的其他规定。在与采购办公室协作确保遵守组织的采购政策的同时，项目管理团队必须确定所有采购都能满足项目的具体需要。因应用领域不同，协议可以是合同、服务水平协议（SLA）、谅解备忘录、协议备忘录（MOA）或订购单。
大多数组织都有相关的书面政策和程序，来专门定义采购规则，并规定谁有权代表组织签署和管理协议。在世界各地，组织虽然用不同的名称来称呼负责采购的单位或部门，如购买部、合同部、采购部或收购部，但其实际职责大同小异。
虽然所有项目文件可能都要经过某种形式的审查与批准，但是，鉴于其法律约束力，合同或协议需要经过更多的审批程序，而且通常会涉及到法务部。在任何情况下，审批程序的主要目标都是确保合同充分描述将由卖方提供的产品、服务或成果，且符合法律法规关于采购的规定。通常把描述产品、服务或成果的文件作为独立的附件或附录，以便合同正文使用标准化的法律合同用语。
在复杂项目中，可能需要同时或先后管理多个合同。这种情况下，不同合同的生命周期可在项目生命周期的任何阶段开始与结束。买卖方关系是采购组织与外部组织之间的关系，可存在于项目的许多层次上。
因应用领域不同，卖方可以是承包商、供货商、服务提供商或供应商；买方可能为最终产品的所有人、分包商、收购机构、服务需求者或购买方。在合同生命周期中，卖方首先是投标人，然后是中标人，之后是签约供应商或供货商。
中标人可将所承揽的工作当作一个项目加以管理。在这种情况下：
- 买方就变成了承包商、供应商及服务提供商的客户，因此也就是卖方的关键项目相关方。
- 卖方的项目管理团队就需要关注工作执行或服务提供所涉及的所有过程。
- 对于卖方来说，合同条款和条件以及采购工作说明书 (SOW) 都是其许多管理过程的重要输入。
在合同中，可实际列出各种输入（如，主要可交付成果、关键里程碑、成本目标），或者可限制项目团队的选择余地（如，在 IT 整合项目中，关于人员配备的决定往往要征得买方的批准）。另外，采购工作说明书可能使用其他名称，如技术工作说明书。
- 卖方本身也可能成为更低层级的产品、服务和材料分包商及供应商的买方。
本节假设项目所需物品或服务的买方是项目团队，或者是组织内部的某个部门，同时假设卖方是为项目提供物品或服务的一方，且通常来自执行组织外部。在某些项目上，卖方可能是项目执行组织内部但属于项目外部的某个小组或部门。在大型复杂的项目上，卖方可能在授予合同后才成为整合式项目团队的一部分。
在小型组织或初创企业，以及未设置购买、合同或采购部门的组织，项目经理可以拥有采购职权，能够直接谈判并签署合同（分散式采购）。在更成熟的组织中，由专设部门开展实际的采购和合同签署工作，即采购、谈判和签署合同（集中式采购）。
在签署国际合同时，应该在合同中明确规定对合同的法律管辖权。在大多数情况下，卖方是受正式合同关系约束的外部承包商。
采购管理的发展趋势和新兴实践不同行业各方面（软件工具、风险、过程、物流和技术）的一些重大趋势，会影响项目的成功率。项目采购管理的发展趋势和新兴实践包括（但不限于）：
- 工具的改进。用于管理项目采购和项目执行的工具已经取得重大发展。现在，买方能够使用在线工具集中发布采购广告；卖方也能够使用在线工具集中查找采购文件，并直接在线填写。在施工、工程和基础设施领域，建筑信息模型(BIM) 软件的应用日益广泛，为工程项目节省了大量时间和资金。它能够大幅减少施工索赔，从而降低成本、缩短工期，因此世界各地的主要公司和政府都开始要求在大型项目中使用 BIM。
- 更先进的风险管理。在风险管理领域日益流行的一个趋势，就是在编制合同时准确地将具体风险分配给最有能力对其加以管理的一方。没有任何承包商有能力管理项目的所有重大风险，买方因而必须接受承包商无法掌控的风险，例如，采购方公司政策的不断变化、法规要求的不断变化，以及项目以外的其他风险。在合同中可以明确规定风险管理是合同工作的一部分。
- 变化中的合同签署实践。在过去几年时间内，超大型项目的数量显著增加，尤其是在基础设施建设和工程项目领域。数十亿美元的项目现在已十分常见。大部分此类项目都要求与多个国家的多家承包商签署国际合同，因此肯定比仅使用当地承包商的项目具有更大的风险。承包商越来越重视在采购过程中与客户开展密切合作，以便对批量采购或有其他特殊关系的客户给予折扣优惠。对于此类项目来说，为了减少执行过程中的问题和索赔，采用国际公认的标准合同范本也日益普遍。
- 物流和供应链管理。因为如此多的大型工程、施工和基础设施建设项目都由多家跨国承包商来完成，材料物流管理对于项目成功完成至关重要。对采购周期较长的产品，制造环节和运输（到项目现场）环节都是项目进度的决定因素。在 IT 领域，有些产品可能需要提前 2 至 3 个月订购；在复杂的施工项目上，订购时间可能需要提前 1-2 年，甚至更长。在这些项目上，可能需要在签订其他采购合同之前就采购这些订购周期长的产品，以便项目如期完成。在最终产品的最终设计完成之前，就可能需要根据总体设计中已确定的要求开始订购采购周期较长的材料、用品或设备。供应链管理也是承包商的项目团队日益重视的一个领域。在项目早期，不仅要明确主要的采购渠道，通常还需要明确次要和备选渠道。全球很多国家会要求跨国承包商至少向当地供应商采购一定比例的材料和用品。
- 技术和相关方关系。公共资助的项目正受越来越多的关注。基础设施和商业建设项目正日益采用包括网络摄像（webcams）在内的技术，以改善与相关方的沟通和关系。在施工期间，施工现场会安装一台或多台网络摄像机，定期更新并发布到公开的网站上，方便所有相关方在互联网上查看项目进展。另外，视频资料可以储存，有助于在索赔发生时进行分析。有些项目显示，使用网络摄像机记录现场情况，能够避免对事实的分歧，从而能够把与现场施工有关的争议降到最低程度。
- 试用采购。并非每一个卖方都能很好地适应买方组织的环境，因此，在决定大批量采购之前，有些项目会试用多个候选卖方，向他们采购少量的可交付成果和工作产品。这样一来，买方可以在推进项目工作的同时，对潜在合作伙伴进行评估。
裁剪时需要考虑的因素因为每个项目都是独特的，所以项目经理需要裁剪项目采购管理过程。裁剪时应考虑的因素包括（但不限于）：
- 采购的复杂性。只开展一次主要的采购，或者需要在不同时间向不同卖方进行多次采购（会提高采购的复杂性）？
- 物理地点。买方和卖方在同一或邻近地点，或者位于不同时区、国家或大洲？
- 治理和法规环境。组织的采购政策是否和当地相关的法律法规兼容？当地的法律法规会如何影响合同审计工作？
- 承包商的可用性。是否有具备工作执行能力的承包商可供选择？
在敏捷或适应型环境中需要考虑的因素在敏捷型环境中，可能需要与特定卖方协作来扩充团队。这种协作关系能够营造风险共担式采购模型，让买方和卖方共担项目风险和共享项目奖励。
在大型项目上，可能针对某些可交付成果采用适应型方法，而对其他部分则采用更稳定的方法。
在这种情况下，可以通过主体协议，如主要服务协议（MSA），来管辖整体协作关系，而将适应型工作写入附录或补充文件。这样一来，变更只针对适应型工作，而不会对主体协议造成影响。
项目相关方管理包括用于开展下列工作的各个过程：识别能够影响项目或会受项目影响的人员、团体或组织，分析相关方对项目的期望和影响，制定合适的管理策略来有效调动相关方参与项目决策和执行。用这些过程分析相关方期望，评估他们对项目或受项目影响的程度，以及制定策略来有效引导相关方支持项目决策、规划和执行。这些过程能够支持项目团队的工作。
项目相关方管理的过程是：
13.1 识别相关方 — 识别相关方是定期识别项目相关方，分析和记录他们的利益、参与度、相互依赖性、影响力和对项目成功的潜在影响的过程。
13.2 规划相关方参与 — 规划相关方参与是根据相关方的需求、期望、利益和对项目的潜在影响，制定项目相关方参与项目的方法的过程。
13.3 管理相关方参与 — 管理相关方参与是与相关方进行沟通和协作，以满足其需求与期望，处理问题，并促进相关方合理参与的过程。
13.4 监督相关方参与 — 监督项目相关方关系，并通过修订参与策略和计划来引导相关方合理参与项目的过程。
图 13-1 概括了项目相关方管理的各个过程。虽然在本《PMBOK® 指南》中，各项目相关方管理过
程以界限分明和相互独立的形式出现，但在实践中它们会以本指南无法全面详述的方式相互交叠和相互作用。
图 13-1项目相关方管理概述
项目相关方管理的核心概念每个项目都有相关方，他们会受项目的积极或消极影响，或者能对项目施加积极或消极的影响。
有些相关方影响项目工作或成果的能力有限，而有些相关方可能对项目及其期望成果有重大影响。
关于重大项目灾难的学术研究及分析强调了结构化方法对识别所有相关方、进行相关方优先级排序，以及引导相关方参与的重要性。项目经理和团队正确识别并合理引导所有相关方参与的能力，能决定着项目的成败。为提高成功的可能性，应该在项目章程被批准、项目经理被委任，以及团队开始组建之后，尽早开始识别相关方并引导相关方参与。
相关方满意度应作为项目目标加以识别和管理。有效引导相关方参与的关键是重视与所有相关方保持持续沟通（包括团队成员），以理解他们的需求和期望、处理所发生的问题、管理利益冲突，并促进相关方参与项目决策和活动。
为了实现项目收益，识别相关方和引导相关方参与的过程需要迭代开展。虽然在项目相关方管理中仅对这些过程讨论一次，但是，应该经常开展识别相关方、排列其优先级以及引导其参与等活动。至少要在以下时点开展这些活动：
- 项目进入其生命周期的不同阶段；
- 当前相关方不再与项目工作有关，或者在项目的相关方社区中出现了新的相关方成员；
- 组织内部或更大区域的相关方社区发生重大变化。
项目相关方管理的发展趋势和新兴实践“ 相关方”一词的外延正在扩大，从传统意义上的员工、供应商和股东扩展到涵盖各式群体，包括监管机构、游说团体、环保人士、金融组织、媒体，以及那些自认为是相关方的人员（他们认为自己会受项目工作或成果的影响）。
项目相关方管理的发展趋势和新兴实践包括（但不限于）：
- 识别所有相关方，而非在限定范围内；
- 确保所有团队成员都涉及引导相关方参与的活动；
- 定期审查相关方社区，往往与单个项目风险的审查并行开展；
- 应用“共创”概念，咨询最受项目工作或成果影响的相关方。该概念的重点是，将团队内受影响的相关方视为合作伙伴。
- 关注与相关方有效参与程度有关的正面及负面价值。正面价值是相关方（尤其是强大相关方）对项目的更积极支持所带来的效益；负面价值是因相关方未有效参与而造成的真实成本，包括产品召回、组织信誉损失或项目信誉损失。
裁剪时需要考虑的因素因为每个项目都是独特的，所以项目经理需要裁剪项目相关方管理过程。裁剪时应考虑的因素包括（但不限于）：
- 相关方多样性。现有多少相关方？相关方群体中的文化多样性如何？
- 相关方关系的复杂性。相关方社区内的关系有多复杂？相关方或相关方群体加入的网络越多，与其相关的信息或误传网络就越复杂。
- 沟通技术。有哪些可用的沟通技术？为了实现技术的最大价值，目前采用怎样的支持机制？
在敏捷或适应型环境中需要考虑的因素高度变化的项目更需要项目相关方的有效互动和参与。为了开展及时且高效的讨论及决策，适应型团队会直接与相关方互动，而不是通过层层的管理级别。客户、用户和开发人员在动态的共创过程中交换信息，通常能实现更高的相关方参与和满意程度。在整个项目期间保持与相关方社区的互动，有利于降低风险、建立信任和尽早做出项目调整，从而节约成本，提高项目成功的可能性。
为加快组织内部和组织之间的信息分享，敏捷型方法提倡高度透明。例如，邀请所有相关方参与项目会议和审查，或将项目工件发布到公共空间，其目的在于让各方之间的不一致和依赖关系，或者与不断变化的项目有关的其他问题，都尽快浮现。
要理解适应型项目中的过程应用，就要先理解项目生命周期的连续区间。《PMBOK® 指南》的术语表将项目生命周期定义为项目从开始到结束所经历的一系列阶段。项目生命周期内通常有一个或多个阶段与产品、服务或成果的开发相关。这些阶段称为开发生命周期。开发生命周期可分为预测型（计划驱动型）、适应型（敏捷型）、迭代型、增量型或混合型。
图 X3-1 显示了根据采用的生命周期类型，处理需求和计划的各种方式、如何管理风险和成本、进度考虑因素，以及如何处理关键相关方的参与。
图 X3-1项目生命周期的连续区间强调在项目开始阶段就明确需求和进行详细规划，这是预测型项目生命周期的特点。基于已知需求和制约因素而制定的详细计划，可以降低风险和成本。计划中也规定了需要关键相关方参与的里程碑时点。随着项目按详细计划逐渐推进，监控过程将重点限制可能影响范围、进度或预算的变更。
基于短期迭代规划和实施周期而对需求进行渐进明细，这是高适应型或敏捷型项目生命周期的特点。风险和成本随着对初始计划的渐进明细而逐渐降低。关键相关方持续参与，并频繁提供反馈，使项目能够更快地应对变更且获得更好的质量。
以下两点适用于处于连续区间中间位置的项目生命周期：(a) 风险和成本随着对初始计划的迭代演进而逐渐降低；以及 (b) 在增量型、迭代型和敏捷型周期中，相关方的参与机会更多，相比在高度预测型生命周期中只在项目里程碑时点参与。
处于连续区间中间位置的项目生命周期，可以更倾向于预测型或敏捷型。这取决于需求的确定方式、风险与成本的管理方式，以及关键相关方的参与性质。处于连续区间中间位置的项目可以采用混合型项目方法。
应该强调的是，开发生命周期具有复杂性和多维性。特定项目的不同阶段往往采用不同的生命周期，正如特定项目集内的每个项目都可用不同的方法去执行。
执行过程组是完成项目管理计划中确定的工作，以满足项目要求的一组过程。
在敏捷型、迭代型和适应型项目生命周期中，通过迭代对工作进行指导和管理。每次迭代都是在一个很短的固定时间段内开展工作，然后演示所形成的功能或设计。有关的相关方和团队再基于演示来开展回顾性审查。这种演示和审查有助于对照计划检查进展情况，确定是否有必要对项目范围、进度或执行过程做任何变更；也有助于通过展示已完成的工作增量，以及讨论未来工作，更好地管理相关方参与。进行回顾性审查，有利于及时发现和讨论与执行方法有关的问题，以及提出改进建议。通过讨论富有成效的做法以及依靠团队解决问题，回顾性审查也是管理项目知识和建设项目团队的主要工具。
虽然工作是通过短期迭代进行的，但是也需要对照长期的项目交付时间框架对其进行跟踪和管理。先在迭代期层面上追踪开发速度、成本支出、缺陷率和团队能力的走势，再汇总并推算到项目层面，来跟踪完工绩效。高度适应型方法旨在利用团队的专业知识去完成任务。有别于由项目经理确定工作内容和排定工作顺序，在这种方法中，项目经理解释高层级的目标，同时授权团队成员作为一个小组用最能实现目标的方式自行安排具体工作。这就使团队成员能够高度投入，制定出切合实际的计划。
对于高度适应型项目上的初级团队，在其达到适合授权的状态之前，通常都需要进行辅导和分配工作。可以在一个短暂迭代期中开展渐进式试验，然后在回顾性审查会上对团队进行审查，确定团队是否已具备无需辅导即能开展工作的技能。
监控过程组指的是跟踪、审查和调整项目进展与绩效，识别必要的计划变更并启动相应变更所需的一组过程。
在迭代型、敏捷型和适应型方法中，通过维护未完项清单，对进展和绩效进行跟踪、审查和调整。在项目团队的协助（分析并提供有关技术依赖关系的信息）下，业务代表对未完项进行优先级排序。基于业务优先级和团队能力，提取未完项清单最前面的任务，供下一个迭代期完成。业务代表在听取项目团队的技术意见之后，评审变更请求和缺陷报告，排列所需变更或补救的优先级，并列入工作未完项清单。
这种把工作和变更列入同一张清单的做法，起源于充满变更的项目环境。在这种项目环境中，无法把变更从原先计划的工作中分离出来。把变更和原先的工作整合到一张未完项清单中，就便于对全部工作进行重新排序，也能够为相关方管理和控制项目工作、实施变更控制和确认范围提供单一的平台。
随着排定了优先级的任务和变更从未完项清单中提取出来，并通过迭代加以完成，就可以测算已完成工作的趋势和指标，以及变更工作量和缺陷率。通过在短期迭代中频繁抽样，计算变更影响的数量和缺陷补救工作量，就可以对照原来的范围来考察团队能力和工作进展。这样一来，就能基于实际的进展速度和变更影响来估算项目成本、进度和范围。
应该借助趋势图表（信息扩散器）与项目相关方分享这些指标和预测，以便沟通进展情况、共同面对问题、推动持续改进，以及管理相关方期望。
收尾过程组是为正式完成或关闭项目、阶段或合同而开展的一组过程。在迭代型、适应型和敏捷型项目中，对工作进行优先级排序，以便首先完成最具商业价值的工作。这样，即便不得不提前关闭项目或阶段，也很可能已经创造出一些有用的商业价值。这就使得提前关闭不太像是一种归因于沉没成本的失败，而更像是一种提前实现收益、快速取得成功或验证某种业务概念。
项目范围管理的核心概念包括：
- 范围可以指产品范围（产品、服务或成果具有的特性和功能），或项目范围（为交付具有特定特性和功能产品、服务或成果而开展的工作）。
- 项目生命周期的连续区间涵盖预测型、适应型或敏捷型。在预测型生命周期中，项目开始时就对项目可交付成果进行定义，对任何范围变化都要进行渐进管理；而在适应型或敏捷型生命周期中，可交付成果经过多次迭代，详细范围得到了定义，并且在每次迭代开始时完成审批。
- 应该根据项目管理计划来衡量项目范围的完成情况，根据产品需求来衡量产品范围的完成情况。
裁剪项目风险管理时要考虑的因素包括（但不限于）：
- 项目规模。项目规模是否需要依据预算、持续时间、范围或团队规模进行调整，并采取更详细的风险管理方式？或者它是否够小，用简化的风险管理过程就足以应对？
- 项目复杂性。高水平创新、新技术、商务安排、相互联系或外部依赖关系会提高项目复杂性，它们是否需要稳健的风险管理方式？或者项目是否够简单，用简化的风险管理过程就足以满足需求？
- 项目重要性。项目有多大的战略重要性？此项目的风险级别升高，是否是因为它以创造突破性机会、克服组织绩效障碍为目标，或牵涉到重要的产品创新？
- 开发方法。它是否是瀑布式项目，风险管理过程可以相继或重复开展；或者此项目是否采取敏捷型方法，需在每个重复过程的开始阶段以及执行期间处理风险？
第 6 章名称从项目时间管理更改为项目进度管理。调查结果也支持对名称进行更改，因为项目经理并不管理时间，他们只是确定并管理项目进度。由于重心转移，以及项目人力资源管理更名为项目资源管理，估算活动资源过程也从此知识领域移到项目资源管理中。制定进度计划过程采纳了部分敏捷型概念。更新了图表和相关文字，以明确阐述本章的进度概念。
与从 X1.1 至 X1.11 节所述信息一致的变更也得到采纳。表 X1-2 对第 6 章的过程进行了总结：
表 X1-2 第 6 章变更
