信息系统项目的收尾工作

第一篇：信息系统项目的收尾工作

论信息系统项目的收尾工作

软件项目收尾是软件项目生命周期的最后阶段，是软件产品准备提交时，软件项目班子所做的收尾工作。收尾工作常常是零碎、繁琐、费时、费力的。许多信息系统项目总是无法收尾，甚至在快要验收时，用户又提出了新的需求，对已开发的系统不满意。请围绕“论信息系统项目的收尾工作”论题，依次对以下三个方面进行论述。

1、概要叙述你参与分析和开发的信息系统项目以及你所担任的主要工作。

2、概要说明信息系统项目收尾工作的工作内容及工作流程。

3、详细讨论在项目的收尾工作中碰到了什么难题，采取了何种方法和措施，得到了什么经验教训。

1、范文写作思路

[尚大教育软考学院评注]下面一起来用前文所述的写作方法来构建写作思路和写作提纲。

拿到考卷后，迅速阅读论文考试试题，以决定写作哪个论题。

接下来，构思论文要相关联的项目和写作提纲。本题准备与论文题目关联的项目是：“某市政府公文流转系统项目”。此项目属于政府办公用的信息系统项目，主要满足某市市政府的市领导、政府办、政府和职能部门的政府内网中的电子公文流转工作。论文拟从乙方的角度来写。

[尚大教育软考学院评注]乙方是指合同中的乙方，常为承包商，甲方常指合同中的外包商；在信息系统项目中乙方指开发公司方；如此处乙方为项目开发公司，甲方为政府方。

考虑好关联的项目后，开始思索文中的主要论点。项目收尾主要包括两个方面的内容：管理收尾和合同收尾，工作流程可按公司的项目管理流程来走。收尾工作中常见的问题与对策有：

（1）用户不断提需求，在项目进入收尾后还在提出需求变更，在使用了开发的系统后，用户由于对公文流转系统认识有了提高又有了新的需求。可采取系统版本控制的办法，即当前版本定为V1.0，新的需求与用户协商放至V2.0中完成，先完成V1.0的验收，部分修改可作变更；和用户的上级进行沟通，约定一个需求提出的最后时限，以界定需求，减少需求和变更的发生，以早日验收；和用户沟通，争取用户的理解与支持。（2）用户不愿意签字。表现为不愿意在正式的文档上签字，希望能让开发方多呆些时日，以多做一些功能，多发现一些问题，用户不愿意承担正式签字的后果。可给出用户详细的维护方案；培养用户方技术人员达到可维护系统的水平；与用户上级协商确定可以拍板的人；向自己的上级，公司领导汇报情况，得到公司领导的支持；召开成功的验收会议。

（3）项目资金迟迟不能到位。政府项目常有这种情况发生。遇到这种情况马上向公司领导请示，要求出面解决；与公司市场营销部门协商解决对策；对相关决策人重点攻关。

（4）项目组内部的工作总结。项目收尾了，文档整理和项目经验的总结都是十分细致的工作，需要项目经理组织人员细心耐致地去做。可组织一次项目组的正式或非正式会议，畅谈项目研发过程中的经验，会中做记录，会后做整理；将所有项目的文档和源程序归档。

以上就是论文写作的基本思路，接下来写作提纲，即写段落大意。

[尚大教育软考学院评注]写提纲的作用就是要使文章显得有条有理，表述清晰，论点分明。考生可在草稿纸上来写，考试时会发草稿纸。“磨刀不误砍柴工”，写好提纲后就能对全文有一个整体的把握。考试时，提纲中的论点可以多写几点，正文写作时如果觉得某个论点不好写可以不写。

范文的写作提纲：

（1）项目简介，以及自己担任的角色与职责。

（2）项目收尾的工作内容（管理收尾和合同收尾）。

（3）项目收尾的工作流程。

（4）收尾中碰到的问题与对策分析。

问题

1、需求变更的问题；

问题

2、用户不愿意签字的问题；

问题

3、项目资金不能到位的问题；

问题

4、如何进行项目组内部的工作总结。

（5）结论。

[尚大教育软考学院评注]对于问题的讨论可以描述问题作为一段，讲解采取的对策和实施效果作为一段，或根据需要分段，一般段不宜过长，以不超过10行为。

2、范文全文

[尚大教育软考学院评注]这里把摘要放在前面以方便读者阅读，考试时提倡摘要写作的时间放在正文写作之后。

论信息系统项目的收尾工作

[摘要] 本文以我作为开发方公司的项目经理主持的某市政府公文流转系统项目为实例，探讨了信息系统项目收尾工作的主要内容，包括合同收尾和管理收尾；给出了该项目的实施收尾的工作流程；针对在该项目在收尾阶段中出现的需求变更、用户不愿意签字、项目资金不能到位、如何进行项目组内部的工作总结四个问题，详细讨论了它们的解决办法。项目最终成功地收尾。

[尚大教育软考学院评注]“针对在该项目在收尾阶段中出现的需求变更、用户不愿意签字、项目资金不能到位、如何进行项目组内部的工作总结四个问题，详细讨论了它们的解决办法。”改为“该项目在收尾过程中也出现了一些问题。对于需求变更的问题，采取了版本控制、与用户沟通及争取用户方领导协商的办法；对于用户不愿意签字的问题，在了解真实原因的基础上，对症下药；项目资金不能到位的问题主要是争取了公司领导和市场营销部的支持，共同攻关；并在验收后在项目组内部进行了认真的总结。”，如此表述全文的论点更为清晰。[正文] 2004年，我作为公司方的项目经理主持了某市政府公文流转系统项目的研发工作，该项目主要完成某市政府（地级市）的市领导、政府办公厅、下属40多个部办委局的工作机构之间的电子公文流转和电子签名工作，项目从启动到成功收尾历时10个月，顺利地达成了项目的标。这个项目由于是客户方是政府机关，涉及的方方面面较广，收尾比较困难，但我们采取了相应的措施，在项目组内部和外部收尾工作都进行得有条不紊。

信息系统项目的收尾是项目生命周期的最后阶段，是软件产品准备提交时，项目班子所做的收尾工作。收尾工作常常是零碎、繁琐、费时、费力的。

收尾过程是项目干系人和客户对最终产品进行验收，使项目或项目阶段有序地结束的过程。许多软件项目在尚未完成之前就被取消了，但项目收尾仍然是重要的，因为通过项目收尾可以总结出经验教训，能够改进未来的项目。项目收尾包括合同收尾和管理收尾两部分。管理收尾涉及为了使项目干系人对项目产品的验收正式化而进行的项目成果验证和归档，具体包括收集项目记录、确保产品满足商业需求、并将项目信息归档，还包括项目审计。

管理收尾对降低信息系统项目失败率有重大的意义。为什么会失败？有什么地方可以改进？获得了什么经验？对一系列的问题应进行分析，总结得越多，资源就越丰富，能形成适合企业自身的成熟的管理模式，以降低信息系统项目管理风险和管理成本。合同收尾就是了结合同并结清帐目，包括解决所有尚未了结的事项。合同收尾需要对整个采购过程进行系统地审查，找出进行本项目其它产品或本组织内其它项目采购时值得借鉴的成功和失败之处。

在某市政府公文流转系统当系统开发完成并经过一个月的上线测试后，系统已基本稳定地运行了，我觉得已经进入可以开始收尾的时机了。于是我先是用《验收报告》（是我公司写的文档模板）给客户观看，做到双方心中有数；然后开始细致地梳理相关的问题，准备移交的文档资料、软件程序清单等资料；在收尾过程中与客户方保持了持续的多次沟通；最后举行了一场正式的验收会议，邀请双方的领导及项目组成员、相关单位的领导参加，完成了验收工作；在项目组内部也组织了一些正式的会议和非正式的谈话，编写的项目总结报告。

当然，在项目验收的过程中也碰到了不少的问题。

“用户需求的变更是不会变的”，项目要收尾了，需求还在变。主要是因为使用了开发的系统后，用户由于对公文流转系统认识有了提高又有了新的需求。系统使用的单位本就比较多，每个单位提一点就相当多了，而且有的还提出了与公文流转无关的业务需求。

对于需求在收尾时还在变更的问题，并不能不允许变更，而应是把变更控制在可接受的范围内。在本项目中，我从以下几个方面入手解决：一是运用版本控制的方法，向用户声明，当前的软件是Version1.0的（或者是某一版本的），不可能包罗万象，哪些功能我们将放在下一个版本中去实现，作为开发方，不能一味的答应下来，否则很有可能会限入变更的反复，被其束缚；二是取得用户的理解，对不甚合理的地方作出解释，让其知道我们做出了多大的牺牲去帮助他们实现愿望，争取谈判和开发上的主动性；三是和用户方的领导小组进行了协商，统一定了提出需求的最后期限，大大减少了变更的数量。

在项目进行验收的过程中，我发现用户并不喜欢在正式的文档上签字。经过仔细的调查，找出了原因，原来用户希望能让开发方多呆些时日，以让公司方多做一些功能，自己多发现一些问题，用户方普遍不愿意承担正式签字的后果。对此，为了消除用户心中的顾虑，我让项目组花些时间细心地给用户准备了详细的维护方案和手册；特别留意在每个单位培养了至少一名用户方技术人员达到可维护系统的水平；为了保证签字的有效性，经与用户方领导小组协商确定了签字责任人，有的在领导小组就可以解决签字的问题；同时我也向公司的领导做了汇报，让公司领导与用户方领导小组有横向的接触；最后组织召开一次成功的验收会议，双方的领导、项目组成员及用户单位的领导都参加了会议，最终获得了用户的一致肯定和高度评价。

项目在验收会议表示验收通过会，项目的资金却迟迟不能到位。资金没有到位，说明收尾还没有完成。我马上向公司领导进行请示，请求支持，并向公司市场营销部门要求协助，共同重点攻关。本项目标的并不高，只有100万，但用户方财务手续审批繁锁，造成了时间上的延时，经用户方领导小组组长的拍板，最后在验收通过的第20拿到了合同规定的款项，并保持了和用户的良好合作关系。

项目只是更大范围的组织环境中的一部分，许多对项目的影响因素不是为项目经理所控制的。项目经理对管理事务常不熟悉，因为在国内项目经理大都是由程序员成长起来的，需要公司领导的培养和指导。在收尾工作，象客户款项的收缴、项目结束时的会谈、客户关系出现危机等许多场合下是需要公司领导的支持和参与的。在一个公司领导很重视的环境下，收尾工作会是更为出色的。

通过验收了，拿到资金还不能说项目收尾成功了。在项目组内部还要进行认真的总结。，文档整理和项目经验的总结都是十分细致的工作，需要项目经理组织人员细心耐致地去做。可组织一次项目组的正式或非正式会议，畅谈项目研发过程中的经验，会中做记录，会后做整理；将所有项目的文档和源程序归档。

项目总结是项目可持续发展的必要，也是对项目和项目组成员的尊重。当前项目的经验对其它项目是有很好的借鉴意义的，特别是对类似的软件项目，在管理上、技术上、开发过程上都是一笔财富。不仅要对项目的程序代码存储，所有相关文档资料（包括合同、开发文档、总结文档等）也要归档。

我比较倾向于在饭桌上和同事们谈经验来总结，一是大家完成项目了，代表公司要表示慰问，另一方面在这个时侯谈感想谈经验是最好的时机，大家话也比较多；在谈话后我编写了项目总结报告，总结了同事们的各种观点，为今后其它项目的开展提供了知识积累。“不断地学习改进”，我把它作为自项目团队的工作信条。

总之，信息系统项目的收尾是一项需要细致、耐心而微妙的工作。项目的收尾包括合同收尾和管理收尾，在本项目中，出现了用户需求仍在变更、用户不愿意在正式的文档上签字、验收后资金不能及时到位、内部项目总结如何开展的问题，都较好地得到了解决，成功地收尾。[尚大教育软考学院评注] 文章写作思路清晰，主旨明确。对项目收尾的主要内容、流程，以及碰到的问题作出了论述，扣题较紧，提出的问题在信息系统项目收尾中是常见的问题，针对问题采取的措施亦十分得体。但摘要的字数还稍少了点，可将四个问题的基本解决办法在摘要中点明。

第二篇：如何做好项目收尾工作

如何做好项目收尾工作

1、要提前或者说提早进入收尾状态

项目竣工验收前的分项验收内容多，如消防、电梯、强配电、供水、环保、电梯、绿化等，这些验收是要由相关政府部门来进行的，因此项目要提前进入收尾状态，正常情况下要在计划项目竣工验收前3至4个月进入收尾阶段。如遇上春节可能要更早。

2、收尾工作包括三大项

这三项工作包括实体收尾、资料收尾和工程量确认。通常的说法只包括实体与资料，但考虑到工程量的确认影响施工方的收尾积极性，因此也要作为一个大项加以重视。

3、收尾前要进行工程完成状态摸底

在确定了收尾阶段起始日后，在起始日前一周要对工程完成的状态进行全面地摸底，查清楚有哪些项目不没有完成，有哪些小项还没有开始，有哪些项目做错了要进行变更或者说是做错了，有哪些严重的施工质量缺陷。

4、收尾工程状态摸底应包括以下内容：

1）工程分部分项的完成情况，按承包单位甚至班组进行分类归纳。

2）已完成的分部分项工程的成品保护和运行状态

3）是否存在完全没开工的分部分项

4）没完成、没开工的分部分项的原因。是否材料采购困难、材料不足？是否专业工种工人缺乏、劳动力不足？是否特种设备、配件不足？是否特种施工工具或机械缺乏？当某些原因发生时，要考虑改设计图纸来进行。

5）不要忽视小项目，如车库门、门锁、路牙石、门牌安装等一些小项。一些小项目由于特种工人不好找，影响后续工序，所以不能忽视。

6）不要小看现场清理，这也是一个重要项目，而且在清理后要设法维持整洁状态。

7）各种边角部位的收口。在统计未收口的同时，要弄清楚未收口的原因，如还有项目没做没完成收不了口、单纯是收口没做、分包单位做不了如弱电燃气管穿墙板管洞的封堵、施工合同的空白地带、交叉地带或扯皮地带等。

5、要注意融洽与各承包单位的关系

有些甲方常常与施工方的现场管理人员争吵，关系搞得紧张，而且还动不动威胁要找其他的施工单位来替代，殊不知这是很难实现的，而且很容易引起合同纠纷，最后两败俱伤。在工程管理中，一定要约束现场管理人员的嘴，不要胡说八道。即使是真要换施工方，也要神不知鬼不觉地进行。

6、制订消项收尾工作计划

制订收尾工作计划要注意在收尾工作与裂缝、渗漏等工作区别开来，即便是同时进行也要以完成工程内容优先。

收尾计划要采取消项计划的方式，按单元、按部位、按楼栋一项一项地规定完成时间，完成一项消除一项。

7、备有后备劳动力或施工队

由于房地产项目的设计变更多，承包单价低，施工方在最后关头总想用拖的方式与甲方谈判从而获取补偿。如果甲方不愿意让步或者施工方狮子大开口，这时就要有后备施工队顶上。从而确保工程按期竣工和交楼。

8、通过分项验收、内部验收、联合验收来促进收尾工程

比妨说通过提前电梯验收、消防验收、规范验收来鞭策施工方，也可以搞几次验收才通过专项验收来促进收尾工作。另组织公司内部、联合监理、甲方，甚至组织没有质量监督人员的监督下的四方验收。每次验收后要把没完成的工程内容和检查发现的问题列出来，并限定完成时间。

9、专人跟踪

将收尾工作计划任务进行分工，派专人盯着和督促。

10、即时做好工程资料和工程量确认。

工程资料在交楼前是必须完成的，工程量确认有利于提高和保证工人的工作积极性。

11作为项目监理方要积极做好项目收尾工作。

作为监理工作周期的最后一个重要过程，在完成业主委托的质量、安全、进度、投资等目标，同时建设单位具备组织工程竣工验收条件时，就正式进入项目收尾过程。项目收尾工作是一项不可或缺的工作，虽然项目收尾是工程竣工验时的最后部分，但并不意味着项 目收尾的各项活动就要拖延到此过程才开始进行。众所周知，成立的项目监理机构是临时性，但承担项目监理公司及项目管理经验成果对建设单位和公司荣誉的影响是长期的。作为项目的总监理工程师（以下简称总监），对项目收尾工作要引起足够的重视。

一、将监理服务工作坚持到底

随着工程主体结构封顶，装修工程接近尾声，监理机构需要的人员越来越少，但总监仍然要在人数减少的同时确保高效地完成项目。

公司人事部门应会同总监对项目监理机构进行弹性管理，在项目收尾时提前考虑项目监理机构人员的安置问题。为了监理工作的连续性，公司应尽量确保总监完成项目所有工作，或确保至少一名总监副手至始至终处于项目监理机构中。

二、收集整理项目信息资料

在项目收尾过程，由于监理机构的注意力集中在完成项目任务的喜悦和期待新项目的兴奋状态，对记录、完善项目信息，进行经验和教训的总结很容易被人忽视。

工程项目历史信息是帮助公司项目管理的重要参考资料。每个公司可能对信息文件存档的要求不同，国家监理规范和其他相关建筑规范对此也作了相应要求，项目监理机构应收集保留以下，但不仅限于以下的内容：

1）项目日记：包括监理日志和旁站监理记录； 2）项目计划：包括监理大纲、监理规划和监理细则； 3）来住函件； 4）项目会议记录； 5）项目进度控制文件； 6）项目质量控制文件； 7）项目安全控制文件； 8）项目投资控制文件； 9）合同文档； 10）其它信息；

项目总监应对以上信息资料输入和保存于计算机中形成电子文本。公司工程部应建立和维护公司整体的计算机信息系统，为需要时可便捷地检索查找，也为公司其他新开项目和人员培训提供依据。

三、合同完成情况的收尾

在项目即将完成阶段，总监应组织监理机构人员重温《监理委托合同》，查找是否有为业主服务的漏项，以免引起业主的不满。合同完成的效果应达到或超过业主的期望。项目总监应积极收回项目尾款。除非公司有特别要求和说明，收回项目尾款应是总监的责任。

四、项目竣工验收

根据国家现行监理规范规定，总监应组织建设、监理、设计、勘察、施工等单位时进行工程初验收，应参与和辅助建设单位项目负责人开展工程竣工验收工作。项目竣工验收工作至少包括以下四个方面的内容：

1）安排项目竣工验收会议的日程。

项目竣工验收会议是建设单位项目负责人组织，各参建单位项目负责人和政府相关部门负责人成立项目竣工验收委员会共同参加的会议，与会者一旦确定，就应安排会议的召开日期和时间。务必要为与会者留出充足的准备时间，让他们能够审阅相关资料。2）分发会议材料

在会议召开之前，总监应代表监理单位签发《质量评估报告》，编制《项目竣工验收方案》，并及早发至相关单位。3）召开项目竣工验收会议

在验收会议期间，验收委员会至少应完成以下工作。（1）审查工程质量控制资料是否完整；（2）审查各分部工程是否均已验收合格；

（3）审查各分部工程有关安全各功能的检测资料是否完整；（4）现场进行主要功能项目的抽检工作，应符合相关专业质量验收规范的规定；

（5）验收委员会应共同对工程观感质量进行评价。

会议结束时，验收人员应确定验收结论。项目竣工验收可能得到以下结果之一：

a.合格。工程质量达到设计和规范要求，建设单位同意接受工程。b.有条件接受。即主要安全和功能方面合格，但必须先完成验收委员会指定的纠正措施项目。c.拆价接受。即工程达不到预期的使用功能，但返工处理不现实或代价太高，甲乙双方可协调、降低使用功能拆价处理。

d.不接受。经过返修加固处理仍不能满足安全使用要求的工程，严禁验收，同时表明项目管理工作完全失败。4）会议记录

竣工验收会议记录是项目监理机构的职责，总监应指定专人负责。在验收会议结束时应完成记录，其中需包括重要的验收意见或行动建议，以及项目验收会议的结果，验收委员会成员如有不同于总体结论的意见应予以保留。对需重新组织验收的项目，应确定再次验收的日程安排。会议记录应发于与会者进行审阅各确定，签字后即时生效。

五、财务核算

总监应配合公司财务人员对本项目进行财务分析和核算，范围应仅限于本项目，公司总部的管理费用不应在此之内。分析项目使用成本，项目收款状况，并与公司其他项目进行对比与分析，找出缺陷和不足，总结项目成本控制经验。同时也为总监的业绩考核提供财务依据，财务核算应形成报告，并至包括以下信息： 1）目前项目财务状况；

2）财务偏差情况：主要与公司在项目启动前的财务计划进行对比； 3）解释与建议：解释发生财务偏差的原因，说明其合理程度，并为今后新的项目财务控制提出好的建议，完善公司相关制度； 4）分析项目利润额：评价项目利润水平是否达到或超过公司平均利润水平；

六、总结项目经验和教训

《监理工作总结报告》是对项目管理成功或失败的总结性文件，应向建设单位和监理公司提交。《监理工作总结报告》的基本内容： 1）工程概况；

2）监理组织机构、监理人员和投入的监理设施； 3）监理合同履行情况； 4）监理工作成效：

5）施工过程中出现的问题及其处理情况各建议； 6）工程照片（有必要时）；

第三篇：项目收尾管理

项目收尾管理

19.1项目收尾的内容

项目收尾管理是指对项目的最后一个阶段----收尾阶段进行妥善的管理，以顺利结束项目。项目启动阶段需要正规的文档和工作，项目收尾阶段也需要正式地将完成的成果进行移交并将相关的经验存档，收尾阶段一旦结束，就标志着整个项目的结束。

项目收尾的具体内容主要是项目验收、项目总结和项目评估审计。

19.2项目验收

项目的正式验收包括：验收项目产品、文档以及已经完成的交付结果。项目验收由验收小组依据合同、行业标准、合同双方认可的技术规范进行。

系统集成项目需要正式的验收测试工作以及正式的验收报告，通常系统集成项目的验收工作步骤包括： 1)系统测试 2)系统的试运行

3)系统的文档验收。系统集成项目应该提交的文档如下：

① 系统集成项目报告（包括用户手册、竣工图、配电图等）。② 信息系统说明手册 ③ 信息系统维护手册

④ 软硬件产品说明书、质量保证书等。4)项目的最终验收报告。

最终验收报告是确认项目工作结束的重要标志性工作。对于信息系统而言，最终验收标志着项目的结束和售后服务的开始。

19.3项目总结

项目总结属于项目收尾的管理收尾。管理收尾详细规定了项目团队成员与参加执行项目收尾的其他项目干系人的所有活动、他们之间的相互配合以及有关的角色和责任。管理收尾过程还包括收集项目记录、分析项目成败、收集应吸取的教训、以及将项目信息存档以供本组织将来使用等活动。项目总结的具体工作如下： 1)收集整理项目过程文档和经验教训。

2)对所有的文档进行归类、形成项目总结会议的讨论稿。3)项目总结。

19.4项目后评估和审计

项目结束后进行评估和审计

1、项目评估

项目后评估是对项目和项目的所有工作加以客观的评价。好的项目评估对未来项目的改进很重要。项目评估的内容如下： 1)盈利要求

2)客户满意度要求 3)后续项目指标要求 4)内部满意度要求

2、项目审计

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

3、项目总结评估

一般的项目总结以会议的形式进行，具体内容如下： 1)项目绩效 2)技术绩效 3)成本绩效 4)进度计划绩效 5)项目的沟通

6)识别问题和解决问题 7)意见和建议

19.5项目后评估和审计

通常情况下，系统集成项目不同于其他项目的特点在于后续工作的比较复杂，而且随着IT服务业的发展对信息系统不再是简单的交钥匙工程。越来越多的业主方要求承包方提供较为完备的后续工作支持和服务，而承包方将逐渐发现其中蕴含的商机，从而为后续的工作开展提供双赢的机会。一般来讲，不同信息系统对后续工作的要求是不同的。软件项目对后续工作的支持要求程度最高，尤其是客户化定制的软件更是如此。通常系统集成项目的后续工作要求是： 1)信息系统缺陷的修改 2)信息系统维护和技术支持

对于系统集成项目来说，经常会把一些合同拆成项目实施和技术服务两个部分。

承建方对项目的责任到什么时间为止？如何保证第三方的技术支持？如果双方未能就此问题达成一致，将很可能造成后续工作的矛盾。例如系统的免费维护期有无系统的升级和更新？升级和更新的成本有谁承担？就此问题承建方的服务部门应与业主事先协商（最好在合同中明确），给出双方都易于接受的方案。3)信息系统的新需求

收集业主对于信息系统的新的要求和建议，这些新的需求将带来新的项目机会。

19.6项目团队人员转移

项目结束后，项目团队解散。其人员面临新的任务，项目经理应事前主动了解项目成员的归属并感谢他们对项目的贡献，以便于将来的合作。

第四篇：信息系统项目管理师项目收尾常考问题及案例实例

首先要知道项目收尾的含义：项目收尾包括合同收尾和管理收尾

1、合同收尾是按照合同约定，项目组和业主一项项的核对，检查是否完成了合同所有的要求，是否可以把项目结束掉，也就是项目验收。

2、管理收尾是对于项目内部来说的，把做好的项目文档等归档，对外宣称项目已经结束，转入维护期，把相关的产品说明转到维护组，同时进行经验、教训总结。

项目收尾包含的主要工作：

1、核实项目范围，项目正式验收

2、梳理项目合同，处理品合同遗留问题，结款

3、进行项目移交，转移项目责任

4、整理项目记录，项目档案归档，完成项目文档收集整理工作，将所有的项目文件存档并建立索引目录

5、进行成果分析，总结经验、教训

6、释放项目资源，迎接新的工作

项目验收的主要工作：

1、承建方自检

2、系统试运行

3、技术培训

4、系统竣工

5、初验合格

6、项目终验

甘特图：也叫横道图或条形图，是一种能有效显示活动时间计划编制的一种方法，主要用于项目计划和项目进度安排。

甘特图的特点是简单、明了、直观，能较清楚地反映工作任务的开始和结束时间，能表达工作任务的活动时差和彼此间的逻辑关系。甘特图可用于WBS 的任何 层次，其时间单位可以从年到月甚至到日。但甘特图只能表明已有的静态关系，而且，对于错综复杂、相互制约的各项活动间的关系没有表示出来，同时也没有指出影响项目生命期的关键所在。这一点不利于合理的组织安排和指挥整个系统，更不利于对整个系统进行动态优化管理。

检查点：指在规定的时间间隔内对项目进行检查，比较实际与计划之间的差异，并根据差异进行调整。可将检查点看成一个固定的采样时点，而时间间隔根据项目周期长短不同而不同，频度过小就会失去意义，频度过大会增加管理成本。常见的间隔是每周一次。里程碑：完成阶段性工作的标志，不同类型的项目里程碑不同。

基线：指一个（或一组）配置项在项目生命周期的不同时间点上通过正式评审而进入正式受控的一种状态。基线其实是一些重要的里程碑，但相关交付物要通过正式评审，并作为后续工作的基准和出发点。基线一旦建立后，其变化需要受控制。

滚动波式计划：为了分解到底层的工作包，有些项目可交付物只需分解到下一层，而有些项目可交付物需要分解到多层。当工作被分解到更低的、更详细的层次时，有助于对这些工作的计划、管理和控制。然而，过度的分解反而有害。

详细的分解对于遥远的将来才能完成的交付物或子项目是不需要的，也是不可能的。一般地，项目管理团队应该等待交付物或子项目足够清晰时才制定详细的WBS.这种技术通常

被称为滚动波式计划。该方法的实质是将近期的工作计划得详细一些，远期的工作计划得相对粗一些。

案例实例

阅读以下说明，请回答问题1至问题3,将解答填入答题纸的对应栏内。

【说明】

在系统集成项目收尾的时候，项目经理小张和他的团队完成了以下工作：

工作一：系统测试。项目组准备了详尽的测试用例，会同业主共同进行系统测试。测试过程中为了节约时间，小张指派项目开发人员小李从测试用例中挑选了部分数据进行测试，保证系统正常运行。

工作二：试运行。项目组将业主的数据和设置加载到系统中进行正常操作，完成了试运行工作。

工作三：文档移交。小张准备了项目最终报告、项目介绍、说明手册、维护手册、较硬件说明书、质量保证书等文档资料发送给业主。

工作四：项目验收。经过业主验收后，小张派小李撰写了项目验收报告，并提请双方工作主管认可。

工作五：准备总结会。小张整理了项目过程文档以及项目组各技术人员的经验，并列出了项目执行过程中的若干优点。

工作六：召开总结会。小张召集全体参与项目的人员参加了总结会，并就相关内容进行了讨论，形成了总结报告。

【问题1】（5分）

请指出案例中的六项工作中那些工作存在问题并具体说明。

【问题2】（6分）

工作六中，项目组召开了总结会，那么总结会讨论的内容可以包含（）、（）、（）、（）、（）、（）。

【问题3】（4分）

项目总结会召开之前，核心技术人员小王产生了抵触心理，他认为更多时间应该放在技术研发上而不是浪费时间召开会议。并简要阐述项目经理小张应该如何从召开总结会意义的角度说服小王参加项目总结会。

第五篇：IT项目收尾管理经验谈

IT项目收尾管理经验谈

2013年12月20日 09:24 来源：中国项目管理资源网 作者： 字号

打印 纠错 分享 推荐 浏览量 267

所谓验收就是对整个软件开发、建设项目的结果的综合评价，是软件系统交付使用前对项目进行评估、认定和总结的过程，包括费用、质量、服务等多个方面，包括对整个系统的运行情况、业务流程重组的有效性、生产运作的效率等方面的一个评估，也是对IT项目范围的再确认。IT项目的实施，一般包括6个阶段，即项目的选型、培训、业务流程重组、基础数据整理、会议室试点、切换等，在系统切换后，紧接着的还有一项关键性的工作，就是项目的验收。

IT项目验收主要是通过对项目全面测试性检验，找出项目中可能存在的问题和不足，并进行最后的修正、完善，以使项目保质保量最终交付到用户单位每个使用人员手中。可以说，验收是IT项目最后关键的环节，它是对项目的实施质量和软件的可交付性起到“一锤定音”的作用，也关系到IT项目能否平滑顺利步入运营期、为企业创造效益，软件开发服务商能否实现收益标志之一。因此CIO必须高度重视，万莫轻视。

比如ERP项目，由于其软件的复杂性、规模性，CIO们可能更多地关注它多变的需求定义、选型、个性化解决方案，却轻视了项目的验收工作，而验收需要大量数据测试、自定义扩展、长时间运行等后才能明辨优劣、成效，但是由于供需双方受种种原因的影响急需“结账”，从而使项目验收从时间、内容、范围、数量、人员等投入均显不足，而且由于多数信息化项目的验收评估标准难以具体量化，常使验收常流于形式，最终使实施结果不佳。

为何不少IT项目成了“鸡肋工程”甚至变成“烂尾工程”?一个重要原因就是最后一个关--“验收”疏忽大意，没有把关好，前功尽弃，败走麦城。对此，作为企业信息官的CIO，负有重要责任。还有，一些用户单位CIO以为项目实施工作做好了，系统跑起来了，文档移交了，开发商确认了，还有什么必要大动干戈做验收？这些想法、做法，源于对验收的目的、流程、方法和意义缺乏认识，造成一个个延期工程、半生不熟项目或烂尾工程。

一、把握项目验收的重点内容

可以说，验收事关项目能否善始善终，悠关全局的成败，那么CIO如何做好项目验收？从哪里重点把握？结合理论与实际操作，一般而言，IT项目验收主要应包括验收准备、数据移植、系统测试、系统评估4个主要过程。

1、着手验收阶段的准备工作

当单位始要进入验收时，CIO应着手进行相应验收的准备工作--向软件开发商收取软件开发过程中各阶段性文档，包括需求分析说明书、概要设计说明书、详细设计说明书、数据库设计说明书、源程序代码、可供安装使用的系统安装程序、系统管理员手册、用户使用手册、测试计划、测试报告、用户报告、数据移植计划及报告、系统上线计划及报告、用户意见书、验收申请等；然后对这些各类约定的技术文档和合同中的相关内容进行自查，要彻底了解系统目前完成的情况如何，是否已完成了与开发商达成的各项书面约定以及口头约定，没有完成的，如果是书面约定，准备采取什么策略去进一步完成等。

当然，此时CIO做一个详细的验收计划是非常必要的，可以用来作为验收阶段的工作指导，并组织管理层领导、业务管理人员和信息技术专家成立项目验收委员会，负责对IT项目进行正式验收。

2、数据移植

如今不少企业都上了OA、CRM等系统，或淘汰老系统，在进行新系统(如ERP或PLM)建设并最终上线时，一般需要将旧系统的原始数据移植到新系统或调用企业原有的OA、CRM等系统内的数据时，则常需数据移植，此时CIO正好可籍此机会检验新系统的优劣、匹配性如何。这些应完成以下主要工作内容：

1)制订数据移植：除了要定义数据收集的格式、范围、进度外，还要考虑系统接口的影响，并建立数据移植完整性和准确性测试方法以及意外事件处理程序;

2)数据收集：项目实施常涉及到数据收集，应由数据收集小组根据数据收集格式，准确对数据进行收集，以确保数据提供人员了解和掌握对数据收集的各项规定和要求;

3)数据导入并核查结果：项目组成员将数据导入系统，并在导入后按照事先制定的数据移植完整性和准确性的测试方法，对系统中的数据做进一步的核查，确保导入数据的质量;

4)数据移植后要进行适当时间的试运行，检测、确认数据移植的真实性、准确性和完整性。

3、系统测试

系统测试是项目验收的关键环节，也是CIO最需花心思把关之处。以ERP软件为例，系统测试具体包括以下5大测试内容：安装测试、功能测试、界面测试、性能测试、文档测试等。而其中，功能测试是重点，必须高度重视。

下面结合ERP，重点阐述如何有效进行功能测试，其功能测试的用例设计，主要应注意以下几点：

1)测试项目的输入域要全面。要有合法数据的输入，也要有非法数据的输入，CIO可以此检验系统的抗干扰性如何;

2)要适时利用边界值进行测试。如“订单预排”中一般要求预排的数量大于0，那么测试数据可以分别为0，-1，1，100000(一个非常大的正数)，查看单据流转和控制情况，系统在执行MRP分解、工单下达、车间任务调度等操作是否正确;

3)CIO可不按照常规的顺序执行功能操作，查看系统计算的准确性，如仓库历史库存、当前库存、货位库存是否准确;

4)验证实体关系，实体间的关系有三种：一对一，一对多，多对多。如一个MPS对应多个MRP，一个MRP对应多个车间任务，CIO对此检验，看能否对应;

5)执行正常操作，观察输出结果的异常性。如CIO删除某条记录对排序的影响，或执行审批后，单据的状态是否改变，报表的打印输出效果如何;

6)划分等价类，提高测试效率。要划分等价类，选择有代表意义的少数用例进行测试，提高测试效率等等。

4、其它系统测试

除上述的系统测试外，CIO还有必要对系统的其他特性和需求加以测试，这些系统测试也很重要，主要有以下几种：

1)负载压力测试，主要包括并发性能测试、疲劳强度测试、大数据量测试和速度测试，一般采用自动化技术分别在客户端、服务器端和网络上进行测试;

2)恢复测试，通过模拟硬件故障或故意造成软件出错，检测系统对数据的破坏程度和可恢复的程度;

3)安全性测试。通过非法登陆、漏洞扫描、模拟攻击等方式检测系统的认证机制、加密机制、防病毒功能等安全防护策略的健壮性;

4)兼容性测试。通过硬件兼容性测试、软件兼容性测试和数据兼容性

测试来考察软件的跨平台、可移植的特性;

5)性能测试，性能测试主要是测试软件的运行速度和对资源的消耗。

5、评估整个系统运行效益

作为信息部门的一把手，聪明的CIO应在项目合同上写明系统试运行2-3月后再来验收、付款的规定，以争取主动。CIO的做法主要是录入1-3月的企业相关经营数据进行核查，目的是利用此段时间来判断系统上线运行后能给企业带来哪些积极变化和成效--看它有无促使企业在管理思想、管理模式、管理方法、管理机制、管理基础、业务流程、组织结构、规章制度、全员素质、企业竞争力、企业形象、科学决策和信息的集成与处理等方面发生一些明显的改进、提高和创新;企业是否运用ERP系统对整个供应链管理中的各相关环节和企业资源实行有效的规划和控制;通过财务模块分析，企业在客户关系管理、市场预测分析、加强财务管理、合理组织生产、资源优化配置、压缩生产周期、降低物料库存、减少资金占用、降低产品成本、提高产品质量、扩大市场销售和实行电子商务等方面有无产生相应的经济效益等。如果在这些方面，用户感觉良好，表明系统运行成功，那CIO就可放心正式验收、签单付款了。

二、项目验收的几大注意事项

CIO把握、核检了项目验收4个主要过程了，并不表示万事大吉，尚需对以下几大事项高度重视，加以解决，以保证项目和验收全面顺利完成。

1、依据行业标准制定验收规则。验收是目前或许是一个比较模糊的概念，业内一直都没有一个统一的标准，随意性大。而这种“验收的随意性”对于用户单位来说将是一个致命性的错误，产生此类问题的根源就在于CIO常不知道或根本就没有制定合理的验收标准，从而导致IT项目在验收过程中，主次颠倒，忽视了对关键业务流程的验收。因此，只有明确了相关系统项目的验收标准，才会做到有备而来，从而达到验收的目的。CIO一定要重新明确、制定每个阶段验收标准和项目总体验收标准，时刻维护验收的严谨性、权威性和准确性，必要时可请第三方咨询顾问机构来帮忙把脉把关。

2、把握验收的时间火候。一般而言，要根据软件模块的多少、系统涉及部门人员、投入费用的多少，CIO要在验收时间上进行更多考量、把控，别急于收尾验收。大型的ERP项目通常是边实施边验收，一步一步地向前推进，以便一边发现问题一边解决问题，但中小型的ERP项目最好是成功切换后，录入了一个月以上的数据，运行一个月时间，再来验收。毕竟一个月才是一个小的系统周期，如果小的周期都没有跑顺，就更别说一年这样的大周期了。如ERP系统能做到平稳运行两个月以上，能够准确导出各类月度报表的时候，系统应用和各项业务操作基本正常、顺畅，通常而言，可认为系统已达到的效果或者是达到了先前预定的目标，系统项目上线成功了，验收可算通过了。

3、建立有效的解决冲突机制。用户、开发商在实施、验收IT项目过程中难免会发生冲突，造成IT建设偏离轨道。关键是事先是否有明确的项目目标和项目要求，是否建立起有效的冲突解决机制。CIO主要是要明确今后双方责权利关系，可对将来可能发生重大事件或不可抗拒事件所引发可能的实施超期、费用超支、产品价格调整以及服务收费超标等事项、行为及其权责做出预测，并有效约定，从而使信息化项目从一开始就按预定的规道行驶，避免再发意外。因此CIO要快速查找以前问题所在，既然上次合约没有明确细节，也就意味着可以增加验收内容，明确细节和进度，从合同中挑出对方的问题，与对方补签合约，保证项目有效进行。建立解决冲突机制，是为了使验收更好地执行。