项目验收之路漫漫无期，项目经理怎样推动项目验收

(一)项目管理案例：项目验收出了问题

　　我们给一家单位做了一个项目，帮助客户进行项目管理，客户接外面的项目，但是高层不晓得项目进展等一些情况，所有就做了项目管理的项目。我们和对方总公司签的的合同，总公司也上线了，使用情况也不错，但是客户就是不给验收，不付验收款，原因就是他们要求等总公司下面的20多家分布在全国各地的分部都用起来后，而且使用效果要好，才给验收。

　　针对上面的情况，我的项目需要尽快的验收，我该怎么处理呢?

分析：在签订合同时甲乙双方都有商务、经济、赔偿、产品设备验收、验收标准等等条款，验收时出现问题，先查阅合同，按合同条款执行，若是甲方的原因，甲方承担，若是乙方的问题，由乙方解决验收的问题。

分析：一是确认项目合同上是否有明确的项目范围，验收标准。如有，和甲方客户一一核实，并声明完结项目。二，如果没有的话，根据以往信息发送的记录，尽快整理一份项目范围，并和甲方复核后，签字画押，作为验收标准。三，考虑到现实情况，乙方内部沟通，是否可以增加一个后期维护服务，限定年限，作为补充协议。再和甲方沟通，让步结束合同。

分析：1、是否有项目章程，依据章程查看验收标准及边界2、没有项目章程，查看合同或者协议中的条款或者附件，是否明确的验收标准；3、如果合同都没有，那么法律意义上的项目关系就很难确认 ，之前项目沟通的往来邮件或者信息，中查询是否有相关的表述

分析：关于项目验收和项目边界，自然以项目合同中约定范围（总公司还是总公司和属下20多家分部？）为判断准绳如果合同边界不清，那么我们可以这么来看：1、这个项目是客户将项目管理外包给你们做，一方面是认可你们的项目管理专业度，一方面是规避自身项目风险。2、总部的部分，客户是比较满意的，那么这个过程的过程资产（管理工具、规范、表格）和知识转移（项目管理能力、方法）是否做好了整理和培训呢？3、我觉得客户不验收的担心点解决了，客户是可以商量的。 

  

分析：新手分析：1、签订了合同，合同是否约定了项目完成的各时间节点，如有，双方是否按时间点做好相应的交付及签字确认。2、合同约定是给该公司做的项目，是否约定了详细的约束内容，包含总公司下属分公司的实施部署。3、我们的项目，初期阶段是否设置有能随时在后台中断使用的功能，如有，给其使用，当有一定的数据时，在合适时间，双方扯皮时，做中断 .

分析：1 制定培训课程，文档，视频，FAQ。2 分部培训和验收。3 出问答卷验收培训结果。

分析：这种情况主要两种吧一种，项目立项之初，双方项目合同是否有说明验收时间、标准、阶段、验收方、甲方延迟验收如何处理等信息，如果有，按合同行驶权利即可。二种，合同为注明相关信息的，接入商业部，与甲方谈验收流程，如果必要可以签一些补充合同，协助甲方完成培训、指导等工作，尽快完成收尾，释放其他资源在项目中，商业部在处理与客户关系上，也有着至关重要的作用.

分析：若在完全满足验收标准与验收条件的情况下，请尝试理清项目前期商务关系，过程中的人员组织调动，项目结尾时验收方的主审查人做好商务沟通，交涉手段.

分析：其实项目验收经常会遇到这样的情况，我的建议是，1.尽快组织下面单位的使用培训，推进项目的使用，2.与项目负责人及他的管理层进行沟通，说明项目组的困难，一般不验收都是怕项目验收后，对乙方没有了约束，需求变更修改有困难，可以签个补充协议。对这部分进行约束打消甲方的顾虑。

分析：这是就是在前期的时候验收标准没有达成一致，这个一定要达成一致，并且写到合同里面。现在已经发生的只能是走和客户沟通或者都高层路线了。


（二）如何做好项目的验收工作？

实施项目最快乐的事情就是项目验收，可是经常是没完没了的信息化，不见不散的项目组，验收之路何其漫漫。

我在整个项目经理技巧中都反复强调任何工作达到成效，并不在一时一地事情做到位，而是在平时工作积累中将事情细节做完善，做到位，很多想要的结果就自然达到了。

项目验收就是我们最想要达到的结果，一旦项目验收对很多人还意味着一件现实的事情就是，我们可以回款了，可以获得项目提成收入了，同样项目验收也是一系列细致工作完成到位的结果，而不是某个点的成功或者个人能力就可以促成的事情。一个项目的验收，未必是一次性活动，而是由一系列验收准备工作组成的，在最终验收之前，我们已经将很多阶段工作细化并得到认可执行，项目验收就是一个水到渠成的事情。

一、项目验收的条件

很多人会奇怪，这个问题还需要谈吗，肯定是按照合同和技术协议验收。

其实在业内目前项目合同和技术协议现状是一个项目，不管金额大小，个性化开发多少，软件功能模块，几乎是一个不少，用户要求我们承诺的服务内容也是一个不少，供应商在竞争压力下的营销过渡承诺很难完全避免杜绝，如果要以完成合同和技术协议为标准进行验收，业内的大部分项目个人以为达到预期要求的可能非常之少。

当然这和技术协议架构方式有关，一般最开始技术协议只谈服务内容和实现目标，很笼统，结果在实施过程中很容易出现业务需求爆炸的情况，软件商难以应付。

这种情况下软件商就开始逐步细化产品功能点，按功能点确定软件细节，只要功能点满足，理论上就应该满足用户业务需要，用户就应该验收，至于业务能否运行，更多的是用户的责任，这里面更多的体现了软件商的自我保护。

实际运做时无论技术协议多细致，对用户而言根本没有太大的参考价值，用户只会考虑其业务是否真的在运做，并以此作为检验我们项目是否可以验收的标准，当然有的项目可以通过商务运做，在业务实现不太好的情况下也能验收。

所以现在一般的模式管理软件项目是按照服务内容分几个业务目标，完成一个业务目标就完成一阶段验收，收取一部分实施费用。

所以项目验收的最小条件是一个或某几个基本业务面能够开始大面积的应用。

这些基本业务面是不是很简单，或者是不是很稳定，或者人员是不是一定全部都上线，或者业务面上功能是否存在可改进功能都不一定，但只要用户看到这些基本业务面可以运行并承认这个可预期的结果就可以了。

二、确定里程碑

我们现在知道如果要真做好一个项目，完成项目验收条件，是以业务是否可用为考量角度。不是一定得实现所有用户的需求，也不是只有将一些所谓的技术难点解决用户就可以用起来并验收，而是我们可以完成一定的阶段应用业务目标。

所以要想成功验收，不是我们什么都承诺，什么技术问题都实现项目才能做好，而是和用户沟通，代表公司和用户就项目业务实施目标达成一致。

因此我们从进行业务调研的时候就要主动控制项目的业务边界，将一个一个业务流根据企业实际情况合理组织实施顺序，形成我们项目实施计划中的里程碑点，明确达到里程碑点的条件，并得到双方一致正式认可。

在中国管理软件售前工作和用户还无法建立长期合作关系，面对不是很成熟的用户和疯狂的竞争对手，我们在生存压力下可以先和用户建立合作关系，一旦能合作，就相对容易和用户建立信任关系，有了信任就可以慢慢教育用户，用户一旦理解很多事情的复杂性不是软件单方面可以控制的，反而会理性地和我们一起解决问题。

因此我们要相信用户是理性的，他一定会坐下来和我们一起谈：那到底怎样解决问题呢？最终可以达成合理的结果，然后我们全力去冲刺每个里程碑。 

里程碑的好处第一是将复杂的业务目标分解为一系列简单的目标，即降低了难度，又使每个阶段实施重点突出，精力集中在一点上，自然可以更有效解决问题。第二里程碑界定目标包含了一个一个相对独立应用台阶，可以促进用户项目一个台阶一个台阶往上走，用户只要达到了一个里程碑，项目在这个业务实现台阶上就可以进入不可逆转的状态，不会走走停停，经常从头开始。

在具体项目中，这些里程碑内容都可以设计，在每个项目中成功设计里程碑的关键就是最小化项目边界，然后和用户高管和中层干部，甚至在某些项目上还要和基层达成一致。

我们控制边界的前提是我们自己要有可置换的因素，这就是用价值换边界。

我们必须在深刻了解用户业务基础上提出我们的业务目标，阐明项目价值所在，让用户接受业务目标，并按照这个业务目标去实施，而不是纠缠在有什么功能没有什么功能。

功能很重要，但考虑用功能如何支撑业务流程更重要。

所以一个人在项目中最大的力量往往源自对业务深刻而理性的把握。

成功项目验收的核心就是边界的确定。

没有双方高度达成一致的里程碑认可，也就是没有项目目标约定，没有目标约定的项目实施计划一定会经常变更内容、变更初始设定目标，导致计划不可控制，更谈不上验收。

很多人希望通过详细解决方案来定义项目要实现的内容和业务目标，这是很有必要的，但解决方案得到认可并非是通过用户审核就可以的结果，应该想办法让用户一起参与解决方案思路思考，变成用户自己推导出来的业务实施目标，未来才不容易变形。

因此我们建议在确定里程碑的时候和不同层面人员大量沟通目标，确定达成一致，在产品比较成熟的情况下，能否就项目边界达成一致是最关键的工作，一旦这个目标达成，就很容易制定计划执行和落实。

确定每个里程碑后续工作可以参考下面的标准流程。

三、主动沟通

一般项目业务目标清晰后，就可以按照业务目标分解相应工作，逐步落实，在落实过程中有一个很重要的工作是很多实施人员会忽视的，就是主动沟通。

项目中一定要有沟通策略，和高管如何汇报工作进展，取得支持？和中层如何就业务目标不断确认，逐步清晰？和基层如何就项目应用操作模式达成一致，持续改进？都需要通过沟通反馈完成。

沟通的作用对于高管是让他们清楚我们一直按照项目目标前进，每个阶段工作进展是否顺利，影响项目正常运做原因是什么，需要哪些资源帮助。和高管沟通比较多的话，第一个好处高管经常听汇报就知道项目进展程度，可以安排反馈检查，看是否具备象我们所说进展，这样一旦认可了各个阶段目标后，最终要求高管签字结项也就顺理成章。

第二个会哭的孩子有奶吃，一把手工程核心就是高管支持项目运行，而做到这一点关键就是通过合理汇报让高管对一个逐步前进的工作进行业绩的承认，高管一旦认为某个事情比较容易成功了，反而容易追加资源保障完成，这就是信息化的：“马太效应”。

一个工作高管经常性不知道进展，怎么会支持呢？当然谁去汇报可以在项目中界定是企业还是我们软件实施商，但一定要和高管主动汇报。

给高管汇报技巧就是简洁明了，真实客观，有理有据分析问题，提出对策建议请其决策即可。

中层往往是项目主要的推动力量和实际执行者，也往往是对具体业务需求最主要要求者，他们对企业实际运做过程最清楚，提出要求最具体，而且项目验收与否没有中层的同意往往也是不太容易做到的。

要达到项目的目标没有中层的配合也是非常困难的，和中层的沟通往往是不断动态调整项目目标，逐步清晰化项目目标和细节的过程。

往往通过前期业务调研只能对企业项目目标有一个大的，宏观的认识，但如何细化并最终落实并非是一步到位的过程。因此在整个项目过程中，双方项目组要不断沟通，特别是企业中层沟通，才能逐步认识越来越深刻，最终达成一致。

和基层的沟通主要体现对最终用户的关怀，定期主动和最终用户沟通，消除一些怨气，让用户能坚持用下去，这个时候我们往往发现很多用户真的是非常可爱，尽管软件还有很多值得改进的地方，但他们一旦认可我们团队，反而会尽心尽力帮助我们推动。

个人以为一般在项目中要坚持每个月到一个半月写一份详尽《情况简报》，分别通报企业项目负责人，部门负责人，项目组成员。

《情况简报》应先发邮件，然后一定电话落实收到并口头简要汇报，特别是高管层，千万不要以为发了就等于别人会去看，一定要口头跟进汇报一次，保证企业各方面负责人对项目进展做到心中有数。

另外实施工程师无论是否在现场，保证每周至少和操作用户、系统管理员沟通一次，主动和用户接触，不要等到用户有问题再来找我们解决。

这样反而可以逐步释放用户一些火气，真要救火的时候我们反而有一些从容周转的时间，一回生，二回熟，到了验收的时候也好说话。

四、写好备忘录

在一个漫长项目周期中，很多工作做了也就做了，认可了也就认可了，时间一长也就忘记了很多承诺和约定，到了验收的时候就翻出来重新要，这种事情很多人可能都经历过，明明说得可以先不做的内容最终验收的时候又成了必要条件。

所以在一个项目中要顺利验收，一定要写好备忘录，把平时项目过程中重要阶段点双方达成的共识详细记录下来，以备查询。

项目组在每次现场工作都必须要写备忘录，备忘录必须注明现场工作天数，按时间段写清楚工作内容，性质和时间长度。

例如培训工作要写清楚培训人员名称，培训内容，培训小时数，培训掌握效果；

例如装机工作要写清楚装机软件，装机台数，是否可正常使用等等细节。

每次备忘录要口头交流认可后才打印签字确定阶段性工作成果。下次工作则根据前次备忘录的双方约定继续进行，保障项目在每次工作基础上不断前进，并用备忘录约束双方的行为。

备忘录标准的写法是先简要汇报阶段工作中内容，要用积极肯定性的文字给自己前一段工作或者一些提法给出正面结论，这样大家看了才有信心。

这个工作内容往往是上一阶段约定要解决的内容，而且在这次现场工作中得到解决的内容，要考虑和上一次备忘录约定工作内容的呼应，很多人写备忘录，纯粹是为了备忘而备忘，备忘录三大功能，第一是备忘，第二是缴功，第三是约定后续工作安排，推动事情继续前进。

所以写备忘录首先要讲上一次我们约定什么工作，这次是否完成，完成质量如何，没有完成是什么原因造成的，是否纳入下一次解决的内容，这样的文档才有体系，也能体现出一个人整个项目过程中的脉络，否则写这么多备忘有什么用？

结论出来后后备忘录要详细描述自己所做工作细节，细节越详细越好，让项目组彼此认可工作内容和质量，而且对服务工作量可以有一个客观的评估。

而且在写备忘录时发现自己大量时间并非在有效沟通或者在推动项目实施上，那么意味着项目已经是在失去控制路上，应该立即引起警觉并采取措施解决。

备忘录最后还要约定下一阶段双方工作安排，在后续工作中严格按照备忘录设计自己的工作计划，了解企业项目组进展，如果企业项目组方面配合出现问题，在下次备忘录中要明确指出责任承担方，给用户形成一定的压力，从而更好推动项目走向前进。

一些重要的项目目标约定或者验收意见可以单独写备忘录，在最终验收时可以作为依据。

这样一个备忘录一个脚印推动项目向目标前进，每个备忘录都在前一阶段工作上有一点点进步，最终项目验收就是水到渠成的事情。

除了实施备忘录外，实施人员最好给每天工作做详细记录，实施备忘录个人认为只是一个工作进度大概描述，而且可能会有水分，因而需要有一个每天工作的详细记录用于自己或者团队成员准确把握项目脉搏，及时发现问题，个人也能随时做项目回顾，用户的反复也能随时记录在案，如果出现项目延误，也能有理有节和用户应对。

五、精心准备一次成功的汇报

如果项目准备验收了，一般要安排一次验收鉴定，这个鉴定可能是要请专家来看，可能是企业内部组织，也可能就是几个人认可签字即可。

因此如果要验收，最后鉴定这个工作质量要高。

要准备好一套模拟现场环境的演示环境，要有足够真实的数据，要设计一套体现应用特色介绍流程，要准备一套详实汇报材料和相应PPT。

要保证验收大会顺利通过，其实是在验收大会前将相关汇报工作和现场应用情况和企业领导做过汇报，并得到充分认可。

六、平时做人的积累

对于项目一个实施人员要为公司考虑节约成本，同时也兼顾客户利益，是比较难以决策的。

特别是在一个多可能同时负责多个项目的时候，想每个项目都应该全力以赴是很困难的。这样难免让用户觉得我们响应不及时，有问题不解决，特别有些问题不是我们一个个体能够解决的，长期下来用户可能会积累很多的怨气。 

因此实施人员平时做人要讲诚信，讲原则，无非是三条：

做不到的事情千万别随意承诺；

承诺的事情一定要努力做到；

每次做到的事情都进步一点点。

有这三条用户会慢慢接受稍微长一点的响应周期，也会用更多积极性眼光看现在的问题，也相信问题一定有人响应，也一定可以得到解决。

我们很多人做项目遇到困难在公司内部没有想尽办法去解决，认为我自己这么努力，承受这么大的压力，而别的同事好象没有什么压力，心理不平衡，就容易回避放弃。拖，拖，拖，拖到无法再拖的时候在用户那里就没法抬头，只能被动挨打。

如果按照以上三条原则做事，反而简单，不做做不到的，当然这个做到做不到不是个人判断，而是和公司内部协调达成一致后的意见，做得到的一定按承诺做好，项目就会简单。

实施过程中可以留一手，有些好功能或者便利的地方，可以不全部告诉用户，毕竟在合同边界中没有涉及，在验收前可以作为条件和用户去置换。

七、如何催款？

首先要主动提出回款要求，这是很多实施人员最难做到的一点，不知道如何开口，担心开口后被动。

其实要钱这个事情最难的就是开口要，开口要了就简单了，为公司催款是天经地意的事情，你是在为公司生存催款，也是为了有钱才能提供更好的服务，要理直气壮的去要钱。

就象很多人催别人还自己借给他的钱一样，难就难在自己的心理顾虑上。

不管项目实施地好不好，一开头要钱，用户马上就会提出不合适，这个时候我们要趁机了解，现在不合适，具备什么条件就是合适？立即和用户约定回款条件，有了回款条件，等于给自己清晰约定了双方工作目标，那么这个回款条件马上写进备忘录，达成一致意见。

所以项目中只要觉得具备一定条件，就要主动提出验收，验收速度取决于对验收目标是否达成一致。

不断提出验收要求，就可以不断就项目目标进行清晰定位，反复三次后，验收目标就清楚了，这个时候双方项目组就该解决的问题就尽快解决，不能解决的就想办法，例如进行价值置换，或者追加资源投入，或者紧急开发，或者变更合同等等。

回款条件也不要立即写成备忘录，先不断提出各种可行回款条件，，逐步选择最合理的条件以加深印象，并不断利用各种汇报的机会明确，最终写到备忘录中成为未来验收工作开展依据文件。

一旦目标一致清晰后，实施团队要全力保障回款条件实现，一旦达到回款条件，还别忘了请商务人员做去商务工作，个人也不是万能的，搞技术的可以催钱，但不要去要钱。


（三）如何改变客户对项目验收的认识

    PMP项目管理专业人士资格认证。它是由美国项目管理协会（Project Management Institute(PMI)发起的，严格评估项目管理人员知识技能是否具有高品质的资格认证考试。其目的是为了给项目管理人员提供统一的行业标准。目前，美国项目管理协会建立的认证考试有：PMP（项目管理师）和CAPM（项目管理助理师）已在全世界190多个国家和地区设立了认证考试机构。现在PMI中国和国家外国专家局培训中心又推出了ACP(AGILE敏捷认证)和PGMP（项目集管理认证），另外PBA(商业分析师)预计于2016年年底开始推行。下面是希赛PMP学院小编为大家提供相关信息内容。

   ★案例正文：

   现在给一个客户做了有3个项目了，但是这3个项目都存在着一个共同的问题，就是客户迟迟不验收。

   客户担心做出的系统不好用，他们最大的领导都是这样想的，并一致认为先用用看，如果没什么问题了再验也不迟。但我们公司内部对项目都划分了项目规模的验收标准时间，以及验收后项目回款的要求。如果该验收时没验收、该回款但是没回款，且超出项目相应缓冲时间的，都是我的责任，都把考核都挂到我头上了。项目管理者联盟文章

   现在客户那边最早做的那个项目，在项目完成后第4个月初才把项目验收完毕，然后进行第二笔款的办理，可公司内部早已经考核过我两次了，该客户以后存在着不少潜在项目，项目肯定会一直做下去，项目款也最终能付过来，但是，就验收这个问题，让我陷入困境。

   ★项目管理专家点评：

   专家简介：

   王树文：毕业于中南大学，硕士，PMP、EMCP(国内最早通过该认证的三人之一)、国家信息系统项目管理师、高级工程师、高级系统集成项目经理、中国软件过程改进专业委员会(CSPIN)专家、广东软件过程改进专业委员会(GDSPIN)高级专家、《交付保障与生产力杂志》编委。现就职于广州华南资讯科技有限公司(上市公司)，从事过多个大型项目的开发和管理，目前任该公司总经理助理兼软件质量保障总监、质量体系管理者副代表。

   专家点评：

   项目验收困难，是很多项目遇到的难题。分析起来，造成项目难以验收的原因很多，根据我的个人经验，主要有以下几种原因：

   (1)项目建设成果没有达到合同要求、没有满足用户期望;

   (2)项目建设过程中，缺乏和客户充分的沟通，和用户“互动”不够，没能让用户充分了解项目的建设情况和成果，用户信心不足，心里没底，不敢验收;

   (3)合同中没有清晰约定好验收的条件，导致双方理解的误差，从而影响项目验收;

   (4)在项目建设阶段(一般是项目建设的前期)，项目组没有和客户沟通落实好验收条件和验收流程，验收工作“无章可行”，从而影响项目验收;

   (5)项目组为验收而验收，对验收工作准备得不充分，没有真正按原来双方约定的验收条件去不折不扣地准备验收材料，而是存在侥幸心理想“蒙混过关”，验收条件中约定的产出物缺失或存在明显质量问题，从而影响项目验收

   (6)客户对乙方不放心，担心项目验收后，乙方的后期服务会跟不上，这也将导致客户不敢验收项目。

   针对以上六种情况，我给出如下建议供大家参考：

   对于第一种情况，需要我们项目组注意认认真真做事，严格履行合同条款，不要把验收当作你的唯一目标，而应该首先解决好客户的问题，工作做好了，大家双赢了，项目验收自然就会顺利很多。

   对于第二种情况，需要我们项目组注意按规范的流程做事，《项目管理规范》、《项目计划》、《沟通计划》等要事先和客户进行充分沟通并得到客户认可，建设过程中严格按规范办事，需要提交给客户的过程性文档和资料，严格按《沟通计划》中的约定及时主动提交(不要等客户催才提交)，和客户的沟通交流会议也应该有序地坚持，经常向客户汇报和演示阶段性成果。只有让客户充分了解我们的工作，才能建立起客户的信心，客户心里有底了，他也就有把握验收了。

   对于第三种情况，则需要我们在和客户签定合同时就注意，产生这种情况的原因，应该是公司没有合同范本或缺乏必要的合同评审机制。要解决这类问题，则要从公司层面确定好合同范本(即合同中需要包括清晰的验收条款)，合同评审人员评审合同时，也要重点关注合同中是否有清晰的验收条款，这些条件是否可执行。

   对于第四种情况，即是说万一在合同中没有清晰的验收条款(或合同中的验收条款有问题)，则项目组就需要注意在合同建设过程中(最好是前期，越早越好)，通过另外一份正式的文档和客户约定好验收条件和验收流程，双方签字，之后就严格按本约定执行。

   对于第五种情况，项目组需要踏踏实实严格按原来双方约定的验收条件去不折不扣的准备验收材料，验收材料准备好后，要组织认真评审，确保验收材料齐备、质量好。客户看到您提供的材料齐全、质量好，自然他心情好，心情好了，验收就顺利了。

   对于第六种情况，则主要取决于公司的品牌和公司的信誉(这是长时间积累的结果)。可以通过公司标准的文档和规范，给予客户优质售后服务的承诺并严格执行，让客户无后顾之忧。验收后的问题，我们都帮客户想到了，客户自然就放心了，从而验收也就顺利了。

   当然，作为项目经理，自身的风格和做事方式也非常重要，这也是影响项目验收的一种因素。因此，项目经理要努力树立好自己良好的品牌和口碑。这样，在其它情况都差不多的情况下，您负责的项目验收起来将会更加顺利。

   题外话：案例中提到把项目验收和回款严格作为对项目经理考核的重要因素，个人认为不太合适，对项目经理的考核应该综合其它方面的因素，因为让一个对不可控因素(因为有时侯项目能否顺利验收和回款，项目经理真的也很无奈)承担过多责任的做法，本身就是不合理的。