项目管理: 我来谈谈项目的收尾

2006年年初，公司面临解散，但是还有部分项目没有验收完毕，公司高层决定采取内部员工承包的方式来解决这个问题，当时，我在公司负责物流项目，刚好有两个项目没有最后终验，这两个项目本来就是我一直负责做下来的，已经完成了初验，所以我承包的时候是非常有信心完成最后的验收的，我也跟公司签定了合同，合同比较苛刻，两个项目最后的终验款合起来是7万元，如果两个项目我在规定时间内全部验收，则公司就把这两个项目的全部回款给我个人，否则拖延一天则赔偿公司0.5%的项目款，直到达到两个项目的回款总额7万元，也就是说，如果我验收不了，则要赔偿公司7万元。一般来说，IT项目的终验基本是很难完成的，大部分公司的合同项目到了最后很多都是不了了之，要不是就拖了很长时间。我承包这两个项目也真的是冒了很大的风险啊，现在想起来真是很害怕，这其中的辛酸只有自己知道啊,幸好我请了2个已经离职的同事来一起帮我完成这件事情（当然是我先垫付工资给他们）。

承包下来后，我首先认真的分析了这两个项目的具体情况，如果让客户快速的验收，我制定了两个策略：(1)根据合同发催终验及回款通知；（2）派人到现场解决客户使用遇到的难题。我的思路是用催终验的方式摸清楚客户的最后需求，以现场解决的方式快速响应，扣住合同的验收条文验收。当时合同的终验都是写在初验后3个月完成,这个对自己有利的地方啊。

我当时承包的两个项目一个在深圳，一个在广州，而且合同规定的终验时间刚好是错开了1个月，因此我首先给深圳的客户发终验的催请函，客户很配合，很快回函说可以进行终验，但是必须解决他们的问题，并且要我先提交终验的报告和相关验收文件，我当时就派了一个请来的同事去深圳现场解决问题，我自己则准备验收报告和验收的相关文件，当时碰到了两个难题：一是去现场的同事技术不过硬，有部分问题要我亲自操刀解决，二是有一些文档不齐全，都是当时赶工忽视了文档，而且在那么短的时间内最后补文档，痛苦啊。我记得我当时是白天在现场解决系统问题，晚上赶文档，经过2个星期的努力，各种准备工作都做好后，客户说要让系统稳定运行1个星期后才能验收，我也同意了，最后那一星期，我吃住在客户那里，还好系统基本上没有出现什么问题，最终得到了客户的认可，客户最后也在验收报告上签字了。

深圳的项目还算是比较顺利的，但是广州这边的项目就很头疼了。

广州这边的项目开始的时候我也采取跟深圳这边项目一样的策略，但是客户根本不吃这一套，客户说要终验，必须要求系统在他们那里完全使用起来才可以，我拿出合同的相关条款，客户根本不理会，说系统没有使用起来就不能验收，我想到过打官司，但是这种官司最后打起来最后肯定是双输的。最后我决定变换策略，一切以客户使用起来为目标。

这套物流系统本来设计理念和思路都是十分先进的，采用.net框架，瘦客户端技术，界面十分友好，系统经过多次测试后比较稳定，特别是业务流程都是进行了优化，功能都已经实现了合同所规定的要求。但是问题就出在我们优化了客户的业务流程，但是客户并不认为这样是对的，因为当时他们的岗位设置，机构设置并没有根据优化的业务流程来设置，所以导致开发好的系统根本不能使用，我一边跟客户交涉什么时候客户的业务流程会变过来，一变着手修改现有的系统使得系统能够满足现有的业务流程。当时系统有几个关键的业务点只要修改过来就可以符合现在的应用模式，在觉得客户更改业务流程无望的情况下，我只能更改系统了，于是我带领了一个请来的同事没日没夜的开始了系统的修改工作，一切的目的就是让客户使用起来。终于客户觉得系统真的能够帮助他们提高工作效率了，客户慢慢在使用系统。

接下来是1个月的慢长的：修改->使用 循环过程，吃住都是在现场，客户也被我们的精神所打动，在全公司范围大面积使用我们开发的系统，甚至动用了行政手段来规范流程，情况越来越好，终于客户在验收报告上签字了。

这次的验收，使得我明白了即使是有最先进的理念的系统(那怕是先进的ERP)，不符合实际，也是没有用的，一切以客户的实际需求为中心，充分满足客户的实际需要，能够真正解决客户的问题，提高客户的工作效率的系统才是好系统。

最后两个项目都验收了，共经历了2个多月，钱也拿到了，数目比较可观（相对来说），于是找了一个投资人和老板，准备运作自己精心准备了1年多的一个综合物流信息平台