抓住空子，往往要付出许多无谓的牺牲。如果需求做得好，文档清晰且又有客户签字，那么后期客户提出的变更就超出了合同范围，需要另外收费。
这个时候千万不能手软，这并作要刻意赚取客户的钱财，而是不能让客户养成经常变更的习惯，否则后患无穷。相对于需求来说，什么WBS、风险管理、计划进度都是次要的，只要需求做好了就会一帆风顺。
6、客观面对需求变更
需求一定会变化，我们也不得不面对这种情况，那么用什么办法改善这种现状呢?下面我提几点建议。
（1）、加强人员培训
从客观方面可以采取的措施来说，首先是加强对需求分析人员的培训，尽可能增强软件系统、行业的背景知识，提高与客户的沟通能力，增强服务意识和责任感， 因为将要开发的系统直接建立在需求分析的基础上;同时规范需求分析人员和客户沟通的方式，以及规范需求说明的格式，如果可能的话，尽量采取用户可以理解的图例来对需求进行标准、规范的描述，保证双方对需求达到共同的认识。
（2）、加强文档管理
需求文档是相当重要的，可是在做文档时大家普遍流于形式，文档也有，格式也正确，但没有人关心文档的真正内容是否正确，格式是否真的合理，是否实用，很多情况下是在几天时间里赶出来或补上去的。
结果往往是在需要文档时，文档找到了，完全符合格式的要求，可是在里面能找到的线索是有限的，结果还要花很长时间查找数据表结构、甚至查看数据表的内容，询问当时的开发人员，才分析到所要的关系。这种情况在设计文档里也存在，所以不管是开发人员、还是项目管理人员都要注意文档的有效性和有用性问题，甚至对文档的格式进行一下合理性检查。
（3）、项目实施阶段的变更控制
成功项目和失败项目的区别就在于项目的整个过程是否是可控的。项目经理应该树立一个理念—“需求变更是必然的、可控的、有益的”。项目实施阶段的变更控制需要做的是分析变更请求，评估变更可能带来的风险和修改基准文件。
能力的提高往往不是从成功的经验中来，而是从失败的教训中来。许多项目经理不注重经验教训总结和积累， 即使在项目运作过程中碰得头破血流，也只是抱怨运气、环境和团队配合不好，很少系统地分析总结，或者不知道如何分析总结，以至于同样的问题反复出现。
事实上，项目总结工作应作为现有项目或将来项目持续改进工作的一项重要内容，同时也可以作为对项目合同、设计方案内容与目标的确认和验证。项目总结工作包括项目中事先识别的风险和没有预料到而发生的变更等风险的应对措施的分析和总结，也包括项目中发生的变更和项目中发生问题的分析统计的总结。
需求变更既然不可避免，那么就必须有一套规范的处理流程。对于需求变更的处理流程应该分以下步骤:提出变更->变更评估->实施变更。图1简要地描述了一般需求变更的处理流程。
CMM提出“分配需求的变更被复审，并加入到软件项目中来”，其关键是在需求发生变更时，没有必要马上把这些变更付诸于软件开发工作之中。
实际上，坚持把需求变更付诸开发努力，企业就会形成一种混乱且不稳定的氛围，进而严重破坏项目的控制和管理。需求管理关键过程试图通过把分配需求的变更囤积到可管理的组中，等到开发工作允许的时候再引入相应的方法，避免产生这种混乱的氛围。结果，需求管理创建了一个隔绝开发工作与所有真实的、潜在无序的、来自于客户的变更。
打破模糊的、暧昧的、没有文档化的需求是一种伟大的挑战，但是制订坚持遵守的