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