1.2.1 项目

标准是基于权威、惯例或共识而建立并用作模式或范例的文件。本标准的开发过程遵循协商一致、开放公开、程序公正和各方平衡的基本原则。本标准描述在大多数时候适用于大多数项目的、被视为良好实践的过程，并把这些过程归入相应的过程组。本标准也对关键的项目管理概念进行定义，包括项目管理与组织战略及目标的关系，项目管理与组织治理、项目组合管理、项目集管理、项目环境及项目成功之间的关系。本标准还介绍项目生命周期、项目相关方，以及项目经理的角色。第 1 章介绍一些基本概念，并提供有关项目管理的背景信息。第 2 章至第 6 章对五大过程组进行逐一定义，并描述其下属过程。第 2 章至第 6 章还描述各项目管理过程的主要作用、输入和输出。本标准将作为《项目管理知识体系指南》（《PMBOK® 指南》）1 的基础和框架。《PMBOK® 指南》通过对相关背景、环境及其对项目管理的影响进行更深入的阐述，来扩展本标准的内容。此外，《PMBOK® 指南》也描述项目管理过程的输入和输出，识别项目管理过程的工具和技术，并按知识领域讨论一些重要概念和新趋势。

本《PMBOK® 指南》与方法论有所不同。方法论是由专门的从业人员所采用的实践、技术、程序和规则所组成的体系。而本《PMBOK® 指南》是组织制定实践项目管理所需方法论、政策、程序、规则、工具、技术和生命周期阶段的基础。

本指南的范围仅限于项目管理领域，而不涉及任何项目组合、项目集和多个项目的领域；仅在与项目有关时才会提及项目组合和项目集。PMI 还发布了针对项目组合和项目集的两部标准：

通用词汇是专业学科的基本要素。《PMI 项目管理术语词典》[4] 收录了基本的专业词汇，供组织、项目组合、项目集和项目经理及其他项目相关方统一使用。《术语词典》会随着时间的推移而更改。本指南的词汇表包含了《术语词典》中的词汇以及其他定义。项目可能会采用由行业文献定义的相关行业特定的术语。

PMI 发布了《道德与专业行为规范》[5]，为项目管理专业人员增强了信心并帮助个人做出明智的决策，尤其是在面对被要求违背正直诚信或价值观的困境时。全球项目管理业界定义的最重要的价值观是责任、尊重、公正和诚实。《道德与专业行为规范》确立了这四个价值观的基础地位。

本章描述了从事项目管理和了解项目管理领域所需的基本要素。

表 1-1促成项目创建的因素示例

项目管理就是将知识、技能、工具与技术应用于项目活动，以满足项目的要求。项目管理通过合理运用与整合特定项目所需的项目管理过程得以实现。项目管理使组织能够有效且高效地开展项目。

有效的项目管理能够帮助个人、群体以及公共和私人组织：

• 达成业务目标；
• 满足相关方的期望；
• 提高可预测性；
• 提高成功的概率；
• 在适当的时间交付正确的产品；
• 解决问题和争议；
• 及时应对风险；
• 优化组织资源的使用；
• 识别、挽救或终止失败项目；
• 管理制约因素（例如范围、质量、进度、成本、资源）；
• 平衡制约因素对项目的影响（例如范围扩大可能会增加成本或延长进度）；
• 以更好的方式管理变更。

项目管理不善或缺乏项目管理可能会导致：

• 超过时限；
• 成本超支；
• 质量低劣；
• 返工；
• 项目范围扩大失控；
• 组织声誉受损；
• 相关方不满意；
• 正在实施的项目无法达成目标。

项目是组织创造价值和效益的主要方式。在当今商业环境下，组织领导者需要应对预算紧缩、时间缩短、资源稀缺以及技术快速变化的情况。商业环境动荡不定，变化越来越快。为了在全球经济中保持竞争力，公司日益广泛利用项目管理，来持续创造商业价值。

有效和高效的项目管理应被视为组织的战略能力。它使组织能够：

• 将项目成果与业务目标联系起来；
• 更有效地展开市场竞争；
• 支持组织发展；
• 通过适当调整项目管理计划，以应对商业环境改变给项目带来的影响（见 4.2 节）。

表 1-2项目、项目集、项目组合管理的比较概述

建立一个新的通信卫星系统就是项目集的一个实例，其所辖项目包括卫星与地面站的设计和建造、卫星发射以及系统整合。

例如，以“投资回报最大化”为战略目标的某基础设施公司，可以把油气、供电、供水、道路、铁路和机场等项目归并成一个项目组合。在这些归并的项目中，组织又可以把相互关联的项目作为项目组合来管理。所有供电项目归类成供电项目组合，同理，所有供水项目归类成供水项目组合。然而，如果组织的项目是设计和建造发电站并运营发电站，这些相互关联的项目可以归类成一个项目集。这样的话，供电项目集和类似的供水项目集就是该基础设施公司项目组合中的基本组成部分。

运营管理是另外一个领域，超出了本指南所描述的规范的项目管理范围。

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

图 1-4组织项目管理

图 1-5 PMBOK® 指南关键组成部分在项目中的相互关系

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

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

阶段关口在项目阶段结束时进行，将项目的绩效和进度与项目和业务文件比较，这些文件包括（ 但不限于）：

• 项目商业论证（见 1.2.6.1 节）；
• 项目章程（见 4.1 节）；
• 项目管理计划（见 4.2 节）；
• 效益管理计划（见 1.2.6.2 节）。

根据比较结果做出决定（例如继续/终止的决定），以便：

• 进入下个阶段；
• 整改后进入下个阶段；
• 结束项目；
• 停留在当前阶段；
• 重复阶段或某个要素。

在不同的组织、行业或工作类型中，阶段关口可能被称为阶段审查、阶段门、关键决策点和阶段入口或阶段出口。组织可以通过这些审查来检查本指南范围之外的其他相关项，例如产品相关文件或模型。

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

项目管理过程组指对项目管理过程进行逻辑分组，以达成项目的特定目标。过程组不同于项目阶段。项目管理过程可分为以下五个项目管理过程组：

• 启动过程组定义一个新项目或现有项目的一个新阶段，授权开始该项目或阶段的一组过程。
• 规划过程组明确项目范围，优化目标，为实现目标制定行动方案的一组过程。
• 执行过程组完成项目管理计划中确定的工作，以满足项目要求的一组过程。
• 监控过程组跟踪、审查和调整项目进展与绩效，识别必要的计划变更并启动相应变更的一组过程。
• 收尾过程组正式完成或结束项目、阶段或合同所执行的过程。

本指南采用流程图。项目管理过程通过具体的输入和输出相互联系，即一个过程的成果或结果可能成为另一个过程（不一定在同一过程组）的输入。请注意，过程组与项目阶段不同（见 1.2.4.2 节）。

某些项目可能需要一个或多个其他的知识领域，例如，建造项目可能需要财务管理或安全与健康管理。表 1-4 列出了项目管理过程组和知识领域。第 4 章至第 13 章详细说明了各个知识领域。该表格概述了第 4 章至第 13章所描述的基本过程。

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

合理的项目管理方法论需要考虑项目的独特性，允许项目经理做出一定程度的裁剪。不过，对某一特定项目而言，方法论中的裁剪法本身可能也需要进行裁剪。

项目经理应适当地为项目裁剪上述项目管理文件。某些组织会维护项目集层面的商业论证和效益管理计划。项目经理应与相应的项目集经理合作，确保项目管理文件与项目集文件保持一致。图 1-8说明了这些关键项目管理商业文件与需求评估之间的相互关系。图 1-8 展示了项目生命周期内各种文件大概的生命周期。

项目商业论证指文档化的经济可行性研究报告，用来对尚缺乏充分定义的所选方案的收益进行有效性论证，是启动后续项目管理活动的依据。商业论证列出了项目启动的目标和理由。它有助于在项目结束时根据项目目标衡量项目是否成功。商业论证是一种项目商业文件，可在整个项目生命周期中使用。在项目启动之前通过商业论证，可能会做出继续/终止项目的决策。

需求评估通常是在商业论证之前进行，包括了解业务目的和目标、问题及机会，并提出处理建议。需求评估结果可能会在商业论证文件中进行总结。

定义业务需要、分析形势、提出建议和定义评估标准的过程，适用于任何组织的项目。商业论证可能包括（但不限于）记录以下内容：

• 业务需要；
• 确定促进采取行动的动机；
• 情况说明，记录了待处理的业务问题或机会，包括能够为组织创造的价值；
• 确定受影响的相关方；
• 确定范围。
• 形势分析：
• 确定组织战略、目的和目标；
• 确定问题的根本原因或机会的触发因素；
• 分析项目所需能力与组织现有能力之间的差距；
• 识别已知风险；
• 识别成功的关键因素；
• 确定可能用于评估各种行动的决策准则；

用于形势分析的准则可分为：

* 必需。必须践行的准则，可处理问题或机会。

* 预期。希望践行的准则，可处理问题或机会。

* 可选。非必要的准则。这一准则的践行情况可能成为区分备选行动方案的因素。

• 确定一套方案，用以处理业务问题或机会。可选方案指组织可能采取的备选行动方案。

可选方案也可称为商业场景。例如，商业论证可提供以下三种可选方案：

* 不采取任何行动。亦称为“一切照常”方案。选择这种方案会使项目未被授权。

* 尽最小的努力处理问题或机会。最小的努力可能指确定一系列对处理问题或机会而言极为关键的既定准则。

* 以超过最低限度的努力处理问题或机会。这一方案可满足最低限度的准则以及一些或所有其他在案准则。商业论证可能会提供上述多个方案。

• 推荐：
• 一种给出了针对项目的建议方案的说明书；
• 说明书的内容可能包括（但不限于）：

* 潜在方案的分析结果；

* 潜在方案的制约因素、假设、风险和依赖关系；

* 成功标准（见 1.2.6.4 节）。

• 一种实施方法，可能包括（但不限于）：

* 里程碑；

* 依赖关系；

* 角色与职责。

• 评估：
• 一种描述了衡量项目交付效益的计划的说明书，应包含在初步实施之后，任何持续运营层面的可选方案。

通过将成果与目标和确定的成功标准进行比较，商业论证文件为衡量整个项目生命周期的成功和进展奠定了基础。请参见《从业者商业分析：实践指南》[7]。

项目效益管理计划的制定和维护是一项迭代活动。它是商业论证、项目章程和项目管理计划的补充性文件。项目经理与发起人共同确保项目章程、项目管理计划和效益管理计划在整个项目生命周期内始终保持一致。请参见《从业者商业分析：实践指南》[7]、《项目集管理标准》[3]和《项目组合管理标准》[2]。

项目管理计划是描述如何执行、监督和控制项目的一份文件。

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

图 2-1项目影响

从性质或类型上讲，事业环境因素是多种多样的。有效开展项目，就必须考虑这些因素。事业环境因素包括（但不限于）第 2.2.1 节和 2.2.2 节所描述的因素。

第二类资产是在整个项目期间结合项目信息而更新的。例如，整个项目期间会持续更新与财务绩效、经验教训、绩效指标和问题以及缺陷相关的信息。

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

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

组织用来存取信息的知识库，包括（但不限于）：

• 配置管理知识库，包括软件和硬件组件版本以及所有执行组织的标准、政策、程序和任何项目文件的基准；
• 财务数据库，包括人工时、实际成本、预算和成本超支等方面的信息；
• 历史信息与经验教训知识库（如项目记录与文件、完整的项目收尾信息与文件、关于以往项目选择决策的结果及以往项目绩效的信息，以及从风险管理活动中获取的信息）；
• 问题与缺陷管理数据库，包括问题与缺陷的状态、控制信息、解决方案以及相关行动的结果；
• 测量指标数据库，用来收集与提供过程和产品的测量数据；
• 以往项目的项目档案（如范围、成本、进度与绩效测量基准，项目日历，项目进度网络图，风险登记册，风险报告以及相关方登记册）。

系统通常由组织管理层负责。组织管理层检查组件与系统之间的优化权衡，以便采取合适的措施为组织实现最佳结果。这一检查工作的结果将对相应的项目造成影响。因此，项目经理在确定如何达成项目目标时务必要考虑这些结果。此外，项目经理应考虑到组织的治理框架。

关于项目治理及其实施的更多信息，请参见《项目组合、项目集和项目治理：实践指南》[10]。

组织需要权衡两个关键变量之后才可确定合适的组织结构类型。这两个变量指可以采用的组织结构类型以及针对特定组织如何优化组织结构类型的方式。不存在一种结构类型适用于任何特定组织。因要考虑各种可变因素，特定组织的最终结构是独特的。2.4.4.1 节和 2.4.4.2 节描述了在权衡这两个变量时应考虑的一些因素。2.4.4.3 节讨论了项目管理中常见的一种组织结构。

组织结构的形式或类型是多种多样的。表 2-1 比较了几种组织结构类型及其对项目的影响。

表 2-1组织结构对项目的影响

项目管理办公室 (PMO) 是对与项目相关的治理过程进行标准化，并促进资源、方法论、工具和技术共享的一个组织结构。PMO 的职责范围可大可小，从提供项目管理支持服务，到直接管理一个或多个项目。

PMO 有几种不同类型，它们对项目的控制和影响程度各不相同，例如：

• 支持型。支持型 PMO 担当顾问的角色，向项目提供模板、最佳实践、培训，以及来自其他项目的信息和经验教训。这种类型的 PMO 其实就是一个项目资源库，对项目的控制程度很低。
• 控制型。控制型 PMO 不仅给项目提供支持，而且通过各种手段要求项目服从，这种类型的 PMO对项目的控制程度属于中等。服从可能包括：
• 采用项目管理框架或方法论；
• 使用特定的模板、格式和工具；
• 服从治理。
• 指令型。指令型 PMO 直接管理和控制项目。项目经理由 PMO 指定并向其报告。这种类型的 PMO对项目的控制程度很高。

项目管理办公室可能会承担整个组织范围的职责，在支持战略调整和创造组织价值方面发挥重要的作用。PMO 从组织战略项目中获取数据和信息，进行综合分析，评估如何实现更高级别的战略目标的。PMO 在组织的项目组合、项目集、项目与组织考评体系（如平衡计分卡）之间建立联系。

除了被集中管理以外，PMO 所支持和管理的项目不一定彼此关联。PMO 的具体形式、职能和结构取决于所在组织的需要。

为了保证项目符合组织的业务目标，PMO 可能有权在每个项目的生命周期中充当重要相关方和关键决策者。PMO 可以：

• 提出建议；
• 领导知识传递；
• 终止项目；
• 根据需要采取其他行动。

PMO 的一个主要职能是通过各种方式向项目经理提供支持，这些方式包括（但不限于）：

• 对 PMO 所辖的全部项目的共享资源进行管理；
• 识别和制定项目管理方法、最佳实践和标准；
• 指导、辅导、培训和监督；
• 通过项目审计，监督对项目管理标准、政策、程序和模板的遵守程度；
• 制定和管理项目政策、程序、模板和其他共享的文件（组织过程资产）；
• 对跨项目的沟通进行协调。

本章接下来的部分讨论项目经理角色的主要方面。关于这个话题有数以千计书籍和文章，但本章不涵盖全部内容，而是旨在通过概述让从业者对这个话题有个基本的认识，为深入研究文中提及的各个方面做好准备。

项目经理的角色不同于职能经理或运营经理。一般而言，职能经理专注于对某个职能领域或业务部门的管理监督。运营经理负责保证业务运营的高效性。项目经理是由执行组织委派，领导团队实现项目目标的个人。

项目经理在其影响力范围内担任多种角色。这些角色反映了项目经理的能力，体现了项目经理这一职业的价值和作用。本章将重点讲述项目经理在图 3-1 所示的各种影响力范围内的角色。

项目经理领导项目团队实现项目目标和相关方的期望。项目经理利用可用资源，以平衡相互竞争的制约因素。

项目经理还充当项目发起人、团队成员与其他相关方之间的沟通者，包括提供指导和展示项目成功的愿景。项目经理使用软技能（例如人际关系技能和人员管理技能）来平衡项目相关方之间相互冲突和竞争的目标，以达成共识。这种情况下的共识指即便不 100% 赞同，相关方还会支持项目决定和行动。

研究表明，成功的项目经理可以持续和有效地使用某些基本技能。研究指出，在由上级和团队成员指定的项目经理中，排名前 2% 的项目经理之所以脱颖而出，是因为他们展现出了超凡的人际关系和沟通技能以及积极的态度 [12]。

与团队和发起人等相关方沟通的能力适用于项目的各个方面，包括（但不限于）以下各个方面：

• 通过多种方法（例如口头、书面和非言语）培养完善的技能；
• 创建、维护和遵循沟通计划和进度计划；
• 不断地以可预见的方式进行沟通；
• 寻求了解项目相关方的沟通需求（沟通可能是某些相关方在最终产品或服务实现之前获取信息的唯一渠道）；
• 以简练、清晰、完整、简单、相关和经过裁剪的方式进行沟通；
• 包含重要的正面和负面消息；
• 合并反馈渠道；
• 人际关系技能，即通过项目经理的影响力范围拓展广泛的人际网络。这些人际网络包括正式的人际网络，例如组织架构图；但项目经理发展、维护和培养的非正式人际网络更加重要。非正式人际网络包括与主题专家和具有影响力的领导者建立的个人人际关系。通过这些正式和非正式的人际网络，项目经理可以让很多人参与解决问题并探询项目中遇到的官僚主义障碍。

基于组织结构，项目经理可能向职能经理报告。而在其他情况下，项目经理可能与其他项目经理一起，向 PMO、项目组合或项目集经理报告。项目组合或项目集经理对整个组织范围内的一个或多个项目承担最终责任。为了实现项目目标，项目经理需要与所有相关经理紧密合作，确保项目管理计划符合所在项目组合或项目集的计划。项目经理还需与其他角色紧密协作，如组织经理、主题专家以及商业分析人员。在某些情况下，项目经理可以是临时管理角色的外部顾问。

项目经理应时刻关注行业的最新发展趋势，获得并思考这一信息对当前项目是否有影响或可用。

这些趋势包括（但不限于）：

• 产品和技术开发；
• 新且正在变化的市场空间；
• 标准（例如项目管理标准、质量管理标准、信息安全管理标准）；
• 技术支持工具；
• 影响当前项目的经济力量；
• 影响项目管理学科的影响力；
• 过程改进和可持续发展战略。

对项目经理而言，持续的知识传递和整合非常重要。项目管理专业和项目经理担任主题专家的其他领域都在持续推进相应的专业发展。知识传递和整合包括（但不限于）：

• 在当地、全国和全球层面（例如实践社区、国际组织）向其他专业人员分享知识和专业技能；
• 参与培训、继续教育和发展：
• 项目管理专业（例如大学、PMI）；
• 相关专业（例如系统工程、配置管理）；
• 其他专业（例如信息技术、航空航天）。

专业的项目经理针对组织的价值可以选择指导和教育其他专业人员项目管理方法。项目经理还可以担任非正式的宣传大使，让组织了解项目管理在及时性、质量、创新和资源管理方面的优势。

为发挥最大的效果，项目经理需要平衡这三种技能。

技术项目管理技能指有效运用项目管理知识实现项目集或项目的预期成果的能力。有很多技术项目管理技能。本指南的知识领域部分描述了很多必要的项目管理技能。项目经理经常会依赖专家判断来有效开展工作。要获得成功，重要的是项目经理必须了解个人专长以及如何找到具备所需专业知识的人员。

研究表明，顶尖的项目经理会持续展现出几种关键技能，包括（但不限于）：

• 重点关注所管理的各个项目的关键技术项目管理要素。简单来说就是随时准备好合适的资料。

最主要的是：

• 项目成功的关键因素；
• 进度；
• 指定的财务报告；
• 问题日志。
• 针对每个项目裁剪传统和敏捷工具、技术和方法。
• 花时间制定完整的计划并谨慎排定优先顺序。
• 管理项目要素，包括（但不限于）进度、成本、资源和风险。

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

领导力技能包括指导、激励和带领团队的能力。这些技能可能包括协商、抗压、沟通、解决问题、批判性思考和人际关系技能等基本能力。随着越来越多的公司通过项目执行战略，项目变得越来越复杂。项目管理不仅仅涉及数字、模板、图表、图形和计算机系统方面的工作。人是所有项目中的共同点。人可以计数，但不仅仅是数字。

人际交往占据项目经理工作的很大一部分。项目经理应研究人的行为和动机，应尽力成为一个好的领导者，因为领导力对组织项目是否成功至关重要。项目经理需要运用领导力技能和品质与所有项目相关方合作，包括项目团队、团队指导和项目发起人。

研究显示，领导者的品质和技能包括（但不限于）：

• 有远见（例如帮助描述项目的产品、目的和目标；能够有梦想并向他人诠释愿景）；
• 积极乐观；
• 乐于合作；
• 通过以下方式管理关系和冲突：
• 建立信任；
• 解决顾虑；
• 寻求共识；
• 平衡相互竞争和对立的目标；
• 运用说服、协商、妥协和解决冲突的技能；
• 发展和培养个人及专业网络；
• 以长远的眼光来看待人际关系是与项目同样重要；
• 持续发展和运用政治敏锐性。
• 通过以下方式进行沟通：
• 花大量的时间沟通（研究显示，顶尖的项目经理投入有 90% 左右的时间是花在沟通上）；
• 管理期望；
• 诚恳地接受反馈；
• 提出建设性的反馈；
• 询问和倾听。
• 尊重他人（帮助他人保持独立自主）、谦恭有礼、友善待人、诚实可信、忠诚可靠、遵守职业道德；
• 展现出诚信正直和文化敏感性，果断、勇敢，能够解决问题；
• 适当时称赞他人；
• 终身学习，以结果和行动为导向；
• 关注重要的事情，包括：
• 通过必要的审查和调整，持续优化工作；
• 寻求并采用适用于团队和项目的优先级排序方法；
• 区分高层级战略优先级，尤其是与项目成功的关键因素相关的事项；
• 对项目的主要制约因素保持警惕；
• 在战术优先级上保持灵活；
• 能够从大量信息中筛选出最重要的信息。
• 以整体和系统的角度来看待项目，同等对待内部和外部因素；
• 能够运用批判性思维（例如运用分析方法来制定决策）并将自己视为变革推动者。
• 能够创建高效的团队、以服务为导向、展现出幽默的一面，与团队成员有效地分享乐趣。

在权力方面，顶尖的项目经理积极主动且目的明确。这些项目经理会在组织政策、协议和程序许可的范围内主动寻求所需的权力和职权，而不是坐等组织授权。

为获得成功，项目经理必须同时采用领导力和管理这两种方式。技巧在于如何针对各种情况找到恰当的平衡点。项目经理的领导风格通常体现了他们所采用的管理和领导力方式。

研究显示项目经理可以采用的多种领导力风格。在这些风格中，最常见的包括（但不限于）：

高效的项目经理在上述各个方面都具备一定程度的能力。每个项目、组织和情况都要求项目经理重视个性的不同方面。

整合是项目经理的一项关键技能。本指南的项目整合管理知识领域对整合更深入地进行了探讨。3.5.1 节至 3.5.4 节重点关注以下三个不同层面发生的整合：过程层面、认知层面和背景层面。

虽然对项目过程的整合方式没有明确的定义，但如果项目经理无法整合相互作用的项目过程，那么实现项目目标的机会将会很小。

项目经理应尽量掌握所有项目管理知识领域。熟练掌握这些知识领域之后，项目经理可以将经验、见解、领导力、技术以及商业管理技能运用到项目管理中。最后，项目经理需要整合这些知识领域所涵盖的过程才有可能实现预期的项目结果。

在管理整合时，项目经理需要意识到项目背景和这些新因素，然后项目经理可以决定如何在项目中最好地利用这些新环境因素，以获得项目成功。

这些因素会增加项目的复杂性，通过检查，有助于项目经理在规划、管理和控制项目时可以识别关键领域，确保完成整合。

在适应型环境下，《整合管理的核心概念》中所述的对项目经理的期望保持不变，但把对具体产品的规划和交付授权给团队来控制。项目经理的关注点在于营造一个合作型的决策氛围，并确保团队有能力应对变更。如果团队成员具备广泛的技能基础而不局限于某个狭窄的专业领域，那么这种合作型方法就会更加有效。

项目可能因内部经营需要或外部影响而启动，故通常需要编制需求分析、可行性研究、商业论证或有待项目处理的情况的描述。通过编制项目章程，来确认项目符合组织战略和日常运营的需要。

专家判断是指基于某应用领域、知识领域、学科和行业等的专业知识而做出的，关于当前活动的合理判断，这些专业知识可来自具有专业学历、知识、技能、经验或培训经历的任何小组或个人。

本过程应该就以下主题，考虑具备相关专业知识或接受过相关培训的个人或小组的意见：

• 组织战略；
• 效益管理；
• 关于项目所在的行业以及项目关注的领域的技术知识；
• 持续时间和预算的估算；
• 风险识别。

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

• 头脑风暴。本技术用于在短时间内获得大量创意，适用于团队环境，需要引导者进行引导。

头脑风暴由两个部分构成：创意产生和创意分析。制定项目章程时可通过头脑风暴向相关方、主题专家和团队成员收集数据、解决方案或创意。

• 焦点小组。见 5.2.2.2 节。焦点小组召集相关方和主题专家讨论项目风险、成功标准和其他议题，比一对一访谈更有利于互动交流。
• 访谈。见 5.2.2.2 节。访谈是指通过与相关方直接交谈来了解高层级需求、假设条件、制约因素、审批标准以及其他信息。

可用于本过程的人际关系与团队技能包括（但不限于）：

• 冲突管理。见 9.5.2.1 节。冲突管理有助于相关方就目标、成功标准、高层级需求、项目描述、总体里程碑和其他内容达成一致意见。
• 引导。引导是指有效引导团队活动成功以达成决定、解决方案或结论的能力。引导者确保参与者有效参与，互相理解，考虑所有意见，按既定决策流程全力支持得到的结论或结果，以及所达成的行动计划和协议在之后得到合理执行。
• 会议管理。见 10.2.2.6 节。会议管理包括准备议程、确保邀请每个关键相关方群体的代表，以及准备和发送后续的会议纪要和行动计划。

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

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

通常，在项目启动之前编制商业论证时，识别高层级的战略和运营假设条件与制约因素。这些假设条件与制约因素应纳入项目章程。较低层级的活动和任务假设条件在项目期间随着诸如定义技术规范、估算、进度和风险等活动的开展而生成。假设日志用于记录整个项目生命周期中的所有假设条件和制约因素。

项目章程包含来源于商业文件中的相关项目信息。既然商业文件不是项目文件，项目经理就不可以对它们进行更新或修改，只可以提出相关建议。

见 12.2.3.2 节。协议用于定义启动项目的初衷。协议有多种形式，包括合同、谅解备忘录（MOUs）、服务水平协议（SLA）、协议书、意向书、口头协议、电子邮件或其他书面协议。为外部客户做项目时，通常就以合同的形式出现。

能够影响制定项目章程过程的组织过程资产包括（但不限于）：

• 组织的标准政策、流程和程序；
• 项目组合、项目集和项目的治理框架（用于提供指导和制定决策的治理职能和过程）；
• 监督和报告方法；
• 模板（如项目章程模板）；
• 历史信息与经验教训知识库（如项目记录与文件、关于以往项目选择决策的结果及以往项目绩效的信息）。

对隶属于项目集或项目组合的项目，则应该制定与项目集或项目组合管理计划相一致的项目管理计划。例如，项目集管理计划中要求超过某一特定成本的所有变更都需要上报变更控制委员会（CCB）审查，在项目管理计划中就应该对审查流程和成本临界值做出相应规定。

见 4.1.3.1 节。项目团队把项目章程作为初始项目规划的起始点。项目章程所包含的信息种类数量因项目的复杂程度和已知的信息而异。在项目章程中至少应该定义项目的高层级信息，供将来在项目管理计划的各个组成部分中进一步细化。

能够影响制定项目管理计划过程的事业环境因素包括（但不限于）：

• 政府或行业标准（如产品标准、质量标准、安全标准和工艺标准）；
• 法律法规要求和（或）制约因素；
• 垂直市场（如建筑）和（或）专门领域（如环境、安全、风险或敏捷软件开发）的项目管理知识体系；
• 组织的结构、文化、管理实践和可持续性；
• 组织治理框架（通过安排人员、制定政策和确定过程，以结构化的方式实施控制、指导和协调，以实现组织的战略和运营目标）；
• 基础设施（如现有的设施和固定资产）。

能够影响制定项目管理计划过程的组织过程资产包括（但不限于）：

• 组织的标准政策、流程和程序；
• 项目管理计划模板，包括：
• 根据项目的特定要求而裁剪组织的标准流程的指南和标准；
• 项目收尾指南或要求，如产品确认及验收标准。
• 变更控制程序，包括修改正式的组织标准、政策、计划、程序或项目文件，以及批准和确认变更所须遵循的步骤；
• 监督和报告方法、风险控制程序，以及沟通要求；
• 以往类似项目的相关信息（如范围、成本、进度与绩效测量基准、项目日历、项目进度网络图和风险登记册）；
• 历史信息和经验教训知识库。

见 4.1.2.1 节。应该就以下主题，考虑具备相关专业知识或接受过相关培训的个人或小组的意见：

• 根据项目需要裁剪项目管理过程，包括这些过程间的依赖关系和相互影响，以及这些过程的主要输入和输出；
• 根据需要制定项目管理计划的附加组成部分；
• 确定这些过程所需的工具与技术；
• 编制应包括在项目管理计划中的技术与管理细节；
• 确定项目所需的资源与技能水平；
• 定义项目的配置管理级别；
• 确定哪些项目文件受制于正式的变更控制过程；
• 确定项目工作的优先级，确保把项目资源在合适的时间分配到合适的工作。

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

• 头脑风暴。见 4.1.2.2 节。制定项目管理计划时，经常以头脑风暴的形式来收集关于项目方法的创意和解决方案。参会者包括项目团队成员，其他主题专家 (SME) 或相关方也可以参与。
• 核对单。见 11.2.2.2 节。很多组织基于自身经验制定了标准化的核对单，或者采用所在行业的核对单。核对单可以指导项目经理制定计划或帮助检查项目管理计划是否包含所需全部信息。
• 焦点小组。见 5.2.2.2 节。焦点小组召集相关方讨论项目管理方法以及项目管理计划各个组成部分的整合方式。
• 访谈。见 5.2.2.2 节。访谈用于从相关方获取特定信息，用以制定项目管理计划、任何子计划或项目文件。

对于多阶段项目，通常在每个阶段开始时都要 举行一次开工会议。

项目管理计划是用于管理项目的主要文件之一。管理项目时还会使用其他项目文件。这些其他文件不属于项目管理计划，但它们也是实现高效管理所必需的文件。表 4-1 列出了主要的项目管理计划组件和项目文件。

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

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

• 变更日志。见 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 节。风险报告提供关于整体项目风险来源的信息，以及关于已识别单个项目风险的概括信息。

见 4.6.3.1 节。批准的变更请求是实施整体变更控制过程的输出，包括经项目经理审查和批准的变更请求，必要时可经变更控制委员会 (CCB) 审查和批准。批准的变更请求可能是纠正措施、预防措施或缺陷补救，并由项目团队纳入项目进度计划付诸实施，可能对项目或项目管理计划的任一领域产生影响，还可能导致修改正式受控的项目管理计划组件或项目文件。

能够影响指导与管理项目工作过程的组织过程资产包括（但不限于）：

• 组织的标准政策、流程和程序；
• 问题与缺陷管理程序，用于定义问题与缺陷控制、问题与缺陷识别及其解决，以及行动事项跟踪；
• 问题与缺陷管理数据库，包括历史问题与缺陷状态、问题和缺陷解决情况，以及行动事项的结果；
• 绩效测量数据库，用来收集与提供过程和产品的测量数据；
• 变更控制和风险控制程序；
• 以往项目的项目信息（如范围、成本、进度与绩效测量基准，项目日历，项目进度网络图，风险登记册，风险报告以及经验教训知识库）。

见 4.1.2.1 节。应该就以下主题，考虑具备相关专业知识或接受过相关培训的个人或小组的意见：

• 关于项目所在的行业以及项目关注的领域的技术知识；
• 成本和预算管理；
• 法规与采购；
• 法律法规；
• 组织治理。

在指导与管理项目工作时，可以通过会议来讨论和解决项目的相关事项。参会者可包括项目经理、项目团队成员，以及与所讨论事项相关或会受该事项影响的相关方。应该明确每个参会者的角色，确保有效参会。会议类型包括（但不限于）：开工会议、技术会议、敏捷或迭代规划会议、每日站会、指导小组会议、问题解决会议、进展跟进会议以及回顾会议。

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

工作绩效数据是在执行项目工作的过程中，从每个正在执行的活动中收集到的原始观察结果和测量值。数据通常是最低层次的细节，将交由其他过程从中提炼出信息。在工作执行过程中收集数据，再交由控制过程做进一步分析。

问题日志可以帮助项目经理有效跟进和管理问题，确保它们得到调查和解决。作为本过程的输出，问题日志被首次创建，尽管在项目期间任何时候都可能发生问题。在整个项目生命周期应该随同监控活动更新问题日志。

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

• 纠正措施。为使项目工作绩效重新与项目管理计划一致，而进行的有目的的活动。
• 预防措施。为确保项目工作的未来绩效符合项目管理计划，而进行的有目的的活动。
• 缺陷补救。为了修正不一致产品或产品组件的有目的的活动。
• 更新。对正式受控的项目文件或计划等进行的变更，以反映修改或增加的意见或内容。

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

• 活动清单。见 6.2.3.1 节。为完成项目工作，可以通过增加或修改活动来更新活动清单。
• 假设日志。见 4.1.3.2 节。可以增加新的假设条件和制约因素，也可以更新或关闭已有的假设条件和制约因素。
• 经验教训登记册。见 4.4.3.1 节。任何有助于提高当前或未来项目绩效的经验教训都应得到及时记录。
• 需求文件。见 5.2.3.1 节。在本过程中可以识别新的需求，也可以适时更新需求的实现情况。
• 风险登记册。见 11.2.3.1 节。在本过程中可以识别新的风险，也可以更新现有风险。风险登记册用于在风险管理过程中记录风险。
• 相关方登记册。见 13.1.3.1 节。如果在本过程中收集到了现有或新相关方的更多信息，则记录到相关方登记册中。

从组织的角度来看，知识管理指的是确保项目团队和其他相关方的技能、经验和专业知识在项目开始之前、开展期间和结束之后得到运用。因为知识存在于人们的思想中，且无法强迫人们分享自己的知识或关注他人的知识，所以，知识管理最重要的环节就是营造一种相互信任的氛围，激励人们分享知识或关注他人的知识。如果不激励人们分享知识或关注他人的知识，即便最好的知识管理工具和技术也无法发挥作用。在实践中，联合使用知识管理工具和技术（用于人际互动）以及信息管理工具和技术（用于编撰显性知识）来分享知识。

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

• 经验教训登记册。见 4.4.3.1 节。经验教训登记册提供了有效的知识管理实践。
• 项目团队派工单。见 9.3.3.1 节。项目团队派工单说明了项目已具有的能力和经验以及可能缺乏的知识。
• 资源分解结构。见 9.2.3.3 节。资源分解结构包含有关团队组成的信息，有助于了解团队拥有和缺乏的知识。
• 相关方登记册。见 13.1.3.1 节。相关方登记册包含已识别的相关方的详细情况，有助于了解他们可能拥有的知识。

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

能够影响管理项目知识过程的事业环境因素包括（但不限于）：

• 组织文化、相关方文化和客户文化。相互信任的工作关系和互不指责的文化对知识管理尤其重要。其他因素则包括赋予学习的价值和社会行为规范。
• 设施和资源的地理分布。团队成员所在的位置有助于确定收集和分享知识的方法。
• 组织中的知识专家。有些组织拥有专门从事知识管理的团队或员工。
• 法律法规要求和（或）制约因素。包括对项目信息的保密性要求。

在项目管理过程和例行工作中，经常必然要使用项目管理知识，能够影响管理项目知识过程的组织过程资产包括（但不限于）：

• 组织的标准政策、流程和程序。可能包括：信息的保密性和获取渠道、安全与数据保护、记录保留政策、版权信息的使用、机密信息的销毁、文件格式和最大篇幅、注册数据和元数据、授权使用的技术和社交媒体等。
• 人事管理制度。包括员工发展与培训记录以及关于知识分享行为的能力框架。
• 组织对沟通的要求。正式且严格的沟通要求有利于信息分享。对于生成新知识和整合不同相关方群体的知识，非正式沟通更加有效。
• 正式的知识分享和信息分享程序。包括项目和项目阶段开始之前、开展期间和结束之后的学习回顾，例如识别、吸取和分享从当前项目和其他项目获得的经验教训。

见 4.1.2.1 节。应该就以下主题，考虑具备相关专业知识或接受过相关培训的个人或小组的意见：

• 知识管理；
• 信息管理；
• 组织学习；
• 知识和信息管理工具；
• 来自其他项目的相关信息。

知识管理工具和技术将员工联系起来，使他们能够合作生成新知识、分享隐性知识，以及集成不同团队成员所拥有的知识。适用于项目的工具和技术取决于项目的性质，尤其是创新程度、项目复杂性，以及团队的多元化（包括学科背景多元化）程度。

知识和信息管理工具与技术应与项目过程和过程责任人相对应。例如，实践社区和主题专家 (SME)可以提供见解，帮助改善控制过程；而设置内部发起人可以确保改善措施得到执行。可以分析经验教训登记册的条目来识别通过项目程序变更能够解决的常见问题。

可用于本过程的人际关系与团队技能包括（但不限于）：

• 积极倾听。见 10.2.2.6 节。积极倾听有助于减少误解并促进沟通和知识分享。
• 引导。见 4.1.2.3 节。引导有助于有效指引团队成功地达成决定、解决方案或结论。
• 领导力。见 3.4.4 节。领导力可帮助沟通愿景并鼓舞项目团队关注合适的知识和知识目标。
• 人际交往。见 10.2.2.6 节。人际交往促使项目相关方之间建立非正式的联系和关系，为显性和隐性知识的分享创造条件。
• 政治意识。见 10.1.2.6 节。政治意识有助于项目经理根据项目环境和组织的政治环境规划沟通。

在项目或阶段结束时，把相关信息归入经验教训知识库，成为组织过程资产的一部分。

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

监控项目工作是跟踪、审查和报告整体项目进展，以实现项目管理计划中确定的绩效目标的过程。本过程的主要作用是，让相关方了解项目的当前状态并认可为处理绩效问题而采取的行动，以及通过成本和进度预测，让相关方了解未来项目状态。本过程需要在整个项目期间开展。

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

图 4-10监控项目工作：输入、工具与技术和输出

• Projectcharter图 4-11监控项目工作：数据流向图

监督是贯穿于整个项目的项目管理活动之一，包括收集、测量和分析测量结果，以及预测趋势，以便推动过程改进。持续的监督使项目管理团队能洞察项目的健康状况，并识别须特别关注的任何方面。控制包括制定纠正或预防措施或重新规划，并跟踪行动计划的实施过程，以确保它们能有效解决问题。监控项目工作过程关注：

• 把项目的实际绩效与项目管理计划进行比较；
• 定期评估项目绩效，决定是否需要采取纠正或预防措施，并推荐必要的措施；
• 检查单个项目风险的状态；
• 在整个项目期间，维护一个准确且及时更新的信息库，以反映项目产品及相关文件的情况；
• 为状态报告、进展测量和预测提供信息；
• 做出预测，以更新当前的成本与进度信息；
• 监督已批准变更的实施情况；
• 如果项目是项目集的一部分，还应向项目集管理层报告项目进展和状态；
• 确保项目与商业需求保持一致。

见 4.2.3.1 节。监控项目工作包括查看项目的各个方面。项目管理计划的任一组成部分都可作为本过程的输入。

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

• 假设日志。见 4.1.3.2 节。假设日志包含会影响项目的假设条件和制约因素的信息。
• 估算依据。见 6.4.3.2 节和 7.2.3.2 节。估算依据说明不同估算是如何得出的，用于决定如何应对偏差。
• 成本预测。见 7.4.3.2 节。成本预测基于项目以往的绩效，用于确定项目是否仍处于预算的公差区间内，并识别任何必要的变更。
• 问题日志。见 4.3.3.3 节。问题日志用于记录和监督由谁负责在目标日期内解决特定问题。
• 经验教训登记册。见 4.4.3.1 节。经验教训登记册可能包含应对偏差的有效方式以及纠正措施和预防措施。
• 里程碑清单。见 6.2.3.3 节。里程碑清单列出特定里程碑的实现日期，用于检查是否达到计划的里程碑。
• 质量报告。见 8.2.3.1 节。质量报告包含质量管理问题，针对过程、项目和产品的改善建议，纠正措施建议（包括返工、缺陷（漏洞）补救、100% 检查等），以及在控制质量过程中发现的情况的概述。
• 风险登记册。见 11.2.3.1 节。风险登记册提供在项目执行过程中发生的各种威胁和机会的相关信息。
• 风险报告。见 11.2.3.2 节。风险报告提供关于整体项目风险和单个风险的信息。
• 进度预测。见 6.6.3.2 节。进度预测基于项目以往的绩效，用于确定项目是否仍处于进度的公差区间内，并识别任何必要的变更。

例如，关于成本的工作绩效数据可能包含已支出的资金，但必须与预算、已执行的工作、用于完成工作的资源以及资金使用计划比较之后才能有用。这些附加信息为确定项目是否符合预算或是否存在偏差提供了相应的情境；还有助于了解偏差的严重程度。通过与项目管理计划中的偏差临界值进行比较，就可以确定是否需要采取预防或纠正措施。对工作绩效数据和附加信息进行综合分析，可以为项目决策提供可靠的基础。

见 12.2.3.2 节。采购协议中包括条款和条件，也可包括其他条目，如买方就卖方应实施的工作或应交付的产品所做的规定。如果项目将部分工作外包出去，项目经理需要监督承包商的工作，确保所有协议都符合项目的特定要求，以及组织的采购政策。

能够影响监控项目工作过程的事业环境因素包括（但不限于）：

• 项目管理信息系统，例如进度、成本、资源工具、绩效指标、数据库、项目记录和财务数据；
• 基础设施（如现有设施、设备、组织通讯渠道）；
• 相关方的期望和风险临界值；
• 政府或行业标准（如监管机构条例、产品标准、质量标准和工艺标准）；

见 4.1.2.1 节。应该就以下主题，考虑具备相关专业知识或接受过相关培训的个人或小组的意见：

• 挣值分析；
• 数据的解释和情境化；
• 持续时间和成本的估算技术；
• 趋势分析；
• 关于项目所在的行业以及项目关注的领域的技术知识；
• 风险管理；
• 合同管理。

可以在每个知识领域，针对特定变量，开展偏差分析。在监控项目工作过程中，通过偏差分析对成本、时间、技术和资源偏差进行综合分析，以了解项目的总体偏差情况。这样就便于采取合适的预防或纠正措施。

会议可以是面对面或虚拟会议，正式或非正式会议。参会者可以包括项目团队成员和其他合适的项目相关方；会议的类型包括（但不限于）用户小组会议和用户审查会议。

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

• 纠正措施。为使项目工作绩效重新与项目管理计划一致，而进行的有目的的活动。
• 预防措施。为确保项目工作的未来绩效符合项目管理计划，而进行的有目的的活动。
• 缺陷补救。为了修正不一致产品或产品组件而进行的有目的的活动。

尽管也可以口头提出，但所有变更请求都必须以书面形式记录，并纳入变更管理和（或）配置管理系统中。在批准变更之前，可能需要了解变更对进度的影响和对成本的影响。在变更请求可能影响任一项目基准的情况下，都需要开展正式的整体变更控制过程。每项记录在案的变更请求都必须由一位责任人批准、推迟或否决，这个责任人通常是项目发起人或项目经理。应该在项目管理计划或组织程序中指定这位责任人，必要时，应该由变更控制委员会（CCB）来开展实施整体变更控制过程。CCB 是一个正式组成的团体，负责审查、评价、批准、推迟或否决项目变更，以及记录和传达变更处理决定。

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

• 变更管理计划。见 4.2.3.1 节。变更管理计划为管理变更控制过程提供指导，并记录变更控制委员会（CCB）的角色和职责。
• 配置管理计划。见 4.2.3.1 节。配置管理计划描述项目的配置项、识别应记录和更新的配置项，以便保持项目产品的一致性和有效性。
• 范围基准。见 5.4.3.1 节。范围基准提供项目和产品定义。
• 进度基准。见 6.5.3.1 节。进度基准用于评估变更对项目进度的影响。
• 成本基准。见 7.3.3.1 节。成本基准用于评估变更对项目成本的影响。

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

• 估算依据。见 6.4.3.2 节。估算依据指出了持续时间、成本和资源估算是如何得出的，可用于计算变更对时间、预算和资源的影响。
• 需求跟踪矩阵。见 5.2.3.2 节。需求跟踪矩阵有助于评估变更对项目范围的影响。
• 风险报告。见 11.2.3.2 节。风险报告提供了与变更请求有关的整体和单个项目风险的来源的信息。

对于会影响项目基准的变更，通常应该在变更请求中说明执行变更的成本、所需的计划日期修改、资源需求以及相关的风险。这种变更应由 CCB（如有）和客户或发起人审批，除非他们本身就是 CCB 的成员。只有经批准的变更才能纳入修改后的基准。

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

• 关于项目所在的行业以及项目关注的领域的技术知识；
• 法律法规；
• 法规与采购；
• 配置管理；
• 风险管理。

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

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

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

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

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

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

由项目经理、CCB或指定的团队成员，根据变更管理计划处理变更请求（见 4.3.3.4 节），做出批准、推迟或否决的决定。批准的变更请求应通过指导与管理项目工作过程加以实施。对于推迟或否决的变更请求，应通知提出变更请求的个人或小组。

变更日志用于记录项目期间发生的变更。

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

见 4.1.3.1 节。项目章程记录了项目成功标准、审批要求，以及由谁来签署项目结束。

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

• 假设日志。见 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 节。验收的可交付成果可包括批准的产品规范、交货收据和工作绩效文件。对于分阶段实施的项目或提前取消的项目，还可能包括部分完成或中间的可交付成果。

商业论证用于确定项目是否达到了经济可行性研究的预期结果。效益管理计划用于测量项目是否达到了计划的效益。

在复杂项目中，可能需要同时或先后管理多个合同。

见 12.3.1.4 节。为关闭合同，需收集全部采购文档，并建立索引和加以归档。有关合同进度、范围、质量和成本绩效的信息，以及全部合同变更文档、支付记录和检查结果，都要归类收录。在项目结束时，应将“实际执行的”计划（图纸）或“初始编制的”文档、手册、故障排除文档和其他技术文档视为采购文件的组成部分。这些信息可用于总结经验教训，并为签署以后的合同而用作评价承包商的基础。

能够影响结束项目或阶段过程的组织过程资产包括（但不限于）：

• 项目或阶段收尾指南或要求（如经验教训、项目终期审计、项目评价、产品确认、验收标准、合同收尾、资源重新分配、团队绩效评估，以及知识传递）；
• 配置管理知识库，包括组织标准、政策、程序和项目文件的各种版本及基准。

可用于项目收尾的数据分析技术包括（但不限于）：

• 文件分析。见 5.2.2.3 节。评估现有文件有助于总结经验教训和分享知识，以改进未来项目和组织资产。
• 回归分析。该技术分析作用于项目结果的不同项目变量之间的相互关系，以提高未来项目的绩效。
• 趋势分析。见 4.5.2.2 节。趋势分析可用于确认组织所用模式的有效性，并且为了未来项目而进行相应的模式调整。
• 偏差分析。见 4.5.2.2 节。偏差分析可通过比较计划目标与最终结果来改进组织的测量指标。

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

可在本过程更新所有项目文件，并标记为最终版本。特别值得注意的是，经验教训登记册的最终版本要包含阶段或项目收尾的最终信息。最终版本的经验教训登记册可包含关于以下事项的信息：效益管理、商业论证的准确性、项目和开发生命周期、风险和问题管理、相关方参与，以及其他项目管理过程。

本输出所指的正是把项目交付的最终产品、服务或成果（对于阶段收尾，则是所在阶段的中间产品、服务或成果）从一个团队转交到另一个团队。

用最终报告总结项目绩效，其中可包含诸如以下信息：

• 项目或阶段的概述；
• 范围目标、范围的评估标准，以及证明达到完工标准的证据；
• 质量目标、项目和产品质量的评估标准、相关核实信息和实际里程碑交付日期以及偏差原因；
• 成本目标，包括可接受的成本区间、实际成本，以及产生任何偏差的原因；
• 最终产品、服务或成果的确认信息的总结。
• 进度计划目标包括成果是否实现项目所预期的效益。如果在项目结束时未能实现效益，则指出效益实现程度并预计未来实现情况。
• 关于最终产品、服务或成果如何满足商业计划所述业务需求的概述。如果在项目结束时未能满足业务需求，则指出需求满足程度并预计业务需求何时能够得到满足。
• 关于项目过程中发生的风险或问题及其解决情况的概述。

需要更新的组织过程资产包括（但不限于）：

• 项目文件。在项目活动中产生的各种文件，例如项目管理计划，范围文件、成本文件、进度文件和项目日历，以及变更管理文件。
• 运营和支持文件。组织维护、运营和支持项目交付的产品或服务时所需的文件。可包括新生成的文件，或对已有文件的更新。
• 项目或阶段收尾文件。项目或阶段收尾文件包括表明项目或阶段完工的正式文件，以及用来将完成的项目或阶段可交付成果移交给他人（如运营部门或下一阶段）的正式文件。在项目收尾期间，项目经理应该回顾以往的阶段文件，确认范围过程（见 5.5 节）所产生的客户验收文件，以及合同协议（如果有的话），以确保在达到全部项目要求之后才正式关闭项目。

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

• 经验教训知识库。将在整个项目期间获得的经验教训和知识归入经验教训知识库，供未来项目使用。

在敏捷或适应型环境中需要考虑的因素对于需求不断变化、风险大或不确定性高的项目，在项目开始时通常无法明确项目的范围，而需要在项目期间逐渐明确。敏捷方法特意在项目早期缩短定义和协商范围的时间，并为持续探索和明确范围而延长创建相应过程的时间。在许多情况下，不断涌现的需求往往导致真实的业务需求与最初所述的业务需求之间存在差异。因此，敏捷方法有目的地构建和审查原型，并通过多次发布版本来明确需求。这样一来，范围会在在整个项目期间被定义和再定义。在敏捷方法中，把需求列入未完项。

范围管理计划是项目或项目集管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。制定范围管理计划和细化项目范围始于对下列信息的分析：项目章程（见 4.1.3.1 节）中的信息、项目管理计划（见 4.2.3.1 节）中已批准的子计划、组织过程资产（见 2.3 节）中的历史信息和相关事业环境因素（见 2.2 节）。

见 4.1.3.1 节。项目章程记录项目目的、项目概述、假设条件、制约因素，以及项目意图实现的高层级需求。

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

• 质量管理计划。见 8.1.3.1 节。在项目中实施组织的质量政策、方法和标准的方式会影响管理项目和产品范围的方式。
• 项目生命周期描述。项目生命周期定义了项目从开始到完成所经历的一系列阶段。
• 开发方法。开发方法定义了项目是采用瀑布式、迭代型、适应型、敏捷型还是混合型开发方法。

见 4.1.2.1 节。应该就以下主题，考虑具备相关专业知识或接受过相关培训的个人或小组的意见：

• 以往类似项目；
• 特定行业、学科和应用领域的信息。

适用于本过程的数据分析技术包括（但不限于）备选方案分析。本技术用于评估收集需求、详述项目和产品范围、创造产品、确认范围和控制范围的各种方法。

项目团队可以参加项目会议来制定范围管理计划。参会者可能包括项目经理、项目发起人、选定的项目团队成员、选定的相关方、范围管理各过程的负责人，以及其他必要人员。

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

需求管理计划是项目管理计划的组成部分，描述将如何分析、记录和管理项目和产品需求。根据《从业者商业分析：实践指南》[7]，有些组织称之为“商业分析计划”。需求管理计划的主要内容包括（但不限于）：

实践指南》[7] 提供了有关产品需求的更深入信息。让相关方积极参与需求的探索和分解工作（分解成项目和产品需求），并仔细确定、记录和管理对产品、服务或成果的需求，能直接促进项目成功。需求是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。它包括发起人、客户和其他相关方的已量化且书面记录的需要和期望。应该足够详细地探明、分析和记录这些需求，将其包含在范围基准中，并在项目执行开始后对其进行测量。需求将成为工作分解结构（WBS）的基础，也将成为成本、进度、质量和采购规划的基础。

见 4.1.3.1 节。项目章程记录了项目概述以及将用于制定详细需求的高层级需求。

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

• 范围管理计划。见 5.1.3.1 节。范围管理计划包含如何定义和制定项目范围的信息。
• 需求管理计划。见 5.1.3.2 节。需求管理计划包含如何收集、分析和记录项目需求的信息。
• 相关方参与计划。见 13.2.3.1 节。从相关方参与计划中了解相关方的沟通需求和参与程度，以便评估并适应相关方对需求活动的参与程度。

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

• 假设日志。见 4.1.3.2 节。假设日志识别了有关产品、项目、环境、相关方以及会影响需求的其他因素的假设条件。
• 经验教训登记册。见 4.4.3.1 节。经验教训登记册提供了有效的需求收集技术，尤其针对使用迭代型或适应型产品开发方法的项目。
• 相关方登记册。见 13.1.3.1 节。相关方登记册用于了解哪些相关方能够提供需求方面的信息，及记录相关方对项目的需求和期望。

见 12.2.3.2 节。协议会包含项目和产品需求。

会影响收集需求过程的组织过程资产包括（但不限于）：

• 政策和程序；
• 包含以往项目信息的历史信息和经验教训知识库。

见 4.1.2.1 节。应该就以下主题，考虑具备相关专业知识或接受过相关培训的个人或小组的意见：

• 商业分析；
• 需求获取；
• 需求分析；
• 需求文件；
• 以往类似项目的项目需求；
• 图解技术；
• 引导；
• 冲突管理。

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

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

故事板是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。故事板用于各种行业的各种项目中，如电影、广告、教学设计，以及敏捷和其他软件开发项目。在软件开发中，故事板使用实体模型来展示网页、屏幕或其他用户界面的导航路径。

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

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

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

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

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

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

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

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

Programs Portfolios

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

见 4.1.3.1 节。项目章程中包含对项目的高层级描述、产品特征和审批要求。

见 4.2.3.1 节。项目管理计划组件包括（但不限于）范围管理计划（见 5.1.3.1 节），其中记录了如何定义、确认和控制项目范围。

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

• 假设日志。见 4.1.3.2 节。假设日志识别了有关产品、项目、环境、相关方以及会影响项目和产品范围的假设条件和制约因素。
• 需求文件。见 5.2.3.1 节。需求文件识别了应纳入范围的需求。
• 风险登记册。见 11.2.3.1 节。风险登记册包含了可能影响项目范围的应对策略，例如缩小或改变项目和产品范围，以规避或缓解风险。

能够影响定义范围过程的组织过程资产包括（但不限于）：

• 用于制定项目范围说明书的政策、程序和模板；
• 以往项目的项目档案；
• 以往阶段或项目的经验教训。

见 4.1.2.1 节。应征求具备类似项目的知识或经验的个人或小组的意见。

见 5.1.2.2 节。可用于本过程的决策技术包括（但不限于）多标准决策分析。如 8.1.2.4 节所述，多标准决策分析是一种借助决策矩阵来使用系统分析方法的技术，目的是建立诸如需求、进度、预算和资源等多种标准来完善项目和产品范围。

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

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

WBS 组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中所规定的工作。

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

• 项目范围说明书。见 5.3.3.1 节。项目范围说明书描述了需要实施的工作及不包含在项目中的工作。
• 需求文件。见 5.2.3.1 节。需求文件详细描述了各种单一需求如何满足项目的业务需要。

会影响创建 WBS 过程的事业环境因素包括（但不限于）项目所在行业的 WBS 标准，这些标准可以作为创建 WBS 的外部参考资料。

能够影响创建 WBS 过程的组织过程资产包括（但不限于）：

• 用于创建 WBS 的政策、程序和模板；
• 以往项目的项目档案；
• 以往项目的经验教训。

见 4.1.2.1 节。应征求具备类似项目知识或经验的个人或小组的意见。

关于 WBS 的详细信息，可参考《工作分解结构实践标准》（第 2 版）[15]。该标准列举了一些具体行业的 WBS 模板，可以在裁剪后应用于特定领域的具体项目。

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

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

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

见 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 节。需求跟踪矩阵含有与需求相关的信息，包括如何确认需求。

见 5.2.2.4 节。可用于本过程的决策技术包括（但不限于）投票。当由项目团队和其他相关方进行验收时，使用投票来形成结论。

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

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

控制项目范围确保所有变更请求、推荐的纠正措施或预防措施都通过实施整体变更控制过程（见 4.6 节）进行处理。在变更实际发生时，也要采用控制范围过程来管理这些变更。控制范围过程应该与其他控制过程协调开展。未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）被称为范围蔓延。变更不可避免，因此在每个项目上，都必须强制实施某种形式的变更控制。

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

• 范围管理计划。见 5.1.3.1 节。范围管理计划记录了如何控制项目和产品范围。
• 需求管理计划。见 5.1.3.2 节。成本管理计划记录了如何管理项目需求。
• 变更管理计划。见 4.2.3.1 节。变更管理计划定义了管理项目变更的过程。
• 配置管理计划。见 4.2.3.1 节。配置管理计划定义了哪些是配置项，哪些配置项需要正式变更控制，以及针对这些配置项的变更控制过程。
• 范围基准。见 5.4.3.1 节。用范围基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。
• 绩效测量基准。见 4.2.3.1 节。使用挣值分析时，将绩效测量基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。

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

• 经验教训登记册。见 4.4.3.1 节。在项目早期获得的经验教训可以运用到后期阶段，以改进范围控制。
• 需求文件。见 5.2.3.1 节。需求文件用于发现任何对商定的项目或产品范围的偏离。
• 需求跟踪矩阵。见 5.2.3.2 节。需求跟踪矩阵有助于探查任何变更或对范围基准的任何偏离对项目目标的影响，它还可以提供受控需求的状态。

确定偏离范围基准（见 5.4.3.1 节）的原因和程度，并决定是否需要采取纠正或预防措施，是项目范围控制的重要工作。

本过程产生的工作绩效信息是有关项目和产品范围实施情况（对照范围基准）的、相互关联且与各种背景相结合的信息，包括收到的变更的分类、识别的范围偏差和原因、偏差对进度和成本的影响，以及对将来范围绩效的预测。

见 4.3.3.4 节。分析项目绩效后，可能会就范围基准和进度基准，或项目管理计划的其他组成部分提出变更请求。变更请求需要经过实施整体变更控制过程（见 4.6 节）的审查和处理。

无论是采用预测型开发生命周期来管理项目，还是在适应型环境下管理项目，项目经理的角色都不变。但是，要成功实施适应型方法，项目经理需要了解如何高效使用相关的工具和技术。

本过程的主要作用是，为如何在整个项目期间管理项目进度提供指南和方向。本过程仅开展一次或仅在项目的预定义点开展。图 6-3 描述本过程的输入、工具与技术和输出。图 6-4 是本过程的数据流程图。

见 4.1.3.1 节。项目章程中规定的总体里程碑进度计划会影响项目的进度管理。

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

• 组织文化和结构；
• 团队资源可用性、技能以及物质资源可用性；
• 进度计划软件；
• 指南和标准，用于裁剪组织标准过程和程序以满足项目的特定要求；
• 商业数据库，如标准化的估算数据。

见 4.1.2.1 节。应征求具备专业知识或在以往类似项目中接受过相关培训的个人或小组的意见：

• 进度计划的编制、管理和控制；
• 进度计划方法（如预测型或适应型生命周期）；
• 进度计划软件；
• 项目所在的特定行业。

适用于本过程的数据分析技术包括（但不限于）备选方案分析。备选方案分析可包括确定采用哪些进度计划方法，以及如何将不同方法整合到项目中；此外，它还可以包括确定进度计划的详细程度、滚动式规划的持续时间，以及审查和更新频率。管理进度所需的计划详细程度与更新计划所需的时间量之间的平衡，应针对各个项目具体而言。

项目团队可能举行规划会议来制定进度管理计划。参会人员可能包括项目经理、项目发起人、选定的项目团队成员、选定的相关方、进度计划或执行负责人，以及其他必要人员。

进度管理计划是项目管理计划的组成部分，为编制、监督和控制项目进度建立准则和明确活动。

根据项目需要，进度管理计划可以是正式或非正式的，非常详细或高度概括的，其中应包括合适的控制临界值。

进度管理计划会规定：

• 项目进度模型制定。需要规定用于制定项目进度模型的进度规划方法论和工具。
• 进度计划的发布和迭代长度。使用适应型生命周期时，应指定固定时间的发布时段、阶段和迭代。固定时间段指项目团队稳定地朝着目标前进的持续时间，它可以推动团队先处理基本功能，然后在时间允许的情况下再处理其他功能，从而尽可能减少范围蔓延。
• 准确度。准确度定义了需要规定活动持续时间估算的可接受区间，以及允许的应急储备数量。
• 计量单位。需要规定每种资源的计量单位，例如，用于测量时间的人时数、人天数或周数，用于计量数量的米、升、吨、千米或立方码。
• 组织程序链接。工作分解结构（WBS，见 5.4 节）为进度管理计划提供了框架，保证了与估算及相应进度计划的协调性。
• 项目进度模型维护。需要规定在项目执行期间，将如何在进度模型中更新项目状态，记录项目进展。
• 控制临界值。可能需要规定偏差临界值，用于监督进度绩效。它是在需要采取某种措施前，允许出现的最大差异。临界值通常用偏离基准计划中的参数的某个百分数来表示。
• 绩效测量规则。需要规定用于绩效测量的挣值管理（EVM）规则或其他测量规则。例如，进度管理计划可能规定：
• 确定完成百分比的规则；
• EVM 技术，如基准法、固定公式法、完成百分比法等。更多信息，参阅《挣值管理实践标准》[17]；
• 进度绩效测量指标，如进度偏差（SV）和进度绩效指数（SPI），用来评价偏离原始进度基准的程度。
• 报告格式。需要规定各种进度报告的格式和编制频率。

本过程需要在整个项目期间开展。图 6-5 描述本过程的输入、工具与技术和输出，图 6-6 是本过程的数据流程图。

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

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

影响定义活动过程的事业环境因素包括（但不限于）：

• 组织文化和结构；
• 商业数据库中发布的商业信息；
• 项目管理信息系统 (PMIS)。

能够影响定义活动过程的组织过程资产包括（但不限于）：

• 经验教训知识库，其中包含以往类似项目的活动清单等历史信息；
• 标准化的流程；
• 以往项目中包含标准活动清单或部分活动清单的模板；
• 现有与活动规划相关的正式和非正式的政策、程序和指南，如进度规划方法论，在编制活动定义时应考虑这些因素。

见 4.1.2.1 节。应征求了解以往类似项目和当前项目的个人或小组的专业意见。

见 5.4.2.2 节。分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术。活动表示完成工作包所需的投入。定义活动过程的最终输出是活动而不是可交付成果，可交付成果是创建 WBS 过程（见 5.4 节）的输出。

活动清单包含项目所需的进度活动。对于使用滚动式规划或敏捷技术的项目，活动清单会在项目进展过程中得到定期更新。活动清单包括每个活动的标识及工作范围详述，使项目团队成员知道需要完成什么工作。

活动属性是指每项活动所具有的多重属性，用来扩充对活动的描述，活动属性随时间演进。在项目初始阶段，活动属性包括唯一活动标识 (ID)、WBS 标识和活动标签或名称；在活动属性编制完成时，活动属性可能包括活动描述、紧前活动、紧后活动、逻辑关系、提前量和滞后量（见 6.3.2.3 节）、资源需求、强制日期、制约因素和假设条件。活动属性可用于识别开展工作的地点、编制开展活动的项目日历，以及相关的活动类型。活动属性还可用于编制进度计划。根据活动属性，可在报告中以各种方式对计划进度活动进行选择、排序和分类。

里程碑是项目中的重要时点或事件，里程碑清单列出了所有项目里程碑，并指明每个里程碑是强制性的（如合同要求的）还是选择性的（如根据历史信息确定的）。里程碑的持续时间为零，因为它们代表的是一个重要时间点或事件。

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

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

• 进度基准。见 6.5.3.1 节。在整个项目期间，工作包逐渐细化为活动。在这个过程中可能会发现原本不属于项目基准的工作，从而需要修改作为进度基准一部分的交付日期或其他重要的进度里程碑。
• 成本基准。见 7.3.3.1 节。在针对进度活动的变更获得批准后，需要对成本基准做出相应的变更。

除了首尾两项，每项活动都至少有一项紧前活动和一项紧后活动，并且逻辑关系适当。通过设计逻辑关系来创建一个切实的项目进度计划，可能有必要在活动之间使用提前量或滞后量，使项目进度计划更为切实可行；可以使用项目管理软件、手动技术或自动技术，来排列活动顺序。排列活动顺序过程旨在将项目活动列表转化为图表，作为发布进度基准的第一步。

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

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

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

• 活动属性。见 6.2.3.2 节。活动属性中可能描述了事件之间的必然顺序或确定的紧前或紧后关系，以及定义的提前量与滞后量，和活动之间的逻辑关系。
• 活动清单。见 6.2.3.1 节。活动清单列出了项目所需的、待排序的全部进度活动，这些活动的依赖关系和其他制约因素会对活动排序产生影响。
• 假设日志。见 4.1.3.2 节。假设日志所记录的假设条件和制约因素可能影响活动排序的方式、活动之间的关系，以及对提前量和滞后量的需求，并且有可能生成一个会影响项目进度的风险。
• 里程碑清单。见 6.2.3.3 节。里程碑清单中可能已经列出特定里程碑的实现日期，这可能影响活动排序的方式。

能够影响排列活动顺序过程的事业环境因素包括（但不限于）：

• 政府或行业标准；
• 项目管理信息系统（PMIS）；
• 进度规划工具；
• 组织的工作授权系统。

能够影响排列活动顺序过程的组织过程资产包括（但不限于）：

• 项目组合与项目集规划，以及项目之间的依赖关系与关联；
• 现有与活动规划相关的正式和非正式的政策、程序和指南，如进度计划方法论，在确定逻辑关系时应考虑这些因素；
• 有助于加快项目活动网络图编制的各种模板；模板中也会包括有助于排列活动顺序的，与活动属性有关的信息；
• 经验教训知识库，其中包含有助于优化排序过程的历史信息。

例如，只有机器组装完毕，团队才能对其测试，这是一个内部的强制性依赖关系。在排列活动顺序过程中，项目管理团队应明确哪些依赖关系属于内部依赖关系。

项目管理团队应该明确哪些依赖关系中需要加入提前量或滞后量，以便准确地表示活动之间的逻辑关系。提前量和滞后量的使用不能替代进度逻辑关系，而且持续时间估算中不包括任何提前量或滞后量，同时还应该记录各种活动及与之相关的假设条件。

见 4.3.2.2 节。项目管理信息系统包括进度计划软件；这些软件有助于规划、组织和调整活动顺序，插入逻辑关系、提前和滞后值，以及区分不同类型的依赖关系。

项目进度网络图是表示项目进度活动之间的逻辑关系（也叫依赖关系）的图形。图 6-11 是项目进度网络图的一个示例。项目进度网络图可手工或借助项目管理软件来绘制，可包括项目的全部细节，也可只列出一项或多项概括性活动。项目进度网络图应附有简要文字描述，说明活动排序所使用的基本方法。在文字描述中，还应该对任何异常的活动序列做详细说明。

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

• 活动属性。见 6.2.3.2 节。活动属性中可能描述了事件之间的必然顺序或确定的紧前或紧后关系，以及定义的提前量与滞后量，和活动之间的逻辑关系。
• 活动清单。见 6.2.3.1 节。在排列活动顺序时，活动清单可能会受到项目活动关系变更的影响。
• 假设日志。见 4.1.3.2 节。根据活动的排序、关系确定以及提前量和滞后量，可能需要更新假设日志中的假设条件和制约因素，并且有可能生成一个会影响项目进度的风险。
• 里程碑清单。见 6.2.3.3 节。在排列活动顺序时，特定里程碑的计划实现日期可能会受到项目活动关系变更的影响。

估算活动持续时间是根据资源估算的结果，估算完成单项活动所需工作时段数的过程。本过程的主要作用是，确定完成每个活动所需花费的时间量。本过程需要在整个项目期间开展。图 6-12 描述本过程的输入、工具与技术和输出。图 6-13 是本过程的数据流程图。

图 6-12估算活动持续时间：输入、工具与技术和输出

图 6-13估算活动持续时间：数据流程图

估算活动持续时间依据的信息包括：工作范围、所需资源类型与技能水平、估算的资源数量和资源日历，而可能影响持续时间估算的其他因素包括对持续时间受到的约束、相关人力投入、资源类型（如固定持续时间、固定人力投入或工作、固定资源数量）以及所采用的进度网络分析技术。

应该由项目团队中最熟悉具体活动的个人或小组提供持续时间估算所需的各种输入，对持续时间的估算也应该渐进明细，取决于输入数据的数量和质量。例如，在工程与设计项目中，随着数据越来越详细，越来越准确，持续时间估算的准确性和质量也会越来越高。

在本过程中，应该首先估算出完成活动所需的工作量和计划投入该活动的资源数量，然后结合项目日历和资源日历，据此估算出完成活动所需的工作时段数（活动持续时间）。在许多情况下，预计可用的资源数量以及这些资源的技能熟练程度可能会决定活动的持续时间，更改分配到活动的主导性资源通常会影响持续时间，但这不是简单的“直线”或线性关系。有时候，因为工作的特性（即受到持续时间的约束、相关人力投入或资源数量），无论资源分配如何（如 24 小时应力测试），都需要花预定的时间才能完成工作。估算持续时间时需要考虑的其他因素包括：

• 收益递减规律。在保持其他因素不变的情况下，增加一个用于确定单位产出所需投入的因素（如资源）会最终达到一个临界点，在该点之后的产出或输出会随着增加这个因素而递减。
• 资源数量。增加资源数量，使其达到初始数量的两倍不一定能缩短一半的时间，因为这样做可能会因风险而造成持续时间增加；在某些情况下，如果增加太多活动资源，可能会因知识传递、学习曲线、额外合作等其他相关因素而造成持续时间增加。
• 技术进步。在确定持续时间估算时，这个因素也可能发挥重要作用。例如，通过采购最新技术，制造工厂可以提高产量，而这可能会影响持续时间和资源需求。
• 员工激励。项目经理还需要了解“学生综合征”（即拖延症）和帕金森定律，前者指出，人们只有在最后一刻，即快到期限时才会全力以赴；后者指出，只要还有时间，工作就会不断扩展，直到用完所有的时间。

应该把活动持续时间估算所依据的全部数据与假设都记录在案。

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

• 活动属性。见 6.2.3.2 节。活动属性可能描述了确定的紧前或紧后关系、定义的提前量与滞后量以及可能影响持续时间估算的活动之间的逻辑关系。
• 活动清单。见 6.2.3.1 节。活动清单列出了项目所需的、待估算的全部进度活动，这些活动的依赖关系和其他制约因素会对持续时间估算产生影响。
• 假设日志。见 4.1.3.2 节。假设日志所记录的假设条件和制约因素有可能生成一个会影响项目进度的风险。
• 经验教训登记册。见 4.4.3.1 节。与人力投入和持续时间估算有关的经验教训登记册可以运用到项目后续阶段，以提高人力投入和持续时间估算的准确性。
• 里程碑清单。见 6.2.3.3 节。里程碑清单中可能已经列出特定里程碑的计划实现日期，这可能影响持续时间估算。
• 项目团队派工单。见 9.3.3.1 节。将合适的人员分派到团队，为项目配备人员。
• 资源分解结构。见 9.2.3.3 节。资源分解结构按照资源类别和资源类型，提供了已识别资源的层级结构。
• 资源日历。见 9.2.1.2 节。资源日历中的资源可用性、资源类型和资源性质，都会影响进度活动的持续时间。资源日历规定了在项目期间特定的项目资源何时可用及可用多久。
• 资源需求。见 9.2.3.1 节。估算的活动资源需求会对活动持续时间产生影响。对于大多数活动来说，所分配的资源能否达到要求，将对其持续时间有显著影响。例如，向某个活动新增资源或分配低技能资源，就需要增加沟通、培训和协调工作，从而可能导致活动效率或生产率下降，由此需要估算更长的持续时间。
• 风险登记册。见 11.2.3.1 节。单个项目风险可能影响资源的选择和可用性。风险登记册的更新包括在项目文件更新中，见“规划风险应对” (11.5.3.2) 一节。

相对于其他估算技术，类比估算通常成本较低、耗时较少，但准确性也较低。类比估算可以针对整个项目或项目中的某个部分进行，或可以与其他估算方法联合使用。如果以往活动是本质上而不是表面上类似，并且从事估算的项目团队成员具备必要的专业知识，那么类比估算就最为可靠。

参数估算的准确性取决于参数模型的成熟度和基础数据的可靠性。且参数进度估算可以针对整个项目或项目中的某个部分，并可以与其他估算方法联合使用。

自下而上估算是一种估算项目持续时间或成本的方法，通过从下到上逐层汇总 WBS 组成部分的估算而得到项目估算。如果无法以合理的可信度对活动持续时间进行估算，则应将活动中的工作进一步细化，然后估算具体的持续时间，接着再汇总这些资源需求估算，得到每个活动的持续时间。活动之间可能存在或不存在会影响资源利用的依赖关系；如果存在，就应该对相应的资源使用方式加以说明，并记录在活动资源需求中。

也可以估算项目进度管理所需要的管理储备量。管理储备是为管理控制的目的而特别留出的项目预算，用来应对项目范围中不可预见的工作。管理储备用来应对会影响项目的“未知-未知”风险，它不包括在进度基准中，但属于项目总持续时间的一部分。依据合同条款，使用管理储备可能需要变更进度基准。

见 5.2.2.4 节。适用于本过程的决策技术包括（但不限于）投票。举手表决是从投票方法衍生出来的一种形式，经常用于敏捷项目中。采用这种技术时，项目经理会让团队成员针对某个决定示意支持程度，举拳头表示不支持，伸五个手指表示完全支持，伸出三个以下手指的团队成员有机会与团队讨论其反对意见。项目经理会不断进行举手表决，直到整个团队达成共识（所有人都伸出三个以上手指）或同意进入下一个决定。

项目团队可能会召开会议来估算活动持续时间。如果采用敏捷方法，则有必要举行冲刺或迭代计划会议，以讨论按优先级排序的产品未完项（用户故事），并决定团队在下一个迭代中会致力于解决哪个未完项。然后团队将用户故事分解为按小时估算的底层级任务，然后根据团队在持续时间（迭代）方面的能力确认估算可行。该会议通常在迭代的第一天举行，参会者包括产品负责人、开发团队和项目经理，会议结果包括迭代未完项、假设条件、关注事项、风险、依赖关系、决定和行动。

持续时间估算所需的支持信息的数量和种类，因应用领域而异。不论其详细程度如何，支持性文件都应该清晰、完整地说明持续时间估算是如何得出的。

持续时间估算的支持信息可包括：

• 关于估算依据的文件（如估算是如何编制的）；
• 关于全部假设条件的文件；
• 关于各种已知制约因素的文件；
• 对估算区间的说明（如“±10%”），以指出预期持续时间的所在区间；
• 对最终估算的置信水平的说明；
• 有关影响估算的单个项目风险的文件。

制定可行的项目进度计划是一个反复进行的过程。基于获取的最佳信息，使用进度模型来确定各项目活动和里程碑的计划开始日期和计划完成日期。编制进度计划时，需要审查和修正持续时间估算、资源估算和进度储备，以制定项目进度计划，并在经批准后作为基准用于跟踪项目进度。关键步骤包括定义项目里程碑、识别活动并排列活动顺序，以及估算持续时间。一旦活动的开始和完成日期得到确定，通常就需要由分配至各个活动的项目人员审查其被分配的活动。之后，项目人员确认开始和完成日期与资源日历没有冲突，也与其他项目或任务没有冲突，从而确认计划日期的有效性。最后分析进度计划，确定是否存在逻辑关系冲突，以及在批准进度计划并将其作为基准之前是否需要资源平衡。同时，需要修订和维护项目进度模型，确保进度计划在整个项目期间一直切实可行，见 6.7 节。

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

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

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

• 活动属性。见 6.2.3.2 节。活动属性提供了创建进度模型所需的细节信息。
• 活动清单。见 6.2.3.1 节。活动清单明确了需要在进度模型中包含的活动。
• 假设日志。见 4.1.3.2 节。假设日志所记录的假设条件和制约因素可能造成影响项目进度的单个项目风险。
• 估算依据。见 6.4.3.2 节。持续时间估算所需的支持信息的数量和种类，因应用领域而异。不论其详细程度如何，支持性文件都应该清晰、完整地说明持续时间估算是如何得出的。
• 持续时间估算。见 6.4.3.1 节。持续时间估算包括对完成某项活动所需的工作时段数的定量评估，用于进度计划的推算。
• 经验教训。见 4.4.3.1 节。与创建进度模型有关的经验教训登记册可以运用到项目后期阶段，以提高进度模型的有效性。
• 里程碑清单。见 6.2.3.3 节。里程碑清单列出特定里程碑的实现日期。
• 项目进度网络图。见 6.3.3.1 节。项目进度网络图中包含用于推算进度计划的紧前和紧后活动的逻辑关系。
• 项目团队派工单。见 9.3.3.1 节。项目团队派工单明确了分配到每个活动的资源。
• 资源日历。见 9.2.1.2 节。资源日历规定了在项目期间的资源可用性。
• 资源需求。见 9.2.3.1 节。活动资源需求明确了每个活动所需的资源类型和数量，用于创建进度模型。
• 风险登记册。见 11.2.3.1 节。风险登记册中的所有已识别的会影响进度模型的风险的详细信息及特征。进度储备则通过预期或平均风险影响程度，反映了与进度有关的风险信息。

见 12.2.3.2 节。在制定如何执行项目工作以履行合同承诺的详细信息时，供应商为项目进度提供了输入。

进度网络分析是创建项目进度模型的一种综合技术，它采用了其他几种技术，例如关键路径法（见6.5.2.2 节）、资源优化技术（见 6.5.2.3 节）和建模技术（见 6.5.2.4 节）。其他分析包括（但不限于）：

在任一网络路径上，进度活动可以从最早开始日期推迟或拖延的时间，而不至于延误项目完成日期或违反进度制约因素，就是总浮动时间或进度灵活性。正常情况下，关键路径的总浮动时间为零。在进行紧前关系绘图法排序的过程中，取决于所用的制约因素，关键路径的总浮动时间可能是正值、零或负值。总浮动时间为正值，是由于逆推计算所使用的进度制约因素要晚于顺推计算所得出的最早完成日期；总浮动时间为负值，是由于持续时间和逻辑关系违反了对最晚日期的制约因素。负值浮动时间分析是一种有助于找到推动延迟的进度回到正轨的方法的技术。进度网络图可能有多条次关键路径。许多软件允许用户自行定义用于确定关键路径的参数。为了使网络路径的总浮动时间为零或正值，可能需要调整活动持续时间（可增加资源或缩减范围时）、逻辑关系（针对选择性依赖关系时）、提前量和滞后量，或其他进度制约因素。一旦计算出总浮动时间和自由浮动时间，自由浮动时间就是指在不延误任何紧后活动最早开始日期或不违反进度制约因素的前提下，某进度活动可以推迟的时间量。例如，图 6-16 中，活动 B 的自由浮动时间是 5 天。

资源优化用于调整活动的开始和完成日期，以调整计划使用的资源，使其等于或少于可用的资源。资源优化技术是根据资源供需情况，来调整进度模型的技术，包括（但不限于）：

• 资源平衡。为了在资源需求与资源供给之间取得平衡，根据资源制约因素对开始日期和完成日期进行调整的一种技术。如果共享资源或关键资源只在特定时间可用，数量有限，或被过度分配，如一个资源在同一时段内被分配至两个或多个活动（见图 6-17），就需要进行资源平衡。

也可以为保持资源使用量处于均衡水平而进行资源平衡。资源平衡往往导致关键路径改变。

而可以用浮动时间平衡资源。因此，在项目进度计划期间，关键路径可能发生变化。

• 资源平滑。对进度模型中的活动进行调整，从而使项目资源需求不超过预定的资源限制的一种技术。相对于资源平衡而言，资源平滑不会改变项目关键路径，完工日期也不会延迟。也就是说，活动只在其自由和总浮动时间内延迟，但资源平滑技术可能无法实现所有资源的优化。

图 6-17资源平衡

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

• 假设情景分析。假设情景分析是对各种情景进行评估，预测它们对项目目标的影响（积极或消极的）。假设情景分析就是对“如果情景 X 出现，情况会怎样？”这样的问题进行分析，即基于已有的进度计划，考虑各种各样的情景。例如，推迟某主要部件的交货日期，延长某设计工作的时间，或加入外部因素（如罢工或许可证申请流程变化等）。可以根据假设情景分析的结果，评估项目进度计划在不同条件下的可行性，以及为应对意外情况的影响而编制进度储备和应对计划。
• 模拟。模拟是把单个项目风险和不确定性的其他来源模型化的方法，以评估它们对项目目标的潜在影响。最常见的模拟技术是蒙特卡罗分析（见 11.4.2.5 节），它利用风险和其他不确定资源计算整个项目可能的进度结果。模拟包括基于多种不同的活动假设、制约因素、风险、问题或情景，使用概率分布和不确定性的其他表现形式（见 11.4.2.4 节），来计算出多种可能的工作包持续时间。图 6-18 显示了一个项目的概率分布，表明实现特定目标日期（即项目完成日期）的可能性。在这个例子中，项目按时或在目标日期，即 5 月 13 日之前完成的概率是 10%，而在 5 月 28 日之前完成的概率是 90%。

图 6-18目标里程碑的概率分布示例

有关蒙特卡洛模拟如何用于进度模型的更多信息，请参见《进度计划实践标准》。

进度压缩技术是指在不缩减项目范围的前提下，缩短或加快进度工期，以满足进度制约因素、强制日期或其他进度目标。负值浮动时间分析是一种有用的技术。关键路径是浮动时间最少的方法。在违反制约因素或强制日期时，总浮动时间可能变成负值。图 6-19 比较了多个进度压缩技术，包括：

• 赶工。通过增加资源，以最小的成本代价来压缩进度工期的一种技术。赶工的例子包括：批准加班、增加额外资源或支付加急费用，来加快关键路径上的活动。赶工只适用于那些通过增加资源就能缩短持续时间的，且位于关键路径上的活动。但赶工并非总是切实可行的，因它可能导致风险和/或成本的增加。
• 快速跟进。一种进度压缩技术，将正常情况下按顺序进行的活动或阶段改为至少是部分并行开展。例如，在大楼的建筑图纸尚未全部完成前就开始建地基。快速跟进可能造成返工和风险增加，所以它只适用于能够通过并行活动来缩短关键路径上的项目工期的情况。以防进度加快而使用提前量通常增加相关活动之间的协调工作，并增加质量风险。快速跟进还有可能增加项目成本。

图 6-19进度压缩技术的比较

见 4.3.2.2 节。项目管理信息系统包括进度计划软件，这些软件用活动、网络图、资源需求和活动持续时间等作为输入，自动生成开始和完成日期，从而可加快进度计划的编制过程。

敏捷发布规划基于项目路线图和产品发展愿景，提供了高度概括的发布进度时间轴（通常是 3 到 6个月）。同时，敏捷发布规划还确定了发布的迭代或冲刺次数，使产品负责人和团队能够决定需要开发的内容，并基于业务目标、依赖关系和障碍因素确定达到产品放行所需的时间。

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

项目进度模型中的进度数据是用以描述和控制进度计划的信息集合。进度数据至少包括进度里程碑、进度活动、活动属性，以及已知的全部假设条件与制约因素，而所需的其他数据因应用领域而异。经常可用作支持细节的信息包括（但不限于）：

见 4.3.3.4 节。修改项目范围或项目进度计划之后，可能会对范围基准和/或项目管理计划的其他组成部分提出变更请求，应该通过实施整体变更控制过程（见 4.6 节）对变更请求进行审查和处理。

控制进度是监督项目状态，以更新项目进度和管理进度基准变更的过程。本过程的主要作用是在整个项目期间保持对进度基准的维护，且需要在整个项目期间开展。图 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.4.3.1 节。在项目早期获得的经验教训可以运用到后期阶段，以改进进度控制。
• 项目日历。见 6.5.3.4 节。在一个进度模型中，可能需要不止一个项目日历来预测项目进度，因为有些活动需要不同的工作时段。
• 项目进度计划。见 6.5.3.2 节。项目进度计划是最新版本的项目进度计划，其中图示了截至指定日期的更新情况、已完活动和已开始活动。
• 资源日历。见 9.2.1.2 节。资源日历显示了团队和物质资源的可用性。
• 进度数据。见 6.5.3.3 节。在控制进度过程中需要对进度数据进行审查和更新。

见 4.3.3.2 节。工作绩效数据包含关于项目状态的数据，例如哪些活动已经开始，它们的进展如何（如实际持续时间、剩余持续时间和实际完成百分比），哪些活动已经完成。

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

• 挣值分析。见 7.4.2.2 节。进度绩效测量指标（如进度偏差（SV）和进度绩效指数（SPI））用于评价偏离初始进度基准的程度。
• 迭代燃尽图。这类图用于追踪迭代未完项中尚待完成的工作。它基于迭代规划（见 6.4.2.8 节）中确定的工作，分析与理想燃尽图的偏差。可使用预测趋势线来预测迭代结束时可能出现的偏差，以及在迭代期间应该采取的合理行动。在燃尽图中，先用对角线表示理想的燃尽情况，再每天画出实际剩余工作，最后基于剩余工作计算出趋势线以预测完成情况。图 6-24 是迭代燃尽图的一个例子。

图 6-24迭代燃尽图

• 绩效审查。绩效审查是指根据进度基准，测量、对比和分析进度绩效，如实际开始和完成日期、已完成百分比，以及当前工作的剩余持续时间。
• 趋势分析。见 4.5.2.2 节。趋势分析检查项目绩效随时间的变化情况，以确定绩效是在改善还是在恶化。图形分析技术有助于理解截至目前的绩效，并与未来的绩效目标（表示为完工日期）进行对比。
• 偏差分析。偏差分析关注实际开始和完成日期与计划的偏离，实际持续时间与计划的差异，以及浮动时间的偏差。它包括确定偏离进度基准（见 6.5.3.1 节）的原因与程度，评估这些偏差对未来工作的影响，以及确定是否需要采取纠正或预防措施。例如，非关键路径上的某个活动发生较长时间的延误，可能不会对整体项目进度产生影响；而某个关键或次关键活动的稍许延误，却可能需要立即采取行动。
• 假设情景分析。见 6.5.2.4 节。假设情景分析基于项目风险管理过程的输出，对各种不同的情景进行评估，促使进度模型符合项目管理计划和批准的基准。

见 6.5.2.2 节。检查关键路径的进展情况有助于确定项目进度状态。关键路径上的偏差将对项目的结束日期产生直接影响。评估次关键路径上的活动的进展情况，有助于识别进度风险。

见 4.3.2.2 节。项目管理信息系统包括进度计划软件。用这种软件对照计划日期跟踪实际日期，对照进度基准报告偏差和进展，以及预测项目进度模型变更的影响。

见 6.5.2.3 节。资源优化技术是在同时考虑资源可用性和项目时间的情况下，对活动和活动所需资源进行的进度规划。

在网络分析中调整提前量与滞后量，设法使进度滞后的项目活动赶上计划。例如，在新办公大楼建设项目中，通过增加活动之间的提前量，把绿化施工调整到大楼外墙装饰完工之前开始；或者，在大型技术文件编写项目中，通过消除或减少滞后量，把草稿编辑工作调整到草稿编写完成之后立即开始。

采用进度压缩技术（见 6.5.2.6 节）使进度落后的项目活动赶上计划，可以对剩余工作使用快速跟进或赶工方法。

见 4.5.1.3 节。工作绩效信息包括与进度基准相比较的项目工作执行情况。可以在工作包层级和控制账户层级，计算开始和完成日期的偏差以及持续时间的偏差。对于使用挣值分析的项目，进步偏差 (SV) 和进度绩效指数 (SPI) 将记录在工作绩效报告中（见 4.5.3.1 节）。

随着项目执行，应该基于工作绩效信息，更新和重新发布预测。这些信息基于项目的过去绩效，并取决于纠正或预防措施所期望的未来绩效，可能包括挣值绩效指数，以及可能在未来对项目造成影响的进度储备信息。

见 4.3.3.4 节。通过分析进度偏差，审查进展报告、绩效测量结果和项目范围或进度调整情况，可能会对进度基准、范围基准和/或项目管理计划的其他组成部分提出变更请求。应该通过实施整体变更控制过程（见 4.6 节）对变更请求进行审查和处理。预防措施可包括推荐的变更，以消除或降低不利进度偏差的发生概率。

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

• 进度管理计划。见 6.1.3.1 节。可能需要更新进度管理计划，以反映进度管理方法的变更。
• 进度基准。见 6.5.3.1 节。在项目范围、活动资源或活动持续时间估算等方面的变更获得批准后，可能需要对进度基准做相应变更。另外，因进度压缩技术或绩效问题造成变更时，也可能需要更新进度基准。
• 成本基准。见 7.3.3.1 节。在针对范围、资源或成本估算的变更获得批准后，需要对成本基准做出相应的变更。
• 绩效测量基准。见 4.2.3.1 节。在范围、进度绩效或成本估算的变更获得批准后，需要对绩效测量基准做出相应的变更。有时绩效偏差太过严重，需要提出变更请求来修订绩效测量基准，以便为绩效测量提供现实可行的依据。

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

• 假设日志。见 4.1.3.2 节。进度绩效可能表明需要修改关于活动排序、持续时间和生产效率的假设条件。
• 估算依据。见 6.4.3.2 节。进度绩效可能表明需要修改持续时间的估算方式。
• 经验教训登记册。见 4.4.3.1 节。更新经验教训登记册，以记录维护进度的有效技术，以及造成偏差的原因和用于应对进度偏差的纠正措施。
• 项目进度计划。把更新后的进度数据代入进度模型，生成更新后的项目进度计划（见 6.5.3.2节），以反映进度变更并有效管理项目。
• 资源日历。见 9.2.1.2 节。更新资源日历，以反映因资源优化、进度压缩，以及纠正或预防措施而导致的资源日历变更。
• 风险登记册。见 11.2.3.1 节。采用进度压缩技术可能导致风险，也就可能需要更新风险登记册及其中的风险应对计划。
• 进度数据。见 6.5.3.3 节。可能需要重新绘制项目进度网络图，以反映经批准的剩余持续时间和经批准的进度计划修改。有时，项目进度延误非常严重，以至于必须重新预测开始与完成日期，编制新的目标进度计划，才能为指导工作、测量绩效和度量进展提供现实的数据。

如果易变的项目也遵循严格的预算，通常需要更频繁地更改范围和进度计划，以始终保持在成本制约因素之内。

应该在项目规划阶段的早期就对成本管理工作进行规划，建立各成本管理过程的基本框架，以确保各过程的有效性及各过程之间的协调性。成本管理计划是项目管理计划的组成部分，其过程及工具与技术应记录在成本管理计划中。

见 4.1.3.1 节。项目章程规定了预先批准的财务资源，可据此确定详细的项目成本。项目章程所规定的项目审批要求，也对项目成本管理有影响。

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

• 进度管理计划。见 6.1.3.1 节。进度管理计划确定了编制、监督和控制项目进度的准则和活动，同时也提供了影响成本估算和管理的过程及控制方法。
• 风险管理计划。见 11.1.3.1 节。风险管理计划提供了识别、分析和监督风险的方法，同时也提供了影响成本估算和管理的过程及控制方法。

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

• 能够影响成本管理的组织文化和组织结构；
• 市场条件，决定着在当地及全球市场上可获取哪些产品、服务和成果；
• 货币汇率，用于换算发生在多个国家的项目成本；
• 发布的商业信息，经常可以从商业数据库中获取资源成本费率及相关信息，而这些数据库动态跟踪具有相应技能的人力资源的成本数据，也提供材料与设备的标准成本数据；还可以从卖方公布的价格清单中获取相关信息；
• 项目管理信息系统，可为管理成本提供多种方案；
• 不同地区的生产率差异，可能会对项目成本造成巨大影响。

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

• 以往类似项目；
• 来自行业、学科和应用领域的信息；
• 成本估算和预算；
• 挣值管理。

适用于本过程的数据分析技术包括（但不限于）备选方案分析。备选方案分析可包括审查筹资的战略方法，如自筹资金、股权投资、借贷投资等，还可以包括对筹集项目资源的方法（如自制、采购、租用或租赁）的考量。

项目团队可能举行规划会议来制定成本管理计划。参会者可能包括项目经理、项目发起人、选定的项目团队成员、选定的相关方、项目成本负责人，以及其他必要人员。

成本管理计划是项目管理计划的组成部分，描述将如何规划、安排和控制项目成本。成本管理过程及其工具与技术应记录在成本管理计划中。

例如，在成本管理计划中规定：

• 计量单位。需要规定每种资源的计量单位，例如用于测量时间的人时数、人天数或周数，用于计量数量的米、升、吨、千米或立方码，或者用货币表示的总价。
• 精确度。根据活动范围和项目规模，设定成本估算向上或向下取整的程度（例如 995.59 美元取整为 1,000 美元）。
• 准确度。为活动成本估算规定一个可接受的区间（如 ±10%），其中可能包括一定数量的应急储备。
• 组织程序链接。工作分解结构（见 5.4 节）为成本管理计划提供了框架，以便据此规范地开展成本估算、预算和控制。在项目成本核算中使用的 WBS 组成部分，称为控制账户（CA），每个控制账户都有唯一的编码或账号，直接与执行组织的会计制度相联系。
• 控制临界值。可能需要规定偏差临界值，用于监督成本绩效。它是在需要采取某种措施前，允许出现的最大差异，通常用偏离基准计划的百分数来表示。
• 绩效测量规则。需要规定用于绩效测量的挣值管理（EVM）规则。例如，成本管理计划应该：
• 定义 WBS 中用于绩效测量的控制账户；
• 确定拟用的 EVM 技术（如加权里程碑法、固定公式法、完成百分比法等）；
• 规定跟踪方法，以及用于计算项目完工估算（EAC）的 EVM 公式，该公式计算出的结果可用于验证通过自下而上方法得出的完工估算。
• 报告格式。需要规定各种成本报告的格式和编制频率。
• 其他细节。关于成本管理活动的其他细节包括（但不限于）：
• 对战略筹资方案的说明；
• 处理汇率波动的程序；
• 记录项目成本的程序。

关于挣值管理的更多信息，参见《挣值管理实践标准》（第 2 版）[17]。

进行成本估算，应该考虑将向项目收费的全部资源，包括（但不限于）人工、材料、设备、服务、设施，以及一些特殊的成本种类，如通货膨胀补贴、融资成本或应急成本。成本估算可在活动层级呈现，也可以汇总形式呈现。

见 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.4.3.1 节。项目早期与制定成本估算有关的经验教训可以运用到项目后期阶段，以提高成本估算的准确度和精确度。
• 项目进度计划。见 6.5.3.2 节。进度计划包括项目可用的团队和实物资源的类型、数量和可用时间长短。如果资源成本取决于使用时间的长短，并且成本出现季节波动，则持续时间估算（见 6.4.3.1 节）会对成本估算产生影响。进度计划还为包含融资成本（包括利息）的项目提供有用信息。
• 资源需求。见 9.2.3.1 节。资源需求明确了每个工作包或活动所需的资源类型和数量。
• 风险登记册。见 11.2.3.1 节。风险登记册包含了已识别并按优先顺序排列的单个项目风险的详细信息，及针对这些风险采取的应对措施。风险登记册还提供了可用于估算成本的详细信息。

会影响估算成本过程的事业环境因素包括（但不限于）：

• 市场条件。可以从市场上获得什么产品、服务和成果，可以从谁那里、以什么条件获得。地区和/或全球性的供求情况会显著影响资源成本。
• 发布的商业信息。经常可以从商业数据库中获取资源成本费率及相关信息，而这些数据库动态跟踪具有相应技能的人力资源的成本数据，也提供材料与设备的标准成本数据；还可以从卖方公布的价格清单中获取相关信息。
• 汇率和通货膨胀率。对于持续多年、涉及多种货币的大规模项目，需要了解汇率波动和通货膨胀，并将其纳入估算成本过程。

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

• 以往类似项目；
• 来自行业、学科和应用领域的信息；
• 成本估算方法。

见 6.4.2.2 节。成本类比估算使用以往类似项目的参数值或属性来估算。项目的参数值和属性包括（但不限于）范围、成本、预算、持续时间和规模指标（如尺寸、重量），类比估算以这些项目参数值或属性为基础来估算当前项目的同类参数或指标。

见 6.4.2.3 节。参数估算是指利用历史数据之间的统计关系和其他变量（如建筑施工中的平方英尺），来进行项目工作的成本估算，参数估算的准确性取决于参数模型的成熟度和基础数据的可靠性。参数估算可以针对整个项目或项目中的某个部分，并可与其他估算方法联合使用。

而随着项目信息越来越明确，可以动用、减少或取消应急储备。应该在成本文件中清楚地列出应急储备。应急储备是成本基准的一部分，也是项目整体资金需求的一部分。

见 4.3.2.2 节。项目管理信息系统可包括电子表单、模拟软件以及统计分析工具，可用来辅助成本估算。这些工具能简化某些成本估算技术的使用，使人们能快速考虑多种成本估算方案。

成本估算包括对完成项目工作可能需要的成本、应对已识别风险的应急储备，以及应对计划外工作的管理储备的量化估算。成本估算可以是汇总的或详细分列的。成本估算应覆盖项目所使用的全部资源，包括（但不限于）直接人工、材料、设备、服务、设施、信息技术，以及一些特殊的成本种类，如融资成本（包括利息）、通货膨胀补贴、汇率或成本应急储备。如果间接成本也包含在项目估算中，则可在活动层次或更高层次上计列间接成本。

项目预算包括经批准用于执行项目的全部资金，而成本基准是经过批准且按时间段分配的项目预算，包括应急储备，但不包括管理储备。

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

• 成本管理计划。见 7.1.3.1 节。成本管理计划描述了如何将项目成本纳入项目预算中。
• 资源管理计划。见 9.1.3.1 节。资源管理计划提供了有关（人力和其他资源的）费率、差旅成本估算，和其他可预见成本的信息，这些信息是估算整个项目预算时必须考虑的因素。
• 范围基准。见 5.4.3.1 节。范围基准包括项目范围说明书、WBS 和 WBS 词典的详细信息，可用于成本估算和管理。

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

• 估算依据。见 6.4.3.2 节。在估算依据中包括基本的假设条件，例如，项目预算中是否应该包含间接成本或其他成本。
• 成本估算。见 7.2.3.1 节。各工作包内每个活动的成本估算汇总后，即得到各工作包的成本估算。
• 项目进度计划。见 6.5.3.2 节。项目进度计划包括项目活动、里程碑、工作包和控制账户的计划开始和完成日期。可根据这些信息，把计划成本和实际成本汇总到相应的日历时段中。
• 风险登记册。见 11.2.3.1 节。应该审查风险登记册，以确定如何汇总风险应对成本。风险登记册的更新包含在项目文件更新中，见 11.5.3.3 节。

见 1.2.6. 节。可作为本过程输入的商业文件包括（但不限于）：

• 商业论证。商业论证识别了项目成功的关键因素，包括财务成功因素。
• 效益管理计划。效益管理计划包括目标效益，例如净现值的计算、实现效益的时限，以及与效益有关的测量指标。

会影响估算成本过程的事业环境因素包括（但不限于）汇率。对于持续多年、涉及多种货币的大规模项目，需要了解汇率波动并将其纳入制定预算过程。

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

• 以往类似项目；
• 来自行业、学科和应用领域的信息；
• 财务原则；
• 资金需求和来源。

先把成本估算汇总到 WBS 中的工作包，再由工作包汇总至 WBS 的更高层次（如控制账户），最终得出整个项目的总成本。

可用于制定预算过程的数据分析技术包括（但不限于）可以建立项目管理储备的储备分析。管理储备是为了管理控制的目的而特别留出的项目预算，用来应对项目范围中不可预见的工作，目的是用来应对会影响项目的“未知 — 未知”风险。管理储备不包括在成本基准中，但属于项目总预算和资金需求的一部分。当动用管理储备资助不可预见的工作时，就要把动用的管理储备增加到成本基准中，从而导致成本基准变更。

审核历史信息有助于进行参数估算或类比估算。历史信息可包括各种项目特征（参数），它们用于建立数学模型预测项目总成本。这些数学模型可以是简单的（例如，建造住房的总成本取决于单位面积建造成本），也可以是复杂的（例如，软件开发项目的成本模型中有多个变量，且每个变量又受许多因素的影响）。

类比和参数模型的成本及准确性可能差别很大。在以下情况下，它们将最为可靠：

• 用来建立模型的历史信息准确；
• 模型中的参数易于量化；
• 模型可以调整，以便对大项目、小项目和各项目阶段都适用。

应该根据对项目资金的任何限制，来平衡资金支出。如果发现资金限制与计划支出之间的差异，则可能需要调整工作的进度计划，以平衡资金支出水平。这可以通过在项目进度计划中添加强制日期来实现。

融资是指为项目获取资金。长期的基础设施、工业和公共服务项目通常会寻求外部融资。如果项目使用外部资金，出资实体可能会提出一些必须满足的要求。

图 7-8项目预算的组成

根据成本基准，确定总资金需求和阶段性（如季度或年度）资金需求。成本基准中既包括预计支出及预计债务。项目资金通常以增量的方式投入，并且可能是非均衡的，呈现出图 7-9 中所示的阶梯状。

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

图 7-10控制成本：输入、工具与技术和输出

图 7-11控制成本的数据流向图

要更新预算，就需要了解截至目前的实际成本。只有经过实施整体变更控制过程（见 4.6 节）的批准，才可以增加预算。只监督资金的支出，而不考虑由这些支出所完成的工作的价值，对项目没有什么意义，最多只能跟踪资金流。所以在成本控制中，应重点分析项目资金支出与相应完成的工作之间的关系。有效成本控制的关键在于管理经批准的成本基准。

项目成本控制包括：

• 对造成成本基准变更的因素施加影响；
• 确保所有变更请求都得到及时处理；
• 当变更实际发生时，管理这些变更；
• 确保成本支出不超过批准的资金限额，既不超出按时段、按 WBS 组件、按活动分配的限额，也不超出项目总限额；
• 监督成本绩效，找出并分析与成本基准间的偏差；
• 对照资金支出，监督工作绩效；
• 防止在成本或资源使用报告中出现未经批准的变更；
• 向相关方报告所有经批准的变更及其相关成本；
• 设法把预期的成本超支控制在可接受的范围内。

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

• 成本管理计划。见 7.1.3.1 节。成本管理计划描述将如何管理和控制项目成本。
• 成本基准。见 7.3.3.1 节。把成本基准与实际结果相比，以判断是否需要进行变更或采取纠正或预防措施。
• 绩效测量基准。见 4.2.3.1 节。使用挣值分析时，将绩效测量基准与实际结果比较，以决定是否有必要进行变更、采取纠正措施或预防措施。

可作为本过程输入的项目文件包括（但不限于）经验教训登记册。见 4.4.3.1 节。在项目早期获得的经验教训可以运用到后期阶段，以改进成本控制。

见 4.3.3.2 节。工作绩效数据包含关于项目状态的数据，例如哪些成本已批准、发生、支付和开具发票。

如果已识别的风险没有发生，就可能要从项目预算中扣除未使用的应急储备，为其他项目或运营腾出资源。同时，在项目中开展进一步风险分析，可能会发现需要为项目预算申请额外的储备。

如果累计 CPI 低于基准（如图 7-13 所示），那么项目的全部剩余工作都应立即按 TCPI（BAC）（图7-13 中最高的那条线）执行，才能确保实际总成本不超过批准的 BAC。至于所要求的这种绩效水平是否可行，就需要综合考虑多种因素（包括风险、项目剩余时间和技术绩效）后才能判断；如果不可行，就需要把项目未来所需的绩效水平调整为如 TCPI（EAC）线所示。基于 EAC 的 TCPI 公式：

见 4.3.2.2 节。项目管理信息系统常用于监测 PV、EV 和 AC 这三个 EVM 指标、绘制趋势图，并预测最终项目结果的可能区间。

见 4.5.1.3 节。工作绩效信息包括有关项目工作实施情况的信息（对照成本基准），可以在工作包层级和控制账户层级上评估已执行的工作和工作成本方面的偏差。对于使用挣值分析的项目，CV、CPI、EAC、VAC 和 TCPI 将记录在工作绩效报告中（见 4.5.3.1 节）。

见 4.3.3.4 节。分析项目绩效后，可能会就成本基准和进度基准，或项目管理计划的其他组成部分提出变更请求。应该通过实施整体变更控制过程（见 4.6 节）对变更请求进行审查和处理。

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

• 成本管理计划。见 7.1.3.1 节。成本管理计划中需要更新的内容包括：用于管理项目成本的控制临界值或所要求的准确度。要根据相关方的反馈意见，对它们进行更新。
• 成本基准。见 7.3.3.1 节。在针对范围、资源或成本估算的变更获得批准后，需要对成本基准做出相应的变更。在某些情况下，成本偏差可能太过严重，以至于需要修订成本基准，以便为绩效测量提供现实可行的依据。
• 绩效测量基准。见 4.2.3.1 节。在针对范围、进度绩效或成本估算的变更获得批准后，需要对绩效测量基准做出相应的变更。在某些情况下，绩效偏差可能太过严重，以至于需要提出变更请求来修订绩效测量基准，以便为绩效测量提供现实可行的依据。

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

• 假设日志。见 4.1.3.2 节。成本绩效可能表明需要重新修订有关资源生产率和其他影响成本绩效的因素的假设条件。
• 估算依据。见 6.4.3.2 节。成本绩效可能表明需要重新审查初始估算依据。
• 成本估算。见 7.2.3.1 节。可能需要更新成本估算，以反映项目的实际成本效率。
• 经验教训登记册。见 4.4.3.1 节。有效维护预算、偏差分析、挣值分析、预测，以及应对成本偏差的纠正措施的相关技术，应当更新在经验教训登记册中。
• 风险登记册。见 11.2.3.1 节。如果出现成本偏差，或者成本可能达到临界值，则应更新风险登记册。

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

本节讨论项目中最常用的质量规划技术，但在特定项目或应用领域中，还可采用许多其他质量规划技术。

见 4.1.3.1 节。项目章程中包含对项目和产品特征的高层级描述，还包括可以影响项目质量管理的项目审批要求、可测量的项目目标和相关的成功标准。

见 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 节。相关方登记册有助于识别对质量有特别兴趣或影响的相关方，尤其注重客户和项目发起人的需求和期望。

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

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

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

• 标杆对照。标杆对照是将实际或计划的项目实践或项目的质量标准与可比项目的实践进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。作为标杆的项目可以来自执行组织内部或外部，或者来自同一应用领域或其他应用领域。标杆对照也允许用不同应用领域或行业的项目做类比。
• 头脑风暴。见 4.1.2.2 节。通过头脑风暴可以向团队成员或主题专家收集数据，以制定最适合新项目的质量管理计划。
• 访谈。见 5.2.2.2 节。访谈有经验的项目参与者、相关方和主题专家有助于了解他们对项目和产品质量的隐性和显性、正式和非正式的需求和期望。应在信任和保密的环境下开展访谈，以获得真实可信、不带偏见的反馈。

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

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

• 流程图。流程图，也称过程图，用来显示在一个或多个输入转化成一个或多个输出的过程中，所需要的步骤顺序和可能分支。它通过映射水平价值链的过程细节来显示活动、决策点、分支循环、并行路径及整体处理顺序。图 8-6 展示了其中一个版本的价值链，即 SIPOC（供应商、输入、过程、输出和客户）模型。流程图可能有助于了解和估算一个过程的质量成本。通过工作流的逻辑分支及其相对频率来估算质量成本。这些逻辑分支细分为完成符合要求的输出而需要开展的一致性工作和非一致性工作。用于展示过程步骤时，流程图有时又被称为“过程流程图”或“过程流向图”，可帮助改进过程并识别可能出现质量缺陷或可以纳入质量检查的地方。
• 逻辑数据模型。逻辑数据模型把组织数据可视化，以商业语言加以描述，不依赖任何特定技术。逻辑数据模型可用于识别会出现数据完整性或其他质量问题的地方。
• 矩阵图。矩阵图在行列交叉的位置展示因素、原因和目标之间的关系强弱。根据可用来比较因素的数量，项目经理可使用不同形状的矩阵图，如 L 型、T 型、Y 型、X 型、C 型和屋顶型矩阵。在本过程中，它们有助于识别对项目成功至关重要的质量测量指标。
• 思维导图。见 5.2.2.3 节。思维导图是一种用于可视化组织信息的绘图法。质量思维导图通常是基于单个质量概念创建的，是绘制在空白的页面中央的图像，之后再增加以图像、词汇或词条形式表现的想法。思维导图技术可以有助于快速收集项目质量要求、制约因素、依赖关系和联系。

图 8-6 SIPOC 模型

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

项目团队可以召开规划会议来制定质量管理计划。参会者可能包括项目经理、项目发起人、选定的项目团队成员、选定的相关方、项目质量管理活动的负责人，以及其他必要人员。

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

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

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

质量测量指标专用于描述项目或产品属性，以及控制质量过程将如何验证符合程度。质量测量指标的例子包括按时完成的任务的百分比、以 CPI 测量的成本绩效、故障率、识别的日缺陷数量、每月总停机时间、每个代码行的错误、客户满意度分数，以及测试计划所涵盖的需求的百分比（即测试覆盖度）。

管理质量被认为是所有人的共同职责，包括项目经理、项目团队、项目发起人、执行组织的管理层，甚至是客户。所有人在管理项目质量方面都扮演一定的角色，尽管这些角色的人数和工作量不同。参与质量管理工作的程度取决于所在行业和项目管理风格。在敏捷项目中，整个项目期间的质量管理由所有团队成员执行；但在传统项目中，质量管理通常是特定团队成员的职责。

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

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

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

能够影响管理质量过程的组织过程资产包括（但不限于）：

• 包括政策、程序及指南的组织质量管理体系；
• 质量模板，例如核查表、跟踪矩阵、测试计划、测试文件及其它模板；
• 以往审计的结果；
• 包含类似项目信息的经验教训知识库。

适用于本过程的数据收集技术包括（但不限于）核对单（见 11.2.2.2 节）。核对单是一种结构化工具，通常列出特定组成部分，用来核实所要求的一系列步骤是否已得到执行或检查需求列表是否已得到满足。基于项目需求和实践，核对单可简可繁。许多组织都有标准化的核对单，用来规范地执行经常性任务。在某些应用领域，核对单也可从专业协会或商业性服务机构获取。质量核对单应该涵盖在范围基准中定义的验收标准。

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

• 备选方案分析。见 9.2.2.5 节。该技术用于评估已识别的可选方案，以选择那些最合适的质量方案或方法。
• 文件分析。见 5.2.2.3 节。分析项目控制过程所输出的不同文件，如质量报告、测试报告、绩效报告和偏差分析，可以重点指出可能超出控制范围之外并阻碍项目团队满足特定要求或相关方期望的过程。
• 过程分析。过程分析可以识别过程改进机会，同时检查在过程期间遇到的问题、制约因素，以及非增值活动。
• 根本原因分析 (RCA)。根本原因分析是确定引起偏差、缺陷或风险的根本原因的一种分析技术。

一项根本原因可能引起多项偏差、缺陷或风险。根本原因分析还可以作为一项技术，用于识别问题的根本原因并解决问题。消除所有根本原因可以杜绝问题再次发生。

适用于本过程的决策技术包括（但不限于）多标准决策分析。见 8.1.2.4 节。在讨论影响项目或产品质量的备选方案时，可以使用多标准决策评估多个标准。“项目”决策可以包括在不同执行情景或供应商中加以选择，“产品”决策可以包括评估生命周期成本、进度、相关方的满意程度，以及与解决产品缺陷有关的风险。

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

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

图 8-9因果图

采取后续措施纠正问题，可以降低质量成本，并提高发起人或客户对项目产品的接受度。质量审计可事先安排，也可随机进行；可由内部或外部审计师进行。

质量报告可能是图形、数据或定性文件，其中包含的信息可帮助其他过程和部门采取纠正措施，以实现项目质量期望。质量报告的信息可以包含团队上报的质量管理问题，针对过程、项目和产品的改善建议，纠正措施建议（包括返工、缺陷/漏洞补救、100% 检查等），以及在控制质量过程中发现的情况的概述。

见 4.3.3.4 节。如果管理质量过程期间出现了可能影响项目管理计划任何组成部分、项目文件或项目/产品管理过程的变更，项目经理应提交变更请求并遵循 4.6 节定义的实施整体变更控制过程。

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

• 问题日志。见 4.3.3.3 节。在本过程中提出的新问题记录到问题日志中。
• 经验教训登记册。见 4.4.3.1 节。项目中遇到的挑战、本应可以规避这些挑战的方法，以及良好的质量管理方式，需要记录在经验教训登记册中。
• 风险登记册。见 11.2.3.1 节。在本过程中识别的新风险记录在风险登记册中，并通过风险管理过程进行管理。

控制质量的努力程度和执行程度可能会因所在行业和项目管理风格而不同。例如，相比其他行业，制药、医疗、运输和核能产业可能拥有更加严格的质量控制程序，为满足标准付出的工作也会更广；在敏捷项目中，控制质量活动可能由所有团队成员在整个项目生命周期中执行，而在瀑布式项目中，控制质量活动由特定团队成员在特定时间点或者项目或阶段快结束时执行。

见 4.2.3.1 节。项目管理计划组件包括（但不限于）质量管理计划。见 8.1.3.1 节。质量管理计划定义了如何在项目中开展质量控制。

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

• 经验教训登记册。见 4.4.3.1 节。在项目早期获得的经验教训可以运用到后期阶段，以改进质量控制。
• 质量测量指标。见 8.1.3.2 节。质量测量指标专用于描述项目或产品属性，以及控制质量过程将如何验证符合程度。
• 测试与评估文件。见 8.2.3.2 节。测试与评估文件用于评估质量目标的实现程度。

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

见 4.3.3.2 节。工作绩效数据包括产品状态数据，例如观察结果、质量测量指标、技术绩效测量数据，以及关于进度绩效和成本绩效的项目质量信息。

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

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

检查是指检验工作产品，以确定是否符合书面标准。检查的结果通常包括相关的测量数据，可在任何层面上进行。可以检查单个活动的成果，也可以检查项目的最终产品。检查也可称为审查、同行审查、审计或巡检等，而在某些应用领域，这些术语的含义比较狭窄和具体。检查也可用于确认缺陷补救。

不同应用领域需要不同测试。例如，软件测试可能包括单元测试、集成测试、黑盒测试、白盒测试、接口测试、回归测试、α 测试等；在建筑项目中，测试可能包括水泥强度测试、混凝土和易性测试、在建筑工地进行的旨在测试硬化混凝土结构的质量的无损伤测试，以及土壤试验；在硬件开发中，测试可能包括环境应力筛选、老化测试、系统测试等。

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

• 因果图。见 8.2.2.4 节。因果图用于识别质量缺陷和错误可能造成的结果。
• 控制图。控制图用于确定一个过程是否稳定，或者是否具有可预测的绩效。规格上限和下限是根据要求制定的，反映了可允许的最大值和最小值。上下控制界限不同于规格界限。控制界限根据标准的统计原则，通过标准的统计计算确定，代表一个稳定过程的自然波动范围。项目经理和相关方可基于计算出的控制界限，识别须采取纠正措施的检查点，以预防不在控制界限内的绩效。控制图可用于监测各种类型的输出变量。虽然控制图最常用来跟踪批量生产中的重复性活动，但也可用来监测成本与进度偏差、产量、范围变更频率或其他管理工作成果，以便帮助确定项目管理过程是否受控。
• 直方图。见 8.2.2.4 节。直方图可按来源或组成部分展示缺陷数量。
• 散点图。见 8.2.2.4 节。散点图可在一支轴上展示计划的绩效，在另一支轴上展示实际绩效。

以下会议可作为控制质量过程的一部分：

• 审查已批准的变更请求。对所有已批准的变更请求进行审查，以核实它们是否已按批准的方式实施，确认是否已完成局部变更，以及是否已执行、测试、完成和证实所有部分。
• 回顾/经验教训。项目团队举行的会议，旨在讨论：
• 项目/阶段的成功要素；
• 待改进之处；
• 当前项目和未来项目可增加的内容；
• 可增加到组织过程资产中的内容。

见 4.5.1.3 节。工作绩效信息包含有关项目需求实现情况的信息、拒绝的原因、要求的返工、纠正措施建议、核实的可交付成果列表、质量测量指标的状态，以及过程调整需求。

见 4.3.3.4 节。如果控制质量过程期间出现了可能影响项目管理计划任何组成部分或项目文件的变更，项目经理应提交变更请求，且应该通过实施整体变更控制过程（见 4.6 节）对变更请求进行审查和处理。

对于易变性高的项目，实物和人力资源规划的可预测性要低得多。在这些环境中，关于快速供应和精益方法的协议，对控制成本和实现进度而言至关重要。

这些资源可以从组织内部资产获得，或者通过采购过程从组织外部获取。其他项目可能在同一时间和地点竞争项目所需的相同资源，从而对项目成本、进度、风险、质量和其他项目领域造成显著影响。

见 4.1.3.1 节。项目章程提供项目的高层级描述和要求，此外还包括可能影响项目资源管理的关键相关方名单、里程碑概况，以及预先批准的财务资源。

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

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

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

• 项目进度计划。见 6.5.3.2 节。项目进度计划提供了所需资源的时间轴。
• 需求文件。见 5.2.3.1 节。需求文件指出了项目所需的资源的类型和数量，并可能影响管理资源的方式。
• 风险登记册。见 11.2.3.1 节。风险登记册包含可能影响资源规划的各种威胁和机会的信息。
• 相关方登记册。见 13.1.3.1 节。相关方登记册有助于识别对项目所需资源有特别兴趣或影响的那些相关方，以及会影响资源使用偏好的相关方。

能够影响规划资源管理过程的组织过程资产包括（但不限于）：

• 人力资源政策和程序；
• 物质资源管理政策和程序；
• 安全政策；
• 安保政策；
• 资源管理计划模板；
• 类似项目的历史信息。

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

• 协调组织内部的最佳资源；
• 人才管理和员工发展；
• 确定为实现项目目标所需的初步投入水平；
• 根据组织文化确定报告要求；
• 根据经验教训和市场条件，评估获取资源所需的提前量；
• 识别与资源获取、留用和遣散计划有关的风险；
• 遵循适用的政府和工会法规；
• 管理卖方和物流工作，确保在需要时能够提供材料和用品。

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

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

图 9-4 RACI 矩阵示例

组织理论阐述个人、团队和组织部门的行为方式。有效利用组织理论中的常用技术，可以节约规划资源管理过程的时间、成本及人力投入，提高规划工作的效率。此外，可以根据相关的组织理论灵活使用领导风格，以适应项目生命周期中团队成熟度的变化。重要的是要认识到，组织的结构和文化影响项目组织结构。

项目团队可召开会议来规划项目资源管理。

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

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

团队章程对项目团队成员的可接受行为确定了明确的期望。尽早认可并遵守明确的规则，有助于减少误解，提高生产力；讨论诸如行为规范、沟通、决策、会议礼仪等领域，团队成员可以了解彼此重要的价值观。由团队制定或参与制定的团队章程可发挥最佳效果。所有项目团队成员都分担责任，确保遵守团队章程中规定的规则。可定期审查和更新团队章程，确保团队始终了解团队基本规则，并指导新成员融入团队。

估算活动资源是估算执行项目所需的团队资源，以及材料、设备和用品的类型和数量的过程。

本过程的主要作用是，明确完成项目所需的资源种类、数量和特性。本过程应根据需要在整个项目期间定期开展。图 9-5 描述本过程的输入、工具与技术和输出，图 9-6 是本过程的数据流向图。

图 9-5估算活动资源：输入、工具与技术和输出

图 9-6估算活动资源的数据流向图

• Projectcharter估算活动资源过程与其他过程紧密相关，例如估算成本过程。例如：

• 建筑项目团队需要熟悉当地建筑法规。这类知识常可从当地卖方获取，但是，如果内部劳动力资源对不常用或专门的建筑技术缺乏经验，那么支付额外费用聘请咨询专家，可能就是了解当地建筑法规的最有效的方法。
• 汽车设计团队需要熟悉最新的自动装配技术。这些必要的知识可以通过聘请顾问、派设计人员参加机器人技术研讨会，或者邀请制造人员加入项目团队等方式来获取。

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

• 资源管理计划。见 9.1.3.1 节。资源管理计划定义了识别项目所需不同资源的方法，还定义了量化各个活动所需的资源并整合这些信息的方法。
• 范围基准。见 5.4.3.1 节。范围基准识别了实现项目目标所需的项目和产品范围，而范围决定了对团队和实物资源的需求。

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

• 活动属性。见 6.2.3.2 节。活动属性为估算活动清单中每项活动所需的团队和实物资源提供了主要数据来源，这些属性的例子包括资源需求、强制日期、活动地点、假设条件和制约因素。
• 活动清单。见 6.2.3.1 节。活动清单识别了需要资源的活动。
• 假设日志。见 4.1.3.2 节。假设日志可能包含有关生产力因素、可用性、成本估算以及工作方法的信息，这些因素会影响团队和实物资源的性质和数量。
• 成本估算。见 7.2.3.1 节。资源成本从数量和技能水平方面会影响资源选择。
• 资源日历。资源日历识别了每种具体资源可用时的工作日、班次、正常营业的上下班时间、周末和公共假期。在规划活动期间，潜在的可用资源信息（如团队资源、设备和材料）用于估算资源可用性。资源日历还规定了在项目期间确定的团队和实物资源何时可用、可用多久。这些信息可以在活动或项目层面建立，这考虑了诸如资源经验和/或技能水平以及不同地理位置等属性。
• 风险登记册。见 11.2.3.1 节。风险登记册描述了可能影响资源选择和可用性的各个风险。

能够影响估算活动资源过程的组织过程资产包括（但不限于）：

• 关于人员配备的政策和程序；
• 关于用品和设备的政策与程序；
• 关于以往项目中类似工作所使用的资源类型的历史信息。

见 6.4.2.5 节。团队和实物资源在活动级别上估算，然后汇总成工作包、控制账户和总体项目层级上的估算。

见 6.4.2.2 节。类比估算将以往类似项目的资源相关信息作为估算未来项目的基础。这是一种快速估算方法，适用于项目经理只能识别 WBS 的几个高层级的情况下。

见 6.4.2.3 节。参数估算基于历史数据和项目参数，使用某种算法或历史数据与其他变量之间的统计关系，来计算活动所需的资源数量。例如，如果一项活动需要 4,000 个小时的编码时间，而且需要在 1 年之内完成，则需要两个人来编码（每人每年付出 2,000 小时）。参数估算的准确性取决于参数模型的成熟度和基础数据的可靠性。

适用于本过程的数据分析技术包括（但不限于）备选方案分析。备选方案分析是一种对已识别的可选方案进行评估的技术，用来决定选择哪种方案或使用何种方法来执行项目工作。很多活动有多个备选的实施方案，例如使用能力或技能水平不同的资源、不同规模或类型的机器、不同的工具（手工或自动），以及关于资源自制、租赁或购买的决策。备选方案分析有助于提供在定义的制约因素范围内执行项目活动的最佳方案。

见 4.3.2.2 节。项目管理信息系统可以包括资源管理软件，这些软件有助于规划、组织与管理资源库，以及编制资源估算。根据软件的复杂程度，可以确定资源分解结构、资源可用性、资源费率和各种资源日历，有助于优化资源使用。

项目经理可以和职能经理一起举行规划会议，以估算每项活动所需的资源、支持型活动 (LoE)、团队资源的技能水平，以及所需材料的数量。参会者可能包括项目经理、项目发起人、选定的项目团队成员、选定的相关方，以及其他必要人员。

资源需求识别了各个工作包或工作包中每个活动所需的资源类型和数量，可以汇总这些需求，以估算每个工作包、每个 WBS 分支以及整个项目所需的资源。资源需求描述的细节数量与具体程度因应用领域而异，而资源需求文件也可包含为确定所用资源的类型、可用性和所需数量所做的假设。

见 6.4.3.2 节。资源估算所需的支持信息的数量和种类，因应用领域而异。但不论其详细程度如何，支持性文件都应该清晰完整地说明资源估算是如何得出的。

资源估算的支持信息可包括：

• 估算方法；
• 用于估算的资源，如以往类似项目的信息；
• 与估算有关的假设条件；
• 已知的制约因素；
• 估算范围；
• 估算的置信水平；
• 有关影响估算的已识别风险的文件。

资源分解结构是资源依类别和类型的层级展现（见图 9-7）。资源类别包括（但不限于）人力、材料、设备和用品，资源类型则包括技能水平、要求证书、等级水平或适用于项目的其他类型。在规划资源管理过程中，资源分解结构用于指导项目的分类活动。在这一过程中，资源分解结构是一份完整的文件，用于获取和监督资源。

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

• 活动属性。见 6.2.3.2 节。活动属性依据资源需求而更新。
• 假设日志。见 4.1.3.2 节。关于项目所需资源的类型和数量的假设条件，更新在假设日志中。此外，任何资源制约因素，包括集体劳资协议、连续工作时间、计划休假等，也应当相应更新。
• 经验教训登记册。见 11.2.3.1 节。能够有效和高效地估算资源的技术，以及有关那些无效或低效的技术信息，更新在经验教训登记册中。

在项目规划阶段，应该对上述因素加以考虑并做出适当安排。项目经理或项目管理团队应该在项目进度计划、项目预算、项目风险计划、项目质量计划、培训计划及其他相关项目管理计划中，说明缺少所需资源的后果。

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

• 资源管理计划。见 9.1.3.1 节。资源管理计划为如何获取项目资源提供指南。
• 采购管理计划。见 12.1.3.1 节。采购管理计划提供了关于将从项目外部获取的资源的信息，包括如何将采购与其他项目工作整合起来以及涉及资源采购工作的相关方。
• 成本基准。见 7.3.3.1 节。成本基准提供了项目活动的总体预算。

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

• 项目进度计划。见 6.5.3.2 节。项目进度计划展示了各项活动及其开始和结束日期，有助于确定需要提供和获取资源的时间。
• 资源日历。见 9.3.3.3 节。资源日历记录了每个项目资源在项目中的可用时间段。编制出可靠的进度计划，应依据对各个资源的可用性和时间限制（包括时区、工作时间、休假时间、当地节假日、维护计划和在其他项目的工作时间）的良好了解。资源日历需要在整个项目过程中渐进明细和更新。资源日历是本过程的输出，在重复本过程时随时可用。
• 资源需求。见 9.2.3.1 节。资源需求识别了需要获取的资源。
• 相关方登记册。见 13.1.3.1 节。相关方登记册可能会发现相关方对项目特定资源的需求或期望，在获取资源过程中应加以考虑。

能够影响获取资源过程的组织过程资产包括（但不限于）：

• 有关项目资源的采购、配置和分配的政策和程序；
• 历史信息和经验教训知识库。

见 5.2.2.4 节。适用于获取资源过程的决策技术包括（但不限于）多标准决策分析（见 8.1.2.4 节）。

选择标准常用于选择项目的实物资源或项目团队。使用多标准决策分析工具制定出标准，用于对潜在资源进行评级或打分（例如，在内部和外部团队资源之间进行选择）。根据标准的相对重要性对标准进行加权，加权值可能因资源类型的不同而发生变化。可使用的选择标准包括：

• 可用性。确认资源能否在项目所需时段内为项目所用。
• 成本。确认增加资源的成本是否在规定的预算内。
• 能力。确认团队成员是否提供了项目所需的能力。

有些选择标准对团队资源来说是独特的，包括：

• 经验。确认团队成员具备项目成功所需的相关经验。
• 知识。团队成员是否掌握关于客户、执行过的类似项目和项目环境细节的相关知识。
• 技能。确认团队成员拥有使用项目工具的相关技能。
• 态度。团队成员能否与他人协同工作，以形成有凝聚力的团队。
• 国际因素。团队成员的位置、时区和沟通能力。

在资源分配谈判中，项目管理团队影响他人的能力很重要，如同在组织中的政治能力一样重要。例如，说服职能经理，让他/她看到项目具有良好的前景，会影响他/她把最佳资源分配给这个项目而不是竞争项目。

预分派指事先确定项目的实物或团队资源，可在下列情况下发生：在竞标过程中承诺分派特定人员进行项目工作；项目取决于特定人员的专有技能；在完成资源管理计划的前期工作之前，制定项目章程过程或其他过程已经指定了某些团队成员的工作分派。

虚拟团队的使用为招募项目团队成员提供了新的可能性。虚拟团队可定义为具有共同目标、在完成角色任务的过程中很少或没有时间面对面工作的一群人。现代沟通技术（如电子邮件、电话会议、社交媒体、网络会议和视频会议等）使虚拟团队成为可行。虚拟团队模式使人们有可能：

• 在组织内部地处不同地理位置的员工之间组建团队；
• 为项目团队增加特殊技能，即使相应的专家不在同一地理区域；
• 将在家办公的员工纳入团队；
• 在工作班次、工作小时或工作日不同的员工之间组建团队；
• 将行动不便者或残疾人纳入团队；
• 执行那些原本会因差旅费用过高而被搁置或取消的项目；
• 节省员工所需的办公室和所有实物设备的开支。

在虚拟团队的环境中，沟通规划变得日益重要。可能需要花更多时间，来设定明确的期望、促进沟通、制定冲突解决方法、召集人员参与决策、理解文化差异，以及共享成功喜悦。

实物资源分配单记录了项目将使用的材料、设备、用品、地点和其他实物资源。

项目团队派工单记录了团队成员及其在项目中的角色和职责，可包括项目团队名录，还需要把人员姓名插入项目管理计划的其他部分，如项目组织图和进度计划。

资源日历规定了在项目期间确定的团队和实物资源何时可用、可用多久。这些信息可以在活动或项目层面建立，这考虑了诸如资源经验和/或技能水平以及不同地理位置等属性。

见 4.3.3.4 节。如果获取资源过程中出现变更请求（例如影响了进度），或者推荐措施、纠正措施或预防措施影响了项目管理计划的任何组成部分或项目文件，项目经理应提交变更请求，且应该通过实施整体变更控制过程（见 4.6 节）对变更请求进行审查和处理。

项目管理计划的任何变更都以变更请求的形式提出，且通过组织的变更控制过程进行处理。

开展本过程可能导致项目管理计划更新的内容包括（但不限于）：

• 资源管理计划。见 9.1.3.1 节。更新资源管理计划，以反映获取项目资源的实际经验，包括在项目早期获取资源的经验教训，这些经验会影响项目后期的资源获取过程。
• 成本基准。见 7.3.3.1 节。在项目资源采购期间，成本基准可能发生变更。

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

• 经验教训登记册。见 4.4.3.1 节。项目中遇到的挑战、本可以规避这些挑战的方法，以及良好的资源获取方式更新在经验教训登记册中。
• 项目进度计划。见 6.5.3.2 节。所需资源的可用性可能会导致项目进度的变更。
• 资源分解结构。见 9.2.3.3 节。在本过程中获取的资源应记录到资源分解结构中。
• 资源需求。见 9.2.3.1 节。可更新资源需求文件，以反映获取的项目资源。
• 风险登记册。见 11.2.3.1 节。本过程中识别的新风险记录在风险登记册中，并通过风险管理过程进行管理。
• 相关方登记册。见 13.1.3.1 节。增加的任何新的相关方，以及在本过程中获得的有关现有相关方的新信息更新在相关方登记册中。

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

见 4.2.3.1 节。项目管理计划组件包括（但不限于）资源管理计划。见 9.1.3.1 节，资源管理计划为如何通过团队绩效评价和其他形式的团队管理活动，为项目团队成员提供奖励、提出反馈、增加培训或采取惩罚措施提供了指南。资源管理计划可能包括团队绩效评价标准。

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

• 经验教训登记册。见 4.4.3.1 节。项目早期与团队建设有关的经验教训可以运用到项目后期阶段，以提高团队绩效。
• 项目进度计划。见 6.5.3.2 节。项目进度计划定义了如何以及何时为项目团队提供培训，以培养不同阶段所需的能力，并根据项目执行期间的任何差异（如有）识别需要的团队建设策略。
• 项目团队派工单。见 9.3.3.1 节。项目团队派工单识别了团队成员的角色与职责。
• 资源日历。见 9.2.1.2 节。资源日历定义了项目团队成员何时能参与团队建设活动，有助于说明团队在整个项目期间的可用性。
• 团队章程。见 9.1.3.2 节。团队章程包含团队工作指南。团队价值观和工作指南为描述团队的合作方式提供了架构。

集中办公是指把许多或全部最活跃的项目团队成员安排在同一个物理地点工作，以增强团队工作能力。集中办公既可以是临时的（如仅在项目特别重要的时期），也可以贯穿整个项目。实施集中办公策略，可借助团队会议室、张贴进度计划的场所，以及其他能增进沟通和集体感的设施。

见 10.1.2.3 节。在解决集中办公或虚拟团队的团队建设问题方面，沟通技术至关重要。它有助于为集中办公团队营造一个融洽的环境，促进虚拟团队（尤其是团队成员分散在不同时区的团队）更好地相互理解。可采用的沟通技术包括：

• 共享门户。共享信息库（例如网站、协作软件或内部网）对虚拟项目团队很有帮助。
• 视频会议。视频会议是一种可有效地与虚拟团队沟通重要技术。
• 音频会议。音频会议有助于与虚拟团队建立融洽的相互信任的关系。
• 电子邮件/聊天软件。使用电子邮件和聊天软件定期沟通也是一种有效的方式。

非正式的沟通和活动有助于建立信任和良好的工作关系。团队建设在项目前期必不可少，但它更是个持续的过程。项目环境的变化不可避免，要有效应对这些变化，就需要持续不断地开展团队建设。项目经理应该持续地监督团队机能和绩效，确定是否需要采取措施来预防或纠正各种团队问题。

大多数项目团队成员会因得到成长机会、获得成就感、得到赞赏以及用专业技能迎接新挑战，而受到激励。项目经理应该在整个项目生命周期中尽可能地给予表彰，而不是等到项目完成时。

培训包括旨在提高项目团队成员能力的全部活动，可以是正式或非正式的，方式包括课堂培训、在线培训、计算机辅助培训、在岗培训（由其他项目团队成员提供）、辅导及训练。如果项目团队成员缺乏必要的管理或技术技能，可以把对这种技能的培养作为项目工作的一部分。项目经理应该按资源管理计划中的安排来实施预定的培训，也应该根据管理项目团队过程中的观察、交谈和项目绩效评估的结果，来开展必要的计划外培训，培训成本通常应该包括在项目预算中，或者如果增加的技能有利于未来的项目，则由执行组织承担。培训可以由内部或外部培训师来执行。

这些工具有利于增进团队成员间的理解、信任、承诺和沟通，在整个项目期间不断提高团队成效。

可以用会议来讨论和解决有关团队建设的问题，参会者包括项目经理和项目团队。会议类型包括（但不限于）：项目说明会、团队建设会议，以及团队发展会议。

通过对团队整体绩效的评价，项目管理团队能够识别出所需的特殊培训、教练、辅导、协助或改变，以提高团队绩效。项目管理团队也应该识别出合适或所需的资源，以执行和实现在绩效评价过程中提出的改进建议。

见 4.3.3.4 节。如果建设团队过程中出现变更请求，或者推荐的纠正措施或预防措施影响了项目管理计划的任何组成部分或项目文件，项目经理应提交变更请求并遵循 4.6 节定义的实施整体变更控制过程。

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

• 经验教训登记册。见 4.4.3.1 节。项目中遇到的挑战、本可以规避这些挑战的方法，以及良好的团队建设方式更新经验教训登记册中。
• 项目进度计划。见 6.5.3.2 节。项目团队建设活动可能会导致项目进度的变更。
• 项目团队派工单。见 9.3.3.1 节。如果团队建设导致已商定的派工单出现变更，应对项目团队派工单做出相应的更新。
• 资源日历。见 9.2.1.2 节。更新资源日历，以反映项目资源的可用性。
• 团队章程。见 9.1.3.2 节。更新团队章程，以反映因团队建设对团队工作指南做出的变更。

作为建设项目团队过程的结果，需要更新的事业环境因素包括（但不限于）：

项目经理应留意团队成员是否有意愿和能力完成工作，然后相应地调整管理和领导力方式。相对那些已展现出能力和有经验的团队成员，技术能力较低的团队成员更需要强化监督。

见 4.2.3.1 节。项目管理计划组件包括（但不限于）资源管理计划。见 9.1.3.1 节，资源管理计划为如何管理和最终遣散项目团队资源提供指南。

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

• 问题日志。见 4.3.3.3 节。在管理项目团队过程中，总会出现各种问题。此时，可用问题日志记录由谁负责在目标日期内解决特定问题，并监督解决情况。
• 经验教训登记册。见 4.4.3.1 节。项目早期的经验教训可以运用到项目后期阶段，以提高团队管理的效率与效果。
• 项目团队派工单。见 9.3.3.1 节。项目团队派工单识别了团队成员的角色与职责。
• 团队章程。见 9.1.3.2 节。团队章程为团队应如何决策、举行会议和解决冲突提供指南。

见 4.5.3.1 节。工作绩效报告是为制定决策、采取行动或引起关注所形成的实物或电子工作绩效信息，它包括从进度控制、成本控制、质量控制和范围确认中得到的结果，有助于项目团队管理。

见 9.4.3.1 节。项目管理团队应该持续地对项目团队绩效进行正式或非正式的评价。不断地评价项目团队绩效，有助于采取措施解决问题、调整沟通方式、解决冲突和改进团队互动。

有多种领导力理论，定义了适用于不同情形或团队的领导风格。领导力对沟通愿景及鼓舞项目团队高效工作十分重要。

见 4.3.2.2 节。项目管理信息系统可包括资源管理或进度计划软件，可用于在各个项目活动中管理和协调团队成员。

例如，人员配备变更，无论是自主选择还是由不可控事件造成，都会干扰项目团队，这种干扰可能导致进度落后或预算超支。人员配备变更包括转派人员、外包部分工作，或替换离职人员。

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

• 资源管理计划。见 9.1.3.1 节。资源管理计划根据实际的项目团队管理经验更新。
• 进度基准。见 6.5.3.1 节。可能需要更改项目进度，以反映团队的执行方式。
• 成本基准。见 7.3.3.1 节。可能需要更改项目成本基准，以反映团队的执行方式。

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

• 问题日志。见 4.3.3.3 节。在本过程中提出的新问题可以记录到问题日志中。
• 经验教训登记册。见 4.4.3.1 节。更新经验教训登记册，记录在项目中遇到的挑战、本应可以规避这些挑战的方法，以及良好的团队管理方式。
• 项目团队派工单。见 9.3.3.1 节。如果需要对团队做出变更，则在项目团队派工单中记录这些变更。

控制资源是确保按计划为项目分配实物资源，以及根据资源使用计划监督资源实际使用情况，并采取必要纠正措施的过程。本过程的主要作用是，确保所分配的资源适时适地可用于项目，且在不再需要时被释放。本过程需要在整个项目期间开展。图 9-14 描述了本过程的输入和输出。图 9-15是本过程的数据流向图。

图 9-14控制资源：输入、工具与技术和输出

• Projectcharter图 9-15控制资源：数据流向图

应在所有项目阶段和整个项目生命周期期间持续开展控制资源过程，且适时、适地和适量地分配和释放资源，使项目能够持续进行。控制资源过程关注实物资源，例如设备、材料、设施和基础设施。管理团队过程关注团队成员。

本节讨论的控制资源技术是项目中最常用的，而在特定项目或应用领域中，还可采用许多其他控制资源技术。

更新资源分配时，需要了解已使用的资源和还需要获取的资源。为此，应审查至今为止的资源使用情况。控制资源过程关注：

• 监督资源支出；
• 及时识别和处理资源缺乏/剩余情况；
• 确保根据计划和项目需求使用和释放资源；
• 在出现资源相关问题时通知相应的相关方；
• 影响可以导致资源使用变更的因素；
• 在变更实际发生时对其进行管理。

进度基准或成本基准的任何变更，都必须经过实施整体变更控制过程的审批（见 4.6 节）。

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

• 问题日志。见 4.3.3.3 节。问题日志用于识别有关缺乏资源、原材料供应延迟，或低等级原材料等问题。
• 经验教训登记册。见 4.4.3.1 节。在项目早期获得的经验教训可以运用到后期阶段，以改进实物资源控制。
• 实物资源分配。见 9.3.3.1 节。实物资源分配描述了资源的预期使用情况以及资源的详细信息，例如类型、数量、地点以及属于组织内部资源还是外购资源。
• 项目进度计划。见 6.5.3.2 节。项目进度计划展示了项目在何时何地需要哪些资源。
• 资源分解结构。见 9.2.3.3 节。资源分解结构为项目过程中需要替换或重新获取资源的情况提供了参考。
• 资源需求。见 9.2.3.1 节。资源需求识别了项目所需的材料、设备、用品和其他资源。
• 风险登记册。见 11.2.3.1 节。风险登记册识别了可能会影响设备、材料或用品的单个风险。

见 4.3.3.2 节。工作绩效数据包含有关项目状态的数据，例如已使用的资源的数量和类型。

见 12.2.3.2 节。在项目中签署的协议是获取组织外部资源的依据，应在需要新的和未规划的资源时，或在当前资源出现问题时，在协议里定义相关程序。

能够影响控制资源过程的组织过程资产包括（但不限于）：

• 有关资源控制和分配的政策；
• 执行组织内用于解决问题的升级程序；
• 经验教训知识库，其中包含以往类似项目的信息。

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

• 备选方案分析。见 9.2.2.5 节。备选方案分析有助于选择最佳解决方案以纠正资源使用偏差，可以将加班和增加团队资源等备选方案与延期交付或阶段性交付相比较，以权衡利弊。
• 成本效益分析。见 8.1.2.3 节。成本效益分析有助于在项目成本出现差异时确定最佳的纠正措施。
• 绩效审查。绩效审查是测量、比较和分析计划的资源使用和实际资源使用的不同。分析成本和进度工作绩效信息有助于指出可能影响资源使用的问题。
• 趋势分析。见 4.5.2.2 节。在项目进展过程中，项目团队可能会使用趋势分析，基于当前绩效信息来确定未来项目阶段所需的资源。趋势分析检查项目绩效随时间的变化情况，可用于确定绩效是在改善还是在恶化。

见 8.2.2.7 节。问题解决可能会用到一系列工具，有助于项目经理解决控制资源过程中出现的问题。问题可能来自组织内部（组织中另一部门使用的机器或基础设施未及时释放，因存储条件不当造成材料受损等）或来自组织外部（主要供应商破产或恶劣天气使资源受损）。项目经理应采取有条不紊的步骤来解决问题，包括：

人际关系与团队技能有时被称为“软技能”，属于个人能力。本过程使用的人际关系与团队技能包括：

• 谈判。见 12.2.2.5 节。项目经理可能需要就增加实物资源、变更实物资源或资源相关成本进行谈判。
• 影响力。见 9.5.2.1 节。影响力有助于项目经理及时解决问题并获得所需资源。

见 4.3.2.2 节。项目管理信息系统可包括资源管理或进度计划软件，可用于监督资源的使用情况，帮助确保合适的资源适时适地用于合适的活动。

见 4.5.1.3 节。工作绩效信息包括项目工作进展信息，这一信息将资源需求和资源分配与项目活动期间的资源使用相比较，从而发现需要处理的资源可用性方面的差异。

见 4.3.3.4 节。如果控制资源过程出现变更请求，或者推荐的纠正措施或预防措施影响了项目管理计划的任何组成部分或项目文件，项目经理应提交变更请求。并通过实施整体变更控制过程（见 4.6节）对变更请求进行审查和处理。

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

• 资源管理计划。见 9.1.3.1 节。资源管理计划根据实际的项目资源管理经验更新。
• 进度基准。见 6.5.3.1 节。可能需要更新项目进度，以反映管理项目资源的方式。
• 成本基准。见 7.3.3.1 节。可能需要更新项目成本基准，以反映管理项目资源的方式。

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

• 假设日志。见 4.1.3.2 节。把关于设备、材料、用品和其他实物资源的新假设条件更新在假设日志中。
• 问题日志。见 4.3.3.3 节。在本过程中出现的新问题可以记录到问题日志中。
• 经验教训登记册。见 4.4.3.1 节。在经验教训登记册中更新有效管理资源物流、废料、使用偏差，以及应对资源偏差的纠正措施的技术。
• 实物资源分配单。见 9.3.3.1 节。实物资源分配单是动态的，会因可用性、项目、组织、环境或其他因素而发生变更。
• 资源分解结构。见 9.2.3.3 节。可能需要更新资源分解结构，以反映使用项目资源的方式。
• 风险登记册。见 11.2.3.1 节。关于资源可用性、利用或其他实物资源的风险更新风在险登记册中。

此外，为了促进与高级管理层和相关方的沟通，还需要以透明的方式发布项目工件，并定期邀请相关方评审项目工件。

虽然所有项目都需要进行信息沟通，但是各项目的信息需求和信息发布方式可能差别很大。此外，在本过程中，需要考虑并合理记录用来存储、检索和最终处置项目信息的方法。应该在整个项目期间，定期审查规划沟通管理过程的成果并做必要修改，以确保其持续适用。

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

• 资源管理计划。见 9.1.3.1 节。指导如何对项目资源进行分类、分配、管理和释放。团队成员和小组可能有沟通要求，应该在沟通管理计划中列出。
• 相关方参与计划。见 13.2.3.1 节。相关方参与计划确定了有效吸引相关方参与所需的管理策略，而这些策略通常通过沟通来落实。

能够影响规划沟通管理过程的组织过程资产包括（但不限于）：

• 组织的社交媒体、道德和安全政策及程序；
• 组织的问题、风险、变更和数据管理政策及程序；
• 组织对沟通的要求；
• 制作、交换、储存和检索信息的标准化指南；
• 历史信息和经验教训知识库；
• 以往项目的相关方及沟通数据和信息。

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

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

分析沟通需求，确定项目相关方的信息需求，包括所需信息的类型和格式，以及信息对相关方的价值。

常用于识别和确定项目沟通需求的信息包括（但不限于）：

• 相关方登记册及相关方参与计划中的相关信息和沟通需求；
• 潜在沟通渠道或途径数量，包括一对一、一对多和多对多沟通；
• 组织结构图；
• 项目组织与相关方的职责、关系及相互依赖；
• 开发方法；
• 项目所涉及的学科、部门和专业；
• 有多少人在什么地点参与项目；
• 内部信息需要（如何时在组织内部沟通）；
• 外部信息需要（如何时与媒体、公众或承包商沟通）；
• 法律要求。

用于在项目相关方之间传递信息的方法很多。信息交换和协作的常见方法包括对话、会议、书面文件、数据库、社交媒体和网站。

可能影响沟通技术选择的因素包括：

• 信息需求的紧迫性。信息传递的紧迫性、频率和形式可能因项目而异，也可能因项目阶段而异。
• 技术的可用性与可靠性。用于发布项目沟通工件的技术，应该在整个项目期间都具备兼容性和可得性，且对所有相关方都可用。
• 易用性。沟通技术的选择应适合项目参与者，而且应在合适的时候安排适当的培训活动。
• 项目环境。团队会议与工作是面对面还是在虚拟环境中开展，成员处于一个还是多个时区，他们是否使用多语种沟通，是否还有能影响沟通效率的其他环境因素（如与文化有关的各个方面）？
• 信息的敏感性和保密性。需要考虑的一些方面有：
• 拟传递的信息是否属于敏感或机密信息？如果是，可能需要采取合理的安全措施。
• 为员工制定社交媒体政策，以确保行为适当、信息安全和知识产权保护。

适用于本过程的人际关系与团队技能包括（但不限于）：

• 沟通风格评估。规划沟通活动时，用于评估沟通风格并识别偏好的沟通方法、形式和内容的一种技术。常用于不支持项目的相关方。可以先开展相关方参与度评估（见 13.2.2.5 节），再开展沟通风格评估。在相关方参与度评估中，找出相关方参与度的差距。为弥补这种差距，就需要特别裁剪沟通活动和工件。
• 政治意识。政治意识有助于项目经理根据项目环境和组织的政治环境来规划沟通。政治意识是指对正式和非正式权力关系的认知，以及在这些关系中工作的意愿。理解组织战略、了解谁能行使权力和施加影响，以及培养与这些相关方沟通的能力，都属于政治意识的范畴。
• 文化意识。文化意识指理解个人、群体和组织之间的差异，并据此调整项目的沟通策略。具有文化意识并采取后续行动，能够最小化因项目相关方社区内的文化差异而导致的理解错误和沟通错误。文化意识和文化敏感性有助于项目经理依据相关方和团队成员的文化差异和文化需求对沟通进行规划。

项目会议可包括虚拟（网络）或面对面会议，且可用文档协同技术进行辅助，包括电子邮件信息和项目网站。在规划沟通管理过程中，需要与项目团队展开讨论，确定最合适的项目信息更新和传递方式，以及回应各相关方的信息请求的方式。

沟通管理计划中还包括关于项目状态会议、项目团队会议、网络会议和电子邮件等的指南和模板。如果项目要使用项目网站和项目管理软件，那就要把它们写进沟通管理计划。

项目管理计划的任何变更都以变更请求的形式提出，且通过组织的变更控制过程进行处理。可能需要变更的项目管理计划组件包括（但不限于）相关方参与计划（见 13.2.3.1 节）。需要更新相关方参与计划，反映会影响相关方参与项目决策和执行的任何过程、程序、工具或技术。

管理沟通是确保项目信息及时且恰当地收集、生成、发布、存储、检索、管理、监督和最终处置的过程。本过程的主要作用是，促成项目团队与相关方之间的有效信息流动。本过程需要在整个项目期间开展。

管理沟通过程会涉及与开展有效沟通有关的所有方面，包括使用适当的技术、方法和技巧。

此外，它还应允许沟通活动具有灵活性，允许对方法和技术进行调整，以满足相关方及项目不断变化的需求。图 10-5 描述本过程的输入、工具与技术和输出。图 10-6 是管理沟通过程的数据流向图。

图 10-5管理沟通：输入、工具与技术和输出

• Projectcharter图 10-6管理沟通：数据流向图

本过程不局限于发布相关信息，它还设法确保信息以适当的格式正确生成和送达目标受众。本过程也为相关方提供机会，允许他们请求更多信息、澄清和讨论。有效的沟通管理需要借助相关技术并考虑相关事宜，包括（但不限于）：

• 发送方 - 接收方模型。运用反馈循环，为互动和参与提供机会，并清除妨碍有效沟通的障碍。
• 媒介选择。为满足特定的项目需求而使用合理的沟通工件，例如，何时进行书面沟通或口头沟通、何时准备非正式备忘录或正式报告、何时使用推式或拉式沟通，以及该选择何种沟通技术。
• 写作风格。合理使用主动或被动语态、句子结构，以及合理选择词汇。
• 会议管理。见 10.2.2.6 节。准备议程，邀请重要参会者并确保他们出席；处理会议现场发生的冲突，或因对会议纪要和后续行动跟进不力而导致的冲突，或因不当人员与会而导致的冲突。
• 演示。了解肢体语言和视觉辅助设计的作用。
• 引导。见 4.1.2.3 节。达成共识、克服障碍（如小组缺乏活力），以及维持小组成员的兴趣和热情。
• 积极倾听。见 10.2.2.6 节。积极倾听包括告知已收到、澄清与确认信息、理解，以及消除妨碍理解的障碍。

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

• 资源管理计划。见 9.1.3.1 节。资源管理计划描述为管理团队或物质资源所需开展的沟通。
• 沟通管理计划。见 10.1.3.1 节。沟通管理计划描述将如何对项目沟通进行规划、结构化和监控。
• 相关方参与计划。详见 13.2.3.1 节。相关方参与计划描述如何用适当的沟通策略引导相关方参与项目。

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

• 变更日志。见 4.6.3.3 节。变更日志用于向受影响的相关方传达变更，以及变更请求的批准、推迟和否决情况。
• 问题日志。见 4.6.3.3 节。将与问题有关的信息传达给受影响的相关方。
• 经验教训登记册。见 4.4.3.1 节。项目早期获取的与管理沟通有关的经验教训，可用于项目后期阶段改进沟通过程，提高沟通效率与效果。
• 质量报告。见 8.2.3.1 节。质量报告包括与质量问题、项目和产品改进，以及过程改进相关的信息。这些信息应交给能够采取纠正措施的人员，以便达成项目的质量期望。
• 风险报告。见 11.2.3.2 节。风险报告提供关于整体项目风险的来源的信息，以及关于已识别的单个项目风险的概述信息 。这些信息应传达给风险责任人及其他受影响的相关方。
• 相关方登记册。见 13.1.3.1 节。相关方登记册确定了需要各类信息的人员、群体或组织。

会影响本过程的组织过程资产包括（但不限于）：

• 企业的社交媒体、道德和安全政策及程序；
• 企业的问题、风险、变更和数据管理政策及程序；
• 组织对沟通的要求；
• 制作、交换、储存和检索信息的标准化指南；
• 以往项目的历史信息，包括经验教训知识库。

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

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

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

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

见 4.3.2.2 节。项目管理信息系统能够确保相关方及时便利地获取所需信息。用来管理和分发项目信息的工具很多，包括：

• 电子项目管理工具。项目管理软件、会议和虚拟办公支持软件、网络界面、专门的项目门户网站和状态仪表盘，以及协同工作管理工具。
• 电子沟通管理。电子邮件、传真和语音邮件，音频、视频和网络会议，以及网站和网络发布。
• 社交媒体管理。网站和网络发布；以及为促进相关方参与和形成在线社区而建立博客和应用程序。

项目报告发布是收集和发布项目信息的行为。项目信息应发布给众多相关方群体。应针对每种相关方来调整项目信息发布的适当层次、形式和细节。从简单的沟通到详尽的定制报告和演示，报告的形式各不相同。可以定期准备信息或基于例外情况准备。虽然工作绩效报告是监控项目工作过程的输出，但是本过程会编制临时报告、项目演示、博客，以及其他类型的信息。

适用于本过程的人际关系与团队技能包括（但不限于）：

• 积极倾听。积极倾听技术包括告知已收到、澄清与确认信息、理解，以及消除妨碍理解的障碍。
• 冲突管理。见 9.5.2.1 节。
• 文化意识。见 10.1.2.6 节。
• 会议管理。会议管理是采取步骤确保会议有效并高效地达到预期目标。规划会议时应采取以下步骤：
• 准备并发布会议议程（其中包含会议目标）；
• 确保会议在规定的时间开始和结束；
• 确保适当参与者受邀并出席；
• 切题；
• 处理会议中的期望、问题和冲突；
• 记录所有行动以及所分配的行动责任人。
• 人际交往。人际交往是通过与他人互动交流信息，建立联系。人际交往有利于项目经理及其团队通过非正式组织解决问题，影响相关方的行动，以及提高相关方对项目工作和成果的支持，从而改善绩效。
• 政治意识。见 10.1.2.6 节。政治意识有助于项目经理在项目期间引导相关方参与，以保持相关方的支持。

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

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

• 沟通管理计划。见 10.1.3.1 节。如果本过程导致了项目沟通方法发生变更，就要把这种变更反映在项目沟通计划中。
• 相关方参与计划。见 13.2.3.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 节。项目管理计划组件包括（但不限于）：

• 资源管理计划。见 9.1.3.1 节。通过描述角色和职责，以及项目组织结构图，资源管理计划可用于理解实际的项目组织及其任何变更。
• 沟通管理计划。见 10.1.3.1 节。沟通管理计划是关于及时收集、生成和发布信息的现行计划，它确定了沟通过程中的团队成员、相关方和有关工作。
• 相关方参与计划。见 13.2.3.1 节。相关方参与计划确定了计划用以引导相关方参与的沟通策略。

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

• 问题日志。见 4.3.3.3 节。问题日志提供项目的历史信息、相关方参与问题的记录，以及它们如何得以解决。
• 经验教训登记册。见 4.4.3.1 节。在项目早期获取的经验教训可用于项目后期阶段，以改进沟通效果。
• 项目沟通记录。见 10.2.3.1 节。提供关于已开展的沟通的信息。

可能影响监督沟通过程的组织过程资产包括（但不限于）：

• 企业的社交媒体、道德和安全政策及程序；
• 组织对沟通的要求；
• 制作、交换、储存和检索信息的标准化指南；
• 以往项目的历史信息和经验教训知识库；
• 以往项目的相关方及沟通数据和信息。

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

• 与公众、社区和媒体的沟通，在国际环境中的沟通，以及虚拟小组之间的沟通；
• 沟通和项目管理系统。

见 4.3.2.2 节。项目管理信息系统为项目经理提供一系列标准化工具，以根据沟通计划为内部和外部的相关方收集、储存与发布所需的信息。应监控该系统中的信息以评估其有效性和效果。

适用于本过程的人际关系与团队技能包括（但不限于）观察和交谈（见 5.2.2.6 节）。与项目团队展开讨论和对话，有助于确定最合适的方法，用于更新和沟通项目绩效，以及回应相关方的信息请求。通过观察和交谈，项目经理能够发现团队内的问题、人员间的冲突，或个人绩效问题。

此外，应该根据对当前风险敞口的理解的加深，定期更新需求文件，并随项目进展重新排列工作优先级。

规划风险管理过程在项目构思阶段就应开始，并在项目早期完成。在项目生命周期的后期，可能有必要重新开展本过程，例如，在发生重大阶段变更时，在项目范围显著变化时，或者后续对风险管理有效性进行审查且确定需要调整项目风险管理过程时。

见 4.1.3.1 节。项目章程记录了高层级的项目描述和边界、高层级的需求和风险。

可作为本过程输入的项目文件包括（但不限于）相关方登记册（见 13.1.3.1 节）。相关方登记册包含项目相关方的详细信息，并概述其在项目中的角色和对项目风险的态度；可用于确定项目风险管理的角色和职责，以及为项目设定风险临界值。

会影响规划风险管理过程的组织过程资产包括（但不限于）：

• 组织的风险政策；
• 风险类别，可能用风险分解结构来表示；
• 风险概念和术语的通用定义；
• 风险描述的格式；
• 风险管理计划、风险登记册和风险报告的模板；
• 角色与职责；
• 决策所需的职权级别；
• 经验教训知识库，其中包含以往类似项目的信息。

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

• 熟悉组织所采取的管理风险的方法，包括该方法所在的企业风险管理体系；
• 裁剪风险管理以适应项目的具体需求；
• 在相同领域的项目上可能遇到的风险类型。

风险管理计划的编制可以是项目开工会议上的一项工作，或者可以举办专门的规划会议来编制风险管理计划。参会者可能包括项目经理、指定项目团队成员、关键相关方，或负责管理项目风险管理过程的团队成员；如果需要，也可邀请其他外部人员参加，包括客户、卖方和监管机构。熟练的会议引导者能够帮助参会者专注于会议事项，就风险管理方法的关键方面达成共识，识别和克服偏见，以及解决任何可能出现的分歧。

风险管理计划是项目管理计划的组成部分，描述如何安排与实施风险管理活动。风险管理计划可包括以下部分或全部内容：

• 风险管理战略。描述用于管理本项目的风险的一般方法。
• 方法论。确定用于开展本项目的风险管理的具体方法、工具及数据来源。
• 角色与职责。确定每项风险管理活动的领导者、支持者和团队成员，并明确他们的职责。
• 资金。确定开展项目风险管理活动所需的资金，并制定应急储备和管理储备的使用方案。
• 时间安排。确定在项目生命周期中实施项目风险管理过程的时间和频率，确定风险管理活动并将其纳入项目进度计划。
• 风险类别。确定对单个项目风险进行分类的方式。通常借助风险分解结构 (RBS)来构建风险类别。风险分解结构是潜在风险来源的层级展现（示例见图 11-4）。风险分解结构有助于项目团队考虑单个项目风险的全部可能来源，对识别风险或归类已识别风险特别有用。组织可能有适用于所有项目的通用风险分解结构，也可能针对不同类型项目使用几种不同的风险分解结构框架，或者允许项目量身定制专用的风险分解结构。如果未使用风险分解结构，组织则可能采用某种常见的风险分类框架，既可以是简单的类别清单，也可以是基于项目目标的某种类别结构。

图 11-4风险分解结构（RBS）示例

• 相关方风险偏好。应在风险管理计划中记录项目关键相关方的风险偏好。他们的风险偏好会影响规划风险管理过程的细节。特别是，应该针对每个项目目标，把相关方的风险偏好表述成可测量的风险临界值。这些临界值不仅将联合决定可接受的整体项目风险敞口水平，而且也用于制定概率和影响定义。以后将根据概率和影响定义，对单个项目风险进行评估和排序。
• 风险概率和影响定义。根据具体的项目环境，组织和关键相关方的风险偏好和临界值，来制定风险概率和影响定义。项目可能自行制定关于概率和影响级别的具体定义，或者用组织提供的通用定义作为出发点。应该根据拟开展项目风险管理过程的详细程度，来确定概率和影响级别的数量，即：更多级别（通常为五级）对应于更详细的风险管理方法，更少级别（通常为三级）对应于更简单的方法。表 11-1 针对三个项目目标提供了概率和影响定义的示例。

通过将影响定义为负面威胁（工期延误、成本增加和绩效不佳）和正面机会（工期缩短、成本节约和绩效改善），表格所示的量表可同时用于评估威胁和机会。

表 11-1概率和影响定义示例

• 概率和影响矩阵。见 11.3.2.6 节。组织可在项目开始前确定优先级排序规则，并将其纳入组织过程资产，或者也可为具体项目量身定制优先级排序规则。在常见的概率和影响矩阵中，会同时列出机会和威胁；以正面影响定义机会，以负面影响定义威胁。概率和影响可以用描述性术语（如很高、高、中、低和很低）或数值来表达。如果使用数值，就可以把两个数值相乘，得出每个风险的概率 - 影响分值，以便据此在每个优先级组别之内排列单个风险相对优先级。

图 11-5 是概率和影响矩阵的示例，其中也有数值风险评分的可能方法。

图 11-5概率和影响矩阵示例（有评分方法）

• 报告格式。确定将如何记录、分析和沟通项目风险管理过程的结果。在这一部分，描述风险登记册、风险报告以及项目风险管理过程的其他输出的内容和格式。
• 跟踪。跟踪是确定将如何记录风险活动，以及将如何审计风险的管理过程。

在整个项目生命周期中，单个项目风险可能随项目进展而不断出现，整体项目风险的级别也会发生变化。因此，识别风险是一个迭代的过程。迭代的频率和每次迭代所需的参与程度因情况而异，应在风险管理计划中做出相应规定。

见 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 节。可以查看成本基准，找出存在不确定性或模糊性的成本估算或资金需求，或者关键假设可能引发风险的方面。

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

• 假设日志。见 4.1.3.2 节。假设日志所记录的假设条件和制约因素可能引发单个项目风险，还可能影响整体项目风险的级别。
• 成本估算。见 7.2.3.1 节。成本估算是对项目成本的定量评估，理想情况下用区间表示，区间的大小预示着风险程度。对成本估算文件进行结构化审查，可能显示当前估算不足，从而引发项目风险。
• 持续时间估算。见 6.4.3.1 节。持续时间估算是对项目持续时间的定量评估，理想情况下用区间表示，区间的大小预示着风险程度。对持续时间估算文件进行结构化审查，可能显示当前估算不足，从而引发项目风险。
• 问题日志。见 4.3.3.3 节。问题日志所记录的问题可能引发单个项目风险，还可能影响整体项目风险的级别。
• 经验教训登记册。见 4.4.3.1 节。可以查看与项目早期所识别的风险相关的经验教训，以确定类似风险是否可能在项目的剩余时间再次出现。
• 需求文件。见 5.2.3.1 节。需求文件列明了项目需求，使团队能够确定哪些需求存在风险。
• 资源需求。见 9.2.3.1 节。资源需求是对项目所需资源的定量评估，理想情况下用区间表示，区间的大小预示着风险程度。对资源需求文件进行结构化审查，可能显示当前估算不足，从而引发项目风险。
• 相关方登记册。见 13.1.3.1 节。相关方登记册规定了哪些个人或小组可能参与项目的风险识别工作，还会详细说明哪些个人适合扮演风险责任人角色。

见 12.2.3.2 节。如果需要从外部采购项目资源，协议所规定的里程碑日期、合同类型、验收标准和奖罚条款等，都可能造成威胁或创造机会。

见 12.3.1.4 节。如果需要从外部采购项目资源，就应该审查初始采购文档，因为从组织外部采购商品和服务可能提高或降低整体项目风险，并可能引发更多的单个项目风险。随着采购文档在项目期间的不断更新，还应该审查最新的文档，例如，卖方绩效报告、核准的变更请求和与检查相关的信息。

会影响识别风险过程的事业环境因素包括（但不限于）：

• 已发布的材料，包括商业风险数据库或核对单；
• 学术研究资料；
• 标杆对照成果；
• 类似项目的行业研究资料。

会影响识别风险过程的组织过程资产包括（但不限于）：

• 项目文档，包括实际数据；
• 组织和项目的过程控制资料；
• 风险描述的格式；
• 以往类似项目的核对单。

见 4.1.2.1 节。应考虑了解类似项目或业务领域的个人或小组的专业意见。项目经理应该选择相关专家，邀请他们根据以往经验和专业知识来考虑单个项目风险的方方面面，以及整体项目风险的各种来源。项目经理应该注意专家可能持有的偏见。

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

• 头脑风暴。头脑风暴（见 4.1.2.2 节）的目标是获取一份全面的单个项目风险和整体项目风险来源的清单。通常由项目团队开展头脑风暴，同时邀请团队以外的多学科专家参与。可以采用自由或结构化的形式开展头脑风暴，在引导者的指引下产生各种创意。可以用风险类别（如风险分解结构）作为识别风险的框架。因为头脑风暴生成的创意并不成型，所以应该特别注意对头脑风暴识别的风险进行清晰描述。
• 核对单。核对单是包括需要考虑的项目、行动或要点的清单。它常被用作提醒。基于从类似项目和其他信息来源积累的历史信息和知识来编制核对单。编制核对单，列出过去曾出现且可能与当前项目相关的具体单个项目风险，这是吸取已完成的类似项目的经验教训的有效方式。组织可能基于自己已完成的项目来编制核对单，或者可能采用特定行业的通用风险核对单。虽然核对单简单易用，但它不可能穷尽所有风险。所以，必须确保不要用核对单来取代所需的风险识别工作；同时，项目团队也应该注意考察未在核对单中列出的事项。此外，还应该不时地审查核对单，增加新信息，删除或存档过时信息。
• 访谈。可以通过对资深项目参与者、相关方和主题专家的访谈，来识别单个项目风险以及整体项目风险的来源。应该在信任和保密的环境下开展访谈（见 5.2.2.2 节），以获得真实可信、不带偏见的意见。

项目文件中的不确定性或模糊性，以及同一文件内部或不同文件之间的不一致，都可能是项目风险的指示信号。

适用于本过程的人际关系与团队技能包括（但不限于）引导（见 4.1.2.3 节）。引导能提高用于识别单个项目风险和整体项目风险来源的许多技术的有效性。熟练的引导者可以帮助参会者专注于风险识别任务、准确遵循与技术相关的方法，有助于确保风险描述清晰、找到并克服偏见，以及解决任何可能出现的分歧。

提示清单是关于可能引发单个项目风险以及可作为整体项目风险来源的风险类别的预设清单。在采用风险识别技术时，提示清单可作为框架用于协助项目团队形成想法。可以用风险分解结构底层的风险类别作为提示清单，来识别单个项目风险。某些常见的战略框架更适用于识别整体项目风险的来源，如 PESTLE（政治、经济、社会、技术、法律、环境）、TECOP（技术、环境、商业、运营、政治），或 VUCA（易变性、不确定性、复杂性、模糊性）

为了开展风险识别工作，项目团队可能要召开专门的会议（通常称为风险研讨会）。在大多数风险研讨会中，都会开展某种形式的头脑风暴（见 4.1.2.2 节）。根据风险管理计划中对开展风险管理过程的要求，还有可能采用其他风险识别技术。配备一名经验丰富的引导者将会提高会议的有效性；确保适当的人员参加风险研讨会也至关重要。对于较大型项目，可能需要邀请项目发起人、主题专家、卖方、客户代表，或其他项目相关方参加会议；而对于较小型项目，可能仅限部分项目团队成员参加。

风险登记册记录已识别单个项目风险的详细信息。随着实施定性风险分析、规划风险应对、实施风险应对和监督风险等过程的开展，这些过程的结果也要记进风险登记册。取决于具体的项目变量（如规模和复杂性），风险登记册可能包含有限或广泛的风险信息。

当完成识别风险过程时，风险登记册的内容可能包括（但不限于）：

• 已识别风险的清单。在风险登记册中，每项单个项目风险都被赋予一个独特的标识号。要以所需的详细程度对已识别风险进行描述，确保明确理解。可以使用结构化的风险描述，来把风险本身与风险原因及风险影响区分开来。
• 潜在风险责任人。如果已在识别风险过程中识别出潜在的风险责任人，就要把该责任人记录到风险登记册中。随后将由实施定性风险分析过程进行确认。
• 潜在风险应对措施清单。如果已在识别风险过程中识别出某种潜在的风险应对措施，就要把它记录到风险登记册中。随后将由规划风险应对过程进行确认。

根据风险管理计划规定的风险登记册格式，可能还要记录关于每项已识别风险的其他数据，包括：简短的风险名称、风险类别、当前风险状态、一项或多项原因、一项或多项对目标的影响、风险触发条件（显示风险即将发生的事件或条件）、受影响的 WBS组件，以及时间信息（风险何时识别、可能何时发生、何时可能不再相关，以及采取行动的最后期限）。

风险报告提供关于整体项目风险的信息，以及关于已识别的单个项目风险的概述信息。在项目风险管理过程中，风险报告的编制是一项渐进式的工作。随着实施定性风险分析、实施定量风险分析、规划风险应对、实施风险应对和监督风险过程的完成，这些过程的结果也需要记录在风险登记册中。在完成识别风险过程时，风险报告的内容可能包括（但不限于）：

• 整体项目风险的来源。说明哪些是整体项目风险敞口的最重要驱动因素。
• 关于已识别单个项目风险的概述信息。例如，已识别的威胁与机会的数量、风险在风险类别中的分布情况、测量指标和发展趋势。

根据风险管理计划中规定的报告要求，风险报告中可能还包含其他信息。

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

• 假设日志。见 4.1.3.2 节。在识别风险过程中，可能做出新的假设，识别出新的制约因素，或者现有的假设条件或制约因素可能被重新审查和修改。应该更新假设日志，记录这些新信息。
• 问题日志。见 4.3.3.3 节。应该更新问题日志，记录发现的新问题或当前问题的变化。
• 经验教训登记册。见 4.4.3.1 节。为了改善后期阶段或其他项目的绩效，而更新经验教训登记册，记录关于行之有效的风险识别技术的信息。

实施定性风险分析能为规划风险应对过程确定单个项目风险的相对优先级。本过程会为每个风险识别出责任人，以便由他们负责规划风险应对措施，并确保应对措施的实施。如果需要开展实施定量风险分析过程，那么实施定性风险分析也能为其奠定基础。

见 4.2.3.1 节。项目管理计划组件包括风险管理计划（见 11.1.3.1 节）。本过程中需要特别注意的是风险管理的角色和职责、预算和进度活动安排，以及风险类别（通常在风险分解结构中定义）、概率和影响定义、概率和影响矩阵和相关方的风险临界值。通常已经在规划风险管理过程中把这些内容裁剪成适合具体项目的需要。如果还没有这些内容，则可以在实施定性风险分析过程中编制，并经项目发起人批准之后用于本过程。

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

• 假设日志。见 4.1.3.2 节。假设日志用于识别、管理和监督可能影响项目的关键假设条件和制约因素，它们可能影响对单个项目风险的优先级的评估。
• 风险登记册。见 11.2.3.1 节。风险登记册包括将在本过程评估的、每个已识别的单个项目风险的详细信息。
• 相关方登记册。见 13.1.3.1 节。它包括可能被指定为风险责任人的项目相关方的详细信息。

能够影响实施定性风险分析的事业环境因素包括（但不限于）：

• 类似项目的行业研究资料；
• 已发布的材料，包括商业风险数据库或核对单。

能够影响实施定性风险分析的组织过程资产包括（但不限于）已完成的类似项目的信息。

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

• 以往类似项目；
• 定性风险分析。

专家判断往往可通过引导式风险研讨会或访谈获取。应该注意专家可能持有偏见。

适用于本过程的数据收集技术包括（但不限于）访谈。结构化或半结构化的访谈（见 5.2.2.2 节）可用于评估单个项目风险的概率和影响，以及其他因素。访谈者应该营造信任和保密的访谈环境，以鼓励被访者提出诚实和无偏见的意见。

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

• 风险数据质量评估。风险数据是开展定性风险分析的基础。风险数据质量评估旨在评价关于单个项目风险的数据的准确性和可靠性。使用低质量的风险数据，可能导致定性风险分析对项目来说基本没用。如果数据质量不可接受，就可能需要收集更好的数据。可以开展问卷调查，了解项目相关方对数据质量各方面的评价，包括数据的完整性、客观性、相关性和及时性，进而对风险数据的质量进行综合评估。可以计算这些方面的加权平均数，将其作为数据质量的总体分数。
• 风险概率和影响评估。风险概率评估考虑的是特定风险发生的可能性，而风险影响评估考虑的是风险对一项或多项项目目标的潜在影响，如进度、成本、质量或绩效。威胁将产生负面的影响，机会将产生正面的影响。要对每个已识别的单个项目风险进行概率和影响评估。风险评估可以采用访谈或会议的形式，参加者将依照他们对风险登记册中所记录的风险类型的熟悉程度而定。项目团队成员和项目外部资深人员应该参加访谈或会议。在访谈或会议期间，评估每个风险的概率水平及其对每项目标的影响级别。如果相关方对概率水平和影响级别的感知存在差异，则应对差异进行探讨。此外，还应记录相应的说明性细节，例如，确定概率水平或影响级别所依据的假设条件。应该采用风险管理计划中的概率和影响定义（表11-1），来评估风险的概率和影响。低概率和影响的风险将被列入风险登记册中的观察清单，以供未来监控。
• 其他风险参数评估。为了方便未来分析和行动，在对单个项目风险进行优先级排序时，项目团队可能考虑（除概率和影响以外的）其他风险特征。此类特征可能包括（但不限于）：
• 紧迫性。为有效应对风险而必须采取应对措施的时间段。时间短就说明紧迫性高。
• 邻近性。风险在多长时间后会影响一项或多项项目目标。时间短就说明邻近性高。
• 潜伏期。从风险发生到影响显现之间可能的时间段。时间短就说明潜伏期短。
• 可管理性。风险责任人（或责任组织）管理风险发生或影响的容易程度。如果容易管理，可管理性就高。
• 可控性。风险责任人（或责任组织）能够控制风险后果的程度。如果后果很容易控制，可控性就高。
• 可监测性。对风险发生或即将发生进行监测的容易程度。如果风险发生很容易监测，可监测性就高。
• 连通性。风险与其他单个项目风险存在关联的程度大小。如果风险与多个其他风险存在关联，连通性就高。
• 战略影响力。风险对组织战略目标潜在的正面或负面影响。如果风险对战略目标有重大影响，战略影响力就大。
• 密切度。风险被一名或多名相关方认为要紧的程度。被认为很要紧的风险，密切度就高。

相对于仅评估概率和影响，考虑上述某些特征有助于进行更稳健的风险优先级排序。

适用于本过程的人际关系与团队技能包括（但不限于）引导（见 4.1.2.3 节）。开展引导，能够提高对单个项目风险的定性分析的有效性。熟练的引导者可以帮助参会者专注于风险分析任务、准确遵循与技术相关的方法、就概率和影响评估达成共识、找到并克服偏见，以及解决任何可能出现的分歧。

项目风险可依据风险来源（如采用风险分解结构 [RBS]，见图 11-4）、受影响的项目领域（如采用工作分解结构 [WBS]，见图 5-12、5-13 和 5-14），以及其他实用类别（如项目阶段、项目预算、角色和职责）来分类，确定哪些项目领域最容易被不确定性影响；风险还可以根据共同的根本原因进行分类。应该在风险管理计划中规定可用于项目的风险分类方法。

组织可针对每个项目目标（如成本、时间和范围）制定单独的概率和影响矩阵，并用它们来评估风险针对每个目标的优先级别。组织还可以用不同的方法为每个风险确定一个总体优先级别。即可综合针对不同目标的评估结果，也可采用最高优先级别（无论针对哪个目标），作为风险的总体优先级别。

要开展定性风险分析，项目团队可能要召开专门会议（通常称为风险研讨会），对已识别单个项目风险进行讨论。会议的目标包括审查已识别的风险、评估概率和影响（及其他可能的风险参数）、对风险进行分类和优先级排序。在实施定性风险分析过程中，要逐一为单个项目风险分配风险责任人。

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

• 假设日志。见 4.1.3.2 节。在实施定性风险分析过程中，可能做出新的假设、识别出新的制约因素，或者现有的假设条件或制约因素可能被重新审查和修改。应该更新假设日志，应记录这些新信息。
• 问题日志。见 4.3.3.3 节。应该更新问题日志，记录发现的新问题或当前问题的变化。
• 风险登记册。见 11.2.3.1 节。用实施定性风险分析过程生成的新信息，去更新风险登记册。

风险登记册的更新内容可能包括：每项单个项目风险的概率和影响评估、优先级别或风险分值、指定风险责任人、风险紧迫性信息或风险类别，以及低优先级风险的观察清单或需要进一步分析的风险。

• 风险报告。见 11.2.3.2 节。更新风险报告，记录最重要的单个项目风险（通常为概率和影响最高的风险）、所有已识别风险的优先级列表以及简要的结论。

实施定量风险分析过程的输出，则要用作规划风险应对过程的输入，特别是要据此为整体项目风险和关键单个项目风险推荐应对措施。定量风险分析也可以在规划风险应对过程之后开展，以分析已规划的应对措施对降低整体项目风险敞口的有效性。

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

• 风险管理计划。见 11.1.3.1 节。风险管理计划确定项目是否需要定量风险分析，还会详述可用于分析的资源，以及预期的分析频率。
• 范围基准。见 5.4.3.1 节。范围基准提供了对单个项目风险和其他不确定性来源的影响开展评估的起始点。
• 进度基准。见 6.5.3.1 节。进度基准提供了对单个项目风险和其他不确定性来源的影响开展评估的起始点。
• 成本基准。见 7.3.3.1 节。成本基准提供了对单个项目风险和其他不确定性来源的影响开展评估的起始点。

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

• 假设日志。见 4.1.3.2 节。如果认为假设条件会引发项目风险，那么就应该把它们列作定量风险分析的输入。在定量风险分析期间，也可以建立模型来分析制约因素的影响。
• 估算依据。见 6.4.3.2 节和 7.2.3.2 节。开展定量风险分析时，可以把用于项目规划的估算依据反映在所建立的变异性模型中。可能包括估算目的、分类、准确性、方法论和资料来源。
• 成本估算。见 7.2.3.1 节。成本估算提供了对成本变化性进行评估的起始点。
• 成本预测。见 7.4.3.2 节。成本预测包括项目的完工尚需估算 (ETC)、完工估算 (EAC)、完工预算(BAC) 和完工尚需绩效指数（TCP）。把这些预测指标与定量成本风险分析的结果进行比较，以确定与实现这些指标相关的置信水平。
• 持续时间估算。见 6.4.3.1 节。持续时间估算提供了对进度变化性进行评估的起始点。
• 里程碑清单。见 6.2.3.3 节。项目的重大事件决定着进度目标。把这些进度目标与定量进度风险分析的结果进行比较，以确定与实现这些目标相关的置信水平。
• 资源需求。见 9.2.3.1 节。资源需求提供了对变化性进行评估的起始点。
• 风险登记册。见 11.2.3.1 节。风险登记册包含了用作定量风险分析的输入的单个项目风险的详细信息。
• 风险报告。见 11.2.3.2 节。风险报告描述了整体项目风险的来源，以及当前的整体项目风险状态。
• 进度预测。见 6.6.3.2 节。可以将预测与定量进度风险分析的结果进行比较，以确定与实现预测目标相关的置信水平。

能够影响实施定量风险分析过程的事业环境因素包括（但不限于）：

• 类似项目的行业研究资料；
• 已发布的材料，包括商业风险数据库或核对单。

能够影响实施定量风险分析过程的组织过程资产包括已完成的类似项目的信息。

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

• 将单个项目风险和其他不确定性来源的信息转化成用于定量风险分析模型的数值输入；
• 选择最适当的方式表示不确定性，以便为特定风险或其他不确定性来源建立模型；
• 用适合项目环境的技术建立模型；
• 识别最适用于所选建模技术的工具；
• 解释定量风险分析的输出。

访谈（见 5.2.2.2 节）可用于针对单个项目风险和其他不确定性来源，生成定量风险分析的输入。

适用于本过程的人际关系与团队技能包括（但不限于）引导（见 4.1.2.3 节）。在由项目团队成员和其他相关方参加的专门风险研讨会中，配备一名熟练的引导者，有助于更好地收集输入数据。

其他不确定性来源也可用概率分支来表示，以描述贯穿项目的其他路径。

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

• 模拟。在定量风险分析中，使用模型来模拟单个项目风险和其他不确定性来源的综合影响，以评估它们对项目目标的潜在影响。模拟通常采用蒙特卡洛分析。对成本风险进行蒙特卡洛分析时，使用项目成本估算作为模拟的输入；对进度风险进行蒙特卡洛分析时，使用进度网络图和持续时间估算作为模拟的输入。开展综合定量成本-进度风险分析时，同时使用这两种输入。

其输出就是定量风险分析模型。

用计算机软件数千次迭代运行定量风险分析模型。每次运行，都要随机选择输入值（如成本估算、持续时间估算或概率分支发生频率）。这些运行的输出构成了项目可能结果（如项目结束日期、项目完工成本）的区间。典型的输出包括：表示模拟得到特定结果的次数的直方图，或表示获得等于或小于特定数值的结果的累积概率分布曲线（S 曲线）。蒙特卡洛成本风险分析所得到的 S 曲线示例，见图11-13。

图 11-13定量成本风险分析 S 曲线示例

在定量进度风险分析中，还可以执行关键性分析，以确定风险模型的哪些活动对项目关键路径的影响最大。对风险模型中的每一项活动计算关键性指标，即：在全部模拟中，该活动出现在关键路径上的频率，通常以百分比表示。通过关键性分析，项目团队就能够重点针对那些对项目整体进度绩效存在最大潜在影响的活动，来规划风险应对措施。

• 敏感性分析。敏感性分析有助于确定哪些单个项目风险或其他不确定性来源对项目结果具有最大的潜在影响。它在项目结果变异与定量风险分析模型中的要素变异之间建立联系。

敏感性分析的结果通常用龙卷风图来表示。在该图中，标出定量风险分析模型中的每项要素与其能影响的项目结果之间的关联系数。这些要素可包括单个项目风险、易变的项目活动，或具体的不明确性来源。每个要素按关联强度降序排列，形成典型的龙卷风形状。龙卷风图示例，见图11-14。

图 11-14龙卷风图示例

• 决策树分析。用决策树在若干备选行动方案中选择一个最佳方案。在决策树中，用不同的分支代表不同的决策或事件，即项目的备选路径。每个决策或事件都有相关的成本和单个项目风险（包括威胁和机会）。决策树分支的终点表示沿特定路径发展的最后结果，可以是负面或正面的结果。

在决策树分析中，通过计算每条分支的预期货币价值，就可以选出最优的路径。决策树示例，见图11-15。

图 11-15决策树示例

• 影响图。影响图是不确定条件下决策制定的图形辅助工具。它将一个项目或项目中的一种情境表现为一系列实体、结果和影响，以及它们之间的关系和相互影响。如果因为存在单个项目风险或其他不确定性来源而使影响图中的某些要素不确定，就在影响图中以区间或概率分布的形式表示这些要素；然后，借助模拟技术（如蒙特卡洛分析）来分析哪些要素对重要结果具有最大的影响。影响图分析，可以得出类似于其他定量风险分析的结果，如 S 曲线图和龙卷风图。

可作为本过程输出的项目文件包括（但不限于）风险报告（见 11.2.3.2 节）。更新风险报告，反映定量风险分析的结果，通常包括：

• 对整体项目风险敞口的评估结果。整体项目风险有两种主要的测量方式：
• 项目成功的可能性。基于已识别的单个项目风险和其他不确定性来源，项目实现其主要目标（例如，既定的结束日期或中间里程碑、既定的成本目标）的概率。
• 项目固有的变异性。在开展定量分析之时，可能的项目结果的分布区间。
• 项目详细概率分析的结果。列出定量风险分析的重要输出，如 S 曲线、龙卷风图和关键性指标，以及对它们的叙述性解释。定量风险分析的详细结果可能包括：
• 所需的应急储备，以达到实现目标的特定置信水平；
• 对项目关键路径有最大影响的单个项目风险或其他不确定性来源的清单；
• 整体项目风险的主要驱动因素，即：对项目结果的不确定性有最大影响的因素。
• 单个项目风险优先级清单。根据敏感性分析的结果，列出对项目造成最大威胁或产生最大机会的单个项目风险。
• 定量风险分析结果的趋势。随着在项目生命周期的不同时间重复开展定量风险分析，风险的发展趋势可能逐渐清晰。发展趋势会影响对风险应对措施的规划。
• 风险应对建议。风险报告可能根据定量风险分析的结果，针对整体项目风险敞口或关键单个项目风险提出应对建议。这些建议将成为规划风险应对过程的输入。

风险应对方案应该与风险的重要性相匹配、能经济有效地应对挑战、在当前项目背景下现实可行、能获得全体相关方的同意，并由一名责任人具体负责。往往需要从几套可选方案中选出最优的风险应对方案。应该为每个风险选择最可能有效的策略或策略组合。可用结构化的决策技术来选择最适当的应对策略。对于大型或复杂项目，可能需要以数学优化模型或实际方案分析为基础，进行更加稳健的备选风险应对策略经济分析。

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

• 资源管理计划。见 9.1.3.1 节。资源管理计划有助于确定该如何协调用于风险应对的资源和其他项目资源。
• 风险管理计划。见 11.1.3.1 节。本过程会用到其中的风险管理角色和职责，以及风险临界值。
• 成本基准。见 7.3.3.1 节。成本基准包含了拟用于风险应对的应急资金的信息。

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

• 经验教训登记册。见 4.4.3.1 节。查看关于项目早期的风险应对的经验教训，确定类似的应对是否适用于项目后期。
• 项目进度计划。见 6.5.3.2 节。进度计划可用于确定如何同时规划商定的风险应对活动和其他项目活动。
• 项目团队派工单。见 9.3.3.2 节。项目团队派工单列明了可用于风险应对的人力资源。
• 资源日历。见 9.2.1.2 节。资源日历确定了潜在的资源何时可用于风险应对。
• 风险登记册。见 11.2.3.1 节。风险登记册包含了已识别并排序的、需要应对的单个项目风险的详细信息。每项风险的优先级有助于选择适当的风险应对措施。例如，针对高优先级的威胁或机会，可能需要采取优先措施和积极主动的应对策略；而针对低优先级的威胁和机会，可能只需要把它们列入风险登记册的观察清单部分，或者只需要为之增加应急储备，而不必采取主动的管理措施。

风险登记册列出了每项风险的指定风险责任人，还可能包含在早期的项目风险管理过程中识别的初步风险应对措施。风险登记册可能还会提供有助于规划风险应对的、关于已识别风险的其他信息，包括根本原因、风险触发因素和预警信号、需要在短期内应对的风险，以及需要进一步分析的风险。

• 风险报告。见 11.2.3.2 节。风险报告中的项目整体风险敞口的当前级别，会影响选择适当的风险应对策略。风险报告也可能按优先级顺序列出了单个项目风险，并对单个项目风险的分布情况进行了更多分析；这些信息都会影响风险应对策略的选择。
• 相关方登记册。见 13.1.3.1 节。相关方登记册列出了风险应对的潜在责任人。

能够影响规划风险应对过程的组织过程资产包括（但不限于）：

• 风险管理计划、风险登记册和风险报告的模板；
• 历史数据库；
• 类似项目的经验教训知识库。

可以就具体单个项目风险向特定主题专家征求意见，例如在需要专家的技术知识时。

适用于本过程的数据收集技术包括（但不限于）访谈（见 5.2.2.2 节）。单个项目风险和整体项目风险的应对措施可以在与风险责任人的结构化或半结构化的访谈（见 5.2.2.2 节）中制定。必要时，也可访谈其他相关方。访谈者应该营造信任和保密的访谈环境，以鼓励被访者提出诚实和无偏见的意见。

适用于本过程的人际关系与团队技能包括（但不限于）引导（见 4.1.2.3 节）。开展引导，能够提高单个项目风险和整体项目风险应对策略制定的有效性。熟练的引导者可以帮助风险责任人理解风险、识别并比较备选的风险应对策略、选择适当的应对策略，以及找到并克服偏见。

风险责任人也可以采取措施，来分离项目目标与风险万一发生的影响。规避措施可能包括消除威胁的原因、延长进度计划、改变项目策略，或缩小范围。有些风险可以通过澄清需求、获取信息、改善沟通或取得专有技能来加以规避。

针对机会，可以考虑下列五种备选策略：

• 上报。如果项目团队或项目发起人认为某机会不在项目范围内，或提议的应对措施超出了项目经理的权限，就应该取用上报策略。被上报的机会将在项目集层面、项目组合层面或组织的其他相关部门加以管理，而不在项目层面。项目经理确定应就机会通知哪些人员，并向该人员或组织部门传达关于该机会的详细信息。对于被上报的机会，组织中的相关人员必须愿意承担应对责任，这一点非常重要。机会通常要上报给其目标会受该机会影响的那个层级。

机会一旦上报，就不再由项目团队做进一步监督，虽然仍可出现在风险登记册中供参考。

• 开拓。如果组织想确保把握住高优先级的机会，就可以选择开拓策略。此策略将特定机会的出现概率提高到 100%，确保其肯定出现，从而获得与其相关的收益。开拓措施可能包括：把组织中最有能力的资源分配给项目来缩短完工时间，或采用全新技术或技术升级来节约项目成本并缩短项目持续时间。
• 分享。分享涉及到将应对机会的责任转移给第三方，使其享有机会所带来的部分收益。必须仔细为已分享的机会安排新的风险责任人，让那些最有能力为项目抓住机会的人担任新的风险责任人。采用风险分享策略，通常需要向承担机会应对责任的一方支付风险费用。分享措施包括建立合伙关系、合作团队、特殊公司或合资企业来分享机会。
• 提高。提高策略用于提高机会出现的概率和（或）影响。提前采取提高措施通常比机会出现后尝试改善收益更加有效。通过关注其原因，可以提高机会出现的概率；如果无法提高概率，也许可以针对决定其潜在收益规模的因素来提高机会发生的影响。机会提高措施包括为早日完成活动而增加资源。
• 接受。接受机会是指承认机会的存在，但不主动采取措施。此策略可用于低优先级机会，也可用于无法以任何其他方式加以经济有效地应对的机会。接受策略又分为主动或被动方式。