一、需求变动
1、获取真实需求
p和客户进行充分地沟通，为便于客户能够直观理解设计方案，可使用图文并茂的讲解方式。如果有条件最好处于客户的使用场景中，体验客户使用的痛点从而挖掘出客户想要的功能。
2、替换需求
基于产品现有逻辑和功能合理的替换客户提出的需求并提供原因和解决方案。
3、需求阉割
为了将核心需求在一定时间内做到最好的效果，将需求划分优先级并将优先级的需求暂时放在下一版本中，利用系统现有资源，采用逻辑简单，较易实现的方案，这样付出成本小，效果达到了，如果方向正确，后期可进行迭代优化。
4、统一对项目目标的认知
对项目整体目标、重要任务优先级达成一致的前提下，分析需求变更的背景和内外部原因，按照既定的优先级和资源情况理性沟通。
5、规范需求变更流程
结合具体业务场景，确定严格和正式的需求变更工作流程，防止随意、不必要的需求变更导致的进度延误。
6、评估变更后影响、更新进度
对需求变更导致的返工任务量、资源浪费情况等影响评估和记录，并按照最新的需求规划更新进度计划。
案例
某项目是新平台的建设，项目进行到收尾的时候，需求方觉得这个不是他想要的，然后提了一堆要求，最后项目不得不进行延期。
总结经验教训，发现还是项目组与需求方的沟通太少，且对需求的理解不正确，有一定的偏差，后面我们定期安排和需求方汇报进展及需求沟通，确保对需求理解的正确性。期间需求也有变动，此时我们就要求按照正常的需求变更流程进行需求变更，同时，团队内部开会讨论充分理解需求并拆分进行评估开发，最后项目也顺利完成并获得需求方的好评。
二、跨部门协同
1、项目计划必须是整合了各部门工作的项目计划，而不能是研发部门的工作计划，或者是各职能部门单独的工作计划。
2、项目计划要足够细化。跨部门团队动作出现的很多问题都是出在细节上，粗放的项目计划无法很好地指导跨部门团队工作，团队成员分工缺乏依据，团队动作也是混乱、低效的。所以，项目计划一定要足够细化，给跨部门团队各成员足够详细的指导。
3、要做好项目计划与部门计划的衔接。很多工作都需要落实到部门的工作中去。
4、最后就是要严格落实计划，及时发现问题，及时解决问题。
三、WBS拆解不彻底
将项目活动一层一层往下分解，按照树状结构，直至分解到一人一周内可以完成的工作，并且为完成项目目标，要做到面面俱到。在分解过程中，如果你认为不可分解，是因为你对这项活动还不太了解，那么我们还需要更进一步了解整个项目或者某个需求。
四、进度计划不合理
1、密切监控项目进度，早发现早解决
利用戈甘特图这个工具，来显示某些时间相关的活动（任务、阶段、项目等）随着时间进展的情况。
2、任务分工明确，做好具体事项跟进
在项目计划阶段，我们一定花足够时间做好项目进度计划，任务分解尽量详细，并确定好完成时间。每项工作项设置负责人，并要求负责人进行跟踪各项任务。一旦发现有延期风险，按计划应对并上报。
