11.4.1.4 组织过程资产
项目所处的环境可能对项目的开展产生有利或不利的影响。这些影响的两大主要来源为事业环境因素 (EEF) 和组织过程资产 (OPA)。
事业环境因素源于项目外部（往往是企业外部）的环境，事业环境因素可能对整个企业、项目组合、项目集或项目产生影响。关于事业环境因素的更多信息，请参见 2.2 节。
组织过程资产源于企业内部，可能来自企业自身、项目组合、项目集、其他项目或这些的组合。
图 2-1 分解了事业环境因素和组织过程资产所涵盖的项目影响。关于组织过程资产的更多信息，请参
见 2.3 节。
图 2-1项目影响
除了事业环境因素和组织过程资产，组织系统对项目生命周期也起着重要的作用。组织系统（见2.4 节）进一步讨论了影响了组织系统内部人员的权力、影响力、利益、技能和政治能力的系统因素。
项目管理办公室 (PMO) 是对与项目相关的治理过程进行标准化，并促进资源、方法论、工具和技术共享的一个组织结构。PMO 的职责范围可大可小，从提供项目管理支持服务，到直接管理一个或多个项目。
PMO 有几种不同类型，它们对项目的控制和影响程度各不相同，例如：
- 支持型。支持型 PMO 担当顾问的角色，向项目提供模板、最佳实践、培训，以及来自其他项目的信息和经验教训。这种类型的 PMO 其实就是一个项目资源库，对项目的控制程度很低。
- 控制型。控制型 PMO 不仅给项目提供支持，而且通过各种手段要求项目服从，这种类型的 PMO对项目的控制程度属于中等。服从可能包括：
- 采用项目管理框架或方法论；
- 使用特定的模板、格式和工具；
- 服从治理。
- 指令型。指令型 PMO 直接管理和控制项目。项目经理由 PMO 指定并向其报告。这种类型的 PMO对项目的控制程度很高。
项目管理办公室可能会承担整个组织范围的职责，在支持战略调整和创造组织价值方面发挥重要的作用。PMO 从组织战略项目中获取数据和信息，进行综合分析，评估如何实现更高级别的战略目标的。PMO 在组织的项目组合、项目集、项目与组织考评体系（如平衡计分卡）之间建立联系。
除了被集中管理以外，PMO 所支持和管理的项目不一定彼此关联。PMO 的具体形式、职能和结构取决于所在组织的需要。
为了保证项目符合组织的业务目标，PMO 可能有权在每个项目的生命周期中充当重要相关方和关键决策者。PMO 可以：
- 提出建议；
- 领导知识传递；
- 终止项目；
- 根据需要采取其他行动。
PMO 的一个主要职能是通过各种方式向项目经理提供支持，这些方式包括（但不限于）：
- 对 PMO 所辖的全部项目的共享资源进行管理；
- 识别和制定项目管理方法、最佳实践和标准；
- 指导、辅导、培训和监督；
- 通过项目审计，监督对项目管理标准、政策、程序和模板的遵守程度；
- 制定和管理项目政策、程序、模板和其他共享的文件（组织过程资产）；
- 对跨项目的沟通进行协调。
项目整合管理包括对隶属于项目管理过程组的各种过程和项目管理活动进行识别、定义、组合、统一和协调的各个过程。在项目管理中，整合兼具统一、合并、沟通和建立联系的性质，这些行动应该贯穿项目始终。项目整合管理包括进行以下选择：
- 资源分配；
- 平衡竞争性需求；
- 研究各种备选方法；
- 为实现项目目标而裁剪过程；
- 管理各个项目管理知识领域之间的依赖关系。
项目整合管理过程包括：
4.1 制定项目章程 — 编写一份正式批准项目并授权项目经理在项目活动中使用组织资源的文件的过程。
4.2 制定项目管理计划 — 定义、准备和协调项目计划的所有组成部分，并把它们整合为一份综合项目管理计划的过程。
4.3 指导与管理项目工作 — 为实现项目目标而领导和执行项目管理计划中所确定的工作，并实施已批准变更的过程。
4.4 管理项目知识 — 使用现有知识并生成新知识，以实现项目目标，并且帮助组织学习的过程。
4.5 监控项目工作 — 跟踪、审查和报告整体项目进展，以实现项目管理计划中确定的绩效目标的过程。
4.6 实施整体变更控制 — 审查所有变更请求，批准变更，管理对可交付成果、组织过程资产、项目文件和项目管理计划的变更，并对变更处理结果进行沟通的过程。
4.7 结束项目或阶段 — 终结项目、阶段或合同的所有活动的过程。
图 4-1 概述了项目整合管理的各个过程。虽然在本《PMBOK® 指南》中，各项目整合管理过程
以界限分明和相互独立的形式出现，但在实践中它们会以本指南无法全面详述的方式相互交叠和相互作用。
图 4-1项目整合管理概述
项目整合管理的核心概念项目整合管理由项目经理负责。虽然其他知识领域可以由相关专家（如成本分析专家、进度规划专家、风险管理专家）管理，但是项目整合管理的责任不能被授权或转移。只能由项目经理负责整合所有其他知识领域的成果，并掌握项目总体情况。项目经理必须对整个项目承担最终责任。
项目与项目管理本质上具有整合性质，例如，为应急计划制定成本估算时，就需要整合项目成本管理、项目进度管理和项目风险管理知识领域中的相关过程。在识别出与各种人员配备方案有关的额外风险时，可能需要再次进行上述某个或某几个过程。
项目管理过程组的各个过程之间经常反复发生联系。例如，在项目早期，规划过程组为执行过程组提供书面的项目管理计划；然后，随着项目的进展，规划过程组还将根据变更情况，更新项目管理计划。
项目整合管理指的是：
- 确保产品、服务或成果的交付日期，项目生命周期以及效益管理计划这些方面保持一致；
- 编制项目管理计划以实现项目目标；
- 确保创造合适的知识并运用到项目中，并从项目中获取必要的知识；
- 管理项目管理计划中活动的绩效和变更；
- 做出针对影响项目的关键变更的综合决策；
- 测量和监督项目进展，并采取适当措施以实现项目目标；
- 收集关于已达成结果的数据，分析数据以获取信息，并与相关方分享信息；
- 完成全部项目工作，正式关闭各个阶段、合同以及整个项目；
- 管理可能需要的阶段过渡。
项目越复杂，相关方的期望越多样化，就需要越全面的整合方法。
项目整合管理的发展趋势和新兴实践项目整合管理知识领域要求整合所有其他知识领域的成果。与整合管理过程相关的发展趋势包括（但不限于）：
- 使用自动化工具。项目经理需要整合大量的数据和信息，因此有必要使用项目管理信息系统(PMIS) 和自动化工具来收集、分析和使用信息，以实现项目目标和项目效益。
- 使用可视化管理工具。有些项目团队使用可视化管理工具，而不是书面计划和其它文档，来获取和监督关键的项目要素。这样，就便于整个团队直观地看到项目的实时状态，促进知识转移，并提高团队成员和其他相关方识别和解决问题的能力。
- 项目知识管理。项目人员的流动性和不稳定性越来越高，就要求采用更严格的过程，在整个项目生命周期中积累知识并传达给目标受众，以防止知识流失。
- 增加项目经理的职责。项目经理被要求介入启动和结束项目，例如开展项目商业论证和效益管理。按照以往的惯例，这些事务均由管理层和项目管理办公室负责。现在，项目经理需要频繁地与他们合作处理这些事务，以便更好地实现项目目标以及交付项目效益。项目经理也需要更全面地识别相关方，并引导他们参与项目，包括管理项目经理与各职能部门、运营部门和高级管理人员之间的接口。
- 混合型方法。经实践检验的新做法会不断地融入项目管理方法，例如，采用敏捷或其他迭代做法，为开展需求管理而采用商业分析技术，为分析项目复杂性而采用相关工具，以及为在组织中应用项目成果而采用组织变革管理方法。
裁剪时需要考虑的因素因为每个项目都是独特的，所以项目经理可能需要裁剪项目整合管理过程。裁剪时应考虑的因素包括（但不限于）：
- 项目生命周期。什么是合适的项目生命周期？项目生命周期应包括哪些阶段？
- 开发生命周期。对特定产品、服务或成果而言，什么是合适的开发生命周期和开发方法？预测型或适应型方法是否适当？如果是适应型，开发产品是该采用增量还是迭代的方式？混合型方法是否为最佳选择？
- 管理方法。考虑到组织文化和项目的复杂性，哪种管理过程最有效？
- 知识管理。在项目中如何管理知识以营造合作的工作氛围？
- 变更。在项目中如何管理变更？
- 治理。有哪些监控机构、委员会和其他相关方该参与项目治理？对项目状态报告的要求是什么？
- 经验教训。在项目期间及项目结束时，应收集哪些信息？历史信息和经验教训是否适用于未来的项目？
- 效益。应该在何时以何方式报告效益：在项目结束时还是在每次迭代或阶段结束时？
在敏捷或适应型环境中需要考虑的因素迭代和敏捷方法能够促进团队成员以相关领域专家的身份参与整合管理。团队成员自行决定计划及其组件的整合方式。
在适应型环境下，《整合管理的核心概念》中所述的对项目经理的期望保持不变，但把对具体产品的规划和交付授权给团队来控制。项目经理的关注点在于营造一个合作型的决策氛围，并确保团队有能力应对变更。如果团队成员具备广泛的技能基础而不局限于某个狭窄的专业领域，那么这种合作型方法就会更加有效。
可在本过程更新任何组织过程资产。
经验教训登记册可以包含情况的类别和描述，经验教训登记册还可包括与情况相关的影响、建议和行动方案。经验教训登记册可以记录遇到的挑战、问题、意识到的风险和机会，或其他适用的内容。
经验教训登记册在项目早期创建，作为本过程的输出。因此，在整个项目期间，它可以作为很多过程的输入，也可以作为输出而不断更新。参与工作的个人和团队也参与记录经验教训。可以通过视频、图片、音频或其他合适的方式记录知识，确保有效吸取经验教训。
在项目或阶段结束时，把相关信息归入经验教训知识库，成为组织过程资产的一部分。
所有项目都会生成新知识。有些知识应该被编撰，并在管理项目知识过程中被嵌入可交付成果，或者被用于改进过程和程序。在本过程中，也可以首次编撰或使用现有知识，例如，关于新程序的现有想法在本项目中试用并获得成功。
可在本过程更新任一组织过程资产。
需要更新的组织过程资产包括（但不限于）：
- 项目文件。在项目活动中产生的各种文件，例如项目管理计划，范围文件、成本文件、进度文件和项目日历，以及变更管理文件。
- 运营和支持文件。组织维护、运营和支持项目交付的产品或服务时所需的文件。可包括新生成的文件，或对已有文件的更新。
- 项目或阶段收尾文件。项目或阶段收尾文件包括表明项目或阶段完工的正式文件，以及用来将完成的项目或阶段可交付成果移交给他人（如运营部门或下一阶段）的正式文件。在项目收尾期间，项目经理应该回顾以往的阶段文件，确认范围过程（见 5.5 节）所产生的客户验收文件，以及合同协议（如果有的话），以确保在达到全部项目要求之后才正式关闭项目。
如果项目在完工前提前终止，则需要在正式的收尾文件中说明项目终止的原因，并规定正式程序，把该项目的已完成和未完成的可交付成果移交他人。
- 经验教训知识库。将在整个项目期间获得的经验教训和知识归入经验教训知识库，供未来项目使用。
规划范围管理是为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。本过程的主要作用是，在整个项目期间对如何管理范围提供指南和方向。本过程仅开展一次或仅在项目的预定义点开展。图 5-2 描述本过程的输入、工具与技术和输出。图 5-3 是本过程的数据流向图。
图 5-2规划范围管理：输入、工具与技术和输出
图 5-3规划范围管理：数据流向图
范围管理计划是项目或项目集管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。制定范围管理计划和细化项目范围始于对下列信息的分析：项目章程（见 4.1.3.1 节）中的信息、项目管理计划（见 4.2.3.1 节）中已批准的子计划、组织过程资产（见 2.3 节）中的历史信息和相关事业环境因素（见 2.2 节）。
以下会议可作为控制质量过程的一部分：
- 审查已批准的变更请求。对所有已批准的变更请求进行审查，以核实它们是否已按批准的方式实施，确认是否已完成局部变更，以及是否已执行、测试、完成和证实所有部分。
- 回顾/经验教训。项目团队举行的会议，旨在讨论：
- 项目/阶段的成功要素；
- 待改进之处；
- 当前项目和未来项目可增加的内容；
- 可增加到组织过程资产中的内容。
作为获取资源过程的结果，需要更新的组织过程资产包括（但不限于）有关采购、配置和分配资源的文件。
作为建设团队过程的结果，需要更新的组织过程资产包括（但不限于）：
- 培训需求；
- 人事评测。
可在本过程更新的组织过程资产包括（但不限于）：
- 项目记录，例如往来函件、备忘录、会议记录及项目中使用的其他文档；
- 计划内的和临时的项目报告和演示。
风险管理计划是项目管理计划的组成部分，描述如何安排与实施风险管理活动。风险管理计划可包括以下部分或全部内容：
- 风险管理战略。描述用于管理本项目的风险的一般方法。
- 方法论。确定用于开展本项目的风险管理的具体方法、工具及数据来源。
- 角色与职责。确定每项风险管理活动的领导者、支持者和团队成员，并明确他们的职责。
- 资金。确定开展项目风险管理活动所需的资金，并制定应急储备和管理储备的使用方案。
- 时间安排。确定在项目生命周期中实施项目风险管理过程的时间和频率，确定风险管理活动并将其纳入项目进度计划。
- 风险类别。确定对单个项目风险进行分类的方式。通常借助风险分解结构 (RBS)来构建风险类别。风险分解结构是潜在风险来源的层级展现（示例见图 11-4）。风险分解结构有助于项目团队考虑单个项目风险的全部可能来源，对识别风险或归类已识别风险特别有用。组织可能有适用于所有项目的通用风险分解结构，也可能针对不同类型项目使用几种不同的风险分解结构框架，或者允许项目量身定制专用的风险分解结构。如果未使用风险分解结构，组织则可能采用某种常见的风险分类框架，既可以是简单的类别清单，也可以是基于项目目标的某种类别结构。
图 11-4风险分解结构（RBS）示例
- 相关方风险偏好。应在风险管理计划中记录项目关键相关方的风险偏好。他们的风险偏好会影响规划风险管理过程的细节。特别是，应该针对每个项目目标，把相关方的风险偏好表述成可测量的风险临界值。这些临界值不仅将联合决定可接受的整体项目风险敞口水平，而且也用于制定概率和影响定义。以后将根据概率和影响定义，对单个项目风险进行评估和排序。
- 风险概率和影响定义。根据具体的项目环境，组织和关键相关方的风险偏好和临界值，来制定风险概率和影响定义。项目可能自行制定关于概率和影响级别的具体定义，或者用组织提供的通用定义作为出发点。应该根据拟开展项目风险管理过程的详细程度，来确定概率和影响级别的数量，即：更多级别（通常为五级）对应于更详细的风险管理方法，更少级别（通常为三级）对应于更简单的方法。表 11-1 针对三个项目目标提供了概率和影响定义的示例。
通过将影响定义为负面威胁（工期延误、成本增加和绩效不佳）和正面机会（工期缩短、成本节约和绩效改善），表格所示的量表可同时用于评估威胁和机会。
表 11-1概率和影响定义示例
- 概率和影响矩阵。见 11.3.2.6 节。组织可在项目开始前确定优先级排序规则，并将其纳入组织过程资产，或者也可为具体项目量身定制优先级排序规则。在常见的概率和影响矩阵中，会同时列出机会和威胁；以正面影响定义机会，以负面影响定义威胁。概率和影响可以用描述性术语（如很高、高、中、低和很低）或数值来表达。如果使用数值，就可以把两个数值相乘，得出每个风险的概率 - 影响分值，以便据此在每个优先级组别之内排列单个风险相对优先级。
图 11-5 是概率和影响矩阵的示例，其中也有数值风险评分的可能方法。
图 11-5概率和影响矩阵示例（有评分方法）
- 报告格式。确定将如何记录、分析和沟通项目风险管理过程的结果。在这一部分，描述风险登记册、风险报告以及项目风险管理过程的其他输出的内容和格式。
- 跟踪。跟踪是确定将如何记录风险活动，以及将如何审计风险的管理过程。
可在本过程更新的组织过程资产包括（但不限于）：
- 风险管理计划、风险登记册和风险报告的模板；
- 风险分解结构。
作为规划采购管理过程的结果，需要更新的组织过程资产包括（但不限于）关于合格卖方的信息。
对于采购次数少且相对简单的项目，作为本过程输出的有些文件可以合并。不过，对于采购规模较大、较复杂，而且大部分工作需由承包商完成的项目，就需要使用几种不同类型的文件。表 12-1 列出了采购中常用的文件类型及其部分内容。鉴于采购的法律性质，不应把表 12-1 的内容看成规定性描述，而只应该把它们看成关于所需文件的类型和内容的总体大纲，用于指导实施采购工作。组织、环境和法律规定会决定项目具体需要的文件类型和内容。
表 12-1采购文件比较
可在实施采购过程更新的组织过程资产包括：
- 潜在和预审合格的卖方清单；
- 与卖方合作的相关经验，包括正反两方面。
作为控制采购过程的结果，需要更新的组织过程资产包括（但不限于）：
- 支付计划和请求。所有支付都应按合同条款和条件进行。
- 卖方绩效评估文件。卖方绩效评估文件由买方准备，用于记录卖方继续执行当前合同工作的能力，说明是否允许卖方承接未来的项目，或对卖方现在的项目执行工作或过去的执行工作进行评级。
- 预审合格卖方清单更新。预审合格卖方清单是以前已经通过资格审查（获得批准）的潜在卖方的清单。因为卖方可能因绩效不佳而被取消资格并从清单中删除，所以应该根据控制采购过程的结果来更新这个清单。
- 经验教训知识库。经验教训应该归档到经验教训知识库中，以改善未来项目的采购工作。在合同执行终了时，应把采购的实际成果与原始采购管理计划中的预期成果进行比较。应该在经验教训中说明项目目标是否达成；若未达成，则说明原因。
- 采购档案。应该准备好带索引的全套合同文档，包括已关闭的合同，并将其纳入最终的项目档案。
项目所处的环境可能对项目的开展产生有利或不利的影响。这些影响的两大主要来源为事业环境因素 (EEF) 和组织过程资产 (OPA)。
事业环境因素源于项目外部（往往是企业外部）的环境，是项目团队不能控制且将影响、制约或指引项目的各种条件。事业环境因素可能对整个企业、项目组合、项目集或项目产生影响。（有关事业环境因素的更多信息，请参阅《PMBOK® 指南》第 2.2 节。）内部的组织文化、组织结构和组织治理就是事业环境因素中的一个类别，其中包括（但不限于）：愿景、使命、价值观、信念、文化传统、等级制度和职权关系。
组织过程资产源于企业内部，可能来自企业自身、项目组合、项目集、其他项目或这些的组合。
组织过程资产是执行组织所特有并使用的计划、过程、政策、程序和知识库，会影响对具体项目的管理，包括（但不限于）：变更控制程序、模板、来自以往项目的信息和经验教训知识库。（有关组织过程资产的更多信息，请参阅《PMBOK® 指南》第 2.3 节）。
在本标准中，术语“工件”包括项目管理过程、输入、工具、技术、输出、事业环境因素和组织过程资产。项目经理和项目管理团队需要选择和调整合适的工件，用于其特定项目。这种选择和调整活动称为裁剪。每个项目的独特性决定了必须进行裁剪，因此，并非每个项目都需要每个过程、输入、工具、技术或输出。
项目管理计划是最常用的工件，有许多组成部分，如子管理计划、基准和项目生命周期描述。
子管理计划是与项目特定方面或知识领域相关的计划，如进度管理计划、风险管理计划和变更管理计划。进行裁剪时，需要确定特定项目所需的项目管理计划组件。项目管理计划是一种输入，而项目管理计划更新是本标准中许多过程的输出。在本标准中，不会在输入和输出表中直接列出单个项目管理计划组件，而是在该表下方的正文中列出每个过程可能用到的项目管理计划组件（输入）或可能得到的项目管理计划组件更新（输出）。所列出的组件仅为示例而已。在开展每个特定过程时，项目经理既非必须、也非限于用到上述输入或得到上述输出。
项目管理计划是主要的项目工件之一。另外，还有不属于项目管理计划但也可用于管理项目的其他文件。这些其他文件称为项目文件。与项目管理计划组件类似，过程所需的项目文件会因具体项目而异。项目经理负责确定过程所需的项目文件，以及将作为过程输出的项目文件更新。在本标准中，在输入和输出表下方的正文中列出的项目文件，仅为项目文件的可能示例，而非完整列表。
表 1-2 列出了项目管理计划的主要组件和主要的项目文件。虽然该表并未穷尽所有的计划组件和项
目文件，但的确列出了有助于管理项目的常用计划组件和项目文件。
表 1-2项目管理计划和项目文件
商业文件通常是在项目之外创建的文件，用作项目的输入。商业文件包括商业论证和效益管理计划。如何应用商业文件，将取决于公司文化和项目启动过程。
会影响项目的事业环境因素，以及可用于项目的组织过程资产，将因项目及其所处环境而异，所以并未在本标准中列出。
实施整体变更控制是指审查所有变更请求，批准变更，管理对可交付成果、组织过程资产、项目文件和项目管理计划的变更，并对变更处理结果进行沟通的过程。本过程审查对项目文件、可交付成果或项目管理计划的所有变更请求，并决定对变更请求的处置方案。本过程的主要作用是，确保对项目中已记录在案的变更做综合评审。如果不考虑变更对整体项目目标或计划的影响就开展变更，往往会加剧整体项目风险。本过程需要在整个项目期间开展。图 5-3 描述了本过程的输入和输出。
图 5-3实施整体变更控制：输入和输出
究竟需要哪些项目管理计划组件和项目文件，取决于具体项目的需求。
以下业务规则用于确保每个项目管理过程中输入和输出的顺序及信息的一致性：
- 基本规则：
- 输入是对过程很关键的任何文件。
- 除非输出为最终输出或被其他输入（如项目文件）采纳，否则输出应成为另一个项目管理过程的输入。
- 若输入并非来自项目外部，它们应该是其他项目管理过程的输出。
- 项目文件规则：
- 具体项目文件首次被识别时会列为具体输出。然后，它们将作为“项目文件更新”列入输出清单，内容叙述部分会对其加以描述。
- 当任何项目文件是输入时，会列出“项目文件”一词，而且内容叙述部分会说明具体的项目文件。
- 项目管理计划规则：
- 对于会制定子计划的规划过程来说，项目章程是第一项输入，项目管理计划为第二项输入。
- 创建项目管理计划组件的过程将具体列出组成部分。在此之后，它们会作为“项目管理计划更新”列入输出清单，内容叙述部分会对其加以描述。
- 如果项目管理计划是过程输入，在内容叙述部分可能会对视为输入的具体项目管理计划组成部分进行说明。
- 排序规则：
- 若项目章程是输入，则其为第一项输入。
- 如果项目管理计划是输入或输出，子管理计划会按《PMBOK® 指南》中输出它们的章节顺序列出，随后列出基准和任何其他计划。
- 项目文件会以字母排列顺序列出。
- 事业环境因素和组织过程资产也会按该顺序列在末尾。
- 如果更新是输出，它们的排列顺序如下：
项目管理计划更新；
项目文件更新；
组织过程资产更新。
第 2 章的内容进行了大量重写。关于组织过程资产和事业环境因素的信息保留不变，但新增了关于治理、管理要素和组织结构类型的内容。