3.5 信息系统项目风险应对与控制

项目风险应对和控制是项目风险管理最主要的阶段,其他步骤所有工作都是为此服务的。本阶段的目的是根据项目风险的种类、性质和大小,结合项目自身的条件和特性,制定和执行合理的风险应对措施的过程。

3.5.1 项目风险应对策略

在项目风险控制策略中,根据项目风险管理团队对项目风险的应对态度,大致可以将其分为积极管理和消极应对。具体的方式有远离、包容、缓解、接受、转嫁4种策略。

（1）远离。远离策略,是在项目风险较为严重,超出了项目团队和组织能够承担的范围时采取的一种措施。远离风险意味着不参与面临较大风险的项目或者项目中面临风险的部分。当然,在远离风险的同时,项目组织也远离了由项目所带来的潜在收益。一般情况下,远离风险策略是一种让人难以决断的方法,因为高风险项目对应的是项目的高收益,收益的诱惑使项目团队领导人难以割舍,但当风险超出了承受能力,或者风险与收益不配比时,放弃是一种最好的选择。

采取远离策略情况下,项目团队有可能是放弃整个项目,也有可能是放弃项目中某个风险过高的部分而将其外包给分包商。

在ERP的开发和应用中,流传着这样一句话,“上ERP是找死,不上ERP是等死”,说明了ERP项目的风险之大。在这种情况下,项目开发客户可能会因为项目风险太大,在权衡了风险和收益之后,认为该风险是企业所不能承担的,决定放弃ERP的开发和使用,这就是采取远离策略。

（2）包容。包容策略,是在项目开发前期进行进度和资源规划时,预留出足够应对项目风险的时间和资源,以弥补由于风险的发生而造成的进度延期和资源不足。对项目风险采取包容策略是以金钱和进度来换取一个稳定的项目进展过程和项目的成功。

在软件编写过程中,对于一个不太成熟的程序员,将对其编程速度的要求从额定的每小时100行调整到每小时80行,给他更富裕的时间从事该项工作。这就是一个最简单的包容策略。

在实际工作中,专门针对某一项工作的风险包容并没有太大的意义。项目将要面对的风险有很多种,我们不能事先预知哪种风险将会出现。但我们可以知道,所有风险都不出现和所有风险都出现的概率很小,几乎可以不计。因此,项目风险的包容可以针对完整的所有风险,而不是为每种风险都预留出一定的资源。按照概率统计原理,将能够以更少的资源应对更多的风险。

包容策略虽然稳妥而且有效,但其弊端也是显而易见的,项目成本将会因此而上升,项目进展速度也会因此而下降。

（3）缓解。缓解策略,是指在项目风险出现之前采取一定的措施,以降低最终包容风险的成本。项目风险的缓解措施必须要在风险发生之前采取,只有这样,当风险开始出现时,采取的策略才会有效。

在信息系统项目风险管理中,缓解策略是一种最为积极有效的风险应对策略,通过项目管理团队和风险管理团队的努力,尽量降低风险发生的概率和风险的影响程度,从而降低风险暴露,减少对风险进行包容所需的成本。

程序开发中的软件编程,现有的编程人员的编程速度可能会达不到在项目计划时所要求的每小时100行的要求,怎么办？如果项目团队想要采取缓解策略的话,可以在项目开始之前就对程序员进行培训,使其能够达到相应的要求。

（4）接受。采取接受风险策略的主要原因可能会有三种：第一种是风险是无法避免的,无论采取什么措施,都不能降低风险暴露；第二种是风险的威胁程度并不大,但如果采取其他措施阻止风险的发生,费用和成本可能会很高而得不偿失；第三种是承担该风险的收益较高、利润较大。接受策略也就是在风险发生之前,项目风险管理团队识别出并分析到了该项风险,并勇于承担该项风险,或者只是设立风险储备金,主要用于在风险发生时处理风险。

接受策略看似不是十分明智,但在实际项目中却常有应用,特别是在一些对时间和成本要求不高的项目,项目开发方直接忽视一部分风险的存在,即便是风险发生了,项目组也有能力和资源来应对风险造成的损失。当然,这些风险必须是不会危及到项目存在且较小的风险。

（5）转嫁。转嫁策略,是指将风险发生的后果及其应对的责任转移到第三方身上。转嫁并没有减少或者消除风险,只是将风险的管理责任推给了另一方。风险转嫁策略的代价是需要向风险实际承担方支付风险承担费用。风险转嫁的方式有多种,我们最常见的是通过保险的方式将风险转嫁给保险公司。其他还有通过合同转嫁风险,如保证书、担保书及相应的合同条款。

3.5.2 项目风险的应对措施

针对于信息系统项目开发过程中可能出现的风险,我们将探讨一般意义上的风险应对和控制。对应于每种风险,给出一个基本的对策,对于实际项目过程中具体到单个项目的风险,可按风险的分类分别应对。

1.政治风险的应对

在项目风险管理中,特别是大型项目的风险管理中,政治风险一直是一个比较重要的问题。大中型项目的开发周期长,投入大,涉及的范围广,在一些政局和法律法规不稳定的国家,极有可能遭受到政治、法律风险的影响。而政治风险的最大特点是不可掌控性,在项目政治风险发生时,项目组织很难通过改变环境的办法规避风险。

对于政治风险,最有效的方法是在项目风险发生之前采取相应措施,如选择政治稳定的国家和地区开展项目,避开政治风险较大的项目。这种方法最简单,也最为保守,放弃了由于高风险带来的高收益。

对于政治风险,另一个可行的办法是投政治风险保险,也就是应用转嫁风险的策略,将政治风险转嫁给专业的保险公司,或者是获得当地政府的担保。但真正愿意承担政治风险的保险公司较少,即使愿意承担,保费也较为昂贵。

结合信息系统项目风险的特点,最为可行有效的方法是转移项目实施地。信息系统项目具有无形性,其成果的主要部分是没有具体形态的数据和程序,可能一个光盘就可以装下。因此,为了规避开发阶段的政治风险,可以将项目的开发转移到一个较为稳定的国家和地区,在开发完成后再回到目的地进行安装和硬件配置。

2.市场风险的应对

对项目来说,市场风险是最容易遇到的,也是项目相关方最为关注的。信息系统项目开发的最初依据就是市场需求,如果不能很好地符合市场需求和市场变化,那么项目成功的可能性就会变得很小。面对市场风险,项目组需要在项目一开始就认真研究市场现状和变化的趋势。

3.金融风险的应对

金融风险主要是源于利率风险和汇率风险两个方面,而应对金融风险的主要措施也应该从金融手段考虑。

4.技术风险的应对

信息系统开发项目的技术风险是最直观的,也是最受技术开发人员关注的。技术风险可以从管理和技术两个方面分别进行应对,因为管理和技术是相辅相成,并且是相互促进的。项目技术风险的来源主要是所采用的技术不成熟,以及现有技术无法满足信息系统的要求。

从管理方面考虑,在选择技术方案时,应对技术方案进行仔细甄选,考虑技术成熟度,尽量减少采用不成熟的技术方案；同时,在进行项目需求识别时,就要开始考虑项目需求在现有技术条件下是否能够得以实现。

在技术方面,技术人员应该积极配合管理人员进行风险分析。技术人员一般会比管理者更了解当前的软硬件技术现状,并且能更好地提出技术改进和发展方案。在技术风险应对中,技术人员应该努力减少采用自己不熟悉的开发方法和软、硬件,避免由于无法完成工作而造成的返工、工期延迟以及成本超支。

另外,应对技术风险的一个有效方法是积极引进新技术,最直接的方式就是引进更好的系统开发人才和开发团队,或者是将具有较大风险的开发部分外包,利用外部分包商的技术能力进行风险的转移。

5.管理风险的应对

在项目开发中,管理风险是最为复杂的,也是最难以应对的,项目团队的管理能力在很大程度上决定了项目的成败。最为严重的是,项目的管理风险往往来自于项目团队的高层,他们的领导能力和管理方法如果不能适应于项目,那么项目将会处于极度危险之中。对于项目的管理风险,应对的方法也比较多。

在应对项目开发管理风险的方法中,最能解决问题的是提高项目管理团队的管理能力。在项目开始之前,可以通过为项目配备更有经验和能力的管理人员来提高项目的管理能力。但在多数情况下,组织并没有足够的管理者进行分配,或者说是项目团队已经组建完成,不适宜调动时,提高现有人员的素质就成了当务之急,对此,对管理人员的培训是一种有效的方法。

但是,在很多情况下,项目组和项目的实际情况不适合于采取培训这种治本但缓慢的方法,比如项目时间紧急,来不及进行培训,或者是培训费用较高。这种情况下,可以采用聘请咨询公司进行管理咨询的方式解决在项目中的管理问题。这种方法直接有效,而且可以对管理人员起到一定的培训作用,是一种比较可取的管理风险应对措施。

6.人员风险的应对

如在前面章节中所叙述的,信息系统项目开发中所涉及的人员风险包括3部分,技术人员的开发能力、开发人员的工作积极性和关键人员的离职风险。

在应对人员风险时,项目的人力资源管理和绩效管理发挥着巨大的作用。项目人力资源管理的作用在于为项目配备高素质的员工；绩效管理的作用在于对现有员工进行考核管理并进行培训,激励现有员工的工作积极性,充分挖掘潜力。对于技术人员的工作能力的考察,可以在实际工作开始前,通过对历史资料的调查和模拟操作,检验现有员工的工作能力和水平,确定一个合理的计划进度。对于能力不足以达到要求的员工,则需要加以培训或者替换。

对于开发人员工作积极性不高而造成的工作效率下降,则需要具体分析原因,找出问题的症结所在,对症下药。

关键人员的离职虽然发生的概率比较小,但是对项目造成的威胁比较大,应该受到密切关注。对于有可能离职的关键人员,应在项目开始时就预先准备后备人员。为了降低高级职员流动给软件项目带来的风险,管理人员可以采取培养后备人才的措施。在软件开发过程中,尽量让更多的人参与总体设计和关键技术的攻关工作。实施这些措施需要一定的人力、时间和经费。管理人员应根据降低风险、减少损失的原则,客观地分析形势,做出正确的决策。

7.需求识别与变更风险的应对

项目需求识别与变更中产生的项目风险的应对措施主要集中在如何更准确地识别项目需求及需求变化。只有对项目需求有更进一步的了解,才能够对项目需求的变化做出快速反应并及时应对由此带来的风险。在进行项目需求风险应对时,首先要建立项目需求的控制机制,在项目需求识别初期,通过深入的沟通交流,明确定义需求,通过项目相关方的确认后,将需求封存,并在合同中约定关于需求变更的相关条款,明确项目需求变更的责任和义务,分担项目需求变化带来的风险。具体来说,就是在项目合同中明确规定,什么情况下可以提出项目需求变更,能够允许什么程度的需求变更,以及由需求变更带来的成本上升以及工期延长的责任由谁来负责。

8.项目计划风险的应对

在招标项目中,投标者为了能够中标,可能会将项目的精度和预算估计的过于乐观,更容易出现项目的计划风险。在固定价格合同中,预算过于乐观意味着项目团队的利润降低或者造成亏损,而进度计划的过于乐观则意味着可能会由于不能按时完成项目而受到罚款,影响到公司的信誉。为了尽量避免这种风险,在项目计划时,项目团队一定要严格把关,合理安排项目进度和预算支出。

9.违约风险的应对

项目利益相关方违约风险控制和应对的主要策略是通过合同进行约束。对于外部的合作方,双方在互相信任、互相合作的同时,也不能忘记可能存在的风险,在签订相关合同时,应具体详细地注明违约责任。如对于供应商的延期交付,可以按照相应的损失制定赔偿条款。

九江移动业务运营支撑网络管理工程的风险应对

在整个项目生命周期内,尽管工程受到高度重视,团队成员热情也很高涨,但还是碰到了一些问题,要面对不少风险。

1.业务需求风险

在编制早期项目计划书时,张海认为满足不断变化的需求对整个项目影响不大,因此,在市场部李虎不断地提出新的需求时,张海“来者不拒”,不停地更新项目计划,导致项目范围无法确定,工期和成本不可控制,团队成员工作目标也不明确。作为软件开发商杰瑞对此也颇有微辞。

2.合同谈判风险

在以往工程合同谈判时,考虑到IT项目建设的独特性,以及硬件设备国际招投标的时效性,九江公司一般采取横向联系方式,即先了解兄弟省公司近期类似项目的采购内容,确定技术和商务条件底线后,再与供应商进行合同谈判,以确保本省项目获得最佳性价比。在这种情况下,往往因采购额度吸引力不大、沟通信息不准确、各供应商关注点不一致、各软件商体系架构不一样等原因,导致公司因此耗费了大量的时间和精力,得不偿失。

3.产品到货风险

为满足九江移动快速发展的业务量和用户数,业务支撑网的项目建设周期越来越短,对于产品（设备或软件）到货时间提出了近乎苛刻的要求,最好“今天提需求,明天就拿货”。但是,稍有工程建设经验的人都很清楚,产品下单、生产开发、国际运输、清关、国内运输、到货签收,每个环节都需要一定时间。一般来讲,硬件设备到货周期为6～8周,软件产品交付时间为8～12周。这与市场需求瞬息万变、业务支撑项目建设分秒必争的大环境有些矛盾。

4.工程设计风险

在设计系统架构时,项目管理经验不足、关键技术不明确、系统扩展性不佳、产品兼容性有问题、软件版本管理混乱等,均可能是影响系统正常运行的潜在隐患。在本期工程的机房设备平面设计中,张海团队起初将大部分机架式的小型机集中摆放在一片较小区域内,从表面上看,提高了机房平面空间的使用率,但是由于未充分考虑到设备散热因素,造成了该区域的机房专用空调因负荷过重而多次宕机。

5.系统测试风险

系统测试工作是项目完工和交付使用前的重要步骤之一。张海团队曾因马虎测试或应付测试,给系统增加了诸多不利影响。例如,功能测试不全面,系统上线后发现部分功能运行不稳定,甚至根本无法实现；从未做过性能压力测试,不了解系统最大承受能力,随着业务量增加,系统负荷加重,系统运行效率下降；修改软件缺陷后未仔细测试,造成更大的缺陷出现,影响系统的安全性。

6.割接上线风险

本期工程正式割接上线前,前期工程仍然保持运行状态,保证系统稳定运行是项目团队的第一要务。在系统割接期间,为确保7天×24小时的业务连续平稳运行,团队必须制订详尽可行的系统割接方案、新旧系统并运行方案和故障应急处理方案等,这需要协调大量的人力、物力、财力才能完成,项目建设进度也因此受到延误。

3.5.3 项目风险应对和控制结果

1.更新的项目风险清单

经过项目风险控制阶段后,项目风险得到一定的控制和解决并且有了一定程度的变化。因此,需要对在项目风险分析阶段得出的项目风险说明书进行更新,将风险的状态更新为现在所处的状态。

2.项目风险控制报告

在项目风险控制阶段后期,项目风险管理团队需要对项目风险的应对和控制阶段进行收尾、总结经验及教训,并将相关资料整理成文档,形成风险控制报告,以备后用。