英国有位经济学家说过，任何变更，即使是向好的方向变更，也总是伴随着折磨与痛苦。这一语也恰道破了信息化建设过程中需求不断变更的苦恼。这种烦恼不仅是软件厂商实施方所有的，企业客户也照样有这烦恼。
需求的变更，对于项目的影响是非常大的。但是，就如同天要下雨一样，我们难于从根本上加以消除。我们所能够做的，就是采取更多行之有效的工作，把这个几率降至到最低，或者采取一些补救措施，把需求变更给软件项目带来的损失减到最小。
1、需求变更不断，难言之痛
一旦需求变更，往往会引起重估、返工，你不得不修改你的设计，重写你的代码，修改你的测试用例，调整你的项目计划等，从而影响软件项目的范围、时间、质量和成本等多个要素，如果控制不好，还会导致项目范围蔓延、进度延迟、质量不过关和成本严重超支等诸多麻烦与问题，甚至因过多的分歧、变更而半途而废。因而需求变更在很多软件项目中都是一件头疼的事情。
时常听到这句业界常言——“上ERP找死，不上ERP等死”。其实何止ERP如此，中小型的IT项目如OA、CRM等，其成功率也不足55%，客户满意率不到30%，有不少项目成了“食之无味，弃之可惜”的鸡肋工程。何以如此?需求不断变更、盲目更改项目内容导致项目难于验收、结案，“始乱终弃”。
软件项目变更原因，总结起来主要有：国家政策不断改变，三天两头一个红头文件，使许多企业单位的财税政策、产品标准、服务规范等也要跟着变化，用户单位的业务内容、流程管理也要跟着变;客户可能一开始对项目内容与需求没有形成初步看法，或者一开始没有想法但随着项目的进行、参考其他单位的好做法，就产生了一些新想法、新需求;或因为业务手续太繁琐、流程太复杂，引起用户反感，要求修改;软件商系统员经验不足，没有捕获到用户的关键业务需求或者用户整理需求能力弱，遗漏了关键的需求点，导致需求不合需要重改;或可能是数据易丢失，也可能是系统不稳定，还可能是兼容性问题，用户反应强烈，要求修改，等等。
可以说，从IT项目的实务看，几乎没有一个项目能够百分之百按照原订计划进行，需求变更是不可避免的，也是正常反应，但如果需求无序无度、变更无常，就易造成甲方、乙方的矛盾、对抗，无疑是种内耗，成了信息化建设的绊脚石。IDC机构调查数据显示，99.5%的信息化建设都有过需求变更，需求变更达到“严重程度”达到38.2%，需求变更“无度”达到甲、乙双方无法容忍乃至项目破裂的程度也占11.3%，只有28.6%的项目需求是甲、乙双方能协调、满意。
所有说，有时项目需求的变化好比是“万恶之源”，一旦发生了需求变化乃至无序变更，将为项目的正常进展带来了不尽的麻烦。因此解决需求变更尤其解决即将验收、签案的项目的需求变化，实际上是一项非常复杂重大、事关全局的工作，必须引起企业一把手、CIO和项目组成员的高度重视，积极管理、应对，千万不能虎头蛇尾、敷衍了事，最后马失前蹄、败走麦城。那么怎样来解决这个问题?有哪些应对之道?
2、项目需求变更的几项须注意事项
需求变更要尽早。若你项目快要完工时，才发现原先的需求有纰漏、缺失，需要变更重设时，那损失就会大了。建房子，若在房子快造好时，却发现原先设计不对，需要推倒重来，那成本与时间的浪费就大得不得了。因此，项目越接近收尾阶段，再进行需求变更的话，给甲乙双方造成的损失则越大。因此需求变更要趋早，早提出早好。
充分交流、协商。变更管理的过程很大程度上就是用户与开发人员的交流过程。软件供应商项目经理、