【信息系统项目管理师】第十六章 项目变更管理（考点汇总篇）

【信息系统项目管理师】第十六章 项目变更管理（考点汇总篇）

考点分析与预测

变更管理是项目整体管理的一部分，上午考题会出1分左右，已经包括在项目整体管理中。下午案例考变更管理的可能性也是很大的。如果论文题目是整体管理，必然要谈谈项目整体管理。所以本章应该是重点。而且在日常工作中，几乎没有项目是不需要变更的。本章节可以结合项目整体管理一起看。

知识点汇总

项目整体管理的知识点汇总：https://blog.csdn.net/Last_Impression/article/details/85763229

章节目录

1.项目变更管理的基本概念
1.1 项目变更产生的原因
1.2 项目变更的分类
1.3 项目变更的含义
2.项目变更管理原则
3.变更管理的组织结构与工作程序
3.1 组织机构
3.2 工作程序
4.项目变更管理的工作内容
4.1 严格控制项目变更申请提交
4.2 变更控制
4.3 变更管理与其他项目管理要素之间的关系
5.版本发布和回退计划
5.1 发布前准备
5.2 应急回退方案
5.3 版本发布和回退实施过程总结

1.项目变更管理的基本概念
根据变更性质可分为：重大变更，重要变更，一般变更。通过不同审批权限控制。
根据变更的迫切性，可以分为：紧急变更，非紧急变更。通过不同变更处理流程进行。
根据变更所发生的领域和阶段，可分为进度变更、成本变更、质量变更、设计变更、实施变更和工作（产品）范围变更
根据变更来源可分为内部变更和外部变更
根据变更类型来分有四个种类：预防措施，纠正措施，缺陷补救，更新

2.项目变更管理原则
原则：项目基准化，变更管理过程规范化。
包括：基准管理；变更控制流程化；明确组织分工；评估变更的可能影响；妥善保存变更产生的相关文档。

3.变更的工作程序
工作程序：1.变更申请；2.对变更进行初审；3.变更方案论证；4.CCB审查；5.发出变更通知并实施变更；6.变更实施监控；7.变更效果评估；8.判断发生变更后的项目是否已纳入正常轨道。
超出基线的变更要走变更流程，不超出基线的变更，不必走变更流程。
项目经理在变更中的作用：响应变更提出者的需求，评估变更对项目的影响及应对方案，将需求由技术要求转化为资源需求，供授权人决策。并根据评审结果，实施即调整基准，确保项目基准反映项目的实际情况。
变更审查过程：审查通常是文档汇签的形式，重大的变更审查可以包括正式会议形式。
变更评估从以下几方面进行评估：
1.首要依据是项目基准
2.还需结合变更的初衷来看，变更所要达到的目的是否已经达成。
3.评估方案中的技术论证，经济论证内容与实施过程的差距并触发解决。

4.项目变更管理的工作内容
变更管理涉及范围，进度，成本，质量，人力资源，合同管理等多个方面。
对进度的变更控制：
1.判断项目进度的当前状态
2.对造成进度变化的因素施加影响
3.查明进度是否已经改变
4.在实际变化出现时对其进行管理
对合同变更的控制：
1.合同变更控制系统规定合同修改的过程
2.包括文书工作，跟踪系统，争议解决程序，批准变更所需的审批层次
3.合同变更控制系统应当与整体变更控制系统结合起来。

项目规模小，关联影响小的时候变更的提出和处理过程可在操作上力求简便，高效。还需要注意以下几点：
1.防止不必要变更，减少无谓的评估，提高必要变更通过效率。
2.对变更的确认应当正式化
3.变更的操作过程应该规范化

在项目整体压力较大的情况下，更需强调变更的提出，处理的规范化。可以使用分批处理，分优先级等方式提高效率。如同繁忙的交通道路，如果红绿灯变化频繁，其实效不是灵活高效，而是整体通过能力的降低。
变更管理和配置管理是相互关联的两套机制。变更管理由项目交付或基准配置调整时，由配置管理系统调用。变更管理最终应将对项目的调整结果反馈给配置管理系统，以确保项目执行与对项目的账目相一致。

5.版本发布和回退计划
在版本发布前，对每次版本发布的风险做出相应的评估
对版本发布的过程checklist做严格的评审
在评审发布内容时，对存在的风险的发布做重点评估
确定相应的回退范围，确定相应的回退策略准备以下回退方案。

大话变更管理

许多项目的失败情况是由于变化的处理不当，有些变更是积极的，有些则是消极的，做好变更管理可以使项目的质量，进度，成本管理更加有效。反之要是变更处理不当，直接会导致项目的失败。
对于变更管理的实质，随着项目建设过程中我们对项目认知的不断提高，需要不断的调整努力方向和资源配置，来满足客户的需求。
变更管理有两个原则：其一，使管理基准化（配置管理），其二，使变更管理流程化（流程管理）过程保证项目的成功。

1.变更申请
在项目中所有的干系人都可以提出变更，变更是通过书面的，所以就有了变更日志来记录变更需求。从客户那里，项目的需求会变更，即使是在团队内部，也会因为进度，质量，成本出现了与项目基准的偏差而发生了变更。这些申请的变更，都由项目经理首先进行响应。
变更分很多种类，有紧急非紧急的，内部和外部的，有质量，进度或成本相关的，还有一种叫推定变更。作为项目经理，在日常的管理中，要特别注意推定变更，通过往来的邮件或其他沟通方式的管理去找出来，同时也要教育干系人，变更依赖申请时，要用正式书面形式写到变更日志中。为什么不先分析影响在提交变更请求？因为团队该花时间在项目工作上，没有那么多时间分析影响。

2.变更评估
项目经理在确认变更日志中的变更内容后，如果干系人提出的变更信息不够全面，首选就得通过沟通去问变更需求。在对变更需求有了一个统一的认识后，确认变更的影响范围，是否是有价值的变更，是否真的需要变更，当项目经理一个人无法判断时，还可以召开变更方案论证会，记录充分讨论的结果到变更日志中，方便供CCB决策。PMBOK中说所有的变更都要经过CCB的审批后才能够实施，但是在实际的工作中，只有超出项目基线的变更需要走变更流程，基线以内的变更就不用走变更流程了。如果变更太多太大，势必会影响整体的项目进展。这个时候可以看看是否有必要终止现在的就可能需要修改项目章程，甚至可以终止现行项目，而另外启动一个新的项目。

3.变更决策
项目变更控制委员会在收到变更日志和对于变更的评估之后，就可以判断变更实施的要否了。首先自然要看看该项变更是否会改变项目的三大基准，再看看项目经理对于变更的评估结果，比如质量镀金的，或者没有价值的变更，直接拒了；对于真正需要的变更，给予审批通过。

4.变更实施
项目经理在拿到审批后变更日志后，就可以开始着手变更了。对于需要改基准的变更，先修改项目管理计划以及项目管理文件，然后根据调整后的计划，安排合适的资源去实施变更。因为变更而改动了计划改动了基准，通知给需要了解情况的干系人是十分需要的。
变更是整体项目的一部分，我们项目经理对其的监控也必不可少。

5.变更验证
批准的变更也是项目范围的一部分，对应好变更就会有变更相应的可交付成果的产生。这个可交付成果自然和其他可交付成果一样，需要通过确认范围来验收，看看本次变更是否达到我们当初的目的，本次变更跟我们之前预期和想象中差距到底大不大。变更实施后项目是否已经纳入了正常轨道。

6.沟通存档
在变更验收通过后，把包括变更产生的可交付成果，项目管理文档等都放入指定的配置库中存档。同时告诉干系人，他们要求的变更需求已经对应好了，将在下次版本发行时发布。
当积累的一定数量的变更，根据配置管理计划，我们要对变更做成基线，发布版本。发布版本前，我们该通过Checklist检查可交付成果是否满足要求，并做项目的风险评估后，向干系人发布变更。
发布的变更用户不满意的时候该怎么半？还好我们在发布版本的同时制定了回退计划，在配置管理中，根据回退计划，将发行库中的内容进行回退，因为良好的配置管理，所以回退版本也变得不那么复杂了。