第十九章项目收尾管理

软件很难做到没有bug，但大多数bug 已经在测试和验收阶段发现，对于这些bug
在系统移交的时候已经处理完毕。而对于移交以后的系统，如果出现bug 将采用双方约定的方式进行处理。例如在保修期内，大多数是免费处理的，但在保修期外如果发生问
题，双方还需要就处理方式及相关费用做出约定。

每一个应用软件都有自己的生命周期，如果双方未能就软件的生命周期达成一致，
将很可能造成软件后续工作的矛盾。例如甲方在用的版本早已经升级，这时如果还需要
继续的技术支持，乙方将很难提供及时的反应。因此，在项目收尾阶段再次进行磋商是
很有必要的。
通常情况下软件会有比较固定的升级周期，例如每年一次或者每两年一次。但不一
定业主方每次都要求升级，因为升级或者更换新的系统往往会给业主方造成一定的经济
成本或者人力成本。因此在项目结束后，由承建方的服务部门和业主协商给出双方都易
于接受的升级方案。

软件项目的技术支持工作是后续工作的主要内容，对于技术支持工作的内容应该在
合同中予以规定。由于软件项目的复杂性和特殊性，合同本身不仅仅含有项目期间的工
作，也包含有项目完成后服务期间的工作内容。

般来讲，系统集成项目的日常维护工作是比较复杂的。对于承建方服务部门来讲，
系统集成项目的售后服务工作牵扯到很多不同的供货商和设备厂商。而在项目后续阶段，
很难保证所有的设备提供商还能够给予充分的支持和合作。因此，系统集成商（承建方）
应该在项目收尾阶段认真考虑如何保证第三方的技术支持。当然，如果在前期供货合同
中清楚地说明了这一要求，项目收尾阶段只需要确认即可。

很多时候，硬件产品不同于软件产品的更新和换代。在大多数信息系统正常运行后，
3～5 年内一般不会更换主要的硬件产品。对于一些必要的更新，可由双方的维护人员协
商解决。

信息系统的后续工作之一是收集业主对于信息系统新的要求和建议，这些新的需求将构成系统集成企业的信息系统新产品的研发需求。
系统集成项目应该与承建方的CRM 系统紧密配合，有利于承建方更好地为客户
服务。

系统测试是对信息系统进行全面测试，依照双方合同约定的系统环境，以确保系
统的功能和技术设计满足业主的需求，并能正常运行。系统测试阶段应包括编制测试用
例，建立测试环境，逐条进行测试。

信息系统在通过双方的测试以后，可以开始试运行。试运行包括数据迁移和日常维
护。业主可将自己的数据和设置加载到信息系统上进行正常操作，一般来讲，在试运行
期间，双方可以确定具体的内容并进行适当的交接培训。对于在试运行期间发生的问题，
可以看作项目突发事件加以处理，如需要增添必要的工作，可按项目变更过程进行处理；
也可另立新的项目加以处理。

在经过系统测试后，系统的文档应当逐步移交给业主方。业主方也可按照合同或者
项目工作说明书的规定，对所交付的文档加以检查和评价；对不清晰的地方可以提出修
改要求。在最终交付系统前，系统的所有文档都应当验收合格并经双方签字认可。
对于系统集成项目，所涉及的文档应该包括如下部分。
①系统集成项目介绍。
②系统集成项目最终报告。
③信息系统说明手册。
④信息系统维护手册。
⑤软硬件产品说明书、质量保证书等。

在系统经过试运行以后的约定时间，双方可以进行项目的最终验收工作。通常情况
下，大型项目都分为试运行和最终验收两个步骤。对于一般项目而言，可以将系统测试
和最终验收合并进行，但需要对最终验收的过程加以确认。
最终验收报告就是业主方认可承建方的项目工作的最主要文件之一，这是确认项目
工作结束的重要标志性工作。对于信息系统而言，最终验收标志着项目的结束和售后服务的开始。
最终验收的工作包括双方对系统测试文件的认可和接受、双方对系统试运行期间的
工作状况的认可和接受、双方对系统文档的认可和接受、双方对结束项目工作的认可和
接受。
项目最终验收合格后，应该由双有的项目组撰写验收报告提请双方工作主管认可。
这标志着项目组具体工作的结束和项目管理收尾的开始。

项目总结的主要意义如下。
(l)了解项目全过程的工作情况及相关的团队或成员的绩效状况。
(2)了解出现的问题并进行改进措施总结。
(3)了解项目全过程中出现的值得吸取的经验并进行总结。
(4)对总结后的文档进行讨论，通过后即存入公司的知识库，从而纳入企业的过程
资产。

(1)收集整理项目过程文档和经验教训。这需要全体项目人员共同进行，而非项目
经理一人的工作。项目经理可将此项工作列入项目的收尾工作中，作为参与项目人员和
团队的必要工作。项目经理还可以根据项目的实际情况对项目过程文档进行收集，对所
有的文档进行归类和整理，给出具体的文档模板并加以指导和要求。
(2)经验教训的收集和形成项目总结会议的讨论稿。在此初始讨论稿中，项目经理
有必要列出项目执行过程中的若干主要优点和若干主要缺点，以有利于讨论的时候加以
重点呈现。

项目总结会需要全体参与项目的成员都参加，并由全体讨论形成文件。项目总结会
议所形成的文件一定要通过所有人的确认，任何有违此项原则的文件都不能作为项目总
结会议的结果。
项目总结会议还应对项目进行自我评价，有利于后面的项目评估和审计的工作
开展。
一般的项目总结会应讨论如下内容。
(1)项目绩效：包括项目的完成情况、具体的项目计划完成率、项目目标的完成情
况等，作为全体参与项目成员的麸同成绩。
(2)技术绩效：最终的工作范围与项目初期的工作范围的比较结果是什么，工作范
围上有什么变更，项目的相关变更是否台理，处理是否有效，变更是否对项目等质量、
进度和成本有重大影响，项目的各项工作是否符合预计的质量标准，是否达到客户满意。
(3)成本绩效：最终的项目成本与原始的项目预算费用，包括项目范围的有关变更
增加的预算是否存在大的差距，项目盈利状况如何。这牵扯到项目组成员的绩效和奖金
的分配。
(4)进度计划绩效：最终的项目进度与原始的项目进度计划比较结果是什么，进度
为何提前或者延后，是什么原因造成这样的影响。
(5)项目的沟通：是否建立了完善并有效利用的沟通体系；是否让客户参与过项目
决策和执行的工作：是否要求让客户定期检查项目的状况：与客户是否有定期的沟通和
阶段总结会议，是否及时通知客户潜在的问题，并邀请客户参与问题的解决等；项目沟
通计划完成情况如何：项目内部会议记录资料是否完备等。
(6)识别问题和解决问题：项目中发生的问题是否解决，问题的原因是否可以避免，
如何改进项目的管理和执行等。
(7)意见和建议：项目成员对项目管理本身和项目执行计划是否有合理化建议和意
见，这些建议和意见是否得到大多数参与项目成员的认可，是否能在未来项目中予以
改进。

项目评估的意义是将项目的所有工作加以客观的评价，从而对项目全体成员的成果
形成绩效结论。好的项目评估会引导后续项目的开展，并对项目过程的改进起到很重要
的作用。
项目评估的依据：不同类型的项目，评估的要求不同，同一项目的评估要求每个公
司也不相同。不同的主体往往对相同的项目有着不同的要求。多数要求包括以下几个
方面：
(l)盈利要求。
(2)客户满意度要求。
(3)后续项目指标要求。
(4)内部满意度要求。
根据不同的权重将这几项指标进行加权平均，从而得出项目的具体分值。
(1)盈利要求：通常情况下，公司对项目都有盈利要求。而在项目开始时，经过测
算大都能够估算出盈利的指标。但由于存在很多不确定性，项目收尾的时候，盈利与预
期之间一定存在不小的差距，而项目管理的水平就是这一差距的原因。好的项目管理和
团队绩效会加大盈利的水平，而差的项目管理和团队绩效将会减低盈利水平，甚至改盈
利为亏损。当然，还有一些外在的因素会影响项目的盈利水平，包括信息系统项目的需
求不明碲、信息系统业主的原因、信息系统第三方或者项目干系人的原因等。项目评估
的时候也需要考虑这些因素。
(2)客户满意度要求：通常情况下，客户满意度会有比较大的差异，因为这项指标
属于主观性比较强的指标。公司如何评价客户满意度，而不对不同的项目产生很多不公
平的结果，需要公司高管有较为谨慎的态度和细致的工作。客户满意度的调查需要项目
组以外的成员进行，通常采用直接访问调查的方式。就是有公司的调查主管直接访问客户方的人员
（最好是多个客户方人员），通过答题的方式进行，最后在比较的基础上得出
较为准确的评价。
(3)后续项目指标要求：承建方一般希望通过本次项目的合作为双方的长期合作打
下基础，所以大都关注该项目是否能带来其他的后续项目。

项目的审计应由项目管理部门与财务部门共同进行，相关的审计项目应在项目成本
管理中列出。在项目收尾的时候，对已经列出的支出和收入进行财务审计，对不合理的
支出和收入加以分析，为改进项目的管理服务。