项目建设中甲乙双方出自不同的利益和项目目标，出现矛盾是在所难免，如果矛盾没有及时化解，继续累积、扩大、蔓延，很有可能演化为纷争。特别是一些软件项目，涉及面广、技术性强、大众对其认识不深等诸多原因， 具体需求繁杂多变和质量指标主观性强等不易界定，项目成果难以评估定论。因此，软件项目在管理上矛盾纷争不断。2005年《提高ERP应用成功率的高层论坛》讨论ERP这一典型的软件项目低成功率问题，也说明了目前IT项目建设纷争过多。每一个项目管理者，都希望尽可能的减少纷争，使1得项目能够顺顺利利的完成。因此，本人在此结合自己的一些实践经验，谈47一谈如何减少软件项目纷争的一些看法。
项目纷争的原因很多，有逾期不能完工的、有质量达不到指标的、由甲方不能提供有效支持的、有项目成果不符合实际需求的等等。从结果上讲，主要是因为其中一方认为项目目标不能达到导致的，当然，由于自身的技术和管理上的原因导致目标不能达到，这部分纷争比较容易沟通、判定和解决，而比较容易引起纷争却又棘手的往往是由于项目目标理解上不一致导致的。软件项目的主要目标中进度和成本指标一般都有明确的定义，分歧较少，而对于范围和质量目标弹性较大，不易界定，如果合同签订时，这些指标标定义模糊不清、主观性较强、为以后的项目实施埋下隐忧。
因此，在项目实施之初，做好需求分析是减少软件项目纷争的首要前提。因为只有准确理解并完整描述甲方的需求目标，双方达成共识，才不至于发生矛盾纷争。但是，在实际操作中要真正做到需求分析全面与描述准确并非易事，因需求分析受以下几方面的影响：
1、 需求提出的局限性。
一般代表甲方提出需求是技术部门的负责人，大部分对整个企业或其它业务领域并不熟练，这样造成需求不清，特别是涉及整个组织运作的集成系统，由于负责人职位问题，很少能够熟知全局业务运作，所提出的需求的完整性因人而异。况且，有些业主持有甲方的“霸主”态度，总说以后不行再改、再加，或者要求加上“一些有关的功能”等模糊意义的需求。这样导致需求分析者未能全面准确的掌握需求源泉。
2、 需求描述的复杂性。
需求的完整描述不仅面面俱到，内部的关联性很强，错综复杂。所以需求描述很花费人力和时间的，一个稍大一点的软件项目需求描述就上百页，并且需求描述粒度会因客户的要求而不同，粒度小的需求描述就更多。
3、 需求审查的随意性。
甲方面对如此繁杂的需求分析与描述举行的需求评审会，专家和由各个业务客户往往因为会议组织安排问题和时间仓促问题而流于形式，并不能对需求描述作深入细致的分析。
4、 需求分析的时间性。
不管是甲方还是乙方的上层，都希望项目能够真刀真枪的干起来，而不想在这样“纸上谈兵”的需求方面花费太多的时间。一些资深专家普遍认为，需求分析阶段的时间应不少于整个项目阶段的20-30%，但迫于各种现实情况匆匆走过场的大有人在。
虽然在现实困难很多，但是要想避免日后发生矛盾，清除这一主要的矛盾根源，甲乙双方一定要在需求分析阶段下足功夫，要有啃硬骨头的精神，不怕繁，不要急，认真沟通协商，千万不要以为只是“纸上谈兵”，急于冒进。一个高质量的需求分析，是项目后续阶段的基础和依据，是减少纷争以及项目成功的关键。
减少软件项目纷争的一个重要控制措施是建立严格的变更控制制度。项目进行过程中，项目的环境和条件在不断变化，导致需求和范围也在变，有增、有减也有修正。一般上变更对项目都有影响，有时影响是巨大的，严重的，所以变更必须控制。严格的变更控制制度要求甲乙双方的项目经理对每一次变更的必要性和影响评估必须充分论证，并正确认识到变更的影响，正式签字确认。这