PMBOK/PMP 项目文件

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

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

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

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

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

项目经理需要确保项目管理方法紧扣商业文件的意图。表 1-5 列出了这些文件的定义。在整个项目生命周期中，这两种文件相互依赖并得到反复制定和维护。

表 1-5项目商业文件

项目发起人通常负责项目商业论证文件的制定和维护。项目经理负责提供建议和见解，使项目商业论证、项目管理计划、项目章程和项目效益管理计划中的成功标准相一致，并与组织的目的和目标保持一致。

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

图 1-8需求评估与关键业务/项目文件的相互关系

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

启动和规划
- 指南和标准，用于裁剪组织标准流程和程序以满足项目的特定要求；
- 特定的组织标准，例如政策（如人力资源政策、健康与安全政策、安保与保密政策、质量政策、采购政策和环境政策）；
- 产品和项目生命周期，以及方法和程序（如项目管理方法、评估指标、过程审计、改进目标、核对单、组织内使用的标准化的过程定义）；
- 模板（如项目管理计划、项目文件、项目登记册、报告格式、合同模板、风险分类、风险描述模板、概率与影响的定义、概率和影响矩阵，以及相关方登记册模板）；
- 预先批准的供应商清单和各种合同协议类型（如总价合同、成本补偿合同和工料合同）。
执行、监控：

变更控制程序，包括修改组织标准、政策、计划和程序（或任何项目文件）所须遵循的步骤，以及如何批准和确认变更；
跟踪矩阵；
财务控制程序（如定期报告、必需的费用与支付审查、会计编码及标准合同条款等）；
问题与缺陷管理程序（如定义问题和缺陷控制、识别与解决问题和缺陷，以及跟踪行动方案）。
资源的可用性控制和分配管理；
组织对沟通的要求（如可用的沟通技术、许可的沟通媒介、记录保存政策、视频会议、协同工具和安全要求）；
确定工作优先顺序、批准工作与签发工作授权的程序；
模板（如风险登记册、问题日志和变更日志）；
标准化的指南、工作指示、建议书评价准则和绩效测量准则；
产品、服务或成果的核实和确认程序。

收尾项目收尾指南或要求（如项目终期审计、项目评价、可交付成果验收、合同收尾、资源分配，以及向生产和（或）运营部门转移知识）

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

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

项目整合管理包括对隶属于项目管理过程组的各种过程和项目管理活动进行识别、定义、组合、统一和协调的各个过程。在项目管理中，整合兼具统一、合并、沟通和建立联系的性质，这些行动应该贯穿项目始终。项目整合管理包括进行以下选择：

资源分配；
平衡竞争性需求；
研究各种备选方法；
为实现项目目标而裁剪过程；
管理各个项目管理知识领域之间的依赖关系。

项目整合管理过程包括：

4.1 制定项目章程 — 编写一份正式批准项目并授权项目经理在项目活动中使用组织资源的文件的过程。

4.2 制定项目管理计划 — 定义、准备和协调项目计划的所有组成部分，并把它们整合为一份综合项目管理计划的过程。

4.3 指导与管理项目工作 — 为实现项目目标而领导和执行项目管理计划中所确定的工作，并实施已批准变更的过程。

4.4 管理项目知识 — 使用现有知识并生成新知识，以实现项目目标，并且帮助组织学习的过程。

4.5 监控项目工作 — 跟踪、审查和报告整体项目进展，以实现项目管理计划中确定的绩效目标的过程。

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

4.7 结束项目或阶段 — 终结项目、阶段或合同的所有活动的过程。

图 4-1 概述了项目整合管理的各个过程。虽然在本《PMBOK® 指南》中，各项目整合管理过程

以界限分明和相互独立的形式出现，但在实践中它们会以本指南无法全面详述的方式相互交叠和相互作用。

图 4-1项目整合管理概述

项目整合管理的核心概念项目整合管理由项目经理负责。虽然其他知识领域可以由相关专家（如成本分析专家、进度规划专家、风险管理专家）管理，但是项目整合管理的责任不能被授权或转移。只能由项目经理负责整合所有其他知识领域的成果，并掌握项目总体情况。项目经理必须对整个项目承担最终责任。

项目与项目管理本质上具有整合性质，例如，为应急计划制定成本估算时，就需要整合项目成本管理、项目进度管理和项目风险管理知识领域中的相关过程。在识别出与各种人员配备方案有关的额外风险时，可能需要再次进行上述某个或某几个过程。

项目管理过程组的各个过程之间经常反复发生联系。例如，在项目早期，规划过程组为执行过程组提供书面的项目管理计划；然后，随着项目的进展，规划过程组还将根据变更情况，更新项目管理计划。

项目整合管理指的是：

确保产品、服务或成果的交付日期，项目生命周期以及效益管理计划这些方面保持一致；
编制项目管理计划以实现项目目标；
确保创造合适的知识并运用到项目中，并从项目中获取必要的知识；
管理项目管理计划中活动的绩效和变更；
做出针对影响项目的关键变更的综合决策；
测量和监督项目进展，并采取适当措施以实现项目目标；
收集关于已达成结果的数据，分析数据以获取信息，并与相关方分享信息；
完成全部项目工作，正式关闭各个阶段、合同以及整个项目；
管理可能需要的阶段过渡。

项目越复杂，相关方的期望越多样化，就需要越全面的整合方法。

项目整合管理的发展趋势和新兴实践项目整合管理知识领域要求整合所有其他知识领域的成果。与整合管理过程相关的发展趋势包括（但不限于）：

使用自动化工具。项目经理需要整合大量的数据和信息，因此有必要使用项目管理信息系统(PMIS) 和自动化工具来收集、分析和使用信息，以实现项目目标和项目效益。
使用可视化管理工具。有些项目团队使用可视化管理工具，而不是书面计划和其它文档，来获取和监督关键的项目要素。这样，就便于整个团队直观地看到项目的实时状态，促进知识转移，并提高团队成员和其他相关方识别和解决问题的能力。
项目知识管理。项目人员的流动性和不稳定性越来越高，就要求采用更严格的过程，在整个项目生命周期中积累知识并传达给目标受众，以防止知识流失。
增加项目经理的职责。项目经理被要求介入启动和结束项目，例如开展项目商业论证和效益管理。按照以往的惯例，这些事务均由管理层和项目管理办公室负责。现在，项目经理需要频繁地与他们合作处理这些事务，以便更好地实现项目目标以及交付项目效益。项目经理也需要更全面地识别相关方，并引导他们参与项目，包括管理项目经理与各职能部门、运营部门和高级管理人员之间的接口。
混合型方法。经实践检验的新做法会不断地融入项目管理方法，例如，采用敏捷或其他迭代做法，为开展需求管理而采用商业分析技术，为分析项目复杂性而采用相关工具，以及为在组织中应用项目成果而采用组织变革管理方法。

裁剪时需要考虑的因素因为每个项目都是独特的，所以项目经理可能需要裁剪项目整合管理过程。裁剪时应考虑的因素包括（但不限于）：

项目生命周期。什么是合适的项目生命周期？项目生命周期应包括哪些阶段？
开发生命周期。对特定产品、服务或成果而言，什么是合适的开发生命周期和开发方法？预测型或适应型方法是否适当？如果是适应型，开发产品是该采用增量还是迭代的方式？混合型方法是否为最佳选择？
管理方法。考虑到组织文化和项目的复杂性，哪种管理过程最有效？
知识管理。在项目中如何管理知识以营造合作的工作氛围？
变更。在项目中如何管理变更？
治理。有哪些监控机构、委员会和其他相关方该参与项目治理？对项目状态报告的要求是什么？
经验教训。在项目期间及项目结束时，应收集哪些信息？历史信息和经验教训是否适用于未来的项目？
效益。应该在何时以何方式报告效益：在项目结束时还是在每次迭代或阶段结束时？

在敏捷或适应型环境中需要考虑的因素迭代和敏捷方法能够促进团队成员以相关领域专家的身份参与整合管理。团队成员自行决定计划及其组件的整合方式。

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

在商业论证（见 1.2.6.1 节）和效益管理计划（见 1.2.6.2 节）中，可以找到关于项目目标以及项目对业务目标的贡献的相关信息。虽然商业文件是在项目之前制定的，但需要定期审核。

商业论证。经批准的商业论证或类似文件是最常用于制定项目章程的商业文件。商业论证从商业视角描述必要的信息，并且据此决定项目的期望结果是否值得所需投资。高于项目级别的经理和高管们通常使用该文件作为决策的依据。一般情况下，商业论证会包含商业需求和成本效益分析，以论证项目的合理性并确定项目边界。关于商业论证的更多信息，请见 1.2.6.1 节。

商业论证的编制可由以下一个或多个因素引发：

市场需求（例如，为应对汽油紧缺，某汽车制造商批准一个低油耗车型的研发项目）；
组织需要（例如，因为管理费用太高，公司决定合并一些职能并优化流程以降低成本）；
客户要求（例如，为了给新工业园区供电，某电力公司批准一个新变电站建设项目）；
技术进步（例如，基于技术进步，某航空公司批准了一个新项目，来开发电子机票以取代纸质机票）；
法律要求（例如，某油漆制品厂批准一个项目，来编写有毒物质处理指南）；
生态影响（例如，某公司批准一个项目，来降低对环境的影响）；
社会需要（例如，为应对霍乱频发，某发展中国家的非政府组织批准一个项目，为社区建设饮用水系统和公共厕所，并开展卫生教育）。

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

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

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

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

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

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

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

项目管理计划是说明项目执行、监控和收尾方式的一份文件，它整合并综合了所有子管理计划和基准，以及管理项目所需的其他信息。究竟需要哪些项目管理计划组件，取决于具体项目的需求。

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

子管理计划：
范围管理计划。见 5.1.3.1 节。确立如何定义、制定、监督、控制和确认项目范围。
需求管理计划。见 5.1.3.2 节。确定如何分析、记录和管理需求。
进度管理计划。见 6.1.3.1 节。为编制、监督和控制项目进度建立准则并确定活动。
成本管理计划。见 7.1.3.1 节。确定如何规划、安排和控制成本。
质量管理计划。见 8.1.3.1 节。确定在项目中如何实施组织的质量政策、方法和标准。
资源管理计划。见 9.1.3.1 节。指导如何对项目资源进行分类、分配、管理和释放。
沟通管理计划。见 10.1.3.1 节。确定项目信息将如何、何时、由谁来进行管理和传播。
风险管理计划。见 11.1.3.1 节。确定如何安排与实施风险管理活动。
采购管理计划。见 12.1.3.1 节。确定项目团队将如何从执行组织外部获取货物和服务。
相关方参与计划。见 13.2.3.1 节。确定如何根据相关方的需求、利益和影响让他们参与项目决策和执行。
基准：
范围基准。见 5.4.3.1 节。经过批准的范围说明书、工作分解结构 (WBS) 和相应的 WBS 词典，用作比较依据。
进度基准。见 6.5.3.1 节。经过批准的进度模型，用作与实际结果进行比较的依据。
成本基准。见 7.3.3.1 节。经过批准的、按时间段分配的项目预算，用作与实际结果进行比较的依据。
其他组件。大多数项目管理计划组件都来自于其他过程，虽然有些组件是在本过程生成的。

虽然在本过程生成的组件会因项目而异，但是通常包括（但不限于）：

变更管理计划。描述在整个项目期间如何正式审批和采纳变更请求。
配置管理计划。描述如何记录和更新项目的特定信息，以及该记录和更新哪些信息，以保持产品、服务或成果的一致性和（或）有效性。
绩效测量基准。经过整合的项目范围、进度和成本计划，用作项目执行的比较依据，以测量和管理项目绩效。
项目生命周期。描述项目从开始到结束所经历的一系列阶段。
开发方法。描述产品、服务或成果的开发方法，例如预测、迭代、敏捷或混合型模式。
管理审查。确定项目经理和有关相关方审查项目进展的时间点，以考核绩效是否符合预期，或者确定是否有必要采取预防或纠正措施。

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

表 4-1项目管理计划和项目文件

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

在整个项目生命周期中，项目经理通常会遇到问题、差距、不一致或意外冲突。项目经理需要采取某些行动加以处理，以免影响项目绩效。问题日志是一种记录和跟进所有问题的项目文件，所需记录和跟进的内容可能包括：

问题类型；
问题提出者和提出时间；
问题描述；
问题优先级；
由谁负责解决问题；
目标解决日期；
问题状态；
最终解决情况。

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

变更请求是关于修改任何文件、可交付成果或基准的正式提议。如果在开展项目工作时发现问题，就可提出变更请求，对项目政策或程序、项目或产品范围、项目成本或预算、项目进度计划、项目或产品结果的质量进行修改。其他变更请求包括必要的预防措施或纠正措施，用来防止以后的不利后果。任何项目相关方都可以提出变更请求，应该通过实施整体变更控制过程（见 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.3.3.4 节。通过比较实际情况与计划要求，可能需要提出变更请求，来扩大、调整或缩小项目范围与产品范围，或者提高、调整或降低质量要求和进度或成本基准。变更请求可能导致需要收集和记录新的需求。变更可能会影响项目管理计划、项目文件或产品可交付成果。应该通过实施整体变更控制过程（见 4.6 节）对变更请求进行审查和处理。变更可能包括（但不限于）：

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

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

成本预测。见 7.4.3.2 节。本过程引起的成本预测的变更应通过成本管理过程进行记录。
问题日志。见 4.3.3.3 节。在本过程中产生的新问题应该记录到问题日志中。
经验教训登记册。见 4.4.3.1 节。更新经验教训登记册，记录应对偏差的有效方式以及纠正措施和预防措施。
风险登记册。见 11.2.3.1 节。在本过程中识别的新风险应记录在风险登记册中，并通过风险管理过程进行管理。
进度预测。见 6.6.3.2 节。本过程引起的进度预测的变更应通过进度管理过程进行记录。

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

图 4-12实施整体变更控制：输入、工具与技术和输出

图 4-13实施整体变更控制：数据流向图

实施整体变更控制过程贯穿项目始终，项目经理对此承担最终责任。变更请求可能影响项目范围、产品范围以及任一项目管理计划组件或任一项目文件。在整个项目生命周期的任何时间，参与项目的任何相关方都可以提出变更请求。变更控制的实施程度，取决于项目所在应用领域、项目复杂程度、合同要求，以及项目所处的背景与环境。

在基准确定之前，变更无需正式受控于实施整体变更控制过程。一旦确定了项目基准，就必须通过本过程来处理变更请求。依照常规，每个项目的配置管理计划应规定哪些项目工件受控于配置控制程序。对配置要素的任何变更都应该提出变更请求，并经过正式控制。

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

变更请求得到批准后，可能需要新编（或修订）成本估算、活动排序、进度日期、资源需求和（或）风险应对方案分析，这些变更可能要求调整项目管理计划和其他项目文件。某些特定的变更请求，在 CCB 批准之后，可能还需要得到客户或发起人的批准，除非他们本身就是 CCB 的成员。

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

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

能够影响实施整体变更控制过程的组织过程资产包括（但不限于）：

变更控制程序，包括修改组织标准、政策、计划和程序（或任一项目文件）所须遵循的步骤，以及如何批准和确认变更；
批准与签发变更的程序；
配置管理知识库，包括组织标准、政策、程序和项目文件的各种版本及基准。

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

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

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

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

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

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

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

以项目文件更新的形式，在变更日志中记录所有变更请求的处理情况。

正式受控的任一项目文件都可在本过程变更，通常在本过程更新的一种项目文件是变更日志。

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

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

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

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

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

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

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

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

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

假设日志。见 4.1.3.2 节。随同本过程识别出更多的假设条件或制约因素而更新假设日志。
需求文件。见 5.2.3.1 节。可以通过增加或修改需求而更新需求文件。
需求跟踪矩阵。见 5.2.3.2 节。应该随同需求文件的更新而更新需求跟踪矩阵。
相关方登记册。见 13.1.3.1 节。如果在本过程中收集到了现有或新相关方的更多信息，则记录到相关方登记册中。

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

假设日志。见 4.1.3.2 节。随同本过程识别出更多的假设条件或制约因素而更新假设日志。
需求文件。见 5.2.3.1 节。可以更新需求文件，以反映在本过程提出并已被批准的变更。

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

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

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

经验教训登记册。见 4.4.3.1 节。更新经验教训登记册，以记录控制范围的有效技术，以及造成偏差的原因和选择的纠正措施。
需求文件。见 5.2.3.1 节。可以通过增加或修改需求而更新需求文件。
需求跟踪矩阵。见 5.2.3.2 节。应该随同需求文件的更新而更新需求跟踪矩阵。

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

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

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

活动属性。见 6.2.3.2 节。本过程输出的活动持续时间估算将记录在活动属性中。
假设日志。见 4.1.3.2 节。这包括为估算持续时间而制定的假设条件，如资源的技能水平、可用性，以及估算依据，此外还记录了进度计划方法论和进度计划编制工具所带来的制约因素。
经验教训登记册。见 4.4.3.1 节。在更新经验教训登记册时，可以增加能够有效和高效地估算人力投入和持续时间的技术。

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

活动属性。见 6.2.3.2 节。更新活动属性以反映在制定进度计划过程中所产生的对资源需求和其他相关内容的修改。
假设日志。见 4.1.3.2 节。可能需要更新假设日志，以反映创建进度模型时发现的有关持续时间、资源使用、排序或其他信息的假设条件的变更。
持续时间估算。见 6.4.3.1 节。资源的数量和可用性以及活动依赖关系可能会引起持续时间估算的变更。如果资源平衡分析改变了资源需求，就可能需要对持续时间估算做出相应的更新。
经验教训登记册。见 4.4.3.1 节。在更新经验教训登记册时，可以增加能够有效和高效制定进度模型的技术。
资源需求。见 9.2.3.1 节。资源平衡可能对所需资源类型与数量的初步估算产生显著影响。如果资源平衡分析改变了资源需求，就需要对资源需求做出相应的更新。
风险登记册。见 11.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.2 节。在成本估算过程中可能会做出新的假设、识别新的制约因素，或者重新审查和修改已有的假设条件或制约因素。假设日志应根据这些新信息做出相应更新。
经验教训登记册。见 4.4.3.1 节。有效和高效地估算成本的技术，需要更新在经验教训登记册中。
风险登记册。见 11.2.3.1 节。在估算成本过程中选择和商定风险应对措施时，可能需要更新风险登记册。

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

成本估算。见 7.2.3.1 节。更新成本估算，以记录任何额外信息。
项目进度计划。见 6.5.3.2 节。项目进度计划可能记录了各项活动的估算成本。
风险登记册。见 11.2.3.1 节。记录在本过程中识别的新风险于风险登记册中，并通过风险管理过程进行管理。

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

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

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

经验教训登记册。见 4.4.3.1 节。在质量规划过程中遇到的挑战需要更新在经验教训登记册中。
需求跟踪矩阵。见 5.2.3.2 节。本过程指定的质量要求，记录在需求跟踪矩阵中。
风险登记册。见 11.2.3.1 节。在本过程中识别的新风险记录在风险登记册中，并通过风险管理过程进行管理。
相关方登记册。见 13.1.3.1 节。如果在本过程中收集到有关现有或新相关方的其他信息，则记录到相关方登记册中。

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

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

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

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

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

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

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

假设日志。见 4.1.3.2 节。更新假设日志时可增加关于实物资源的可用性、物流要求和位置信息以及团队资源的技能集和可用性的假设条件。
风险登记册。见 11.2.3.1 节。关于团队和实物资源可用性的风险，以及其他已知资源的相关风险，更新在风险登记册中。

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

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

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

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

经验教训登记册。见 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.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.3.3.4 节。如果管理团队过程中出现变更请求，或者推荐措施、纠正措施或预防措施影响了项目管理计划的任何组成部分或项目文件，项目经理应提交变更请求。并通过实施整体变更控制过程（见 4.6 节）对变更请求进行审查和处理。

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

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

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

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

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

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

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

项目进度计划。见 6.5.3.2 节。可能需要更新项目进度计划，以反映沟通活动。
相关方登记册。见 13.1.3.1 节。可能需要更新相关方登记册，以反映计划好的沟通。

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

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

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

问题日志。见 4.3.3.3 节。可能需要更新问题日志，记录与出现的问题及其处理进展和解决办法相关的新信息。
经验教训登记册。见 4.4.3.1 节。可能需要更新经验教训登记册，记录问题的原因、所选纠正措施的理由，以及其他与沟通有关的经验教训。
相关方登记册。见 13.1.3.1 节。可能需要更新相关方登记册，加入修订的相关方沟通要求。

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

根本原因分析。根本原因分析（见 8.2.2.2 节）常用于发现导致问题的深层原因并制定预防措施。可以用问题陈述（如项目可能延误或超支）作为出发点，来探讨哪些威胁可能导致该问题，从而识别出相应的威胁。也可以用收益陈述（如提前交付或低于预算）作为出发点，来探讨哪些机会可能有利于实现该效益，从而识别出相应的机会。
假设条件和制约因素分析。每个项目及其项目管理计划的构思和开发都基于一系列的假设条件，并受一系列制约因素的限制。这些假设条件和制约因素往往都已纳入范围基准和项目估算。开展假设条件和制约因素分析，来探索假设条件和制约因素的有效性，确定其中哪些会引发项目风险。从假设条件的不准确、不稳定、不一致或不完整，可以识别出威胁，通过清除或放松会影响项目或过程执行的制约因素，可以创造出机会。
SWOT 分析。这是对项目的优势、劣势、机会和威胁 (SWOT) 进行逐个检查。在识别风险时，它会将内部产生的风险包含在内，从而拓宽识别风险的范围。首先，关注项目、组织或一般业务领域，识别出组织的优势和劣势；然后，找出组织优势可能为项目带来的机会，组织劣势可能造成的威胁。还可以分析组织优势能在多大程度上克服威胁，组织劣势是否会妨碍机会的产生。
文件分析。见 5.2.2.3 节。通过对项目文件的结构化审查，可以识别出一些风险。可供审查的文件包括（但不限于）计划、假设条件、制约因素、以往项目档案、合同、协议和技术文件。

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

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

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

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

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

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

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

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

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

规划风险应对是为处理整体项目风险敞口，以及应对单个项目风险，而制定可选方案、选择应对策略并商定应对行动的过程。本过程的主要作用是，制定应对整体项目风险和单个项目风险的适当方法；本过程还将分配资源，并根据需要将相关活动添加进项目文件和项目管理计划。本过程需要在整个项目期间开展。图 11-16 描述本过程的输入、工具与技术和输出。图 11-17 是本过程的数据流向图。

图 11-16规划风险应对：输入、工具与技术和输出

图 11-17规划风险应对：数据流向图

有效和适当的风险应对可以最小化单个威胁，最大化单个机会，并降低整体项目风险敞口；不恰当的风险应对则会适得其反。一旦完成对风险的识别、分析和排序，指定的风险责任人就应该编制计划，以应对项目团队认为足够重要的每项单个项目风险。这些风险会对项目目标的实现造成威胁或提供机会。项目经理也应该思考如何针对整体项目风险的当前级别做出适当的应对。

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

要为实施商定的风险应对策略，包括主要策略和备用策略（若必要），制定具体的应对行动。

如果选定的策略并不完全有效，或者发生了已接受的风险，就需要制定应急计划（或弹回计划）。

同时，也需要识别次生风险。次生风险是实施风险应对措施而直接导致的风险。往往需要为风险分配时间或成本应急储备，并可能需要说明动用应急储备的条件。

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

假设日志。见 4.1.3.2 节。在规划风险应对过程中，可能做出新的假设、识别出新的制约因素，或者现有的假设条件或制约因素可能被重新审查和修改。应该更新假设日志，记录这些新信息。
成本预测。见 7.4.3.2 节。成本预测可能因规划的风险应对策略而发生变更。
经验教训登记册。见 4.4.3.1 节。更新经验教训登记册，记录适用于项目的未来阶段或未来项目的风险应对信息。
项目进度计划。见 6.5.3.2 节。可以把用于执行已商定的风险应对策略的活动添加到项目进度计划中。
项目团队派工单。见 9.3.3.2 节。一旦确定应对策略，应为每项与风险应对计划相关的措施分配必要的资源，包括用于执行商定的措施的具有适当资质和经验的人员（通常在项目团队中）、合理的资金和时间，以及必要的技术手段。
风险登记册。见 11.2.3.1 节。需要更新风险登记册，记录选择和商定的风险应对措施。风险登记册的更新可能包括（但不限于）：
商定的应对策略；
实施所选应对策略所需要的具体行动；
风险发生的触发条件、征兆和预警信号；
实施所选应对策略所需要的预算和进度活动；
应急计划，以及启动该计划所需的风险触发条件；
弹回计划，供风险发生且主要应对措施不足以应对时使用；
在采取预定应对措施之后仍然存在的残余风险，以及被有意接受的风险；
由实施风险应对措施而直接导致的次生风险。
风险报告。见 11.2.3.2 节。更新风险报告，记录针对当前整体项目风险敞口和高优先级风险的经商定的应对措施，以及实施这些措施之后的预期变化。

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

问题日志。见 4.3.3.3 节。作为实施风险应对过程的一部分，已识别的问题会被记录到问题日志中。
经验教训登记册。见 4.4.3.1 节。更新经验教训登记册，记录在实施风险应对时遇到的挑战、本可采取的规避方法，以及实施风险应对的有效方式。
项目团队派工单。见 9.3.3.2 节。一旦确定风险应对策略，应为每项与风险应对计划相关的措施分配必要的资源，包括用于执行商定的措施的具有适当资质和经验的人员、合理的资金和时间，以及必要的技术手段。
风险登记册。见 11.2.3.1 节。可能需要更新风险登记册，反映开展本过程所导致的对单个项目风险的已商定应对措施的任何变更。
风险报告。见 11.2.3.2 节。可能需要风险报告，反映开展本过程所导致的对整体项目风险敞口的已商定应对措施的任何变更。

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

假设日志。见 4.1.3.2 节。在监督风险过程中，可能做出新的假设、识别出新的制约因素，或者现有假设条件或制约因素可能被重新审查和修改。需要更新假设日志，记录这些新信息。
问题日志。见 4.3.3.3 节。作为监督风险过程的一部分，已识别的问题会记录到问题日志中。
经验教训登记册。见 4.4.3.1 节。更新经验教训登记册，记录风险审查期间得到的任何与风险相关的经验教训，以便用于项目的后期阶段或未来项目。
风险登记册。见 11.2.3.1 节。更新风险登记册，记录在监督风险过程中产生的关于单个项目风险的信息，可能包括添加新风险、更新已过时风险或已发生风险，以及更新风险应对措施，等等。
风险报告。见 11.2.3.2 节。应该随着监督风险过程生成新信息，而更新风险报告，反映重要单个项目风险的当前状态，以及整体项目风险的当前级别。风险报告还可能包括有关的详细信息，诸如最高优先级单个项目风险、已商定的应对措施和责任人，以及结论与建议。风险报告也可以收录风险审计给出的关于风险管理过程有效性的的结论。

项目采购管理包括从项目团队外部采购或获取所需产品、服务或成果的各个过程。项目采购管理包括编制和管理协议所需的管理和控制过程，例如，合同、订购单、协议备忘录 (MOA)，或服务水平协议 (SLA)。被授权采购项目所需货物和（或）服务的人员可以是项目团队、管理层或组织采购部（如果有）的成员。

项目采购管理过程包括：

12.1 规划采购管理 — 记录项目采购决策、明确采购方法，及识别潜在卖方的过程。

12.2 实施采购 — 获取卖方应答、选择卖方并授予合同的过程。

12.3 控制采购 — 管理采购关系、监督合同绩效、实施必要的变更和纠偏，以及关闭合同的过程。

虽然在本指南中，采购过程以界限分明和相互独立的形式出现，但在实践中，采购过程相当复杂且相互作用，还与其他知识领域的过程相互作用。本指南无法全面详述这些相互作用。本章以从项目外部获取货物或服务的视角来叙述采购过程。

图 12-1 概括了项目采购管理的各个过程。虽然在本《PMBOK® 指南》中，各项目采购管理过程

以界限分明和相互独立的形式出现，但在实践中它们会以本指南无法全面详述的方式相互交叠和相互作用。

图 12-1项目采购管理概述

项目采购管理的核心概念与采购过程相关的重大法律义务和惩罚，通常超出大多数其他的项目管理过程。虽然项目经理不必成为采购管理法律法规领域的专家，但应该对采购过程有足够了解，以便做出与合同及合同关系相关的明智决定。通常情况下，项目经理无权签署对组织有约束力的法律协议，这项工作仅由具备相关职权的人员执行。

项目采购管理过程涉及到用协议来描述买卖双方之间的关系。协议可以很简单，如以特定人工单价购买所需的工时，也可以很复杂，如多年的国际施工合同。合同签署的方法和合同本身应体现可交付成果或所需人力投入的简单性或复杂性，其书写形式也应符合当地、所在国或国际法中关于合同签署的规定。

合同应明确说明预期的可交付成果和结果，包括从卖方到买方的任何知识转移。合同中未规定的任何事项则不具法律强制力。开展国际合作的项目经理应牢记，无论合同规定如何详尽，文化和当地法律对合同及其可执行性均有影响。

采购合同中包括条款和条件，也可包括买方就卖方应实施工作或应交付产品的其他规定。在与采购办公室协作确保遵守组织的采购政策的同时，项目管理团队必须确定所有采购都能满足项目的具体需要。因应用领域不同，协议可以是合同、服务水平协议（SLA）、谅解备忘录、协议备忘录（MOA）或订购单。

大多数组织都有相关的书面政策和程序，来专门定义采购规则，并规定谁有权代表组织签署和管理协议。在世界各地，组织虽然用不同的名称来称呼负责采购的单位或部门，如购买部、合同部、采购部或收购部，但其实际职责大同小异。

虽然所有项目文件可能都要经过某种形式的审查与批准，但是，鉴于其法律约束力，合同或协议需要经过更多的审批程序，而且通常会涉及到法务部。在任何情况下，审批程序的主要目标都是确保合同充分描述将由卖方提供的产品、服务或成果，且符合法律法规关于采购的规定。通常把描述产品、服务或成果的文件作为独立的附件或附录，以便合同正文使用标准化的法律合同用语。

在复杂项目中，可能需要同时或先后管理多个合同。这种情况下，不同合同的生命周期可在项目生命周期的任何阶段开始与结束。买卖方关系是采购组织与外部组织之间的关系，可存在于项目的许多层次上。

因应用领域不同，卖方可以是承包商、供货商、服务提供商或供应商；买方可能为最终产品的所有人、分包商、收购机构、服务需求者或购买方。在合同生命周期中，卖方首先是投标人，然后是中标人，之后是签约供应商或供货商。

中标人可将所承揽的工作当作一个项目加以管理。在这种情况下：

买方就变成了承包商、供应商及服务提供商的客户，因此也就是卖方的关键项目相关方。
卖方的项目管理团队就需要关注工作执行或服务提供所涉及的所有过程。
对于卖方来说，合同条款和条件以及采购工作说明书 (SOW) 都是其许多管理过程的重要输入。

在合同中，可实际列出各种输入（如，主要可交付成果、关键里程碑、成本目标），或者可限制项目团队的选择余地（如，在 IT 整合项目中，关于人员配备的决定往往要征得买方的批准）。另外，采购工作说明书可能使用其他名称，如技术工作说明书。

卖方本身也可能成为更低层级的产品、服务和材料分包商及供应商的买方。

本节假设项目所需物品或服务的买方是项目团队，或者是组织内部的某个部门，同时假设卖方是为项目提供物品或服务的一方，且通常来自执行组织外部。在某些项目上，卖方可能是项目执行组织内部但属于项目外部的某个小组或部门。在大型复杂的项目上，卖方可能在授予合同后才成为整合式项目团队的一部分。

在小型组织或初创企业，以及未设置购买、合同或采购部门的组织，项目经理可以拥有采购职权，能够直接谈判并签署合同（分散式采购）。在更成熟的组织中，由专设部门开展实际的采购和合同签署工作，即采购、谈判和签署合同（集中式采购）。

在签署国际合同时，应该在合同中明确规定对合同的法律管辖权。在大多数情况下，卖方是受正式合同关系约束的外部承包商。

采购管理的发展趋势和新兴实践不同行业各方面（软件工具、风险、过程、物流和技术）的一些重大趋势，会影响项目的成功率。项目采购管理的发展趋势和新兴实践包括（但不限于）：

工具的改进。用于管理项目采购和项目执行的工具已经取得重大发展。现在，买方能够使用在线工具集中发布采购广告；卖方也能够使用在线工具集中查找采购文件，并直接在线填写。在施工、工程和基础设施领域，建筑信息模型(BIM) 软件的应用日益广泛，为工程项目节省了大量时间和资金。它能够大幅减少施工索赔，从而降低成本、缩短工期，因此世界各地的主要公司和政府都开始要求在大型项目中使用 BIM。
更先进的风险管理。在风险管理领域日益流行的一个趋势，就是在编制合同时准确地将具体风险分配给最有能力对其加以管理的一方。没有任何承包商有能力管理项目的所有重大风险，买方因而必须接受承包商无法掌控的风险，例如，采购方公司政策的不断变化、法规要求的不断变化，以及项目以外的其他风险。在合同中可以明确规定风险管理是合同工作的一部分。
变化中的合同签署实践。在过去几年时间内，超大型项目的数量显著增加，尤其是在基础设施建设和工程项目领域。数十亿美元的项目现在已十分常见。大部分此类项目都要求与多个国家的多家承包商签署国际合同，因此肯定比仅使用当地承包商的项目具有更大的风险。承包商越来越重视在采购过程中与客户开展密切合作，以便对批量采购或有其他特殊关系的客户给予折扣优惠。对于此类项目来说，为了减少执行过程中的问题和索赔，采用国际公认的标准合同范本也日益普遍。
物流和供应链管理。因为如此多的大型工程、施工和基础设施建设项目都由多家跨国承包商来完成，材料物流管理对于项目成功完成至关重要。对采购周期较长的产品，制造环节和运输（到项目现场）环节都是项目进度的决定因素。在 IT 领域，有些产品可能需要提前 2 至 3 个月订购；在复杂的施工项目上，订购时间可能需要提前 1-2 年，甚至更长。在这些项目上，可能需要在签订其他采购合同之前就采购这些订购周期长的产品，以便项目如期完成。在最终产品的最终设计完成之前，就可能需要根据总体设计中已确定的要求开始订购采购周期较长的材料、用品或设备。供应链管理也是承包商的项目团队日益重视的一个领域。在项目早期，不仅要明确主要的采购渠道，通常还需要明确次要和备选渠道。全球很多国家会要求跨国承包商至少向当地供应商采购一定比例的材料和用品。
技术和相关方关系。公共资助的项目正受越来越多的关注。基础设施和商业建设项目正日益采用包括网络摄像（webcams）在内的技术，以改善与相关方的沟通和关系。在施工期间，施工现场会安装一台或多台网络摄像机，定期更新并发布到公开的网站上，方便所有相关方在互联网上查看项目进展。另外，视频资料可以储存，有助于在索赔发生时进行分析。有些项目显示，使用网络摄像机记录现场情况，能够避免对事实的分歧，从而能够把与现场施工有关的争议降到最低程度。
试用采购。并非每一个卖方都能很好地适应买方组织的环境，因此，在决定大批量采购之前，有些项目会试用多个候选卖方，向他们采购少量的可交付成果和工作产品。这样一来，买方可以在推进项目工作的同时，对潜在合作伙伴进行评估。

裁剪时需要考虑的因素因为每个项目都是独特的，所以项目经理需要裁剪项目采购管理过程。裁剪时应考虑的因素包括（但不限于）：

采购的复杂性。只开展一次主要的采购，或者需要在不同时间向不同卖方进行多次采购（会提高采购的复杂性）？
物理地点。买方和卖方在同一或邻近地点，或者位于不同时区、国家或大洲？
治理和法规环境。组织的采购政策是否和当地相关的法律法规兼容？当地的法律法规会如何影响合同审计工作？
承包商的可用性。是否有具备工作执行能力的承包商可供选择？

在敏捷或适应型环境中需要考虑的因素在敏捷型环境中，可能需要与特定卖方协作来扩充团队。这种协作关系能够营造风险共担式采购模型，让买方和卖方共担项目风险和共享项目奖励。

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

在这种情况下，可以通过主体协议，如主要服务协议（MSA），来管辖整体协作关系，而将适应型工作写入附录或补充文件。这样一来，变更只针对适应型工作，而不会对主体协议造成影响。

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

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

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

经验教训登记册。见 4.4.3.1 节。更新经验教训登记册，记录在实施采购期间所遇到的挑战、本可采取的规避方法，以及有效的方法。
需求文件。见 5.2.3.1 节。需求文件可能包括：
卖方需要满足的技术要求；
具有合同和法律意义的需求，如健康、安全、安保、绩效、环境、保险、知识产权、同等就业机会、执照、许可证，以及其他非技术要求。
需求跟踪矩阵。见 5.2.3.2 节。随着将卖方纳入项目计划，可能需要根据特定卖方的能力，变更需求登记册及跟踪矩阵。
资源日历。见 9.2.1.2 节。可能需要根据卖方的可用性更新与进度计划有关的资源日历。
风险登记册。见 11.2.3.1 节。取决于卖方的组织、合同的持续时间、外部环境、项目交付方法、所选合同类型，以及最终商定的价格，每个被选中的卖方都会带来特殊的风险。在合同签署过程中，应该对风险登记册进行变更，以反映每个卖方带来的具体风险。
相关方登记册。见 13.1.3.1 节。此文件包含与已识别相关方有关的所有详细信息。与具体卖方签订协议后，需要更新相关方登记册。

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

经验教训登记册。见 4.4.3.1 节。更新经验教训登记册，记录能有效维护采购工作的范围、进度和成本的技术。对于出现的偏差，经验教训登记册应该记录曾采取的纠正措施及其有效性。

如果已经发生索赔，则应记录相关信息以避免重蹈覆辙，其他关于如何改善采购过程的信息也应记录在内。

资源需求。见 9.2.3.1 节。随着承包商的工作进展，可能因工作执行不符合原定计划而需要变更资源需求。
需求跟踪矩阵。见 5.2.3.2 节。更新需求跟踪矩阵，记录已实现的需求。
风险登记册。见 11.2.3.1 节。取决于卖方的组织、合同的持续时间、外部环境、项目交付方法、所选合同类型，以及最终商定的价格，每个被选中的卖方都会带来特殊的风险。随着早期风险的过时以及新风险的出现，在项目执行期间对风险登记册进行变更。
相关方登记册。见 13.1.3.1 节。随着执行阶段的工作进展，承包商和供应商可能发生变更，应该把承包商和供应商的变更情况记录在相关方登记册中。

识别相关方是定期识别项目相关方，分析和记录他们的利益、参与度、相互依赖性、影响力和对项目成功的潜在影响的过程。本过程的主要作用是，使项目团队能够建立对每个相关方或相关方群体的适度关注。本过程应根据需要在整个项目期间定期开展。图 13-2 描述本过程的输入、工具与技术和输出。图 13-3 是本过程的数据流向图。

图 13-2识别相关方：输入、工具与技术和输出

图 13-3识别相关方：数据流向图

本过程通常在编制和批准项目章程之前或同时首次开展。本过程需在必要时重复开展，至少应在每个阶段开始时，以及项目或组织出现重大变化时重复开展。每次重复开展本过程，都应通过查阅项目管理计划组件及项目文件，来识别有关的项目相关方。

• Projectcharter

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

相关方分析。相关方分析会产生相关方清单和关于相关方的各种信息，例如，在组织内的位置、在项目中的角色、与项目的利害关系、期望、态度（对项目的支持程度），以及对项目信息的兴趣。相关方的利害关系可包括（但不限于）以下各条的组合：
兴趣。个人或群体会受与项目有关的决策或成果的影响。
权利（合法权利或道德权利）。国家的法律框架可能已就相关方的合法权利做出规定，如职业健康和安全。道德权利可能涉及保护历史遗迹或环境的可持续性。
所有权。人员或群体对资产或财产拥有的法定所有权。
知识。专业知识有助于更有效地达成项目目标和组织成果，或有助于了解组织的权力结构，从而有益于项目。
贡献。提供资金或其他资源，包括人力资源，或者以无形方式为项目提供支持，例如，宣传项目目标，或在项目与组织权力结构及政治之间扮演缓冲角色。
文件分析。见 5.2.2.3 节。评估现有项目文件及以往项目的经验教训，以识别相关方和其他支持性信息。

见 4.3.3.4 节。首次开展识别相关方过程，不会提出任何变更请求。但随着在后续项目期间继续识别相关方，新出现的相关方或关于现有相关方的新信息可能导致对产品、项目管理计划或项目文件提出变更请求。

应该通过实施整体变更控制过程（见 4.6 节）对变更请求进行审查和处理。

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

假设日志。见 4.1.3.2 节。大量关于相对权力、利益和相关方参与度的信息，都是基于一定的假设条件的。应该在假设日志中记录这些假设条件。此外，还要在假设日志中记录会影响与具体相关方互动的各种制约因素。
问题日志。见 4.3.3.3 节。在本过程中产生的新问题应该记录到问题日志中。
风险登记册。见 11.2.3.1 节。风险登记册记录在本过程中识别，并通过风险管理过程加以管理的新风险。

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

变更日志。见 4.6.3.3 节。根据变更请求更新变更日志。
问题日志。见 4.3.3.3 节。可能需要更新问题日志，以反映问题日志条目的更新或添加。
经验教训登记册。见 4.4.3.1 节。更新经验教训登记册，记录管理相关方参与的有效或无效方法，以供当前或未来项目借鉴。
相关方登记册。见 13.1.3.1 节。可能需要基于提供给相关方的关于问题解决、变更审批和项目状态的新信息，来更新相关方的登记册。

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

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

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

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

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

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

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

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

Newtown Square, PA: Author.

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

Newtown Square, PA: Author.

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

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

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

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

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

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

启动项目旨在抓住与组织的战略目标相符的商业机会。在启动项目之前，通常需要编制商业论证，以概述项目目标、所需投资，以及用于测量项目成功的财务标准和其他量化标准。商业论证为在整个项目生命周期中衡量项目成功和进展奠定了基础，以便把实际结果与预定的目标和成功标准进行比较。

项目的启动通常出于以下一项或多项战略考虑：

市场需求；
战略机会/业务需求；
社会需要；
环境考虑；
客户要求；
技术进步；
法律或法规要求；
现有问题或已预见到的问题。

效益管理计划描述项目效益的实现方法和时间及其衡量方式。效益管理计划可能包括以下内容：

目标效益。使用产品、服务或成果而预期获得的有形和无形商业价值。
战略一致性。项目效益如何支持组织的业务战略并与之保持一致。
实现效益的时限。效益按阶段划分，包括：短期效益、长期效益和持续性效益。
效益责任人。在效益实现计划规定的整个时限内，监督、记录和报告效益实现情况的责任个人或小组。
测量指标。用于考核效益实现情况的直接和间接方法。
风险。与实现目标效益有关的风险。

根据项目目标和成功标准考核项目的成功程度。在许多情况下，产品、服务或成果的成功只有在项目完成后一段时间方能知晓。例如，在项目产品、服务或成果交付运营时，市场份额增加、运营成本降低或新产品成功可能都是未知的。在这些情况下，项目管理办公室 (PMO)、项目组合指导委员会或组织内的其他职能部门，应该在稍晚时间才对项目成功进行评估，以确定结果是否符合业务目标。

商业论证和效益管理计划都是在项目启动之前编制的，并且要成为项目完成之后评估项目成功的依据。因此，它们被视为商业文件，而非项目文件，或者项目管理计划的组成部分。这些商业文件可能成为某些项目管理过程的输入，例如，制定项目章程。

本标准描述用于实现项目目标的项目管理过程。项目管理过程可归为五大项目管理过程组：

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

监控过程组详见第 5 章。

收尾过程组正式完成或结束项目、阶段或合同所执行的过程（组）。收尾过程组详见第 6 章。

这五大过程组与应用领域（如营销、信息服务或会计）或行业（如建筑、航天、电信）无关。

在阶段或项目完成之前，往往需要反复实施过程组中的单个过程。过程迭代的次数和过程间的相互作用因具体项目的需求而不同。过程通常分为三类：

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

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

过程组不同于项目阶段。如果将项目划分为若干阶段，则各过程组中的过程会在每个阶段内相互作用。在一个阶段内可能需要使用所有的过程组，如图 1-5 所示。当项目被分为不同的阶段（例如概念开发、可行性研究、设计、原型、构建或测试等）时，各过程组中的过程根据需要在每个阶段中重复，直到达到该阶段的完工标准。

图 1-5项目或阶段中的过程组相互作用示例

过程组和知识领域涵盖的 49 个过程如表 1-1 所示。

表 1-1项目管理过程组与知识领域

在本标准中，术语“工件”包括项目管理过程、输入、工具、技术、输出、事业环境因素和组织过程资产。项目经理和项目管理团队需要选择和调整合适的工件，用于其特定项目。这种选择和调整活动称为裁剪。每个项目的独特性决定了必须进行裁剪，因此，并非每个项目都需要每个过程、输入、工具、技术或输出。

项目管理计划是最常用的工件，有许多组成部分，如子管理计划、基准和项目生命周期描述。

子管理计划是与项目特定方面或知识领域相关的计划，如进度管理计划、风险管理计划和变更管理计划。进行裁剪时，需要确定特定项目所需的项目管理计划组件。项目管理计划是一种输入，而项目管理计划更新是本标准中许多过程的输出。在本标准中，不会在输入和输出表中直接列出单个项目管理计划组件，而是在该表下方的正文中列出每个过程可能用到的项目管理计划组件（输入）或可能得到的项目管理计划组件更新（输出）。所列出的组件仅为示例而已。在开展每个特定过程时，项目经理既非必须、也非限于用到上述输入或得到上述输出。

项目管理计划是主要的项目工件之一。另外，还有不属于项目管理计划但也可用于管理项目的其他文件。这些其他文件称为项目文件。与项目管理计划组件类似，过程所需的项目文件会因具体项目而异。项目经理负责确定过程所需的项目文件，以及将作为过程输出的项目文件更新。在本标准中，在输入和输出表下方的正文中列出的项目文件，仅为项目文件的可能示例，而非完整列表。

表 1-2 列出了项目管理计划的主要组件和主要的项目文件。虽然该表并未穷尽所有的计划组件和项

目文件，但的确列出了有助于管理项目的常用计划组件和项目文件。

表 1-2项目管理计划和项目文件

商业文件通常是在项目之外创建的文件，用作项目的输入。商业文件包括商业论证和效益管理计划。如何应用商业文件，将取决于公司文化和项目启动过程。

会影响项目的事业环境因素，以及可用于项目的组织过程资产，将因项目及其所处环境而异，所以并未在本标准中列出。

识别相关方是定期识别项目相关方，分析和记录他们的利益、参与度、相互依赖性、影响力和对项目成功的潜在影响的过程。本过程的主要作用是，使项目团队能够建立对每个相关方或相关方群体的适度关注。本过程应根据需要在整个项目期间定期开展。图 2-4 描述了本过程的输入和输出。

图 2-4识别相关方：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

变更日志；
问题日志；
需求文件。

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

假设日志；
问题日志；
风险登记册。

规划过程组包括明确项目全部范围、定义和优化目标，并为实现目标制定行动方案的一组过程。规划过程组中的过程制定项目管理计划的组成部分，以及用于执行项目的项目文件。取决于项目本身的性质，可能需要通过多轮反馈来做进一步分析。随着收集和掌握更多的项目信息或特性，项目很可能需要进一步规划。项目生命周期中发生的重大变更，可能引发重新开展一个或多个规划过程，甚至一个或全部两个启动过程。这种对项目管理计划的持续精细化叫做“渐进明细”，表明项目规划和文件编制是迭代或持续开展的活动。本过程组的主要作用是，确定成功完成项目或阶段的行动方案。

在规划项目、制定项目管理计划和项目文件时，项目管理团队应当征求适当相关方的意见，并鼓励相关方参与。初始规划工作完成时，经批准的项目管理计划就被视为基准。在整个项目期间，监控过程将把项目绩效与基准进行比较。

规划过程组（图 3-1）包括第 3.1 节至 3.24 节所列的项目管理过程。

图 3-1规划过程组

制定项目管理计划是定义、准备和协调项目计划的所有组成部分，并把它们整合为一份综合项目管理计划的过程。本过程的主要作用是，生成一份综合文件，用于确定所有项目工作的基础及其执行方式。本过程仅开展一次或仅在项目的预定义点开展。图 3-2 描述了本过程的输入和输出。

图 3-2制定项目管理计划：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

收集需求是为实现目标而确定、记录并管理相关方的需要和需求的过程。本过程的主要作用是，为定义产品范围和项目范围奠定基础。本过程仅开展一次或仅在项目的预定义点开展。图 3-4 描述了本过程的输入和输出。

图 3-4收集需求：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

假设日志；
经验教训登记册；
相关方登记册。

定义范围是制定项目和产品详细描述的过程。本过程的主要作用是，描述产品、服务或成果的边界和验收标准。本过程仅开展一次或仅在项目的预定义点开展。图 3-5 描述了本过程的输入和输出。

图 3-5定义范围：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

假设日志；
需求文件；
风险登记册。

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

假设日志；
需求文件；
需求跟踪矩阵；
相关方登记册。

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

图 3-6创建 WBS：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

项目范围说明书；
需求文件。

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

假设日志；
需求文件。

排列活动顺序是识别和记录项目活动之间的关系的过程。本过程的主要作用是定义工作之间的逻辑顺序，以便在既定的所有项目制约因素下获得最高的效率。本过程需要在整个项目期间开展。

图 3-9 描述了本过程的输入和输出。

图 3-9排列活动顺序：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

活动属性；
活动清单；
假设日志；
里程碑清单。

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

活动属性；
活动清单；
假设日志；
里程碑清单。

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

图 3-10估算活动持续时间：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

活动属性；
活动清单；
假设日志；
经验教训登记册；
里程碑清单；
项目团队派工单；
资源分解结构；
资源日历；
资源需求；
风险登记册。

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

活动属性；
假设日志；
经验教训登记册。

制定进度计划是分析活动顺序、持续时间、资源需求和进度制约因素，创建进度模型，从而落实项目执行和监控的过程。本过程的主要作用是，为完成项目活动而制定具有计划日期的进度模型。

本过程需要在整个项目期间开展。图 3-11 描述了本过程的输入和输出。

图 3-11制定进度计划：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

活动属性；
活动清单；
假设日志；
估算依据；
持续时间估算；
经验教训登记册；
里程碑清单；
项目进度网络图；
项目团队派工单；
资源日历；
资源需求；
风险登记册。

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

活动属性；
假设日志；
持续时间估算；
经验教训登记册；
资源需求；
风险登记册。

估算成本是对完成项目工作所需资金进行近似估算的过程。本过程的主要作用是，确定项目所需的资金。本过程应根据需要在整个项目期间定期开展。图 3-13 描述了本过程的输入和输出。

图 3-13估算成本：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

经验教训登记册；
项目进度计划；
资源需求；
风险登记册。

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

假设日志；
经验教训登记册；
风险登记册。

制定预算是汇总所有单个活动或工作包的估算成本，建立一个经批准的成本基准的过程。本过程的主要作用是，确定可据以监督和控制项目绩效的成本基准。本过程仅开展一次或仅在项目的预定义点开展。图 3-14 描述了本过程的输入和输出。

图 3-14制定预算：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

估算依据；
成本估算；
项目进度计划；
风险登记册。

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

成本估算；
项目进度计划；
风险登记册。

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

图 3-15规划质量管理：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

假设日志；
需求文件；
需求跟踪矩阵；
风险登记册；
相关方登记册。

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

经验教训登记册；
需求跟踪矩阵；
风险登记册；
相关方登记册。

规划资源管理是定义如何估算、获取、管理和利用实物以及团队资源的过程。本过程的主要作用是，根据项目类型和复杂程度确定适用于项目资源的管理方法和管理程度。本过程仅开展一次或仅在项目的预定义点开展。图 3-16 描述了本过程的输入和输出。

图 3-16规划资源管理：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

假设日志；
风险登记册。

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

本过程的主要作用是，明确完成项目所需的资源种类、数量和特性。本过程应根据需要在整个项目期间定期开展。图 3-17 描述了本过程的输入和输出。

图 3-17估算活动资源：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

活动属性；
活动清单；
假设日志；
成本估算；
资源日历；
风险登记册。

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

活动属性；
假设日志；
经验教训登记册。

规划沟通管理是基于每个相关方或相关方群体的信息需求、可用的组织资产，以及具体项目的需求，为项目沟通活动制定恰当的方法和计划的过程。本过程的主要作用是，为及时向相关方提供相关信息，引导相关方有效参与项目，而编制书面沟通计划。本过程应根据需要在整个项目期间定期开展。图 3-18 描述了本过程的输入和输出。

图 3-18规划沟通管理：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

需求文件；
相关方登记册。

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

项目进度计划；
相关方登记册。

规划风险管理是定义如何实施项目风险管理活动的过程。本过程的主要作用是，确保风险管理的水平、方法和可见度与项目风险程度，以及项目对组织和其他相关方的重要程度相匹配。本过程仅开展一次或仅在项目的预定义点开展。图 3-19 描述了本过程的输入和输出。

图 3-19规划风险管理：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

可用作本过程输入的项目文件包括（但不限于）相关方登记册。

识别风险是识别单个项目风险，以及整体项目风险的来源，并记录风险特征的过程。本过程的主要作用是，记录现有的单个项目风险，以及整体项目风险的来源。本过程还汇集相关信息，以便项目团队能够恰当应对已识别风险。本过程需要在整个项目期间开展。图 3-20 描述了本过程的输入和输出。

图 3-20识别风险：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

假设日志；
成本估算；
持续时间估算；
问题日志；
经验教训登记册；
需求文件；
资源需求；
相关方登记册。

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

假设日志；
问题日志；
经验教训登记册。

实施定性风险分析是通过评估单个项目风险发生的概率和影响以及其他特征，对风险进行优先排序，从而为后续分析或行动提供基础的过程。本过程的主要作用是重点关注高优先级的风险。本过程需要在整个项目期间开展。图 3-21 描述了本过程的输入和输出。

图 3-21实施定性风险分析：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

假设日志；
风险登记册；
相关方登记册。

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

假设日志；
问题日志；
风险登记册；
风险报告。

实施定量风险分析是就已识别的单个项目风险和不确定性的其他来源对整体项目目标的影响进行定量分析的过程。本过程的主要作用是，量化整体项目风险敞口，并提供额外的定量风险信息，以支持风险应对规划。本过程需要在整个项目期间开展。图 3-22 描述了本过程的输入和输出。

图 3-22实施定量风险分析：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

假设日志；
估算依据；
成本估算；
成本预测；
持续时间估算；
里程碑清单；
资源需求；
风险登记册；
风险报告；
进度预测。

可在本过程更新的项目文件包括（但不限于）风险报告。

规划风险应对是为处理整体项目风险敞口，以及应对单个项目风险，而制定可选方案、选择应对策略并商定应对行动的过程。本过程的主要作用是，制定应对整体项目风险和单个项目风险的适当方法。本过程还将分配资源，并根据需要将相关活动添加进项目文件和项目管理计划。本过程需要在整个项目期间开展。图 3-23 描述了本过程的输入和输出。

图 3-23规划风险应对：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

经验教训登记册；
项目进度计划；
项目团队派工单；
资源日历；
风险登记册；
风险报告；
相关方登记册

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

假设日志；
成本预测；
经验教训登记册；
项目进度计划；
项目团队派工单；
风险登记册；
风险报告。

规划采购管理是记录项目采购决策，明确采购方法，识别潜在卖方的过程。本过程的主要作用是，确定是否从项目外部获取货物和服务，如果是，则还要确定将在什么时间、以什么方式获取什么货物和服务。货物和服务可从执行组织的其他部门采购，或者从外部渠道采购。本过程仅开展一次或仅在项目的预定义点开展。图 3-24 描述了本过程的输入和输出。

图 3-24规划采购：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

里程碑清单；
项目团队派工单；
需求文件；
需求跟踪矩阵；
资源需求；
风险登记册；
相关方登记册。

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

经验教训登记册；
里程碑清单；
需求文件；
需求跟踪矩阵；
风险登记册；
相关方登记册。

规划相关方参与是根据相关方的需求、期望、利益和对项目的潜在影响，制定项目相关方参与项目的方法的过程。本过程的主要作用是，提供与相关方进行有效互动的可行计划。本过程应根据需要在整个项目期间定期开展。图 3-25 描述了本过程的输入和输出。

图 3-25规划相关方参与：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

假设日志；
变更日志；
问题日志；
项目进度计划；
风险登记册；
相关方登记册。

执行过程组包括完成项目管理计划中确定的工作，以满足项目要求的一组过程。本过程组需要按照项目管理计划来协调资源，管理相关方参与，以及整合并实施项目活动。本过程组的主要作用是，根据计划执行为满足项目要求、实现项目目标所需的项目工作。相当多的项目预算、资源和时间将用于开展执行过程组的过程。开展执行过程组的过程，可能导致变更请求。一旦变更请求获得批准，则可能触发一个或多个规划过程，来修改管理计划、完善项目文件，甚至建立新的基准。

执行过程组（图 4-1）包括第 4.1 节至 4.10 节所列的项目管理过程。

图 4-1执行过程组

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

图 4-2指导与管理项目工作：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

变更日志；
经验教训登记册；
里程碑清单；
项目沟通记录；
项目进度计划；
需求跟踪矩阵；
风险登记册；
风险报告。

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

活动清单；
假设日志；
经验教训登记册；
需求文件；
风险登记册；
相关方登记册。

管理项目知识是使用现有知识并生成新知识，以实现项目目标，并且帮助组织学习的过程。

本过程的主要作用是，利用已有的组织知识来创造或改进项目成果，并且使当前项目创造的知识可用于支持组织运营和未来的项目或阶段。本过程需要在整个项目期间开展。图 4-3 描述了本过程的输入和输出。

图 4-3管理项目知识：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

管理质量是把组织的质量政策用于项目，并将质量管理计划转化为可执行的质量活动的过程。

本过程的主要作用是，提高实现质量目标的可能性，以及识别无效过程和导致质量低劣的原因。

本过程需要在整个项目期间开展。图 4-4 描述了本过程的输入和输出。

图 4-4管理质量：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

经验教训登记册；
质量控制测量结果；
质量测量指标；
风险报告。

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

问题日志；
经验教训登记册；
风险登记册。

获取资源是获取项目所需的团队成员、设施、设备、材料、用品和其他资源的过程。本过程的主要作用是，概述和指导资源的选择，并将其分配给相应的活动。本过程应根据需要在整个项目期间定期开展。图 4-5 描述了本过程的输入和输出。

图 4-5获取资源：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

项目进度计划；
资源日历；
资源需求；
相关方登记册。

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

经验教训登记册；
项目进度计划；
资源分解结构；
资源日历；
资源需求；
风险登记册；
相关方登记册。

建设团队是提高工作能力，促进团队成员互动，改善团队整体氛围，以提高项目绩效的过程。本过程的主要作用是，改进团队协作、增强人际技能、激励员工、减少摩擦以及提升整体项目绩效。

本过程需要在整个项目期间开展。图 4-6 描述了本过程的输入和输出。

图 4-6建设团队：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

经验教训登记册；
项目进度计划；
项目团队派工单；
资源日历；
团队章程。

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

经验教训登记册；
项目进度计划；
项目团队派工单；
资源日历；
团队章程。

管理团队是跟踪团队成员工作表现，提供反馈，解决问题并管理团队变更，以优化项目绩效的过程。本过程的主要作用是，影响团队行为、管理冲突以及解决问题。本过程需要在整个项目期间开展。图 4-7 描述了本过程的输入和输出。

图 4-7管理团队：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

问题日志；
经验教训登记册；
项目团队派工单；
团队章程。

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

问题日志；
经验教训登记册；
项目团队派工单。

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

图 4-8管理沟通：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

变更日志；
问题日志；
经验教训登记册；
质量报告；
风险报告；
相关方登记册。

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

问题日志；
经验教训登记册；
项目进度计划；
风险登记册；
相关方登记册。

实施风险应对是执行商定的风险应对计划的过程。本过程的主要作用是，确保按计划执行商定的风险应对措施，来管理整体项目风险敞口，以及最小化单个项目威胁，最大化单个项目机会。本过程需要在整个项目期间开展。图 4-9 描述了本过程的输入和输出。

图 4-9实施风险应对：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

经验教训登记册；
风险登记册；
风险报告。

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

问题日志；
经验教训登记册；
项目团队派工单；
风险登记册；
风险报告。

实施采购是获取卖方应答、选择卖方并授予合同的过程。本过程的主要作用是，选定合格卖方并签署关于货物或服务交付的法律协议。本过程应根据需要在整个项目期间定期开展。图 4-10 描述了本过程的输入和输出。

图 4-10实施采购：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

经验教训登记册；
项目进度计划；
需求文件；
风险登记册；
相关方登记册。

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

经验教训登记册；
需求文件；
需求跟踪矩阵；
资源日历；
风险登记册；
相关方登记册。

管理相关方参与是与相关方进行沟通和协作，以满足其需求与期望，处理问题，并促进相关方合理参与项目活动的过程。本过程的主要作用是，让项目经理提升相关方的支持，降低相关方的抵制。本过程需要在整个项目期间开展。图 4-11 描述了本过程的输入和输出。

图 4-11管理相关方参与：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

变更日志；
问题日志；
经验教训登记册；
相关方登记册。

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

变更日志；
问题日志；
经验教训登记册；
相关方登记册。

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

图 5-2监控项目工作：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

假设日志；
估算依据；
成本预测；
问题日志；
经验教训登记册；
里程碑清单；
质量报告；
风险登记册；
风险报告；
进度预测。

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

成本预测；
问题日志；
经验教训登记册；
风险登记册；
进度预测。

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

图 5-3实施整体变更控制：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

估算依据；
需求跟踪矩阵；
风险报告。

正式受控的任何项目文件都可在本过程变更。通常在本过程更新的一种项目文件是变更日志。

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

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

图 5-4确认范围：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

经验教训登记册；
质量报告；
需求文件；
需求跟踪矩阵。

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

经验教训登记册；
需求文件；
需求跟踪矩阵。

控制范围是监督项目和产品的范围状态，管理范围基准变更的过程。本过程的主要作用是，在整个项目期间保持对范围基准的维护。本过程需要在整个项目期间开展。图 5-5 描述了本过程的输入和输出。

图 5-5控制范围：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

经验教训登记册；
需求文件；
需求跟踪矩阵。

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

经验教训登记册；
需求文件；
需求跟踪矩阵。

控制进度是监督项目状态，以更新项目进度和管理进度基准变更的过程。本过程的主要作用是，在整个项目期间保持对进度基准的维护。本过程需要在整个项目期间开展。图 5-6 描述了本过程的输入和输出。

图 5-6控制进度：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

经验教训登记册；
项目日历；
项目进度计划；
资源日历；
进度数据。

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

假设日志；
估算依据；
经验教训登记册；
项目进度计划；
资源日历；
风险登记册；
进度数据。

可用作本过程输入的项目文件包括（但不限于）经验教训登记册。

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

假设日志；
估算依据；
成本估算；
经验教训登记册；
风险登记册。

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

图 5-8控制质量：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

经验教训登记册；
质量测量指标；
测试与评估文件。

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

问题日志；
经验教训登记册；
风险登记册；
测试与评估文件。

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

图 5-9控制资源：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

问题日志；
经验教训登记册；
物质资源分配单；
项目进度计划；
资源分解结构；
资源需求；
风险登记册。

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

假设日志；
问题日志；
经验教训登记册；
物质资源分配单；
资源分解结构；
风险登记册。

监督沟通是确保满足项目及其相关方的信息需求的过程。本过程的主要作用是，按沟通管理计划和相关方参与计划的要求开展高效的信息传递。本过程需要在整个项目期间开展。图 5-10 描述了本过程的输入和输出。

图 5-10监督沟通：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

问题日志；
经验教训登记册；
项目沟通记录。

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

问题日志；
经验教训登记册；
相关方登记册。

监督风险是在整个项目期间，监督商定的风险应对计划的实施、跟踪已识别风险、识别和分析新风险，以及评估风险管理有效性的过程。本过程的主要作用是，使项目决策都基于关于整体项目风险敞口和单个项目风险的当前信息。本过程需要在整个项目期间开展。图 5-11 描述了本过程的输入和输出。

图 5-11监督风险：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

问题日志；
经验教训登记册；
风险登记册；
风险报告。

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

假设日志；
问题日志；
经验教训登记册；
风险登记册；
风险报告。

控制采购是管理采购关系，监督合同绩效，实施必要的变更和纠偏，以及关闭合同的过程。本过程的主要作用是，确保买卖双方履行法律协议，满足项目需求。如果存在一系列采购活动，本过程就需要在整个项目期间开展。图 5-12 描述了本过程的输入和输出。

图 5-12控制采购：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

假设日志；
经验教训登记册；
里程碑清单；
质量报告；
需求文件；
需求跟踪矩阵；
风险登记册；
相关方登记册。

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

经验教训登记册；
资源需求；
需求跟踪矩阵；
风险登记册；
相关方登记册。

监督相关方参与是监督项目相关方关系，并通过修订参与策略和计划来引导相关方合理参与项目的过程。本过程的主要作用是，随着项目进展和环境变化，维持或提升相关方参与项目的效率和效果。本过程需要在整个项目期间开展。图 5-13 描述了本过程的输入和输出。

图 5-13监督相关方参与：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

问题日志；
经验教训登记册；
项目沟通记录；
风险登记册；
相关方登记册。

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

问题日志；
经验教训登记册；
风险登记册；
相关方登记册。

结束项目或阶段是终结项目、阶段或合同的所有活动的过程。本过程的主要作用是，存档项目或阶段信息，完成计划的工作，释放组织资源以展开新的工作。本过程仅开展一次或仅在项目的预定义点开展。图 6-2 描述了本过程的输入和输出。

图 6-2结束项目或阶段：输入和输出

究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。

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

假设日志；
估算依据；
变更日志；
问题日志；
经验教训登记册；
里程碑清单；
项目沟通记录；
质量控制测量结果；
质量报告；
需求文件；
风险登记册；
风险报告。

可在本过程更新的项目文件包括（但不限于）经验教训登记册。

以下业务规则用于确保每个项目管理过程中输入和输出的顺序及信息的一致性：

基本规则：
输入是对过程很关键的任何文件。
除非输出为最终输出或被其他输入（如项目文件）采纳，否则输出应成为另一个项目管理过程的输入。
若输入并非来自项目外部，它们应该是其他项目管理过程的输出。
项目文件规则：
具体项目文件首次被识别时会列为具体输出。然后，它们将作为“项目文件更新”列入输出清单，内容叙述部分会对其加以描述。
当任何项目文件是输入时，会列出“项目文件”一词，而且内容叙述部分会说明具体的项目文件。
项目管理计划规则：
对于会制定子计划的规划过程来说，项目章程是第一项输入，项目管理计划为第二项输入。
创建项目管理计划组件的过程将具体列出组成部分。在此之后，它们会作为“项目管理计划更新”列入输出清单，内容叙述部分会对其加以描述。
如果项目管理计划是过程输入，在内容叙述部分可能会对视为输入的具体项目管理计划组成部分进行说明。
排序规则：
若项目章程是输入，则其为第一项输入。
如果项目管理计划是输入或输出，子管理计划会按《PMBOK® 指南》中输出它们的章节顺序列出，随后列出基准和任何其他计划。
项目文件会以字母排列顺序列出。
事业环境因素和组织过程资产也会按该顺序列在末尾。
如果更新是输出，它们的排列顺序如下：

项目管理计划更新；

项目文件更新；

组织过程资产更新。

11.1.1.3 项目文件