【中项】系统集成项目管理工程师-第10章 项目整合管理-10.6实施整体变更控制

前言：系统集成项目管理工程师专业，现分享一些教材知识点。觉得文章还不错的喜欢点赞收藏的同时帮忙点点关注。 

       软考同样是国家人社部和工信部组织的国家级考试，全称为“全国计算机与软件专业技术资格（水平）考试”，目前涵盖了计算机软件、计算机网络、计算机应用技术、信息系统、信息服务5大领域，总共27个科目，也是分为初、中、高三个级别。

       通信专业主要需要关注“计算机网络”这个专业类别，可以考的科目有初级资格的“网络管理员”、中级的“网络工程师”。

       还有5个高级资格专业，分别是“信息系统项目管理师“”系统分析师“”系统架构设计师“”网络规划设计师“”系统规划与管理师“。

       软考高级证书在通信行业比较吃香，主要原因有两个： 通信行业与计算机软件是相近专业，评职称满足相近专业的要求； 通信高级不能以考代评，但软考高级可以，很多考生通过考软考高级来评高级职称。
————————————————

                       

10.6实施整体变更控制

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

        实施整体变更控制过程贯穿项目始终，项目经理对此承担最终责任（ 中19下）。变更请求可能 影响项目范围、产品范围以及任一项目管理计划组件或任一项目文件。在整个项目生命周期的任何时间，参与项目的任何干系人都可以提出变更请求。

        在基准确定之前，变更无须正式受控并实施整体变更控制过程。一旦确定了项目基准，就必须 通过实施整体变更控制过程来处理变更请求。尽管变更可以口头提出，但所有变更请求都必须以书 面形式记录，并纳入变更管理和（或）配置管理系统中。在批准变更之前，可能需要了解变更对进 度的影响和对成本的影响。在变更请求可能影响任一项目基准的情况下，都需要开展正式的整体变 更控制过程。每项记录在案的变更请求都必须由一位责任人批准、推迟或否决，这个责任人通常是 项目发起人或项目经理（ 中21下）。应该在项目管理计划或组织程序中指定这位责任人，必要时， 应该由CCB来开展实施整体变更控制过程（ 高18上、中23下） 。变更请求得到批准后，可能需要新 编（或修订）成本估算、活动排序、进度日期、资源需求和（或）风险应对方案分析，这些变更可 能会对项目管理计划和其他项目文件进行调整。

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

        变更控制工具的选择应基于项目干系人的需要，并充分考虑组织和环境的情况和制约因素。变 更控制工具需要支持的配置管理活动包括：识别配置项、记录并报告配置项状态、进行配置项核实 与审计等。

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

（2）记录并报告配置项状态：对各个配置项的信息进行记录和报告。

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

变更控制工具还需要支持的变更管理活动包括：识别变更、记录变更、做出变更决定和跟踪变 更等。

（1）识别变更：识别并选择过程或项目文件的变更项。

（2）记录变更：将变更记录为合适的变更请求。

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

（4）跟踪变更：确认变更被登记、评估、批准、跟踪并向干系人传达最终结果。

也可以使用变更控制工具管理变更请求和后续的决策，同时还需要及时沟通，帮助CCB的成员 履行职责，并向干系人传达变更相关的决定。

实施整体变更控制过程的主要输入为项目管理计划、项目文件、工作绩效报告和变更请求，主 要输出为批准的变更请求。

10.6.1主要输入（ 高21上、中23下） ）

1.项目管理计划

        实施整体变更控制过程使用的项目管理计划组件主要包括：变更管理计划、配置管理计划、范 围基准、进度基准和成本基准等。

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

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

（3）范围基准：提供项目和产品定义。

（4）进度基准：用于评估变更对项目进度的影响。

（5）成本基准：用于评估变更对项目成本的影响。

2.项目文件

        可用于实施整体变更控制过程输入的项目文件主要包括：需求跟踪矩阵、风险报告和估算依据等。

（1）需求跟踪矩阵：有助于评估变更对项目范围的影响。

（2）风险报告：提供了与变更请求有关的项目风险的来源的信息。

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

3.工作绩效报告

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

4.变更请求

        项目执行中很多过程都会输出变更请求。变更请求可能包含纠正措施、预防措施、缺陷补救， 以及针对正式受控的项目文件或可交付成果的更新。变更可能影响项目基准，也可能不影响项目基 准，变更决定通常由项目经理做决策。

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

10.6.2主要输出（ 高21下、高20下）

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

10.6.3 变更管理

        变更管理的大致作用与基本操作原则， 已在整合管理、范围管理等相关章节中介绍。但由于变 更管理方法在项目管理中的重要性不断增加，且在实际应用中的影响越来越大，故特设本节单独论 述。变更在信息系统项目过程中经常发生，许多项目失败是对变更处理不当造成的。有些变更是积 极的，有些则是消极的，做好变更管理可以使项目的质量、进度和成本管理更有效。

10.6.3.1 基本概念

1.项目变更的含义

        项目变更是指在信息系统项目的实施过程中， 由于项目环境或者其他的原因而对项目的功能、性能、架构、技术指标、集成方法和项目进度等方面做出的改变。项目管理方法的基本原理，是将 特定的目标通过规范的计划过程，转化为基准共识之后以指导项目执行， 同时作为项目有效监控、 收尾的依据。变更管理，即是为使项目基准与项目实际执行情况相一致，应对项目变化的一套管理 方法（ 高21上）。其可能的结果是拒绝变化，或是调整项目基准。变更管理的实质是根据项目推进 过程中越来越丰富的项目认知，不断调整项目努力方向和资源配置，最大程度地满足项目需求。

2.变更产生的原因

        由于项目具有逐渐完善的基本特性，这意味着早期的共识会随着项目的进行，对项目有不断深 入的理解，作业过程与预先的计划发生变化是必然的。如果持续按照项目早期的定义开展，很难保 质保量地交付项目，因而变更控制必不可少。变更可能是对交付物的需求发生的变化，也可能是项 目范围或是项目的资源、进度等执行过程发生的变化。变更的常见原因包括；

●产品范围（成果）定义的过失或者疏忽；（ 高23上）

●项目范围（工作）定义的过失或者疏忽；

●增值变更；

●应对风险的紧急计划或回避计划；

●项目执行过程与基准要求不一致带来的被动调整；

●外部事件等。 

3.变更分类

        变更分类的方式有很多，需要根据具体项目的类型和组织对项目管理的模式与方法等确定，如 弱电工程、应用开发、集成、IT咨询、IT运维和信息系统开发等。项目业务形态各异，组织管理成 熟度亦有差距，每种业务内容的变更分类方法尚无法统一，组织可在各项目中细化分类，并对不同 内容的变更区别情况提出不同的控制方法，通过不同的变更处理流程进行管理。通常来说，根据变 更性质可分为重大变更、重要变更和一般变更，可通过不同审批权限来控制；根据变更的迫切性可 分为紧急变更、非紧急变更（ 高21下） ；还有根据行业特征进行的变更，如弱电工程行业的常见分 类方法为产品（工作）范围变更、环境变更、设计变更、实施变更和技术标准变更。

4.变更管理原则

        变更管理的原则是项目基准化、变更管理过程规范化（ 中23下） 。变更管理的主要内容包括：基准管理、变更控制流程化、明确组织分工、与干系人充分沟通、变更的及时性、评估变更的可能 影响、妥善保存变更产生的相关文档等。

（1）基准管理：基准是变更的依据。在项目实施过程中，基准计划确定并经过评审后（通常用户应参与部分评审工作），建立初始基准。此后每次变更通过评审后，都应重新确定基准。

（2）变更控制流程化：建立或选用符合项目需要的变更管理流程，所有变更都必须遵循这个控 制流程进行控制。流程化的作用在于将变更的原因、专业能力、资源运用方案、决策权、干系人的 共识、信息流转等元素有效综合起来，按科学的顺序进行。

（3）明确组织分工：至少应明确变更相关工作的评估、评审、执行的职能。

（4）与干系人充分沟通：须征求项目重要干系人的意见，获得对项目变更的支持。

（5）变更的及时性：变更宜早不宜晚，只做必须要变更的。越在项目早期，项目变更的代价越 小，随着项目的开展，项目变更的代价就会越来越大。由于变更可能带来连锁反应，所以可做可不 做的，尽量不做。

（6）评估变更的可能影响：变更的来源是多样的，既需要完成对客户可视的成果、交付期等变 更操作，还需要完成对客户不可视的项目内部工作的变更，如实施方的人员分工、管理工作、资源 配置等。

（7）妥善保存变更产生的相关文档：确保其完整、及时、准确、清晰，适当时可以引入配置管 理工具。

5.变更管理与相关活动的关系

1）变更管理与项目整合管理的关系

        变更管理是项目整合管理的一部分，实施整体变更控制过程贯穿项目始终。实施整体变更控制 是审查所有变更请求、批准变更，管理对可交付成果、项目文件和项目管理计划的变更，并对变更 处理结果进行沟通的过程。一旦确定了项目基准，就必须通过变更管理来处理变更请求。变更请求 可能影响项目范围、产品范围以及项目管理计划组件或任一项目文件，应确保对变更请求做综合评 审。如果不考虑变更对整体项目目标或计划的影响就开展变更，往往会加剧整体项目风险。变更控 制的实施程度，取决于项目所在应用领域、项目复杂程度、合同要求， 以及项目所处的背景与环 境。

        在批准变更之前，需要了解变更对进度、成本、质量、资源等多方面的影响。变更请求得到批 准后，可能需要更新成本估算、活动排序、进度日期、资源需求和风险应对方案分析等，这些变更 可能要求调整项目管理计划和其他项目文件。

2）变更管理与配置管理的关系

        项目的配置管理计划应规定哪些项目组件受控于配置控制程序。对配置项的任何变更都应该提 出变更请求，并经过变更控制。配置管理重点关注可交付产品（包括中间产品）及各过程文档，而 变更管理则着眼于识别、记录、批准或否决对项目文件、可交付产品或基准的变更。变更管理过程中包含的部分配置管理活动如下。

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

●配置状态记录：为了能及时提供关于配置项的准确数据，应记录和报告配置项的相关信息。此 类信息包括变更控制中的已批准的配置项清单、变更申请的状态和已批准变更的实施状态。

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

10.6.3.2角色与职责

        规范的项目实施，提倡分权操作。项目经理是组织委托对项目经营过程负责者，其正式权利由 项目章程取得，而资源调度的权力通常由基准中明确。基准中不包括的储备资源须经授权人批准后 方可使用。通常情况下，项目经理在变更中的作用是，响应变更提出者的需求，评估变更对项目的 影响及应对方案，将需求由技术要求转化为资源要求，供授权人决策。依据变更评审结果调整基 准，确保项目基准反映项目实施情况，并监控变更及已批准的变更正确实施。

        信息系统项目中，通常会定义变更控制委员会（CCB） 、变更管理负责人、变更请求者、变更 实施者和变更顾问委员会等。

1.变更控制委员会（CCB）

        变更控制委员会是由主要项目干系人代表组成的一个正式团体，它是决策机构，不是作业机 构，通过评审手段决定项目基准是否能变更。其主要职责包括：

●负责审查、评价、批准、推迟或否决项目变更；

●将变更申请的批准、否决或推迟的决定通知受此处置意见影响的相关干系人；

●接收变更与验证结果，确认变更是否按要求完成。

2.变更管理负责人（一般指项目经理）

变更管理负责人也称变更经理，通常是变更管理过程解决方案的负责人，其主要职责包括：

●负责整个变更过程方案的结果；

●负责变更管理过程的监控；

●负责协调相关的资源，保障所有变更按照预定过程顺利运作；

●确定变更类型，组织变更计划和日程安排；

●管理变更的日程安排；

●变更实施完成之后的回顾和关闭；

●承担变更相关责任，并且具有相应权限；

●可能以逐级审批形式或团队会议的形式参与变更的风险评估和审批等。 3.变更请求者（任何干系人）

变更请求者需要具备理解变更过程的能力要求，提出变更需求。其主要职责包括：

●提出变更需求，记录并提交变更请求单；

●初步评价变更的风险和影响，给变更请求设定适当的变更类型。 4.变更实施者（软件开发者）

变更实施者需要具备执行变更方案的技术能力，按照批准的变更计划实施变更的内容（包括必 要时的恢复步骤） 。其主要职责包括：

●负责按照变更计划实施具体的变更任务；

●负责记录并保存变更过程中的产物，将变更后的基准纳入项目基准中；

●参与变更正确性的验证与确认工作。 5.变更顾问委员会（专家、高层领导） 变更顾问委员会的主要职责包括：

●在紧急变更时，可以对被授权者行使审批权限；

●定期听取变更经理汇报，评估变更管理执行情况，必要时提出改进建议等。

10.6.3.3工作程序（高21下、19下、18上、中23下、20下）

1.变更申请

        变更的提出应当及时以正式方式进行，并留下书面记录。变更的提出可以是各种形式，但在评 估前应以书面形式提出。项目的干系人都可以提出变更申请，但一般情况下都需要经过指定人员进 行审批，一般项目经理或者项目配置管理员负责相关信息的收集， 以及对变更申请的初审。

2.对变更的初审

        变更初审的目的主要包括：

●对变更提出方施加影响，确认变更的必要性，确保变更是有价值的；（ 高20下）

●格式校验，完整性校验，确保评估所需信息准备充分；

●在干系人间就提出供评估的变更信息达成共识等。变更初审的常见方式为变更申请文档的审核 流转。

3.变更方案论证（ 中23上）

        变更方案的主要作用，首先是对变更请求是否可实现进行论证，如果可能实现，则将变更请求 由技术要求转化为资源需求， 以供CCB决策 。常见的方案内容包括技术评估和经济与社会效益评估，前者评估需求如何转化为成果，后者评估变更方面的经济与社会价值和潜在的风险。

        对于一些大型的变更，可以召开相关的变更方案论证会议，通常需要由变更顾问委员会（相关 技术和经济方面的专家组成）进行相关论证，并将相关专家意见作为项目变更方案的一部分，报项 目CCB作为决策参考。

4.变更审查

        变更审查是项目所有者根据变更申请及评估方案，决定是否变更项目基准。评审过程常包括客户、相关领域的专业人士等。审查通常是文档、会签形式，重大的变更审查可以包括正式会议形式。

        审查过程应注意分工，项目投资人虽有最终的决策权，但通常技术上并不专业。所以应当在评 审过程中将专业评审、经济评审分开，对涉及项目目标和交付成果的变更，客户和服务对象的意见 应放在核心位置。

5.发出通知并实施

        变更评审通过后，意味着基准的调整， 同时确保变更方案中的资源需求及时到位。基准调整包 括项目目标的确认，最终成果、工作内容和资源、进度计划的调整。需要强调的是：变更通知不只 是包括项目实施基准的调整，更要明确项目的交付日期， 以及成果对相关干系人的影响。如变更造 成交付期的调整，应在变更确认时发布，而非在交付前公布。

6.实施监控

        变更实施的监控，除了调整基准中涉及变更的内容外，还应当对项目的整体基准是否反映项目 实施情况负责。通过监控行动，确保项目的整体实施工作是受控的。变更实施的过程监控，通常由 项目经理负责基准的监控。CCB监控变更的主要成果、进度里程碑等，也可以通过监理单位完成监 控。通过对变更实施的监控，确认变更是否正确完成，对于正确完成的变更，需按配置管理计划中 定义的配置控制范围，纳入配置管理系统中。

7.效果评估

变更评估的关注内容主要包括：

●评估依据是项目的基准；

●结合变更的初衷来看，变更所要达到的目的是否已达成；

●评估变更方案中的技术论证、经济论证内容与实施过程的差距并促发解决。 8.变更收尾

变更收尾是判断发生变更后的项目是否已纳入正常轨道。配置基准调整后，需要确认的是资源 配置是否及时到位，若涉及人员的调整，则需要更加关注。变更完成后对项目的整体监控应按新的基准进行。若涉及变更的项目范围及进度，则在变更后的紧邻监控中，应更多关注确认新的基准生 效情况，以及项目实施流程的正常使用情况。

10.6.3.4变更控制

        由于变更的实际情况千差万别，可能简单，也可能相当复杂。越是大型的项目，调整基准的边 际成本越高，随意的调整可能带来的后果也越多，包括基准失效、项目干系人冲突、资源浪费、项 目执行情况混乱等。在项目整体压力较大的情况下，更需强调变更的提出、处理应当规范化，可以 使用分批处理、分优先级等方式提高效率，就如同在繁忙的交通道口，如果红绿灯变化频繁，其实 效不是灵活高效，而是整体通过能力的降低。

        项目规模小，与其他项目的关联度小时，变更的提出与处理过程可在操作上力求简便、高效， 但关于小项目变更仍应注意对变更产生的因素施加影响（如防止不必要的变更，减少无谓的评估， 提高必要变更的通过效率等），对变更的确认应当正式化，变更的操作过程应当规范化等。

        变更管理虽然遵循一致的工作过程，但需要针对不同类型变更， 明确其控制要求。一般来说， 项目的变更控制主要关注变更申请的控制及变更类型的控制。在变更类型控制中，需要重点关注进 度变更控制、成本变更控制和合同变更控制等，其他类型的变更控制需要结合具体变更的重点关注 项，定义其控制要求。

1.变更申请的控制

        由于变更的真实原因和提出背景复杂，如不经评估就快速实施则可能涉及的项目影响难以预 料，而变更申请是变更管理流程的起点，故应严格控制变更申请的提交。变更控制的前提是项目基 准健全，变更处理的流程事先达成共识。严格控制是指变更管理体系能确保项目基准反映项目的实 施情况。

        变更申请的提交，首先应当确保覆盖所有变更操作，这意味着如果变更申请操作可以被绕过， 那么变更申请的严格管理便毫无意义，但项目应根据变更的影响和代价提高变更流程的效率，并在 某些情况下使用进度管理中的快速跟进等方法。例如，委托方和实施方高层管理者已共识的变更请 求，在实施过程中应提高变更执行的效率。

2.变更内容的控制

（1）对进度变更的控制主要包括：

●判断当前项目进度的状态；

●对造成进度变化的因素施加影响；

●查明进度是否已经改变；

●在实际变化出现时对其进行管理。

（2）对成本变更的控制主要包括：

●对造成费用基准变更的因素施加影响；

●确保变更请求获得同意：

●当变更发生时，管理这些实际的变更；

●保证潜在的费用超支不超过授权的项目阶段资金和总体资金；

●监督项目费用绩效，找出与费用基准的偏差；

●准确记录所有的与费用基准的偏差；

●防止错误的、不恰当的或未批准的变更被纳入费用或资源使用报告中；

●就审定的变更，通知利害关系者；

●采取措施，将预期的费用超支控制在可接受的范围内；

●控制项目费用，查找造成正、负偏差的原因。例如，若对费用偏差采取不适当的应对措施，就 可能造成质量或进度问题，或在项目后期产生无法接受的巨大风险等。

（3）对合同变更的控制。合同变更控制是规定合同修改的过程，它包括文书工作、跟踪系统、 争议解决程序以及批准变更所需的审批层次。合同变更控制应当与整体变更控制结合起来。

3.变更类型的控制

1 ）标准变更的控制

        标准变更通常是低风险、预先授权的变更，这类变更已得到充分理解和完整记录，并且可以在 不需要额外授权的情况下实现。它们通常作为服务请求发起，但也可以是操作改变。当创建或修改 标准变更时，对于任何其他变更，应进行全面的风险评估和授权。此风险评估不需要在每次实施标 准变更时重复，只有在对此类执行方式修改时进行评估。

2 ）正常变更的控制

        正常变更通常是常规的、较低风险的变更，依据15.3.3节的工作程序，通过已确定的变更授权角 色和变更管理流程进行管理。组织可通过使用自动化来提高变更效率，使用连续集成和连续部署的  自动化管道控制大部分变更控制过程。

3 ）紧急变更的控制

        紧急变更通常不包括在变更计划中，必须快速响应，尽快实施，例如业务中断故障或事故、安 全攻击等。处理紧急变更的程序在需要时可以精简，遇到紧急变化时和决策权限变更时可以临时调 整，如少数了解业务风险的高级管理人员和重要干系人的决策权发生变化时。在考虑到规避问题复 杂化的风险的同时，尽可能迅速地进行变更，尽可能接受相同的测试，但有些情况下，更全面的测 试和调整可能会在实现之后持续一段时间再进行。

4.变更输入输出的控制

（1）变更输入的控制主要包括：

●项目控制变更的基准、项目计划、配置管理计划、项目文件和组织过程资产等；

●变更前的项目工作绩效报告；

●提出的变更请求和变更方案等。

（2）变更输出的控制主要包括：

●批准的变更请求；

●更新的项目基准，更新的项目计划、配置管理计划、项目文件和变更日志等；

●变更后的项目工作绩效报告，对比变更执行效果；

●共享经验教训，如偏差产生的原因，已采取的行动措施，以及所吸取的经验教训，使其成为本 项目和实施组织内其他项目历史数据的组成部分。

1 #include "stdio.h"
2 void main()
3 {
4     int time;
5     for (time=1;time<=10;time++)
6     printf("%d、喜欢的帮忙点赞收藏加关注哦！\n",time);
7 }