总结

16.1 项目变更的基本概念

无重要考点

16.1.1 项目变更的含义

无重要考点

16.1.2 项目变更的分类

项目变更有多种分类方式，如
（1）按变更性质分为重大变更、重要变更和一般变更，可通过不同审批权限控制。
（2）按变更的迫切性分为紧急变更和非紧急变更，可通过不同的变更处理流程进行控制。
（3）按变更所发生的领域和阶段，可分为进度变更、成本变更、质量变更、设计变更、实施变更和工作（产品）范围变更等。
（4）按变更来源可分为内部变更和外部变更等。

16.1.3 项目变更产生的原因

项目变更的原因很多，常见的有：
（1）产品范围（成果）定义的过失或者疏忽；
（2）项目范围（工作）定义的过失或者疏忽；
（3）客户提出新需求；
（4）应对风险的紧急措施或规避措施；
（5）项目执行过程与项目基准要求不一致带来的被动调整（如进度、质量、成本等）·
（6）项目团队人员调整；
（7）技术革新的要求；
（8） 外部事件 （例如政策变动或自然环境变化等）。

16.2 变更管理的基本原则

1、变更管理的基本原则是首先建立项目基准、变更流程和变更控制委员会（也叫变更管理委员会）。
2、可以使用手工或自动化工具进行配置管理，

• 目前常用的配置管理工具有Ratlonal Clear Case、Perforce、CA CCC/Havest、MerantPVCS、Microsoft VSS、CVS等，
• 常用的开源免费的配置管理工具：SVN（SVN的全称是Subversion，即版本控制系统）、GIT、CVS等。

16.3 变更管理角色职责与工作程序

16.3.1 角色职责

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

16.3.2 工作程序

变更程序是

1. 提出变更申请
   1. 变更申请可能是：
   • 纠正措施：为了使项目工作绩效与项目管理计划保持一致而进行的变更申请。
   • 预防措施：为了确保项目工作的未来绩效符合项目管理计划而进行的变更申请。
   • 缺陷补救：为了修正不一致的产品或产品组件而进行的变更申请。
   • 更新：对正式受控的项目文件或计划等进行的变更申请，以便反映修改或增加的意见或内容。
2. 变更影响分析
   1. 项目经理在接到变更申请以后，首先要检查变更申请中需要填写的内容是否完备，然后对变更申请进行影响分析。变更影响分析由项目经理负责，项目经理可以自己或指定人员完成，也可以召集相关人员讨论完成。
3. CCB审查批准（通过/否决）
   • 更新文件以及通知相关方
4. 实施变更
5. 监控变更实施
6. 结束变更
   • 通知相关方

16.4 变更管理相关事项

16.4.1 变更管理操作要点

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

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

• 配置管理：重点关注可交付产品（包括中间产品）及 各过程文档
• 变更管理：着眼于识别、记录、批准或否决对项目文件、可交付产品或基准的变更。

1. 配置项识别：识别与选择配置项，从而为核实产品配置、标记产品和文件、管理变更和明确责任提供基础。
2. 配置状态记录：为了能及时提供关于配置项的准确数据，应记录和报告配置项的相关信息。此类信息包括变更控制中的已批准的配置项清单、变更申请的状态和已批准变更的实施状态。
3. 配置确认与审计：通过配置确认与配置审计，可以保证项目各配置项组成的正确性，以及相应的变更都被登记、评估、批准、跟踪和正确实施，从而确保配置文件所规定的功能要求都已实现。