首先，现阶段国内尚缺乏尊重契约的商业环境；其次软件行业难以标准化，验收的主观因素更重。在大环境不变的情况下，严格按照合同执行验收，你将会四处碰壁，尤其是集团内部项目。 所以不管长期、短期，平衡各方的利益，是项目经理在整个建设过程中，都应重点关注的。
简单来说，如果处于强势地位，你可以强硬一些，反之，则需要处处隐忍一些，多打打人情牌。另外做好日常各种沟通、会议的纪要，尤其是重要结论、决策的，形成书面记录。为的是一旦做不下去了，也有个说理的依据。
验收计划
1、项目介绍 背景、目标、概述完成情况 2、验收的说明 验收方式、依据、验收标准、验收范围、软件验收的环境、双方的人员、时间信息等 3、项目验收情况 交付物的要求 和完成情况 测试（或者试运行）的缺陷情况、解决情况、包括性能测试的结果情况 系统软件的运行情况:多少人使用、多少笔单子，重点是运行正常，符合项目目标和需求。 项目遗留的任务和问题情况可以没有 4、验收结论 项目实现了XX目标，达到了XXX，经 XXX方，研究决定，一致同意：验收通过。 5、签署 重要参与验收的人员，签字 （或者 盖章） 地点、日期 附录：相关附件 比如 验收的测试案例、功能清单（一个个功能打钩）、客户出具的系统运行情况报告等。
验收准备工作
当系统经过一段试运行，具备验收的各项条件之后，我们就需要着手验收阶段的准备工作了。
首先我们需要把到目前为止完成的工作进行一个总结，列出我们已经完成的各项目工作成果、各类文档，对合同以及各类约定的技术文档中的相关内容进行自查，要彻底了解系统目前完成的情况如何，是否已经完成了与客户方达成的各项书面约定以及口头约定，没有完成的，如果是书面约定，准备采取什么策略去进一步完成或者采取一定的回避措施，使客户在验收的时候不再提出这些未实现的需求。
这就需要与客户进行详细的沟通，再次明确验收前需要完成的工作，尽量避免客户方在此阶段提出过多的更改需求，这是极为重要的。验收计划中不光要有需要继续完成的工作，还需要有一个相对固定的工期，使双方都继续朝着这个方向去努力，防止无限制的拖延。
项目验收资料清单
建设单位（甲方）与承建单位（乙方）签订的合同中一般都会有项目资料交付清单，那么项目经理就可以在此基础上进行其他项目管理文档的补充，让项目管理文档更加规范、合理，如下：
注：标红的文档为合同中明确要求的交付资料。
好打交道vs不好打交道
项目验收可以说是项目某个阶段的一个终点，但是这个终点要怎么过去，就需要我们注意了，如果打交道的对方是注重实效、实用的，在开发过程当中做的改动都是为了更好的服务，那么软件验收将是非常简单的事情，只需要拿原来的协议看一看，把软件都测试好，也就验收通过了.
但是对于那种不好打交道的人来说，就比较麻烦了，他就会把协议上写的东西一条条对，看是不是都完成了，哪怕是为了更好的操作而做的改动，也要一五一十的交代清楚才好.
所以综上所述，最好的办法是在前期沟通、签合同、签技术协议的时候都能做到条理清晰，尤其是技术协议，也就是将来的验收标准，一定不能马虎，所以在前期签订这个的时候，需要我们在写的时候尽量写一些最核心的功能，而且文字表述方面尽量做到明确，因为软件的开发过程中有许多要调整的地方，所以在前期的验收协议里面只涉及核心功能方面，作为委托方也是能理解的，因为他们主要的功能我们都做到了，就不会有什么太大的问题，这一点是前期必须注意的，
另外，有某些功能由于前期没有考虑清楚的，如果在开发过程当中，需要和委托方商议，并写成文字性的东西双方签字确认，在这个过程当中也要把当初的验收协议拿出来，做标注，比如：验收协议第八条写的内容，在实际开发当中由于不合理要做调整，那么我们需要出一份调整协议作为验收协议的附件，双方签字后，并将第八条的验收方式在协议中标明，也就是在将来验收第八条的时候，我们只需要在协议附件中对应修改过的该条验收即可，以此类推形成委托方最终验收的依据；
总之在开发过程当中双方需要多沟通、多交流，把需要明确的部分确认好，一般情况下，在后期验收的时候就会很大程度上减少不必要的麻烦。
