1、提前去识别项目变更的具体特征，并请求专家支持。

　　把领导拉到统一战线：向发起人(领导)汇报初步调研结果以及判断，与发起人共同确立了对项目危机情况的认知，在发起人授权的情况下，请求公司技术和业务专家支持。

　　当你承接的项目比较复杂的情况下，最好是可以拉上转接给你做背书，这里不是拉背锅侠的意思，而是借助专家的影响力来构建我们项目经理在领域内的权威性。

　　2、指定相应策划，重视需求变更的流程和规范的建立。

　　可以根据相应策划开启头脑风暴会、并同时共同讨论项目实施过程中可能会因为项目频繁变更的项目风险到底存在于哪些环节，我们把存在项目的关键节点都找出来，并分析相对应的解决方案，重视需求变更的流程和规范的建立，我们把它称为“三步走解决方案”

　　1)签署敞口合作框架协议、因为最开始需求不够明确，如果签订闭口协议很容易把自己送入火坑，可以先签订敞口框架协议，等我们后续大致范围定义清楚之后，才会和甲方签署具体合同约定。

　　2)把项目范围定义清楚，一开始很头痛，我们当时把需求范围定义当成一个独立的子项目来做，并且把子项目约束在合作框架中。

　　3)裁剪指定项目管理框架，采用敏捷开发模式的决定，在项目成员人数比较多的时候，我们选择了比较流行的规模化敏捷框架Safe搭配Scrum of scrums敏捷框架，针对需求变更过程的管控规则也进行了定制化的裁剪。

　　3、紧跟项目目标，及时调整项目基准。

　　总体来说我们要紧跟项目的战略目标，及时的去调整项目的基准，通过调整基准来重新映射我们的需求范围，如果是产品型项目，因为涉及到运营阶段的反馈，会影响到产品的建设，所以我们需要在项目的综合规划阶段，去考虑设置充分的缓冲空间，并且及时去跟进缓冲的流失情况，对缓冲进行及时有效的管理。

　　对于项目经理来说变，才是唯一的不变，对于甲方来说，需求一直变更一直爽……

　　在项目实施过程中，只要提了第一个，紧接着就会有第二个、第三个，对于项目经理来说，甲方的变更需求无法改变，提起来都是血泪史，希望作为项目经理的我们，遇到需求变更能够总结出一套自己适用的方案。