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. 对正式受控的项目文件或计划等进行的变更申请，以便反映修改或增加的意见或内容
