一、变更管理基本概念（掌握）
1. 项目变更的含义
变更管理的实质，是根据项目推进过程中越来越丰富的项目认知，不断调整项目努力方向和资源配置，最大程度地满足项目需求，提升项目价值。
2. 变更产生的原因
变更的常见原因有6个：
| 序号 | 原因 |
|---|---|
| ① | 产品范围（成果）定义的过失或者疏忽 |
| ② | 项目范围（工作）定义的过失或者疏忽 |
| ③ | 增值变更 |
| ④ | 应对风险的紧急计划或回避计划 |
| ⑤ | 项目执行过程与基准要求不一致带来的被动调整 |
| ⑥ | 外部事件 |
📌 记忆口诀：产项增应基外（产品范围、项目范围、增值、应对风险、基准不一致、外部事件）
3. 变更分类
| 分类维度 | 类型 | 说明 |
|---|---|---|
| 按性质 | 重大变更、重要变更、一般变更 | 通过不同审批权限控制 |
| 按迫切性 | 紧急变更、非紧急变更 | 通过不同变更处理流程进行 |
4. 变更管理原则
变更管理的原则是项目基准化、变更管理过程规范化。包括7项：
| 序号 | 原则 |
|---|---|
| (1) | 基准管理：基准是变更的依据 |
| (2) | 变更控制流程化：所有变更都必须遵循这个控制流程进行控制 |
| (3) | 明确组织分工：至少应明确变更相关工作的评估、评审、执行的职能 |
| (4) | 与干系人充分沟通：须征求项目重要干系人的意见，获得对项目变更的支持 |
| (5) | 变更的及时性：变更宜早不宜晚，只做必须要变更的。由于变更可能带来连锁反应，所以可做可不做的，尽量不做 |
| (6) | 评估变更的可能影响：变更的来源是多样的，既需要完成对客户可视的成果、交付期等变更操作，还需要完成对客户不可视的项目内部工作的变更 |
| (7) | 妥善保存变更产生的相关文档：确保其完整、及时、准确、清晰，适当时可以引入配置管理工具 |
5. 变更管理与相关活动的关系
（1）变更管理与项目整合管理的关系
变更管理是项目整合管理的一部分，实施整体变更控制过程贯穿项目始终。
（2）变更管理与配置管理的关系
项目的配置管理计划应规定哪些项目组件受控于配置控制程序。对配置项的任何变更都应该提出变更请求，并经过变更控制。
| 对比维度 | 配置管理 | 变更管理 |
|---|---|---|
| 关注重点 | 可交付产品（包括中间产品）及各过程文档 | 识别、记录、批准或否决对项目文件、可交付产品或基准的变更 |
| 包含关系 | 变更管理过程中包含部分配置管理活动：配置项识别、配置状态记录、配置确认与审计 |
二、角色与职责（掌握）
1. 项目经理
项目经理在变更中的作用：
- 响应变更提出者的需求
- 评估变更对项目的影响及应对方案
- 将需求由技术要求转化为资源需求，供授权人决策
- 依据变更评审结果调整基准，确保项目基准反映项目实施情况
- 监控变更及已批准的变更正确实施
2. 变更控制委员会（CCB）
CCB是由主要项目干系人代表组成的一个正式团体 ，它是决策机构，不是作业机构，通过评审手段决定项目基准是否能变更。
主要职责：
- 负责审查、评价、批准、推迟或否决项目变更
- 将变更申请的批准、否决或推迟的决定通知受此处置意见影响的相关干系人
- 接收变更与验证结果，确认变更是否按要求完成
3. 变更管理负责人（变更经理）
通常是变更管理过程解决方案的负责人，主要职责：
- 负责整个变更过程方案的结果
- 负责变更管理过程的监控
- 负责协调相关的资源，保障所有变更按照预定过程顺利运作
- 确定变更类型，组织变更计划和日程安排
- 管理变更的日程安排
- 变更实施完成之后的回顾和关闭
- 承担变更相关责任，并且具有相应权限
- 可能以逐级审批形式或团队会议的形式参与变更的风险评估和审批等
4. 变更请求者
需要具备理解变更过程的能力要求，提出变更需求。主要职责：
- 提出变更需求，记录并提交变更请求单
- 初步评价变更的风险和影响，给变更请求设定适当的变更类型
5. 变更实施者
需要具备执行变更方案的技术能力，按照批准的变更计划实施变更的内容（包括必要时的恢复步骤）。主要职责：
- 负责按照变更计划实施具体的变更任务
- 负责记录并保存变更过程中的产物，将变更后的基准纳入项目基准中
- 参与变更正确性的验证与确认工作
6. 变更顾问委员会
主要职责：
- 在紧急变更时，可以对被授权者行使审批权限
- 定期听取变更经理汇报，评估变更管理执行情况，必要时提出改进建议等
变更管理角色关系图
三、工作程序（掌握）
变更的完整流程共8个步骤：
| 步骤 | 说明 |
|---|---|
| ①变更申请 | 变更的提出应当及时以正式方式进行，并留下书面记录。项目的干系人都可以提出变更申请，但一般情况下都需要经过指定人员进行审批，一般项目经理或者项目配置管理员负责相关信息的收集，以及对变更申请的初审 |
| ②对变更的初审 | 目的：①对变更提出方施加影响，确认变更的必要性，确保变更有价值；②格式校验、完整性校验，确保评估所需信息准备充分；③在干系人间就提出供评估的变更信息达成共识。常见方式为变更申请文档的审核流转 |
| ③变更方案论证 | 对变更请求是否可实现进行论证，如果可能实现，则将变更请求由技术要求转化为资源需求，以供CCB决策。大型变更可召开变更方案论证会议，由变更顾问委员会进行相关论证 |
| ④变更审查 | 评审过程常包括客户、相关领域的专业人士等。审查通常是文档、会签形式，重大的变更审查可以采用正式会议形式。应将专业评审、经济评审分开，对于涉及项目目标和交付成果的变更，客户和服务对象的意见应放在核心位置 |
| ⑤发出通知并实施 | 变更评审通过后，意味着基准的调整，同时确保变更方案中的资源需求及时到位。如果变更造成交付期的调整，应在变更确认时发布，而非在交付前公布 |
| ⑥实施监控 | 由项目经理负责基准的监控。CCB监控变更的主要成果、进度里程碑等，也可以通过监理单位完成监控 |
| ⑦效果评估 | 评估依据是项目的基准；结合变更的初衷来看，变更所要达到的目的是否已达成；评估变更方案中的技术论证、经济论证内容与实施过程的差距，并促发解决 |
| ⑧变更收尾 | 判断发生变更后的项目是否已纳入正常轨道。配置基准调整后，需要确认资源配置是否及时到位，若涉及人员的调整，则需要更加关注。变更完成后对项目的整体监控应按新的基准进行 |
📌 记忆口诀：申初论审通监评收（申请→初审→论证→审查→通知实施→监控→评估→收尾）
变更管理8步流程图
四、变更控制（掌握）
1. 变更申请的控制
变更申请是变更管理流程的起点，故应严格控制变更申请的提交。变更控制的前提是项目基准健全，变更处理的流程事先达成共识。严格控制是指变更管理体系能确保项目基准反映项目的实施情况。变更申请的提交，首先应当确保覆盖所有变更操作，这意味着如果变更申请操作可以被绕过，那么变更申请的严格管理便毫无意义。
2. 变更内容的控制
| 控制类型 | 说明 |
|---|---|
| 对进度变更的控制 | 确保进度变更经过评估和审批 |
| 对成本变更的控制 | 确保成本变更经过评估和审批 |
| 对合同变更的控制 | 规定合同修改的过程，包括文书工作、跟踪系统、争议解决程序以及批准变更所需的审批层次。合同变更控制应当与整体变更控制结合起来 |
3. 变更类型的控制
| 类型 | 说明 |
|---|---|
| 标准变更 | 低风险、预先授权的变更，已得到充分理解和完整记录，可在不需要额外授权的情况下实现。通常作为服务请求发起，也可以是操作改变。风险评估只需在创建或修改标准变更时进行一次，不需每次重复 |
| 正常变更 | 常规的、较低风险的变更，依据8步工作程序，通过已确定的变更授权角色和变更管理流程进行管理。组织可通过使用自动化（如CI/CD）来提高变更效率 |
| 紧急变更 | 通常不包括在变更计划中，必须快速响应，尽快实施，例如业务中断故障或事故、安全攻击等。处理紧急变更的程序在需要时可以精简，遇到紧急变化时和决策权限变更时可以临时调整 |
4. 变更输入输出的控制
| 控制类型 | 内容 |
|---|---|
| 变更输入的控制 | ①项目控制变更的基准、项目计划、配置管理计划、项目文件和组织过程资产等；②变更前的项目工作绩效报告；③提出的变更请求和变更方案等 |
| 变更输出的控制 | ①批准的变更请求；②更新的项目基准、更新的项目计划、配置管理计划、项目文件和变更日志等；③变更后的项目工作绩效报告，对比变更执行效果；④共享经验教训，如偏差产生的原因，已采取的行动措施，以及所吸取的经验教训，使其成为本项目和实施组织内其他项目历史数据的组成部分 |
五、版本发布和回退计划（掌握）
版本发布是变更实施后的重要环节，需要做好充分的准备工作，并制定回退计划以应对意外情况。
1. 版本发布前的准备工作
| 序号 | 准备工作内容 |
|---|---|
| ① | 进行相关的回退分析 |
| ② | 备份版本发布所涉及的存储过程、函数等其他数据的存储及回退管理 |
| ③ | 备份配置数据，包括数据备份的方式 |
| ④ | 备份在线生产平台接口、应用、工作流等版本 |
| ⑤ | 启动回退机制的触发条件 |
| ⑥ | 对变更回退的机制职责的说明，如通知相关部门，确定需要回退的关联系统和回退时间点等 |
📌 记忆口诀：回退分析→数据备份→配置备份→平台备份→触发条件→职责说明
2. 回退步骤
当版本发布出现问题需要回退时，应按照以下步骤执行：
| 序号 | 回退步骤 |
|---|---|
| ① | 通知相关用户系统开始回退 |
| ② | 通知各关联系统进行版本回退 |
| ③ | 回退存储过程等数据对象 |
| ④ | 配置数据回退 |
| ⑤ | 应用程序、接口程序、工作流等版本回退 |
| ⑥ | 回退完成通知各周边关联系统 |
| ⑦ | 回退后进行相关测试，保证回退系统能够正常运行 |
| ⑧ | 通知用户回退完成 |
📌 记忆口诀：通知用户→通知关联→回退数据→回退配置→回退应用→通知周边→测试验证→通知完成
版本发布回退步骤流程图
六、本章真题小测
Q1：项目变更的常见原因一般不包括（）。
A. 项目范围（工作）定义的过失或者疏忽
B. 应对风险的紧急计划，但不包括回避计划
C. 项目执行过程与基准要求不一致带来的被动调整
D. 外部灾害天气
Q2：项目变更的依据是（）。
A. 干系人的需求 B. 甲方的要求 C. 项目基准 D. 项目成员的请求
Q3：软件版本发布前的准备工作一般不包括（）。
A. 备份版本发布所涉及的存储过程
B. 启动回退机制的触发条件
C. 系统应急方案
D. 进行相关的回退分析
Q4：在项目的实施阶段，当客户明确提出某项需求更改时，项目经理应该（）。
A. 与客户方领导进行沟通，尽量劝说其不要更改需求
B. 先评估变更会对项目带来怎样的影响，然后再与客户协商解决措施
C. 接受客户的变更请求，启动变更控制流程，遵循变更流程进行更改
D. 汇报给高层领导，由领导决定
Q5：关于变更的流程和规则的做法中，错误的是（）。
A. 以口头方式提出某项变更，在评估前针对该变更提交了书面报告
B. 项目组成员变更以邮件发出，在评审前填写了变更申请
C. 为了规范，监理不对变更进行分级，所有变更流程都不能简化
D. 按照影响范围、紧急程度把变更分为3个优先级别
Q6：在对一项任务的检查中，项目经理发现一个团队成员正在用与WBS字典规定不符的方法来完成这项工作。项目经理应首先（）。
A. 告诉这名团队成员采取纠正措施
B. 确定这种方法对职能经理而言是否尚可接受
C. 问这名团队成员，这种变化是否必要
D. 确定这种变化是否改变了工作包的范围
Q7：某项目已制定了详细的范围说明书，并完成了WBS分解。在项目执行过程中，项目经理在进行下一周工作安排的时候，发现WBS中遗漏了一项重要的工作，那么接下来他应该首先（）。
A. 组织项目组讨论，修改WBS
B. 修改项目管理计划，并重新评审
C. 汇报给客户，与其沟通，重新编写项目文档
D. 填写项目变更申请，对产生的工作量进行估算，等待变更委员会审批
Q8：变更管理首要完成的任务是（）。
A. 分析变更的必要性和合理性，确认是否实施变更
B. 记录变更信息、填写变更控制单
C. 做出变更，并交上级审批
D. 修改相应的软件配置项（基线），确立新的版本
Q9：在进行项目整体变更控制过程中，首先要受理变更申请，接下来（）。
A. 接受或拒绝变更
B. 执行变更
C. 进行变更结果追踪与审核
D. 进行变更的整体影响分析
📩 答案：
Q1：B（应对风险的紧急计划或回避计划都属于变更的常见原因，B选项说不包括回避计划是错误的）
Q2：C（项目基准是变更的依据）
Q3：C（系统应急方案不属于版本发布前的准备工作，准备工作包括回退分析、数据备份、配置备份、平台备份、触发条件、职责说明）
Q4：B（应先评估变更影响，再与客户协商）
Q5：C（变更应根据影响范围、紧急程度进行分级，不同级别流程可以简化，不能一刀切）
Q6：D（首先应确定这种变化是否改变了工作包的范围，即判断是否为变更）
Q7：D（发现WBS遗漏工作属于范围变更，应首先提交变更申请）
Q8：A（变更管理首要任务是分析变更的必要性和合理性，确认是否实施）
Q9：D（受理变更申请后，下一步应进行变更的整体影响分析）