it项目收尾管理

it项目收尾管理（精选8篇）

it项目收尾管理 第1篇

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要快速查找以前问题所在，既然上次合约没有明确细节，也就意味着可以增加验收内容，明确细节和进度，从合同中挑出对方的问题，与对方补签合约，保证项目有效进行。建立解决冲突机制，是为了使验收更好地执行。

it项目收尾管理 第2篇

一、项目收尾的内容

内容：

1、完成项目交付成果的检验，由承建方将完成的成果交与用户方，业主（用户）确认成果符合合同规定；

2、从项目中获得相关经验，指导和改善未来项目的运作和实施。主要内容是：项目验收

项目总结和项目评估审计。

1、项目验收——包括验收项目产品、文档及已经完成的交付成果。验收需要正式的验收报告，验收工作包括以下步骤：（1）系统测试：包括编制测试用例、建立测试环境、逐条进行测试；（2）系统的试运行：包括数据迁移和日常维护。还可以进行交接培训，这期间发生的问题，既可看作项目变更过程处理，也可看作另立新的项目处。

（3）系统的文档验收：移交给业主，在最终交付系统前，系统的所有文档都应当验收合同并经双方验收认可。所涉及的文档应包括：A.系统集成项目介绍；B.系统集成项目最终报告；C.信息系统说明手册；D.信息系统维护手册；E.软硬件产品说明书、质量保证书等。（4）项目的最终验收报告，标志着项目组具体工作的结束和项目管理收尾的开始，以及项目的结束和售后服务的开始。大型项目分为试运行和最终验收两个阶段。一般项目而言，可以将系统测试和最终验收合并进行，但需要对最终验收的过程加以确认。

2、项目总结——属于项目收尾的管理收尾（又称为行政收尾）。（1）项目总结的意义（了解）；（2）项目总结会的准备工作：A.收集整理项目过程文档和经验教训；B.经验教训的收集和形成项目总结会议的讨论稿。（3）项目总结会。讨论内容如下：A.项目绩效；B.技术绩效；C.成本绩效；D.进度计划绩效；E.项目的沟通；F.识别问题和解决问题；G.意见和建议。其中，B.C.D项是将最终的结论与原始的计划相对比。

3、项目评估审计——属于项目事后评估和审计。（1）项目评估，具体要求是：A.盈利要求；B.客户满意度要求；

C.后续项目指标要求；D.内部满意度要求。（2）项目审计，由项目管理部门与财务部门共同进行，对已经列出的支出和收入进行财务审计，对不合理的支出和收入加以分析。

二、对信息系统的后续支持工作

后续的工作比较复杂。软件项目对后续工作的支持要求程度最高，尤其是客户定制的软件更是如此。

1、软件项目的后续工作——（1）软件bug的修改；（2）软件升级，在项目结束后，由承建方的服务部门和业主协商给出双方都易于接受的升级方案；（3）后续技术支持（后续工作的主要内容）。

2、系统集成项目的后续工作——（1）信息系统日常维护工作，系统集成商（承建方）应该在项目收尾阶段认真考虑如何保证第三方的技术支持；（2）硬件产品的更新；（3）信息系统的新需求（收集业主对于信息系统新的要求和建议）。

三、项目团队人员转移

1、项目团队人员的转移；

2、项目转移人员的业绩评定——考评要多面性和综合性；

it项目收尾管理 第3篇

一、阶段收尾管理

软件项目结束的状态:

1. 正常结束。

2.提前结束。3.延期结束。4.暂停。5.取消 (因变更或不可完成) 。软件开发是一项复杂的系统工程, 牵涉到各方面的因素, 在实际工作中, 经常会出现各种各样的问题, 甚至面临失败。而如何总结、分析失败的原因, 得出有益的教训, 这对一个公司来说, 则是今后项目中取得成功的关键。

以前会听说过这样的项目:客户验收后, 项目活动就随之收场, 项目资料没有认真归纳总结, 不是束之高阁就是缺失不全。但是当新项目启动时, 面对新的项目问题, 项目组成员才发现:其实这类问题以前也遇到过, 但是却无法找到相应的解决方案资料, 只好再投入人力、时间甚至金钱来重新经历一遍!为什么相同的问题会重复出现?究其根源, 是因为缺少项目总结, 也就是说没有做好项目收尾工作。那么是不是我们只能等到项目结束或收尾时才能开始进行项目总结、文档保存的工作呢?当然不是。在软件项目管理的各个阶段, 我们都可以做收尾管理工作, 也就是阶段收尾管理工作。

二、阶段收尾管理的重要性

在实际软件项目管理中, 阶段性的收尾管理过程和工作往往不被大家重视, 其实阶段性的收尾管理工作也是非常重要的。阶段收尾管理工作的重要性主要体现在如下几个方面:

1. 进度管理中的里程碑。每个项目都是由若干个相对独立的

任务链组成的, 软件项目也是如此。只有在任何一条任务链都已经优化的基础上, 才可能进行系统的全面的优化, 因此, 保证每条任务链的效率是整个项目进度完成的前提和基础, 只要能保证里程碑事件的按时完成, 整个项目的进度也就有了保障。那么我们在里程碑点都来做些什么呢?

在计划好的阶段管理工作中, 收集项目的最新信息和数据, 并将这些数据与项目计划进行比较, 来判定项目的阶段效率, 进度是提前了还是落后了?成本是在控制中还是超支了?质量是否符合要求?客户对阶段工作结果满意么?及时总结经验与教训, 同时及时发现项目存在的或潜在的问题, 以便近早采取纠正措施, 这就是阶段管理工作中的收尾管理, 所以说阶段收尾管理是进度中的里程碑, 是整个项目进度优化的前提和基础。

2. 沟通管理中的契机。

沟通是保持项目顺利进行的润滑剂。与传统项目相比, 软件项目具有较高的技术含量和较大的风险。参与软件项目建设的用户并不都是软件开发专家, 他们具有丰富的业务经验, 但是很少能了解软件开发的技术, 随着项目工作进程的深入, 就会有许多新的问题出现, 与客户的及时有效沟通更显得尤为重要。软件项目是客户和用户共同面对的项目, 只有双方的积极参与才能促进项目的成功, 而只有进行有效的项目沟通管理才能确保用户的积极参与。一个阶段的项目工作完成后, 与客户一起就前一段时间的工作进行总结和检查是十分必要的。一方面可以及时了解客户对项目工作的满意程度, 及时统计、分析客户对项目的意见, 为下一阶段工作的顺利进行提供了保障。另一方面有些因工作繁忙未能及时签署的文件, 也尽快找客户给予签字确认。当双方出现纠纷时, 只有双方签字的文字记录才是最有用、最有说服力的证据。

3. 收尾管理的基础。

一个项目阶段的工作刚完成时, 项目组成员都保留着最新的阶段记录, 如阶段文档或最新的代码版本, 这个时候收集起来是非常容易的。时间久了, 随着人员的变动或者项目的需求变更, 有些项目成员可能离开了项目组, 那时再去收集他们保存的文档资料就非常困难了, 甚至有些记录永远也找不到了。好多大的软件开发项目跨几年的时间, 项目经理可能已经换了几任, 客户的项目主管也换了几位, 最后项目收尾管理时的文档收集、总结的工作, 就是在阶段收尾管理的基础上来确保每个阶段的文档、资料都能按时完整地保存、归档。只有阶段管理收尾提供的数据信息越真实、越准确, 才能保证在项目最终收尾时客观评定项目的绩效, 总结的经验教训和文档资料才有真正借鉴的价值。总而言之, 作为一个好的项目经理, 一定要重视进度中的里程碑事件, 抓住与客户沟通的契机, 做好项目阶段工作的总结收尾工作。如何做好这些工作呢?也就是要做好项目阶段管理收尾工作。阶段收尾管理工作是保证项目成功的重要管理手段, 它和项目的其他工作一样, 应该纳入项目计划并按计划落实。

参考文献

it项目收尾管理 第4篇

中小型的IT项目如OA、CRM等,其成功率也不足55%,客户满意率不到30%,成了“食之无味,弃之可惜”的鸡肋工程。

造成这种IT项目成了“鸡肋工程”甚至变成“烂尾工程”的一个重要原因,就是对项目的最后一个关——“验收”时的疏忽大意,没有把好关,致使前功尽弃,败走麦城。对此,作为企业信息官的CIO,负有重要责任。

众所周知,IT项目的实施,一般包括6个阶段,即项目的选型、培训、业务流程重组、基础数据整理、会议室试点、系统切换等。在系统切换后,参与项目实施的人员和CIO常都会松下一口气,以为大功告成,高枕无忧。但此时的CIO往往没有料到,紧接着的还有一项关键性的工作,就是项目的验收。

所谓验收就是对整个软件开发、建设项目的结果的综合评价,是软件系统交付使用前对项目进行评估、认定和总结的过程,包括费用、质量、服务等多个方面,以及对整个系统的运行情况、业务流程重组的有效性、生产运作的效率等方面的一个评估,也是对IT项目范围的再确认。IT项目验收主要是通过对项目全面测试性检验,找出项目中可能存在的问题和不足,并进行最后的修正、完善,以使项目保质保量最终交付到用户单位每个使用人员手中。

可以说,验收是IT项目最后关键的环节,它是对项目的实施质量和软件的可交付性起到“一锤定音”的作用,也关系到IT项目能否平滑顺利步入运营期、为企业创造效益,软件开发服务商能否实现收益标志之一。因此,CIO必须高度重视,万莫轻视。

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

把握项目验收的重点内容

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

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

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

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

2、数据移植

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

这些应完成以下主要工作内容:

1)制订数据移植:除了要定义数据收集的格式、范围、进度外,还要考虑系统接口的影响,并建立数据移植完整性和准确性测试方法以及意外事件处理程序;2)数据收集:项目实施常涉及到数据收集,应由数据收集小组根据数据收集格式,准确对数据进行收集,以确保数据提供人员了解和掌握对数据收集的各项规定和要求;4)数据导入并核查结果:项目组成员将数据导入系统,并在导入后按照事先制定的数据移植完整性和准确性的测试方法,对系统中的数据做进一步的核查,确保导入数据的质量;5)数据移植后要进行适当时间的试运行,检测、确认数据移植的真实性、准确性和完整性。

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

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

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

信息化项目验收看似简单容易,实际上是一项非常复杂重大、事关全局的工作,必须引起企业“一把手”、CIO和项目组成员的高度重视,积极管理、应对,千万不能虎头蛇尾、敷衍了事,最后马失前蹄、败走麦城。

如何抓好收尾工程项目管理 第5篇

经营管理部

颜良文

在项目管理过程中，管理层往往忽视项目的收尾阶段管理，认为剩余的工程量不大，对项目的施工组织生产不紧凑，人员管理松散，施工组织设计和施工方案对剩余的资源利用不合理，造成项目经营效益的流失。收尾阶段的项目管理作为项目管理的一个重要组成部分，对项目的“成本控制”和“二次经营”效果起决定性作用。收尾阶段的项目管理是项目成功的重要管理手段，它和项目其他工作和任务一样均应纳入项目计划并按照计划落实，现结合自己的工作体会及施工项目的现状，对有关收尾项目的管理浅谈一下自己的看法。

一、对剩余工程进行梳理，合理利用既有资源

在项目收尾过程中，由于项目管理人员更换频繁，而且遗留工作大多是零碎、分散、工程量不多的工程项目，往往不被重视，管理层对剩余工程量没有整体认识，缺乏总体管理思路，容易出现发现一项就施工一项的现象，造成人员窝工、机械设备闲置、材料浪费、劳务队伍反复进退场等，引起项目经济效益的流失。对于收尾阶段，项目管理人员要对本项目的施工图纸、施工过程中出现的变更设计、项目既有的人材机资源、已完工程量、未完工程量等进行统一梳理，编制收尾阶段的实施性施工组织设计。施工组织设计的编制要充分考虑项目的既有劳动力资源、机械设备的配置，剩余材料等因素，减少劳务队伍的进场次数，充分理利用项目既有的材料和机械设备，同时考虑业主对完工日期的总体要求。要把施工组织设计的内容层层落实，全面交底，组织相关人员定期和不定期地对施工任务的完成情况进行检查，建立工程项目动态管理台帐，防止施工过程中出现遗漏。

二、加强人员管理，合理安排现场管理人员

在项目收尾阶段，一方面部分职工工作任务已经完成需要调整工作岗位；另一方面项目管理者认为工程已经接近收尾，对员工疏于管理，对员工的工作安排不明确，甚至部分员工无具体工作任务。这样容易造成职工责权不明确，人浮于事，此时下发的工作任务在员工之间相互推诿，甚至无人执行，对项目的整个施工进度、竣工资料的收集整理等都有一定程度的影响。要加强项目收尾阶段的人员管理，合理安排现场管理人员，做到责权利明确，充分调动员工的积极性。对于调出人员，特别是一些主要人员，要进行详细的工作交接。根据现场施工、经营工作及竣工验收需要，项目管理者要对收尾阶段的人员需求做统一规划，提前布置，将需裁减人员及时移交公司人力资源部进行统一协调，防止出现人浮于事，管理人员偏多、项目间接费偏高等现象。同时要加强劳动纪律建设，制定各项工作计划，对员工进行阶段性考核。对于关键岗位人员，特别是二次经营和主要技术负责人，必须保证人员的稳定，确保工作的连续性。

三、加强材料管理，防止经济效益的流失

工程项目在项目收尾阶段，材料管理部门要对剩余材料进行详细盘点，根据工程部门提供的剩余工程量编制进料计划，做到工完料尽，减少材料的库存和浪费。施工收尾阶段施工方案的确定，要尽量考虑利用项目既有剩余材料，对剩余材料做到物尽其用。施工项目的特点是点多面广，材料分布分散，而后期项目管理人员偏少，材料容易发生丢失，因此对现场材料要及时收集，统一入库，并建立入库登记手续，防止丢失。对于废旧物资的处理要上报公司，实行公开招标制度，防止暗箱操作，在数量和单价上严格控制。

四、加强竣工资料的收集整理，缩短收尾时间

竣工资料的收集整理是项目收尾阶段一项主要的工作内容。由于在项目实施过程中项目管理层重点放在施工进度、安全、质量等方面，对资料的收集整理不重视；业主在实施过程中对资料无统一要求而在交工验收时提出这样那样的要求；在收尾阶段人员调整时没有进行工作交接，在收尾阶段个别资料容易丢失；在收尾阶段员工管理比较松散，职工工作主动性不强等几个方面原因造成项目收尾阶段竣工资料的收集整理工作难度大，时间较长。因此在项目的收尾阶段一定要重视竣工资料的收集整理工作，缩短项目收尾时间，减少项目费用。在项目的收尾阶段，要多跟业主、档案局等相关单位沟通，明确竣工资料的具体要求。根据竣工资料的要求，建立项目竣工文件资料清单，结合本项目的特点明确每个阶段所需要的资料、归谁提供、什么时候提供，明确文档格式和具体要求，并告知项目的相关人员。在进行人员调转时，要求项目相关人员根据资料清单要求进行资料的移交，并做好相关记录工作，明确责任人。对于竣工文件的资料收集整理，要明确阶段性目标，制定相关的奖惩措施，加强员工责任心建设。

五、加强结算工作管理，确保企业经济效益

要重视工程结算，一是要重视与业主的结算，加强与业主的沟通，要有时效性。前期主要是“干”，关注施工质量、安全、工期、资金的回收、资料的收集及与业主的协作关系等；后期主要是“算”，要整理好竣工资料，检查资料是否齐全，是否有漏洞，完善变更索赔资料，签字手续要完备，根据整个项目的预算情况及实际验工计价、成本费用开支情况进行对比分析，找出增加收入的切入点和关键点，为最后工程结算做好充分准备，做好工程项目的二次经营，只有算好了才会取得较好的效益。

二是要重视与劳务队的结算，理清与劳务队往来，把握好资金的支付，绝不能超支，扣缴一定比例的质保金，使其保证工程项目的最终验收。稳定劳务队伍，按程序办事，避免出现起诉、上访事件的发生，以防给公司带来不利影响。

六、加强应收帐款的管理

工程竣工后，要及时进行决算，以明确债权债务关系，项目部会同公司落实专人与业主加强联系，紧盯不放，力争尽快回收资金。对一些不能在短期内清偿债务的甲方，通过协商签定还款计划，明确还款时间、制定违约责任，以增强对债务单位的约束力；对一些收回资金可能性较小的应收帐款，则可采取让利清收等办法，以减轻成本损失。

it项目收尾管理 第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分）

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

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）监理工作成效：

IT项目风险及其管理 第8篇

一、IT项目风险管理的相关概念

从广义上讲, 如果项目没有实现使用者或系统所有者最初的预期或目标时, 那项目可以说是失败的。这样的解释显然过于简单, 因为预期和目标在何时以及何种程度上完成是很难判断的。但一般意义上, 项目的成功与否我们可以用时间、预算和规格来衡量。通过这些标准, 彼姆 (Beam, 1994) 说只有2%的IT项目是成功的, 因为很多成功的项目延期或严重超出了预算。一旦项目实施失败, 必然会造成巨大损失, 甚至会导致公司业务的混乱。而导致项目实施失败的因素, 常常被人们说成是“风险”。因此沃德 (1997) 把项目风险定义为“项目绩效水平中隐藏着的严重的不确定性”。然而, 由于风险往往和巨额的利润联系在一起。IT项目开发中的风险可以定义为:由于在生产过程中遇到问题而使系统不能实现计划和预期收益率的机率 (雷曼尹, 2000) 。显然, 风险是和未来事件联系在一起的。

因此, 要想使IT项目成功, 必须进行风险管理。通行的穆非 (Murphy) 法则认为, 如果项目不是完全根据风险问题进行管理的话, 他们可能会遇到问题, 并且会无法挽救或者超过预算, 甚至导致全盘失败;麦克高迪 (Mc Gaughty, 1994) 干脆就把卓有成效的风险管理看成是一定范围内的科学和艺术。然而风险管理也不是独立的事情, 它应该作为项目管理的一个部分, 而且也不仅仅是存在于项目实施的早期。从理论上讲, 虽然IT项目风险管理开始于软件开发的生命周期 (SDLC) 的可行性研究阶段, 但实际上风险管理应该贯穿于项目的始终, 并需要持续的关注和评估。实施项目风险管理的直接益处就在于防范于未然, 及时识别风险并采取降低风险的措施, 从而减小不确定性和偏差, 把项目引向成功。开普斯 (Keepers) 国际银行运作零售银行 (Retai Banking) 就是在项目开发过程中成功应用风险管理的典型案例。

二、IT项目开发中的主要风险

我们知道, 风险有可能会随着时间慢慢消失, 但也有可能像“滚雪球”一样不断累积, 直到最后不可收拾。而且由于风险定义的差异性, 导致风险的种类也千差万别, 从细节上可以列举出无数的风险。但这种列举往往会冲淡人们对某些关键风险的关注程度。因此, 本文只关注IT项目中三类主要的风险:业务风险、开发风险、技术风险, 而且这三种风险在开发过程中在数量上是不平衡的。

1. 业务风险

业务风险是普遍存在的, 包括业务理解不当、开发过程中辅助项目的购买、不能适应业务需求的变化。很多项目运行出错就是因为没有正确地理解业务问题, 因此开发项目面临的最大风险就是项目主管人员对主要业务问题理解不完全或不充分。另外如果项目开发过程中需要企业本身购买相应的辅助设备或项目, 虽然这些东西与业务利益无关, 但对IT项目的开发或者实施是非常重要的。一旦缺少, 也必将带来严重的后果。业务风险还表现在项目无法紧跟业务的变化。因为业务变化就有可能改变最初的项目需求分析乃至项目规划。特别对于一些特殊的行业如金融而言, 金融创新不断, 业务变化频繁。这种变化会使得IT项目变得越来越庞大, 如果开发人员不能适应这种变化, 将会导致IT项目的失败。

2. 开发风险

开发风险可能出现在评估或计划的不足、开发过程中人员的频繁流动、开发工具的使用不当等方面。尽管这些风险发生时, 并不必然导致项目的全盘失败, 但能引起严重的延迟和极大的成本超支。首先, 项目的评估一直是个问题, 因为在做评估的过程中所需的东西大多是不现实的。在IT项目的可行性研究阶段, 最初执行的工作如分析、设计或规格, 可能是不够的或者是不正确的。再就是项目开发过程中, 或者是开发人员, 或者是客户的业务人员, 都有可能改变其职务。如果是项目开发的核心人员或业务的主管离开或调任时, 不可避免地会使项目遭受挫折。因为新来的人员要花相当时间来熟悉项目的细节以及业务问题。最后是开发工具, 主要是硬件和软件的开发工具应用不当的。

3. 技术风险

技术风险是指潜在的设计、实现、接口、验证和维护等方面的问题。此外, 技术的不确定性、技术平台、技术生命周期以及“过于先进”的技术也是风险因素。从保守的观点来看待风险, 过多领先的创新可能成为IT项目巨大的灾难。另外如果所选择的技术正处于其生命周期的末期, 也有可能产生投资上的诸多问题, 而且它也可能会缚住项目的手脚并且变得多余或陈腐。技术风险的威胁主要会对项目的质量及交付时间产生影响。一旦技术风险变成现实, 则开发工作可能变得很困难。

三、IT项目风险的主要后果

伯恩斯坦 (1996) 曾经说过, 梦魇在于我们决策的结果, 而不在于决策本身。风险也是这样, 风险并不可怕, 可怕的是它带来的后果。在此, 本文还是按照上面的分类方法, 来阐述各自带来的风险后果。

1. 业务风险后果

由于项目的主管人员对业务问题缺乏了解或了解得不充分, 将造成资源和机会的错误匹配, 导致资金使用不当。所谓隔行如隔山, 由于各行业都有其独特性, 使得项目主管很难深入理解, 这种现象也曾被格林德尼 (Grindley, 1992) 称作“文化隔阂”。他的研究表明, 文化隔阂是IT项目主管所面临的最大问题之一。第二个后果是, 业务部门与项目开发部门的合作越来越困难, 这种不和谐最容易导致项目开发时的“信息孤岛”, 这样项目开发就形同闭门造车。第三个后果是, 所开发的功能在实际工作中并不需要, 其结果必然是IT系统不能被采用或很快就被放弃。这种结果很常见, 往往是开发出来的系统由于过于复杂, 业务人员无法适应, 或者系统严重脱离实际, 导致系统最后的闲置。雷曼尹 (1997) 的研究表明, 避免这种后果, 需要一个正式的风险管理策略, 这也是开普斯 (Keepers) 国际银行所采用的策略。

2. 开发风险后果

由于IT项目往往规模很大, 所以评估和计划的不足将会导致预算严重超支和时间超期, 从而会导致项目失去高层领导的支持, 这是很多项目最终失败的原因。另外, 关键人员的离职是项目开发过程中越来越难管理的问题, 这种结果可能是延迟开发时间, 也可能导致成本上升和开发混乱, 造成项目质量降低, 甚至极端情况下不能交付系统。还有如开发工具的不合适或不够匹配, 它可以导致重新设计系统和重新编码, 这会由于高成本而导致放弃IT项目。比如2000年联想就是过分地相信MOVEX产品而导致了最后与三露厂之间噩梦般的结局。

3. 技术风险后果

由于所选择的技术不当或者是没能成功地执行, 其结果通常是项目的质量降低。另外, 到目前所遇到的最重要的技术困难在于新技术本身, 或者是在行业内是最新的, 或者是开发组以前没有用过的。这就需要时间和资金来应对新技术带来的新挑战, 稍有不慎, 会导致项目不能完成或者是系统缺乏稳定性。

四、IT项目的风险管理手段

各行业务本身就是与风险并存的, 因此在实施IT项目过程中会不可避免地遇到各种风险问题。项目风险管理的基本目标 (雷曼尹, 1997) 就是确定这些风险的行动路径, 然后选择必要的步骤来减小或消除风险。另外在这个过程中关键问题还在于管理的成本, 减小或转移风险的总成本不应该大于风险物化时所发生问题的成本, 因为往往会出现避免风险的花费比风险实际发生时的成本要大的多。但无论如何都要进行风险管理, 采取具体的手段来应对各种潜在的问题。

1. 确定专门的风险管理负责人

IT风险管理是一项极具挑战性的工作, 因为它要求组织内部必须做好充分的准备, 并且贯穿整个项目的始终, 这样才能保证项目的成功完成。IT项目的风险管理是非常耗时间和精力的, 这样就需要一个风险管理负责人, 这个人要求既懂金融业务又懂IT问题。当然如果项目非常小, 项目经理是可以兼任风险管理负责人的工作的。风险管理负责人, 必须始终对风险保持警惕, 并且能够制定风险防范计划, 采取合适的手段应对各种潜在的、突如其来的不确定性。

2. 选择合适的项目经理

现在IT行业里面, 顶着项目经理头衔的人越来越多, 取得PMP证书的人也越来越多, 但真正做起项目管理却不见成效。因此如何选择合适的项目经理, 对于一个IT项目的风险管理至关重要。一般而言, 可以从四个方面进行评判:知识、经历、能力、性格。这里特别强调对行业的了解, 这不单是对IT行业的深入了解, 还需要对其他行业的经营理念有所涉猎。知识掌握得是否扎实, 是否全面, 是否应用自如, 决定着项目经理的水准。在项目开发中, 项目经理要帮助风险管理负责人阐明风险和管理风险, 而且他也要让所有参与项目开发的人关注风险问题, 因此选择合适的项目经理是成功的关键。

3. 建立风险管理计划

如前所述, IT项目的风险管理应该作为项目的一个部分, 需要编制一个完善的管理计划。这包括四个阶段:识别风险、建立风险物化结果、理解风险的驱动因素、为最小化风险达成一致意见。按照前面的三种风险分类, 用聚焦的方法, 提出各自相应的风险问题, 从而形成项目的风险评价问卷。这有助于风险管理负责人能够考虑所有主要的或现在的相关风险。之后是检查风险物化后的结果或问题, 这可以为避免风险提供指南。紧接着要全面检验风险的驱动因素。如果能理解这些因素, 那风险管理负责人就可以在防止和避免风险方面发挥重要作用。最后就可以根据上述步骤建立和执行适当的行动方案。在这个过程中, 应该注意, 避免风险的成本不能超过解决风险物化后造成结果的成本。

4. 对项目参与人员进行业务培训

业务风险中很大一部分是由于参与人员对相关业务不熟悉或理解不充分, 特别是项目经理。因此必须在IT项目开始之前对其进行必要的业务培训, 使之能对业务流程有相应的理解, 并且有必要安排业务考核, 以便组成精干的开发队伍。

5. 建立定期风险审计进度计划

在IT项目的风险管理过程中需要认识这样一个事实:风险熵 (穆非, 1997) 在整个项目中是一直存在的。因此除了要检查风险管理计划外, 定时检查或审计风险水平也是很重要的。在国外的IT项目开发中通常应用风险评审技术 (VERT) 来做这个工作, 这可以为项目管理人员进行项目风险分析提供一系列行之有效的方法。

6. 建立应急计划

在项目开发过程中最困难的问题就是变化。这些变化常常是以一种极具威胁的方式出现的, 或者耗时间或者费资金, 而且变化的蔓延对项目的进行极其不利。当然项目从一开始, 就不可能知道最终确切的结果。而且由于这种不确定性, IT项目开发只能依赖当前没有变化的假设。然而如果适应不了这些变化, 那么应急方案也许是唯一能够挽救的措施, 这也是风险管理中最糟糕的结局。

从风险细节上讲, 管理的手段还有很多。比如, 加强对开发人员的管理, 避免人员的频繁流动, 做好项目的整体评估, 对准备运用的新技术进行小规模的实验, 像一般的项目一样建立项目监理制度等等, 当然取得管理层对项目的支持也是非常重要的。

五、结束语