第19章项目收尾管理

19章工程收尾治理工程收尾阶段是收获工程成果的阶段，同时也是IT信息类工程简洁理解但较难操作的阶段之一。这个阶段一旦完毕，就标志着整个工程治理过程的最终完毕。如同工程启动阶段需要正式的文档和工作一样，工程收尾阶段也需要以某种正式的活动作为完毕标志：主要是完成工程交付成果的检验，由承建方将完成的成果交与用户方，业主〔用户〕确认成果符合合同规定。工程收尾工作的另一重要内容是从工程中获得相关阅历，以便指导和改善将来工程的运作和实施。工程收尾的内容工程收尾的具体内容主要是工程验收、工程总结和工程评估审计。工程验收工程的正式验收包括验收工程产品、文档及已经完成的交付成果。验收需要正式的验收报告。对于系统集成工程，一般来讲，需要正式的验收测试工作。验收浸4试工作可以由业主和承建单位共同进展，也可以由第三方公司进展，但无论哪种方式都需要双方认可的正式文档为依据进展验收测试。假设验收测试未获通过，则应马上查找缘由，一般会转向变更环节进展修改和补救。假设工程验收测试正式通过，则标志着工程验收的完成。通常，系统集成工程的验收工作包括如下步骤。系统测试系统测试是对信息系统进展全面酌测试，依照双方合同商定的系统环境，以确保系统的功能和技术设计满足业主的需求，井能正常运行。系统测试阶段应包括编制测试用倒，建立测试环境，逐条进展测试。系统的试运行信息系统在通过双方的测试以后，可以开头试运行。试运行包括数据迁移和日常维护。业主可将自己的数据和设置加载到信息系统上进展正常操作，一般来讲，在试运行期间，双方可以确定具体的内容并进展适当的交接培训。对于在试运行期间发生的问题，可以看作工程突发大事加以处理，如需要增加必要的工作，可按工程变更过程进展处理；也可咀另立的工程加以处理。系统的文档验收在经过系统测试后，系统的文档应当逐步移交给业主方。业主方也可依据合同或者工程工作说明书的规定，对所交付的文档加以检查和评价；对不清楚的地方可以提出修改要求。在最终交付系统前，系统的全部文档都应当验收合格并经双方签字认可。对于系统集成工程，所涉及的文档应当包括如下局部。工程的最终验收报告在系统经过试运行以后的商定时间，双方可以进展工程的最终验收工作。通常状况下，大型工程都分为试运行和最终验收两个步骤。对于一般工程而言，可以将系统测试和最终验收合并进展，但需要对最终验收的过程加以确认。最终验收报告就是业主方认可承建方的工程工作的最主要文件之一，这是确认工程工作完毕的重要标志性工作。对于信息系统而言，最终验收标志着工程的完毕和售后效劳的开头。最终验收的工作包括双方对系统测试文件的认可和承受、双方对系统试运行期间的工作状况的认可和承受、双方对系统文档的认可和承受、双方对完毕工程工作的认可和承受。工程最终验收合格后，应当由双有的工程组撰写验收报告提请双方工作主管认可。这标志着工程组具体工作的完毕和工程治理收尾的开头。工程总结工程总结属于工程收尾的治理收尾。而治理收尾有时又被称为行政收尾，就是检查工程团队成员及相关干系人是否按规定履行了全部责任。实施行政结尾过程还包括收集工程记录、分析工程成败、收集应吸取的教训，以及将工程信息存档供本组织将来使用等活动统一为一个整体。工程总结的意义工程总结的主要意义如下。(l)了解工程全过程的工作状况及相关的团队或成员的绩效状况。(2)了解消灭的问题并进展改进措施总结。了解工程全过程中消灭的值得吸取的阅历并进展总结。对总结后的文档进展争论，通过后即存入公司的学问库，从而纳入企业的过程资产。工程总结会的预备工作(】)收集整理工程过程文档和阅历教训。这需要全体工程人员共同进展，而非工程经理一人的工作。工程经理可将此项工作列入工程的收尾工作中，作为参与工程人员和团队的必要工作。工程经理还可以依据工程的实际状况对工程过程文档进展收集，对全部的文档进展归类和整理，给出具体的文档模板并加以指导和要求。(2)阅历教训的收集和形成工程总结会议的争论稿。在此初始争论稿中，工程经理有必要列出工程执行过程中的假设干主要优点和假设干主要缺点，以有利于争论的时候加以重点呈现。工程总结会工程总结会需要全体参与工程的成员都参与，并由全体争论形成文件。工程总结会议所形成的文件肯定要通过全部人确实认，任何有违此项原则的文件都不能作为工程总结会议的结果。工程总结会议还应对工程进展自我评价，有利于后面的工程评估和审计的工作开展。一般的工程总结会应争论如下内容。(I)工程绩效：包括工程的完成状况、具体的工程打算完成率、工程目标的完成状况等，作为全体参与工程成员的麸同成绩。技术绩效：最终的工作范围与工程初期的工作范围的比较结果是什么，工作范围上有什么变更，工程的相关变更是否台理，处理是否有效，变更是否对工程等质量、进度和本钱有重大影响，工程的各项工作是否符合估量的质量标准，是否到达客户满足。本钱绩效：最终的工程本钱与原始的工程预算费用，包括工程范围的有关变更增加的预算是否存在大的差距，工程盈利状况如何。这牵扯到工程组成员的绩效和奖金的安排。进度打算绩效：最终的工程进度与原始的工程进度打算比较结果是什么，进度为何提前或者延后，是什么缘由造成这样的影响。工程的沟通：是否建立了完善并有效利用的沟通体系；是否让客户参与过工程决策和执行的工作：是否要求让客户定期检查工程的状况：与客户是否有定期的沟通和阶段总结会议，是否准时通知客户潜在的问题，并邀请客户参与问题的解决等；工程沟通打算完成状况如何：工程内部会议记录资料是否完备等。识别问题和解决问题：工程中发生的问题是否解决，问题的缘由是否可以避开，如何改进工程的治理和执行等。意见和建议：工程成员对工程治理本身和工程执行打算是否有合理化建议和意见，这些建议和意见是否得到大多数参与工程成员的认可，是否能在将来工程中予以改进。工程评估和审计这里所说的工程评估和审计属于工程事后评估和审计，以有别于工程初始阶段进展的工程评估工作。工程评估工程评估的意义是将工程的全部工作加以客观的评价，从而对工程全体成员的成果形成绩效结论。好的工程评估会引导后续工程的开展，并对工程过程的改进起到很重要的作用。工程评估的依据：不同类型的工程，评估的要求不同，同一工程的评估要求每个公司也不一样。不同的主体往往对一样的工程有着不同的要求。多数要求包括以下几个方面：(l)盈利要求。(2)客户满足度要求。(3)后续工程指标要求。(4)内部满足度要求。依据不同的权重将这几项指标进展加权平均，从而得出工程的具体分值。盈利要求：通常状况下，公司对工程都有盈利要求。而在工程开头时，经过测算大都能够估算出盈利的指标。但由于存在很多不确定性，工程收尾的时候，盈利与预期之间肯定存在不小的差距，而工程治理的水平就是这一差距的缘由。好的工程治理和团队绩效会加大盈利的水平，而差的工程治理和团队绩效将会减低盈利水平，甚至改盈利为亏损。固然，还有一些外在的因素会影响工程的盈利水平，包括信息系统工程的需求不明碲、信息系统业主的缘由、信息系统第三方或者工程干系人的缘由等。工程评估的时候也需要考虑这些因素。客户满足度要求：通常状况下，客户满足度会有比较大的差异，由于这项指标属于主观性比较强的指标。公司如何评价客户满足度，而不对不同的工程产生很多不公平的结果，需要公司高管有较为慎重的态度和细致的工作。客户满足度的调查需要工程组以外的成员进展，通常承受直接访问调查的方式。就是有公司的调查主管直接访问客户方的人员〔最好是多个客户方人员较为准确的评价。除了固定的客户满足度调查外，企业还可以引入行为描述类指标，对客户满足度指标进展补充修正。但收集客户满足度并不简洁，全面调查工作量太大，常常操作的可能性不强，客户也不情愿承受这样频繁的调查。企业可以针对每一次工程活动的特点，设立具体的行为类问题。例如，客户对工程的协作程度、工程成员与客户的生疏程度、客户对工程的问题与答复状况等。这些指标或许太具体化和共性化，但能够激发人们主动提高客户满足度的意识，以及对客户关系的维护。后续工程指标要求：承建方一般期望通过本次工程的合作为双方的长期合作打下根底，所以大都关注该工程是否能带来其他的后续工程。内部满足度：通常状况下，工程收尾以后，需要对工程的内部成员加以调查，确认工程在实施过程中的内部满足度，作为工程评价的指标之一。工程审计工程的审计应由工程治理部门与财务部门共同进展，相关的审计工程应在工程本钱治理中列出。在工程收尾的时候，对已经列出的支出和收入进展财务审计，对不合理的支出和收入加以分析，为改进工程的治理效劳。对信息系统的后续工作的支持通常状况下，系统集成工程不同于其他工程的特点在于其后续的工作比较简单，而且随着IT效劳业的进展对信息系统不再是简洁的交钥匙工程。越来越多的业主方要求承包方供给较为完备的后续工作支持和效劳，而承包方将渐渐觉察其中蕴吉的商机，从而为后续的工作开展供给双赢的时机。一般来讲，不同信息系统对后续工作的要求是不同的。软件工程对后续工作的支持要求程度最高，尤其是客户化定制的软件更是如此。软件工程的后续工作bog的修改bugbug已经在测试和验牧阶段觉察，对于这些bug在系统移交的时候已经处理完毕。而对于移交以后的系统，假设消灭bug将承受双方商定的方式进展处理。例如在保修期内，大多数是免费处理的，但在倮修期外假设发生问题，双方还需要就处理方式及相关费用做出商定。软件升级每一个应用软件都有自己的生命周期，假设双方未能就软件的生命周期达成全都，将很可能造成软件后续工作的冲突。例如甲方在用的版本早已经升级，这时假设还需要连续的技术支持，乙方将很难供给准时的反响。因此，在工程收尾阶段再次进展磋商是很有必要的。通常状况下软件会有比较固定的升级周期，例如每年一次或者每两年一次。但不肯定业主方每次都要求升级，由于升级或者更换的系统往往会给业主方造成肯定的经济本钱或者人力本钱。因此在工程完毕后，由承建方的效劳部门和业主协商给出双方都易于承受的升级方案。后续技术支持软件工程的技术支持工作是后续工作的主要内容，对于技术支持工作的内容应当在合同中予以规定。由于软件工程的简单性和特别性，合同本身不仅仅含有工程期间的工作，也包含有工程完成后效劳期间的工作内容。系统集成工程的后续工作信息系统日常维护工作一般来讲，系统集成工程的日常维护工作是比较简单的。对于承建方效劳部门来讲，系统集成工程的售后效劳工作牵扯到很多不同的供货商和设备厂商。而在工程后续阶段，很难保证全部的设备供给商还能够赐予充分的支持和合作。因此，系统集成商〔承建方〕应当在工程收尾阶段认真考虑如何保证第三方的技术支持。固然，假设在前期供货合同中清楚地说明白这一要求，工程收尾阶段只需要确认即可。硬件产品的更很多时候，硬件产品不同于软件产品的更和换代。在大多数信息系统正常运行后，3～5年内一般不会更换主要的硬件产品。对于一些必要的更，可由双方的维护人员协商解决。信息系统的需求信息系统的后续工作之一是收集业主对于信息系统的要求和建议，这些的需求将构成系统集成企业的信息系统产品的研发需求。CRM系统严密协作，有利于承建方更好地为客户效劳。工程团队人员转移工程完毕后，工程囝队的人员面临的任务，这时工程团队随之消亡。有阅历的工程经理将会主动了解工程成员的归属，并发送亲笔的感谢信，以便于将来的合作。工程团队人员的转移严格地说，只有在工程真正完毕后，团队成员才能正式脱离工程。但是在实际操作中，团队的局部成员可能由于一些缘由中途离开工程团队，或者完成了自己的任务而转到其他的工程团队。无论团队成员是中途转移还是在工程完毕时转移，工程经理都应当经过必要的程序对成员的转移加以治理和安排。一般的工程人员的转移流程如下。工程团队成员的治理打算，也就是工程人力资源治理打算中描述所说的人员转移条件已经触发。工程团队成员所担当的任务已完成，提交了经过确认的可交付物并已完成工作交接。工程经理与工程团队成员确认该成员的工作连接已经告一段落或者已经完成。(4)工程经理签发项刚团趴成员转移确认文件。(5)工程经理签发工程团队成员的绩效考核文件。+(6)工程经理通知全部相关的干系人。(7)假设是工程收尾全体工程成员完毕工程工作，应召开工程总结表彰大会，确定工程的成绩、团队成员的业绩，同时总结工程的阅历教训。工程转移人员的业绩评定工程经理要对工程转移人员在工程中的业绩进展评定，主要考虑以下两个方面。考评的多面性。工程团队中的人员往往是以工程团队的形式台作完成任务，而工程团队一般承受矩阵式组织构造，具有工程组织与业务部门的双重治理系统。工程经理应制定对应的考核标准，保持与成员所在职能部门的联系，不仅对工程工作进展评价，还要向所属职能部门反映该成员在专业技能方面的表现。考评的综合性。考虑到工程人员的工作具有团队性和制造性的特点，在考评内容上应由单纯考评“结果”转向兼顾“结果、行为和个体特质”多个方面，综合运用结果类和行为类指标。增加其他的团队成员和工程干系