学系统集成项目管理工程师（中项）系列20_变更管理

1. 许多项目失败的原因就是由于对变更的处理不当

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

3. 分类

3.1. 性质

3.1.1. 重大变更

3.1.2. 重要变更

3.1.3. 一般变更

3.1.4. 通过不同审批权限控制

3.2. 迫切性

3.2.1. 紧急变更

3.2.2. 非紧急变更

3.2.3. 通过不同的变更处理流程进行控制

3.3. 发生的领域和阶段

3.3.1. 进度变更、成本变更、质量变更、设计变更、实施变更和工作（产品）范围变更

3.4. 来源

3.4.1. 内部变更

3.4.2. 外部变更

4. 变更的原因

4.1. 产品范围（成果）定义的过失或者疏忽

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

4.3. 客户提出新需求

4.4. 应对风险的紧急措施或规避措施

4.5. 项目执行过程与项目基准要求不一致带来的被动调整（如进度、质量、成本等）

4.6. 项目团队人员调整

4.7. 技术革新的要求

4.8. 外部事件（例如政策变动或自然环境变化等）

5. 基本原则

5.1. 基准管理

5.1.1. 基准是变更的依据

5.2. 建立变更控制流程

5.3. 建立变更控制委员会

5.4. 完整体现变更的影响

5.5. 变更产生的相关文档应纳入配置管理中

6. 角色职责

6.1. 变更申请人

6.1.1. 提出变更申请的相关人员

6.1.2. 项目的任何干系人都可以提出变更申请

6.2. 项目经理

6.3. 变更控制委员会（Configuration Control Board, CCB）

6.3.1. 负责对提交的变更申请进行审查，并对变更申请做出批准、否决或其他决定

6.4. 变更实施人

6.4.1. 实施已批准的变更的相关人员

6.4.2. 变更申请内容不同，相应的变更实施人员也不同

6.4.3. 要参与变更正确性的确认工作

6.5. 配置管理员

6.5.1. 变更过程的相关产物应纳入配置管理系统中

6.5.2. 把变更后的基准纳入整个项目基准中

7. 工作程序

7.1. 提出变更申请

7.1.1. 【20下选42】

7.1.2. 以书面形式记录，并纳入配置管理系统中

7.1.3. 关于修改文档、可交付物或基准的正式提议

7.1.4. 纠正措施

7.1.4.1. 为了使项目工作绩效与项目管理计划保持一致而进行的变更申请

7.1.5. 预防措施

7.1.5.1. 为了确保项目工作的未来绩效符合项目管理计划而进行的变更申请

7.1.6. 缺陷补救

7.1.6.1. 为了修正不一致的产品或产品组件而进行的变更申请

7.1.7. 更新

7.1.7.1. 对正式受控的项目文件或计划等进行的变更申请，以便反映修改或增加的意见或内容

7.2. 变更影响分析

7.3. CCB审查批准

7.3.1. 【20下选38】

7.4. 实施变更

7.5. 监控变更实施

7.5.1. 保证批准的变更都得到正确的落实，即需要对变更实施进行监控

7.6. 结束变更

7.6.1. 变更申请被否决时变更结束，项目经理通知相关变更申请人

7.6.2. 批准的变更被正确完成后，成果纳入配置管理系统中并通知相关受影响人员，变更结束

8. 操作要点

8.1. 对变更产生的因素施加影响，防止不必要的变更，减少无谓的评估，提高必要变更的通过效率

8.2. 变更的操作过程应当规范化

8.3. 对变更的确认应当正式化

9. 项目整体管理的一部分，属于项目整体变更控制的范畴

10. 着眼于识别、记录、批准或否决对项目文件、可交付产品或基准的变更

11. 变更管理过程中包含的部分配置管理活动

11.1. 配置项识别

11.2. 配置状态记录

11.3. 配置确认与审计

11.4. 配置管理重点关注可交付产品（包括中间产品）及各过程文档


来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

谢谢分享，试用一下

感谢分享，学习下。

热心回复！

感谢分享，学习下。

感谢，下载保存了

分享、互助 让互联网精神温暖你我

这个有用。

谢谢楼主提供！

感谢，下载保存了

感谢分享，下载保存了，貌似很强大

感谢分享，下载保存了，貌似很强大

热心回复！

过来提前占个楼

感谢分享

感谢分享，学习下。

谢谢分享，试用一下

前排留名，哈哈哈

用心讨论，共获提升！

收藏一下   不知道什么时候能用到