如何做项目验收.docVIP

9如何做项目验收?

9.1验收工作应如何组织？

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

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

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

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

9.1.1项目验收的条件

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

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

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

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

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

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

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

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

9.1.2拟定里程碑

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

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

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

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

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

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

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

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

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

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

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

成功