---

上篇：第十六章、信息（文档）和配置管理
下篇：第十八章、安全管理

第十七章 变更管理

---

17.1 项目变更的基本概念

变更管理是为了使项目实际执行情况和项目基准相一致而对项目变更进行管理，其可能的结果是拒绝或者调整基准。

从资源增值视角看，变更的实质是项目过程中，按一定流程、根据变化了的情况更新方案、调整资源的配置方式或将储备资源运用于项目中，以满足客户相关干系人的需求。

变更管理的实质是根据项目推进过程中越来越丰富的项目认知、不断调整项目努力方向和资源配置，最大程度地满足客户等相关干系人的需求，提升项目价值。

变更管理是项目整体管理的一部分，属于项目整体变更控制的范畴。涉及到范围、进度、成本、质量、人力资源和合同管理等多个方面。

变更管理就是要控制变更，保证项目可控；另一个是变更度量分析，帮助组织提供自己的开发能力。

项目变更：

• 概述：项目变更是指信息系统项目的实施过程中，由于项目环境或者其他原因而对项目产品的功能、性能、架构、技术指标、集成方法、项目的范围基准、进度基准和成本基准等方面做出的改变。项目变更贯穿于整个项目过程的始终，项目越往后进行，变更成本越大。
• 分类：
  • 按变更性质（可通过不同审批权限控制）
    • 重大变更
    • 重要变更
    • 一般变更
  • 按变更的迫切性（可通过不同的变更处理流程进行控制）
    • 紧急变更
    • 非紧急变更
  • 按变更所发生的领域和阶段
    • 进度变更
      • 对进度变更的控制包括以下主题：
        • （1）判断项目进度的当前状态
        • （2）对造成进度变更的因素施加影响
        • （3）查明进度是否已经改变
        • （4）在实际变更出现时对其进行管理
    • 成本变更
    • 质量变更
    • 设计变更
    • 实施变更
    • 工作（产品）范围变更
  • 按照来源
    • 内部变更
    • 外部变更
• 产生原因：
  • （1）产品范围（成果）定义的过失或者疏忽
  • （2）项目范围（工作）定义的过失或者疏忽
  • （3）客户提出新需求
  • （4）应对风险的积极措施或规避措施
  • （5）项目执行过程与基准要求不一致带来的被动调整（如进度，质量，成本等）
  • （6）项目团队人员调整
  • （7）技术革新的要求
  • （8）外部事件（例如政策变动或自然环境变化等）
• 变更注意项：
  1. 对变更产生的因素施加影响，防止不必要的变更和无谓的评估
  2. 变更的操作过程应当规范化
  3. 对变更的确认应当正式化

---

17.2 变更管理的基本原则

基本原则：是首先建立项目基准，变更流程和变更控制委员会（也称变更管理委员会）

---

17.3 角色职位与工作程序

角色职责：

• 变更申请人
  • 职责：提出变更申请的相关人员，项目的任何干系人都可以提出变更申请
• 项目经理
  • 职责：对项目负责，也对整个项目变更管理过程负责。项目经理负责变更申请的影响分析，负责召开变更控制委员会会议
• 变更控制委员会（CCB）
  • 职责：负责审查，评价，批准，推迟或否决项目变更。CCB 由项目所涉及的多方人员共同组成，通常包括甲方和乙方的决策人员，作为决策机构，CCB 在变更管理过程中负责对提交的变 更申请进行审查，并对变更申请做出批准，否则或其他决定
• 配置管理员
  • 职责：变更过程的相关产物应纳入配置管理系统中，配置管理员负责把变更后的基准纳入整个项目的基准中，变更过程中的其他记录文件也应纳入配置管理系统

工作程序：

• 变更程序
  • （1）提出与接受变更申请
    • 变更申请包含：
      • 纠正措施：为了使项目工作绩效与项目管理计划保持一致而进行的变更申请
      • 预防措施：为了确保项目工作的未来绩效符合项目管理计划而进行的变更申请
      • 缺陷补救：为了修正不一致的产品或产品组件而进行的变更申请
      • 更新：对正式受控的项目文件或计划等进行的变更申请，以便反映修改或增加意见或内容
    • 注意：所有的变更申请都必须以书面形式记录，并纳入配置管理系统中
  • （2）变更影响分析
    • 注意：一般由项目经理负责
  • （3）对变更的初审
    • 目的：
      ① 变更提出方施加影响，确认变更的必要性，确保变更是有价值的。
      ② 格式校验，完整性较验，确保评估所需信息准备充分。
      ③ 干系人间就提出供评估的变更信息达成共识。
      ④ 变更初审的常见方式为变更申请文档的审核流转。
  • （4）变更方案论证
  • （5）CCB 审查批准
  • （6）发出变更通知并开始实施
  • （7）监控变更实施
  • （8）变更效果评估
    • 包含方面：
      1. 首要的评估依据是项目基准
      2. 需结合变更的初衷来看，变更所要达到的目的是否已达成
      3. 评估变更方案中的技术论证、经济论证内容与实施过程的差距并推进解决
  • （9）判断发生变更的项目是否已纳入正常轨道
  • （10）结束变更

项目变更管理流程图：

变更的完整流程:

1. 先沟通，然后提出变更申请，应采用书面方式
2. 充分评变更的影响，包括对范围、成本、进度、质量等方方面面的影响，将评估结果通知干系人
3. 按规定变更流程，由CCB进行审批
4. 变更审批未通过则取消变更，纳入监控;
5. 变更审批通过则调整和更新相应的项目计划及文件，并通知干系人
6. 根据要求执行变更、记录变更实施情况7.验证变更，归档等。

变更管理活动：

1. 识别可能发生的变更
2. 管理每个已识别的变更
3. 维持所有基线的完整性
4. 根据已批准的变更，更新范围、进度、成本、预算、质量要求，协调整体项目内的变更
5. 基于质量报告，控制项目质量使其符合标准
6. 维护一个及时、精确的关于项目产品及其相关文档的信息库，直至项目结束

---

17.4 相关事宜

变更管理操作要点：

1.在项目整体压力较大的情况下，更需强调变更管理的规范化，可以使用分批处理，分优先级处理等方式提高效率、如同繁忙的交通道口，如果红绿灯变化频繁，其结果不是灵活高效，而是整体通过能力的降低。
2.项目规模小，与其他项目的关联度小时，变更的提出与处理过程可在操作上力求简便，高效，但仍应注意以下几点：
（1）对变更产生的因素施加影响，防止不必要的变更，减少无谓的评估，提高必要变更的通过效率。
（2）变更的操作过程应当规范化。
（3）对变更的确认应当正式化。

变更管理和整体管理及配置管理的关系：

配置管理重点关注可交付产品（包括中间产品〉及各过程文档（技术之间的匹配问题），而变更管理则着眼于识别、记录、批准或否决对项目文件、可交付产品或基准的变更。
变更管理过程中包含的部分配置管理活动如下：
(1）配置项识别。识别与选择配置项，从而为核实产品配置、标记产品和文件、管理变更和明确责任提供基础。
(2）配置状态记录。为了能及时提供关于配置项的准确数据，应记录和报告配置项的相关信息。此类信息包括变更控制中的已批准的配置项清单、变更申请的状态和已批准变更的实施状态。
(3）配置确认与审计。通过配置确认与配置审计，可以保证项目各配置项组成的正确性，以及相应的变更都被登记、评估、批准、跟踪和正确实施，从而确保配置文件所规定的功能要求都已实现。

---

上篇：第十六章、信息（文档）和配置管理
下篇：第十八章、安全管理