项e目收尾.docVIP

系统集成项目的收尾工作 江苏赛杰科技发展有限公司 陈明 我在一家系统集成公司工作，2004年3月，我所在的部门接了个超五星级酒店的系统集成项目的安装调试工作，我担任该项目的业务经理。该项目主要完成该五星级酒店集团总部的音视频工程以及与其集团下属全国100家卖场和其他省市的12家联锁酒店的工作可视会议的联调工作，项目从启动到成功收尾历时10个月，顺利地完成了该项目工作。 我这里主要是探讨了该系统项目收尾工作的主要内容，包括合同收尾和管理收尾，项目的实施收尾的工作流程，该项目在收尾过程中也出现了一些问题。对于需求变更的问题，采取了版本控制、与用户沟通及争取用户方领导协商的办法；对于用户不愿意签字的问题，在了解真实原因的基础上，对症下药；项目资金不能到位的问题主要是争取了公司领导和市场营销部的支持，共同攻关；并在验收后在项目组内部进行了认真的总结。 2008年3月，我作为公司方的项目销售经理参加了某集团总部的音视频工程以及与其集团下属全国100家卖场和其他省市的12家联锁酒店的工作可视会议的联调工作。这个项目由于是客户方是上市公司，涉及的方方面面较广，收尾比较困难，但我们采取了相应的措施，在项目组内部和外部收尾工作都进行得有条不紊。 信息系统项目的收尾是项目生命周期的最后阶段，是软件产品准备提交时，项目班子所做的收尾工作。收尾工作常常是零碎、繁琐、费时、费力的。 收尾过程是项目干系人和客户对最终产品进行验收，使项目或项目阶段有序地结束的过程。许多软件项目在尚未完成之前就被取消了，但项目收尾仍然是重要的，因为通过项目收尾可以总结出经验教训，能够改进未来的项目。 项目收尾包括合同收尾和管理收尾两部分。 管理收尾涉及为了使项目干系人对项目产品的验收正式化而进行的项目成果验证和归档，具体包括收集项目记录、确保产品满足商业需求、并将项目信息归档，还包括项目审计。 管理收尾对降低信息系统项目失败率有重大的意义。为什么会失败？有什么地方可以改进？获得了什么经验？对一系列的问题应进行分析，总结得越多，资源就越丰富，能形成适合企业自身的成熟的管理模式，以降低信息系统项目管理风险和管理成本。 合同收尾就是了结合同并结清帐目，包括解决所有尚未了结的事项。合同收尾需要对整个采购过程进行系统地审查，找出进行本项目其它产品或本组织内其他项目采购时值得借鉴的成功和失败之处。 在该系统当系统开发完成并经过一个月的上线测试后，系统已基本稳定地运行了，我觉得已经进入可以开始收尾的时机了。于是我先是用《验收报告》（是我公司写文档模板）给客户观看，做到双方心中有数，然后开始细致地梳理相关的问题，准备移交的文档资料、软件程序清单等资料；在收尾过程中与客户方保持了持续的多次沟通；最后举行了一场正式的验收会议，邀请双方的领导及项目组成员、相关单位的领导参加，完成了验收工作；在项目组内部也组织了一些正式的会议和非正式的谈话，编写的项目总结报告。 当然，在项目验收的过程中也碰到了不少的问题。 “用户需求的变更是不会变的”，项目要收尾了，需求还在变。主要是因为使用了开发的系统后，用户由于对视频转播点播系统认识有了提高又有了新的需求。系统使用的单位本就比较多，每个单位提一点就相当多了，而且有的还提出了与本业务无关的需求。 对于需求在收尾时还在变更的问题，并不能不允许变更，而应是把变更控制在可接受的范围内。在本项目中，我从以也几个方面入手解决：一是运用版本控制的方法，向用户声明，当前的软件是1.0版本的，不可能包罗万象，哪些功能我们将放在下一个版本中去实现，用户可以直接在我司的网站上免费下载升级版。作为开发方，不能一味的答应下来，否则很有可能会限入变更的的反复，被其束缚；二是取得用户的理解，对不甚合理的地方作出解释，让其知道我们做出了多大的牺牲去帮助他们实现愿望，争取谈判和开发上的主动性；三是和用户方的领导小组进行了协商，统一定了提出需求的最后期限，大大减少了变更的数量。 在项目进行验收的过程中，我发现用户并不喜欢在正式的文档上签字。经过仔细的调查，找出了原因，原来用户有2个需求点。一是希望能让我们多呆些时日，以让公司方多做一些功能，自己多发现一些问题，二是用户方普遍不愿意承担正式签字后的后果。对此，为了消除用户心中的顾虑，我让项目组花些时间细心地给用户准备了详细的维护方案和手册；特别留意在每个单位培养了至少二名用户方技术人员达到可维护系统的水平；为了保证签字的有效性，经与用户方领导小组协商确定了签字责任人，有的在领导小组就可以解决签字的问题；同时我也向公司的领导做了汇报，让公司领导与用户方领导小组有横向的接触；最后组织召开了一次成功的验收会议，双方的领导、项目组成员及用户单位的领导都参加了会议，最终获得了用户的一致肯定和高度评价