从历年考试情况来看，项目的变更管理属于下午案例分析的重点考查内容，虽然变更管理一般不会单独出题，但是会和其他管理领域出题。
1.变更的常见原因：
（1）产品范围（成果）定义的过失或者疏忽。
（2）项目范围（工作）定义的过失或者疏忽。
（3）增值变更。
（4）应对风险的紧急计划或回避计划。
（5）项目执行过程与项目基准要求不一致带来的被动调整。
（6）外部事件。
2.变更的程序：
（1）提出与接受变更申请。
变更提出应当及时以正式方式进行，并留下书面记录。变更的提出可以是各种形式，但在评估前应以书面形式提出。
（2）对变更的初审。
变更初审的目的如下：
①对变更提出方施加影响，确认变更的必要性，确保变更是有价值的。
②格式校验，完整性校验，确保评估所需信息准备充分。
③在干系人间就提出供评估的变更信息达成共识。
④变更初审的常见方式为变更申请文档的审核流转。
（3）变更方案论证。
变更方案的主要作用，首先是对变更请求是否可实现进行论证，如果可能实现，则将变更请求由技术要求转化为资源需求，以供CCB决策。常见的方案内容包括技术评估和经济评估，前者评估需求如何转化为成果，后者评估价值和风险。
（4）项目变更控制委员会审查。
审查过程，是项目所有者根据变更申请及评估方案，决定是否批准变更。评审过程常包括客户、相关领域的专业人士等。审查通常是文档会签形式，重大的变更审查可以包括正式会议形式。审查过程应注意分工，项目投资人虽有最终的决策权，但通常在专业技术上并非强项。所以应当在评审过程中将专业评审、经济评审分开，对涉及项目目标和交付成果的变更，客户的意见应放在核心位置。
（5）发出变更通知并开始实施。
评审通过，意味着项目基准的调整，同时确保变更方案中的资源需求及时到位。项目基准的调整，包括项目目标的确认、最终成果、工作内容和资源、进度计划的调整。需要强调的是，变更通知后，不只是包括实施项目基准的调整，更要明确项目的交付日期、成果对相关干系人的影响。如变更造成交付期的调整，应在变更确认时发布，而非在交付前公布。
（6）变更实施的监控。
要监控的，除了调整过的项目基准中所涉及变更的内容外，还应当对项目的整体基准是否反映项目实施情况负责。通过监控行动，确保项目的整体实施工作是受控的。变更实施的过程监控，通常由项目经理负责项目基准的监控。管理委员会监控变更明确的主要成果、进度里程碑等，可以委托监理单位承担监控职责。
（7）变更效果的评估。
变更评估可以从以下几个方面进行。(www.xing528.com)
①首要的评估依据，是项目基准。
②还需结合变更的初衷来看，变更所要达到的目的是否已达成。
③评估变更方案中的技术论证、经济论证内容与实施过程的差距并推进解决。
（8）判断发生变更后的项目是否已纳入正常轨道。
项目基准调整后，需要确认的是相应的资源配置和人员是否及时到位，更需多加关注。之后对项目的整体监控应按新的项目基准进行。涉及变更的项目范围及进度，在变更后的紧邻监控中，应更多地关注，当确认新的项目基准已经生效则按正常的项目实施流程进行。
有可能的问题
①对用户的要求未进行记录。
②对变更的请求未进行足够的分析，也没有获得批准。
③在修改的过程中没有注意进行版本管理。
④修改完成后未进行验证。
⑤修改的内容未和项目干系人进行沟通。
导致的后果
①缺乏对变更请求的记录可能会导致对产品的变更历史无法追溯，并会导致对工作产物的整体变化情况失去把握。
②缺乏对变更请求的分析可能会导致后期的变更工作失误。
③在修改过程中不注意版本管理，一方面可能会导致当变更失败时无法进行复原；另一方面，对于组织财富和经验的积累也是不利的。
④修改完成后不进行验证则难以确证变更是否正确实现。
⑤未与项目干系人进行沟通可能会导致项目干系人的工作之间出现不一致之处。
3.可能案例：
需求不明确的情况下就签订合同，开发过程中开发人员对于变更随便答应。随着项目进行，变更越来越混乱，导致项目失败。
答题要点：这类题目是变更管理中的典型题目，主要有以下几点。
①在项目功能和标准不明确的时候就签订了合同，为后来的项目变更埋下了隐患。
②没有建立项目变更管理制度（例如：开发人员随口答应，不上报给项目经理）。
③作为上点的衍生品，还可以回答，变更请求没有经过评估，没有评估产生的费用和技术要求，也没有签字确认。
④变更实施时没有考虑对系统其他功能的影响，也没有考虑能否实现。
⑤变更后没有进行验证。
⑥没有对变更后的内容进行存档，也没有通知给相关的项目干系人。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
