行需求变更。一般把需求变更或者新需求的确认最迟时间定在系统培训阶段。也就是说，在系统培训完成后、开始准备双线并行前，企业用户还可以提出需求变更的申请，但是，当系统开始双线运行时，就不允许用户再提出需求变更等类似的请求了，如编码的内容和规则、表单的数量和格式、数据流转和统计方式等，否则就要付出变更的代价。
建立变更控制组织系统。项目启动时，尽可能地与客户沟通，尽快建立正式的对变更进行控制的组织，通称变更控制委员会(CCB)，成员可包括双方高层(挂名)、甲乙双方的项目负责人、相关的需求负责人等，负责裁定接受变更内容、方法、步骤等。建立该系统的目的是统一管理需求变更和跟踪变更的状态，便于项目组测试人员、开发人员、系统分析员以及PM相互之间的沟通和交流。建立变更控制系统目的不是让用户不提出变更，而是让用户不轻易、随便的提出变更。
严格规范变更流程。一旦需求分析阶段结束，此后如果用户要求有新的需求加入即将交付的软件系统中，甲乙双方的项目组或变更控制委员会，要根据角色定义，确定变更流程，规定严格的变更控制流程，并控制新需求提出的频率。
1)变更申请。系统界面如按钮的位置、字段的位置的细微调整，不涉及到业务规则，对基线基本没有影响的变更，由测试人员直接在变更控制系统中提出;其他如操作风格的较大变化、编码内容、业务规则的变化等，均要求用户提出电子和书面的需求变更单。
2)变更评估。由项目组或变更控制委员会组织人员对变更进行变更的合理性分析，变更替换方案分析，工作量的估算以及涉及什么模块、影响什么模块等影响分析。
3)变更实施。由测试人员在变更控制系统中填写变更信息，由系统分析员填写处理方法和影响分析后交由开发人员实施。
需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。
选用适当的开发模型防止多变更。采用建立原型的开发模型比较适合需求不明确的开发项目。软件供应商研发人员先根据用户对基本需求的说明建立一个系统原型，再与用户沟通。一般用户看到一些实际的东西后，对需求会有更为详细的解释，开发人员可根据用户的说明进一步完善系统原型。这个过程重复几次后，系统原型逐渐向用户最终、比较全面的需求靠拢，从根本上减少需求过多变更的出现。目前业界较为流行的叠代式开发方法对工期紧迫的项目的需求变更控制较为管用。通常情况下，原型之后的需求沟通就实际得多，双方的理解迅速向一个全面折衷的方案贴近，一个可以指导研发过程、有针对性的需求说明书就可起到重要作用。
通过合同约束，建立有效的解决冲突机制。用户、开发商在实施、验收软件项目过程中难免会发生冲突，而需求变更给软件项目建设带来的影响也是有目共睹，从而可能让项目建设偏离轨道。关键是事先是否有明确的项目目标和项目要求，是否建立起有效的冲突解决机制。所以双方在签订合同时，可以增加一些相关条款，主要是要明确今后双方责权利关系，如限定用户提出需求变更的时间，规定何种情况的变更可以接受、拒绝接受或部分接受，还可以规定发生需求变更时必须执行变更控制流程，否则自担变更的代价;而企业用户，也可对将来可能发生重大事件或不可抗拒事件所引发可能的实施超期、费用超支、产品价格调整以及服务收费超标等事项、行为及其权责做出预测，并有效约定，从而使信息化项目从一开始就按双方预定的规道行驶，互为制约、协调，避免再发意外。
验收与发现、检验需求并举。大型的ERP项目不少是边实施边验收，然后再发现新问题新需求，再进一步返工完善，一步一步地把项目向前推进