科技项目验收流程及方案怎么写，科研项目验收流程及方案？

作为一名身经百战的项目经理，你应该对项目交付及验收深有感触，现在项目越来越难做，好不容易经历九九八十一难，终于完成了交付，但是客户就是迟迟不给你验收。正所谓：“成功的项目都是相似的，不幸的项目各有各的不幸”。

下面来看PM经常遇到的几种典型的验收问题：

项目1：项目顺利交付上线，客户也答应签署验收文件。PM决定扩大项目影响力，找设计师设计了一张炫酷的项目验收报告，等待客户签署完毕之后，把证书悬挂到公司的展厅进行宣传。当客户方的PM看到如此高大上的证书时，他开始犹豫了，并变得很谨慎。他决定先汇报给他的领导，征求领导的意见。于是，说好的验收就这样搁置了。

项目2：项目顺利交付上线，运行平稳，并没有什么纰漏。然而客户坚决不在验收报告上签字。原因可能是这样的：乙方某技术人员在实施期间，针对某技术问题写过一篇文章，并且在相关行业的网站，自媒体等发表文章，文中把技术问题的根源归结于客户侧的原因，比如技术架构落后，客户认为这会对他们造成了不好的影响及极不尊重。

项目3: 项目顺利交付上线，运行平稳，并没有什么纰漏，但是客户从其它渠道了解到，你公司的售后服务不能得到保障，担心签字之后如果再出现技术问题，就没有人来解决了，因此一再拖后验收签字的日期。

项目4：项目实施完毕，没有什么问题。项目经理三番五次给客户负责人打电话，但是客户负责人总是忙于别的工作，无法安排验收。

项目5: 项目顺利交付上线，运行平稳，并没有什么纰漏。你提验收的时候，对方给你提出非常严格的验收标准，要求项目每个过程文档都要提供，缺少了文档无法开始验收流程。

项目6: 每次催客户签验收报告时，就拿项目的缺陷或小部分没被满足的需求来说事，拒绝验收；

项目7：客户迟迟不签署验收报告，因为验收签署是客户最后一笔付款的触发条件，而客户目前的资金周转有问题，所以希望能晚一天算一天。

那么，面对诸如上述种种客户不验收的问题，我们作为PM该怎么办?

分两步走：

1、先解决问题（事后解决问题的方法：结构化的问题解决流程）

2、再复盘优化（事前规避问题的方法：把验收当作一个“小项目”，按PMBOK来管）

第一步：采用结构化的问题解决流程，来解决验收问题。（事后解决问题）

《项目管理知识体系指南》(PMBOK指南)中提到，使用结构化的问题的决方法，有助于消除问题和制定长久有效的解决方案。问题的解决方法通常包括以下几个要素：

定义问题；
识别根本原因；
生成可能的解决方案；
选择最佳解决方案；
执行解决方案；
验证解决方案的有效性。

不能顺利的通过验收，它本身也是属于一种问题，因此我们可以借鉴《PMBOK指南》的方法来尝试解决验收问题，按照：定义问题—识别根本原因—生成可能的解决方案—选择最佳解决方案—执行解决方案—验证解决方案的有效性，不断PDCA加以改进。

一：定义问题：

输入：客户或销售正式或非正式的反馈，如面对面交谈，电话，邮件或微信等社交工具的反馈等；

工具技术：思维导图(Xmind/Zen/Mind Manager/百度脑图等)

输出：以下是五种常见的验收问题：

二、识别根本原因：

输入：问题列表

工具技术：鱼骨图；

输出：以下是可能的原因分析；

（值得点击放大，仔细阅读）

三、生成可能的解决方案：

输入：问题列表、鱼骨图

工具技术：思维导图或Excel或word；

输出：以下是可能的解决方案；

（值得点击放大，仔细阅读）

四、选择最佳解决方案

根据每种问题，PM和项目团队充分讨论分析出的可能解决方案，结合实际情况，进行决策，并选择一个最佳的解决方案。

输入：前面步骤输入的内容，如问题，可能的原因，可能的解决方案等；

工具技术：会议、决策；

输出：选择的解决方案；

五、执行解决方案

根据选择的解决方案，PM和团队进行执行，实施解决方案。

六、验证解决方案的有效性

执行解决方案之后，要定时监控所做的解决方案对项目验收是否有效果。如果没有效果，或效果不明确，需要开始PDCA循环，重新分析问题，原因，寻找合适的解决方案，直至验收问题趋于相对顺畅，相对稳定的节奏中来。

第二步：事前规避问题。从项目管理的角度，把验收当作一个“小项目”，按PMBOK的流程来管。

在《项目管理知识体系指南》（PMBOK指南)这本书中有提到，项目验收越早开始越好，甚至启动的时候就开始准备项目验收。作为PM，我们可以把项目验收的工作进行前置，明确在启动，规划，执行，监控，收尾这5个过程组中，每个过程组要做哪些关于项目验收的事宜，然后按计划执行，监控与收尾。不要等到项目上线之后，才开始启动准备项目验收的相关工作，然后又遇到一些未知的未知问题，导致验收工作一再延误，甚至无法验收等不可控的问题出现。

2.1 启动：

识别客户方有验收权利的重要利益相关方与实际决策人。包括但不限于客户方的项目经理、业务部门负责人、IT负责人、高层管理人员等。

以软件项目为例，前期项目组经常对接的是具体的业务使用部门、IT部门，随着项目的交付，验收之后，其他的部门，比如运维部门，网络安全部门等部门的工作和责任就增加了。因此，在验收中他们在最后一刻，提出的问题最多、要求也最严格。所以，尽早识别出对验收有直接利益关系和重大影响的重要相关方，并进行规划管理，对于确保项目按时验收起着举足轻重的作用。

2.2 规划：

在规划项目管理，制定项目管理计划的时候，千万不要忘记要针对项目的验收做相关的规划，并设置阶段检查点。比如项目的验收标准，验收清单，验收决策人，验收的开始时间，验收必须什么时候结束等事宜。并在规划阶段结束后，与客户方达成共识，占据主动地位。千万不要等到项目上线之后，在你催客户验收的时候，客户拿出他们制定的项目验收标准来执行验收审核，这个时候你再根据客户方提出的验收审核不通过的问题点来修改、调整和优化，再次申请二次验收，你就会变得更加被动，让你身心疲惫不说，甚至会给最终的验收造成极大的障碍。

2.3 执行：

在项目执行，实施的过程中，严格按照SOW工作范围说明书，按系统功能模块或项目生命周期，进行细分拆解成WBS，形成RACI角色职责矩阵与需求跟踪矩阵。

RACI角色职责矩阵，明确每个WBS工作包的负责人，职责，以及要求每个WBS工作包的完成，必须同步产出对应的项目文档，确保项目过程文档的完整，齐全，真实和准确，为后续验收铺路，而不是项目上线后，对方要求你补项目文档，你一个人再来苦苦的写“项目回忆录”，痛苦不堪。（不要陷入只重视成果，但轻视文档资料的误区）。

另外需求跟踪矩阵，连接客户需求与项目可交付成果的完成所需要做的工作任务清单，通过工作任务的完成来监控客户的需求是否被满足，不要在项目验收的时候，被客户发现某项需求被遗漏，造成验收延期。

另外实施项目经理和项目团队，一定要对已经完成的项目工作进行严格自测，严控质量，以免给客户留下质量低下的印象。项目实施团队需要确保项目组内部测试通过之后，在移交给客户方参与UAT测试。如果你因为进度原因或资源等各种原因，省去自测环节，直接让客户来UAT测试，一旦客户测试发现大量系统问题，不管问题大小，客户会觉得你的项目交付质量较差。在后续项目上线及验收的时候，客户会变得非常谨慎，会组织测试团队进行多轮次的验收测试，从而反复评估你的项目是否还存在他们未发现的BUG等情形，从而对你项目的验收造成一定的影响。

2.4 监控：

将当前的项目状态与项目计划的预期进行比对，审查是否存在偏差。比如是否识别出哪些人会对项目验收有重要影响，验收标准是否在前期启动和执行的时候，双方已达成共识。如果没达成共识，你是否有应对策略。项目过程文档是否完整，项目质量是否符合标准等。通过监控发现问题后，PM需要立即采取对应的纠正措施，将偏差逐步带回正轨，确保项目状态与预期保持一致。

2.5 收尾：

前面说到，验收是一个“小项目”，因此在验收结束的时候，我们要总结验收相关的经验教训，形成组织过程资产，用于指导后续项目验收该如何做的更好，迭代我们的方法论。验收问题复盘，可参照下方模板进行总结：