第四章：项目整合管理 - （4.6 实施整体变更控制）

实施整体变更控制：

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

过程图：

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

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

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

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

输入：

1、项目管理计划

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

       a、变更管理计划。变更管理计划为管理变更控制过程提供指导，并记录变更控制委员会（CCB）的角色和职责。

       b、配置管理计划。配置管理计划描述项目的配置项、识别应记录和更新的配置项，以便保持项目产品的一致性和有效性。

       c、范围基准。范围基准提供项目和产品定义。

       d、进度基准。进度基准用于评估变更对项目进度的影响。

       e、成本基准。成本基准用于评估变更对项目成本的影响。

2、项目文件

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

       a、估算依据。估算依据指出了持续时间、成本和资源估算是如何得出的，可用于计算变更对时间、预算和资源的影响。

       b、需求跟踪矩阵。需求跟踪矩阵有助于评估变更对项目范围的影响。

       c、风险报告。风险报告提供了与变更请求有关的整体和单个项目风险的来源的信息。

3、工作绩效报告

       对实施整体变更控制过程特别有用的工作绩效报告包括：资源可用情况、进度和成本数据、挣值报告、燃烧图或燃尽图。

4、变更请求       

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

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

5、事业环境因素

       能够影响实施整体变更控制过程的事业环境因素包括（但不限于）：

       a、法律限制，例如国家或地区法规；

       b、政府或行业标准（如产品标准、质量标准、安全标准和工艺标准）；

       c、法律法规要求和（或）制约因素；

       d、组织治理框架（通过安排人员、制定政策和确定过程，以结构化的方式实施控制、指导和协调，以实现组织的战略和运营目标）；

       e、合同和采购制约因素。

6、组织过程资产

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

       a、变更控制程序，包括修改组织标准、政策、计划和程序（或任一项目文件）所须遵循的步骤，以及如何批准和确认变更；

       b、批准与签发变更的程序；

       c、配置管理知识库，包括组织标准、政策、程序和项目文件的各种版本及基准。

工具与技术：

1、专家判断

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

       a、关于项目所在的行业以及项目关注的领域的技术知识；

       b、法律法规；

       c、法规与采购；

       d、配置管理；

       e、风险管理

2、变更控制工具

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

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

       a、识别配置项。识别与选择配置项，从而为定义与核实产品配置、标记产品和文件、管理变更和明确责任提供基础。

       b、记录并报告配置项状态。关于各个配置项的信息记录和报告。

       c、进行配置项核实与审计。通过配置核实与审计，确保项目的配置项组成的正确性，以及相应的变更都被登记、评估、批准、跟踪和正确实施，从而确保配置文件所规定的功能要求都已实现。

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

       a、识别变更。识别并选择过程或项目文件的变更项。

       b、记录变更。将变更记录为合适的变更请求。

       c、做出变更决定。审查变更，批准、否决、推迟对项目文件、可交付成果或基准的变更或做出其他决定。

       d、跟踪变更。确认变更被登记、评估、批准、跟踪并向相关方传达最终结果。

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

3、数据分析

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

       a、备选方案分析。该技术用于评估变更请求，并决定哪些请求可接受、应否决或需修改。

       b、成本效益分析。该分析有助于确定变更请求是否值得投入相关成本。

4、决策

       可用于本过程的决策技术包括（但不限于）：

       a、投票。投票可以采取一致同意、大多数同意或相对多数原则的方式，以决定是否接受、推迟或否决变更请求。

       b、独裁型决策制定。采用这种决策技术，将由一个人负责为整个集体制定决策。

       c、多标准决策分析。该技术借助决策矩阵，根据一系列预定义的准则，用系统分析方法评估变更请求。

5、会议

       与变更控制委员会（CCB）一起召开变更控制会。变更控制委员会负责审查变更请求，并做出批准、否决或推迟的决定。大部分变更会对时间、成本、资源或风险产生一定的影响，因此，评估变更的影响也是会议的基本工作。此外，会议上可能还要讨论并提议所请求变更的备选方案。最后，将会议决定传达给提出变更请求的责任人或小组。

       CCB 也可以审查配置管理活动。应该明确规定变更控制委员会的角色和职责，并经相关方一致同意后，记录在变更管理计划中。CCB 的决定都应记录在案，并向相关方传达，以便其知晓并采取后续行动。

输出：

1、批准的变更请求

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

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

2、项目管理计划更新

       项目管理计划的任一正式受控的组成部分，都可通过本过程进行变更。对基准的变更，只能基于最新版本的基准且针对将来的情况，而不能变更以往的绩效。这有助于保护基准和历史绩效数据的严肃性和完整性。

3、项目文件更新

       正式受控的任一项目文件都可在本过程变更，通常在本过程更新的一种项目文件是变更日志。 变更日志用于记录项目期间发生的变更。