如何做项目验收

9 如何做项目验收?

9.1 验收工作应如何组织？

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

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

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

下面我们就一起讨论一下如何进行项目验收。

9.1.1 项目验收的条件

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

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

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

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

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

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

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

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

9.1.2 确定里程碑

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9.1.3 主动沟通

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

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

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

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

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

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

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

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

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