项目变更管理知识总结

信息系统项目管理师（第三版） PMBOK（第五版）考试参考资料。项目变更管理是指项目组织为适应项目运行过程中与项目相关的各种因素的变化，保证项目目标的实现而对项目计划进行相应的部分变更或全部变更，并按变更后的要求组织项目实施的过程。

第16章 项目变更管理 529

• 16.1 项目变更管理的基本概念 529
  • 16.1.3 项目变更的含义 530
    • （1）变更在信息系统工程建设过程中经常发生，许多项目的失败都是由于变化的处理不当。有些变更是积极的，有些则是消极的，做好变更管理可以使项目的质量、进度、成本管理更有效。
    • 变化可能是产品范围，即对交付物的需求发生的变化，也可能是项目范围或是项目的资源、进度等执行过程发生的变化。变更控制不可少。
    • （2）项目变更管理，是指在信息系统工程建设项目的实施过程中，由于项目环境或者其他的原因而对项目的功能、性能、架构、技术指标、集成方法、项目进度等方面做出的改变。
  • 16.1.1 项目变更产生的原因 529
    • （1）产品范围（成果）定义的过失或者疏忽。
    • （2）项目范围（工作）定义的过失或者疏忽。
    • （3）客户提出新需求（增值变更）。
    • （4）应对风险的紧急计划（措施）或回避计划（措施）。
    • （5）项目执行过程与基准要求不一致带来的被动调整（如进度、质量、成本等）。
    • （6）外部事件（如政策变动或自然环境变化等）。
    • （7）项目团队人员调整。
    • （8）技术革新的要求。
  • 16.1.2 项目变更分类 530 项目变更因多种变化而存在，其形式也多种多样，具体分类和进行方式如表 16-1 所示。 
• 原则和工作流程
  • 16.2 项目变更管理原则 530 变更管理的原则是项目基准化、变更管理过程规范化。包括以下内容： ①基准管理∶基准是变更的依据。在项目实施过程中，基准计划确定并经过评审后，通常用户应参与部分评审工作建立初始基准。此后每次变更通过评审后，都应重新确定基准。 ②变更控制流程化∶建立或选用符合项目需要的变更管理流程，所有变更都必须遵循这个控制流程进行控制。流程化的作用在于将变更原因、专业能力、资源运用方案、决策权、干系人的共识、信息流转等元素有效综合起来，按科学的顺序进行。 ③明确组织分工∶至少应明确变更相关工作的评审、执行的职能。 ④评估变更的可能影响∶变更的来源是多样的，既需要完成对客户可视的成果，交付期等变更操作，还需要完成对客户不可视的顼目内部工作的变更，比如实施方的人员分工、管理工作、资源配置等等。 ⑤妥善保存变更产生的相关文档∶确保其完整、及时、准确、清晰。适当引入配置管理工具。
  • 16.3 变更管理组织机构与工作程序 531
    • 16.3.1 组织机构 531
      • （1）项目控制委员会或配置控制委员会（CCB），或相关职能的类似组织是项目的所有者权益代表，负责裁定接受哪些变更。 CCB 由项目所涉及的多方人员共同组成，通常包括用户和实施方的决策人员。 CCB 是决策机构，不是作业机构； 通常 CCB 的工作是通过评审手段来决定项目基准是否能变更，但不提出变更方案。
      • （2）项目经理是受业主委托对项目经营过程负责者，其正式权利由项目章程取得，而资源调度的权力通常由基准中明确。 基准中不包括的储备资源需经授权人批准后方可使用。 项目经理对项目负责、也对整个项目变更管理负责。 项目经理在变更中 的作用是响应变更提出者的需求，评估变更对项目的影响及应对方案，将需求由技术要求转化为资源需求，供授权人决策，并据评审结果实施，即调整基准，确保项目基准反映项目实施情况。
    • 16.3.2 工作程序 531
      • （1）变更管理的工作程序包括以下八个步骤：提出与接受变更申请、对变更的初审、变更方案论证、项目管理委员会审查、发出变更通知并组织实施、变更实施的监控、变更效果的评估、判断发生变更后的项目是否已纳入正常轨道。
      • （2）提出与接受变更申请：变更提出应当及时以正式方式进行，并留下书面记录。变更的提出可以是各种形式，但在评估前应以书面形式的提出。项目的干系人都可以提出变更申请。
      • （3）变更初审的目的如下：
        • 1）对变更提出方施加影响，确认变更的必要性，确保变更是有价值的。
        • 2）格式校验，完整性校验，确保评估所需信息准备充分。
        • 3）在干系人间就提出供评估的变更信息达成共识。变更初审的常见方式为变更申请文档的审核流转。
      • （4）变更评估可以从以下几个方面进行评估：
        • 1）首要的评估依据是项目的基准。
        • 2）还需结合变更的初衷来看，变更所要达到的目的是否已达成。
        • 3）评估变更方案中的技术论证、经济论证内容与实施过程的差距并促发解决。
• 16.4 项目变更管理的工作内容 533
  • 16.4.1 严格控制项目变更申请的提交 533
    • （1）变更申请是变更管理流程的起点，故应严格控制变更申请的提交。变更控制的前提是项目基准健全，对变更处理的流程事先达成共识。
      • 由于变更的真实原因和提出背景复杂，如不经评估而快速实施则可能涉及的项目影响难以预料，而变更申请是变更管理流程的起点，故应严格控制变更申请的提交。
    • （2）变更申请的提交，首先应当确保覆盖所有变更操作，这意味着如果变更申请操作可以被绕过，则此处的严格便毫无意义；但应根据变更的影响和代价提高变更流程的效率。
  • 16.4.2 变更控制 533
    • 变更控制包括如下几个内容：对进度变更的控制、对成本变更的控制和对合同变更的控制。
  • 16.4.3 变更管理与其他项目管理要素的关系 534
    • （1）变更管理与整体管理的关系：变更管理是项目整体管理的一部分，属于项目整体变更控制的范畴。涉及范围、进度、成本、质量、人力资源、合同管理等多个方面，且影响日益变大。
    • （2）变更管理与配置管理的关系：变更管理与配置管理为相关联的两套机制，变更管理由项目交付或基准配置调整时，由配置管理系统调用，变更管理最终应将对项目的调整结果反馈给配置管理系统，以确保项目执行与对项目的账目相一致。
• 16.5 版本发布和回退计划 534
  • 16.5.1 软件版本发布前的准备 534
    • ①进行相关的回退分析;
    • ②备份版本发布所涉及的存储过程、函数等其他数据的存储及回退管理;
    • ③备份配置数据;
    • ④备份在线生产平台接口、应用、工作流等版本;
    • ⑤启动回退机制的触发条件;
    • ⑥对变更回退的机制职责的说明;如通知相关部门，确定需要回退的关联系统和回退时间点等。
  • 16.5.2 版本发布应急回退方案 535
    • （1）对于很多软件项目来说，项目变更就必需做相应的版本发布，并制订相应的应急回退方案。 为确保版本发布的成功，在版本发布前应对每次版本发布进行管理，并做好发布失败后的回退方案。
    • （2）为确保版本发布的成功，在版本发布前应对每次版本发布的风险做相应的评估，对版本发布的过程 Check list 做严格的评审。 在评审发布内容时对存在风险的发布项做重点评估，确定相应的回退范围，制定相应的回退策略。 为确保每次版本发布风险的可防可控，特准备回退方案。
    • 应急回退步骤 ①通知相关用户系统开始回退。 ②通知各关联系统进行版本回退。 ③回退存储过程等数据对象。 ④配置数据回退。 ⑤应用程序、接口程序、工作流等版本回退。 ⑥回退完成通知各周边关联系统。 ⑦回退后进行相关测试，保证回退系统能够正常运行。 ⑧通知用户回退完成。
  • 16.5.3 版本发布和回退实施过程总结 535
    • （3）对引起回退的原因做深入分析、总结经验，避免下次回退发生。对进行回退计划中出现的问题进行分析，完善公司回退计划。
• 16.6 本章练习 535