原创： 项目经理训练营 欣旋咨询
作者：项目经理训练营
项目背景
研发团队提出一个变更，项目经理没能在第一时间评估该变更对计划的影响，没有对该变更进行制止或提出建议。经过一段时间，研发团队意识到了变更的影响，打算取消这个变更，可是该变更已经实施一半了，无论取消还是继续往下做都需要花费更多时间，都会影响项目原有计划。
团队组成
产品部、研发部
问题求助
—面对该种情况如何解决
问题1：取消变更，之前做的工作白费了，而继续做下去，还需要花费更多的时间和成本，并且会影响项目的原计划，该如何应对？
问题2：以后该如何避免此类事件的再次发生？
【观点1】
对于当前的问题，我觉得首要任务是确认这个需求现在还有没有必要做，这需要与相关干系人沟通确认。无论取消还是继续做，都需与干系人确认影响和优先级，并予以实施；
对于以后的需求变更，我们可以参照PMP的方法，遵循变更7个步骤：
1、提交变更请求（书面的，纸质/邮件）
2、评估影响
3、通知客户（能作决定的人）
4、批准或拒绝
5、通知受影响干系人
6、记录并更新文档
7、追踪并实施变更
【观点2】
对于此次事件，评估继续做与取消做对项目的影响哪个大，在自己无法决定的情况下，与高层商议如何解决，并将此次事件记录到企业知识库，指导我们下次遇到这种情况我们该如何去应对。
嘉宾总结
这个案例是关于项目中的变更控制，可以拆解为以下三点：
1. 团队没有第一时间分析清楚风险，直接批准了变更；
2. 实施之后发现了问题，才反馈给了项目组；
3. 最后项目组发现无论退回还是继续都会影响计划。
我们就这三点一个个来分析，总结一下经验教训：
第一，PMP中的变更顺序要把握好
这些点虽说繁琐，但其实每一步都是必需要的——变更的控制也是一个非常重要的“业务流程”，包含在质量控制体系内。只有遵循了流程才能保证不出错。但在具体实施起来，我们会遇到各种各样的限制，尤其对于处于尚在研发阶段的变更，有时候变化得太快以至于“变更的流程”往往跟不上变更的节奏，从而时常会产生迫于进度和时间点的压力而造成的不当的变更决策。在这个时候我们可以抓住几个要点进行处理：
a. 有可能的话，提前定义清楚变更的审批者，尽量从个人决策转为团队决策；
b. 优先评估关键点的影响，再做决策，在案例中专注点就是项目的进度，其余的可以作为非gating项在之后再进行详细的分析；
c. 研发中的快速变更若可以不走系统，但也要保存好相关记录；
d. 一旦做了决策，项目经理就要做好心理准备去承担相应的后果，以身作则让团队放心；
e. 无论决策的最后是好还是不好，都要做好经验教训。有条件的话，开个短会或者主动去找相关人员聊一聊再做决策都是可取的。尽量使项目中遇到的决策控制成为项目组的决策而不是项目经理的决策，这样既能多方面考虑问题也利于项目经理的自保。
第二，问题越早发现其影响的范围也越小
可以看出项目组的反馈机制还是不错的，反应速度很快，这是值得肯定的地方。
除此以外，对于项目经理来说，在项目中发现了有问题的反馈后，除了去找解决方案外，还有一点比较容易忽视的是要去控制问题的影响。在案例中，是否该立即停止实施变更就是控制影响的问题，是与不是由具体的情况来决定，这时候尽量避免优柔寡断。在信息不完备的情况下，保守的决策会较为安全的——仅做参考。
第三，尽量避免去考虑沉默成本，一切向前看
关于最后怎么更正，两条路都不好走的情况下我们可以换一下思路——看看接下来能做什么，抛去过去的决策，接受事实，就在这样一个变更实施了一半的情况下，评估一下接下来哪一个决策会更有利。
