就项目而言，通常情况下，项目经理和团队成员将各项计划落实，开始执行后，每个变动都会牵一发而动全身。
与此同时，由于项目本身具有不确定性的特点，项目的需求变更更是在项目管理过程中被谈论最多的。 由于整个闭环链条上的每个角色对项目输出的成果都是不可逆的，一旦决策，项目实施就会出现相应的后果，尤其是到了项目实施的中后期，需求变更所带来的影响将显著提高。
与业务确定需求
当需求文档完成审查之后，即可交付给业务负责人做确认。为了加速业务负责人确认需求文档的时间，可以邀请业务负责人参加需求评审会，或者讲述一遍业务需求，然后再让业务负责人线下确认，如果有修改意见，可约定邮件或者备注形式反馈，同时要跟对方说清楚确认完成时间。
罗列详细任务需要
需求类别和模板确定之后，就要分配给项目相关负责人去撰写需求。对中大型项目来说，撰写需求说明书的人应该有多个，所以需要切分工作任务。
切分的原则是：每个任务尽可能独立，任务的安排尽可能并行。每个任务必须要确定完成时间，如果时间不满足项目进度，需调配其它人力资源进行协助。有些项目比较特殊，可能现有项目成员的专业能力无法覆盖，此时需要引入外部专家或者将这部分任务外包出去。
为了把控需求收集的进度，需求撰写计划中要安排几个检查点。
举个例子，假如需求撰写的排期是1个月，那么就可以设置3个检查点。
第一个检查点为第一周结束。
第二个检查点为第三周结束。
第三个检查点为第四周结束前2天。
每到一个检查点，各个需求撰写人需将成果汇总到项目经理手里做review，根据review的意见或建议迅速调整或整改。
从四要素思考处理方案
如果团队决定接受这个需求，项目经理接下来就要看团队怎么处理这个需求了。
项目经理可以从项目管理四要素出发，看下能改变哪一个要素：
是降低系统的质量要求?——比如留些bug以后处理
是改变项目的交付范围?—— 比如多了一个功能进来总得砍一个出去
是延长项目的交付时间?
还是改变实现功能的方式?
给出合理的需求处理解决方案，是项目经理综合能力的体现。
另外，别忘了一件重要的事情，就是把变更的后续跟进方案通知到整个团队，并且存档变更纪录。
经常遇到需求小范围讨论完就改掉的情况，但是测试人员并没有通知到位，导致上线后才发现问题。项目经理需要有机制让团队避免这种情况。