软件项目管理——05 软件项目风险管理

·
2025-12-07 13:21:20

1 案例故事

NaleNet 是国外一家知名的网络设备厂商,它在中国拥有许多电信运营商客户。NaleNet 主要通过分销的方式发展中国业务,与国内的合作伙伴和电信公司签约并提供具有增值内容的集成服务。国内一家电信公司盛世通讯打算实施某项目,通过招标选定 NaleNet 为其提供网络设备。福清公司是 NaleNet 在中国的一级代理商,是该项目的实施单位;随后盛世通讯和福清公司签订了总额近1000万人民币的合同,项目的施工周期确定为3个月,由 NaleNet 负责提供主要设备。福清公司第一次承接此类项目,负责全面的项目管理和系统集成工作,包括提供一些附属设备和支持设备,并且负责项目的整个运作和管理。NaleNet和福清公司之间的支付关系是一次性付账。这就意味着 NaleNet 不承担任何风险而福清公司虽然有很多利润,但要承当全部风险;然而,由于激烈的商业竞争,福清公司在参与投标过程中对盛世通讯做了一些额外的承诺,提供的技术建议书远远超过了系统能达到的实际技术指标,并于 NaleNet 和福清公司的代理合同有不少出入;经过3个月的建设期,整套系统安装完成。但自系统试运行之日起就不断有问题暴露出来。盛世通讯要求福清公司负责解决,可其中很多问题涉及 NaleNet 的设备本身。尽管 NaleNet 也一直积极参与配合此项目的工作,但由于开发周期的原因,NaleNet 公司无法马上达到新的技术指标并满足新的功能。对于盛世通讯来说,他们认为按照招投标的要求,福清公司实施的项目没有达到合同要求。因此项目一直拖到次年,盛世通讯还拖欠福清公司10%的验收款和10%的尾款。为完成此项目,福清公司只好不断将 NaleNet 公司的最新升级软件提供给盛世通讯,甚至派人常驻盛世通讯;次年年中,盛世通讯终于进行了初步验收,在福清公司同意承当系统升级工作指导完全满足招投标的条件下,盛世通讯支付了10%的验收款。然而到了年底,NaleNet 公司由于战略调整暂时中断了在中国的业务,其产品的支持力度大幅下降,结果致使该项目的收尾工作至今无法完成;原本福清公司在此项目上预算可以有250万元左右的毛利,可是扣除预算外增加的项目成本(差旅费、沟通费用、公共费用和贴现率)和尾款,实际上的毛利不到70万元。如果再考虑项目拖期带来的机会成本、公司名誉的影响等,实际利润可能更少甚至是负值。

2 概述

2.1 风险

卡耐基梅隆大学的软件工程研究所将风险定义为损失的可能性,即风险具有两大属性:可能性和损失;

可能性是指风险发生的概率;损失是指预期与后果之间的差异;

风险常和以下词紧紧相联:

目标:说明有明确目标,才会因结果与目标的偏差产生风险,比如软件项目要按时交付(目标),才会有进度延误的风险,是风险存在的前提;损失:强调 “造成损失” 是风险最本质的特征,风险一旦发生,会让项目在成本、质量、进度等方面偏离预期,带来负面结果;或然:指风险发生的时间、条件难精准预判,像软件测试时突然出现的兼容性问题,体现了风险的不确定性,这也是风险管理要提前规划、持续监控的原因。

2.2 软件风险

定义:软件风险是有关软件项目、软件开发过程和软件产品损失的可能性。由于软件生产的特殊性,软件风险包括软件项目风险、技术风险和产品风险;软件项目风险:

潜在的预算、进度、人力、资源、客户和需求等方面的问题及它们对软件项目的影响;软件项目风险威胁项目计划,如果风险变成现实,有可能会拖延项目的进度,增加项目的成本;软件项目风险的因素还包括项目的复杂性、规模及结构的不确定性;

技术风险:

潜在的设计、实现、验证和维护等方面的问题;此外规约的二义性、陈旧技术缺乏竞争力、先进技术带有不确定性以及技术人员的流动性也都是风险因素;技术风险威胁软件的质量和交付时间,如果技术风险变成现实,则开发工作可能变得很困难或者走向失败;

商业风险:

威胁到要开发软件的生存能力;主要的商业风险,如市场降温、公司运营战略转变及资金链断裂等都会危害项目或产品研发。

2.3 软件项目风险管理

风险管理是一种涉及社会科学、工程技术、系统科学和管理科学的综合性多学科管理手段,它是涵盖风险识别、分析、计划、监督与控制等活动的系统过程,也是一项实现项目目标机会最大化与损失最小化的过程;

风险管理过程就是从一堆模糊不清的问题、担心和未知开始逐步将这些不确定因素加以辨识、分析、并进而转化为可接受的风险。风险管理是一个持续不断的过程,贯穿于项目周期的始终;

软件项目风险管理主要包括:

风险识别:识别风险和风险来源;风险分析与策划:在已建立的标准基础上分析风险;

估计风险的可能性与后果;评估风险的严重程度;策划如何解决风险;制订风险解决方案,并为选择的方法定义行动计划;建立起点,帮助决定何时执行风险行动计划;

风险跟踪:监视计划的起点和风险的状态;

比较起点和状态以决定变化;使用触发器提供风险的早期警告,以便及时应对风险,执行风险行动计划;

风险应对:对触发事件的通知作出反应,执行风险行动计划,报告风险应对措施的结果,直到风险降到可接受范围;风险管理验证:保证项目实施无偏差地执行风险管理计划;

需要制订评审标准,设定恰当的期望值;评审的目的是理解风险管理计划的活动、行为人和典型产物,为符合审计做准备;审计过程将验证计划的活动是否得以执行,参加者是否得到培训,是否坚持了风险管理计划;审计报告详细说明了现实与计划的差异,还要表明要求是否达到以及任何不符合计划的情况;

风险管理与项目管理的关系:

2.4 软件项目风险管理的意义

风险管理的目的是将风险带来的影响或造成的损失减少到最小。尤其是对于大型复杂的项目,风险管理显得尤其重要。如果不进行风险分析,没有针对风险采取强有力的避免和降低损失等措施,项目必将以巨额损失为结局;

通过风险管理可以使决策更科学,从总体上减少项目风险,保证项目目标的实现;通过风险识别,可加深对项目和风险的认识和理解,分析各个方案的利弊,了解风险对项目的影响,以便减少或分散风险;通过风险分析提升项目计划的可信度,改善项目执行组织内部和外部之间的沟通;使编制的应急反应计划更有针对性,即使风险无法避免,也能减少项目承受的损失;能够将处理风险的各种方式有效组织起来,在项目管理中增加主动;为以后的规划与设计工作提供反馈,以便采取措施防止与避免风险造成的损失;为制订项目应急计划提供依据,有利于抓住与利用机会;可推动项目管理层和项目组织积累风险资料,以便改进将来的项目管理方式和方法。

3 风险识别

风险识别,是寻找可能影响项目的风险以及确认风险特性的过程。风险识别活动的参加人员一般包括:项目组成员、风险管理人员、学科专家、客户、项目的其他管理人员以及外聘专家等;风险识别的目标是辨识项目面临的风险,揭示风险和风险来源以及记录风险信息。

3.1 风险识别依据

项目计划:包括项目的各种资源及要求,项目目标、计划和资源能力之间的配比关系为软件项目风险预估提供了基础;历史经验:历史类似项目的信息对于风险识别,尤其是对于陌生项目具有不可或缺的参考价值;外部制度约束:如国家或部门相关制度或法律环境的变化,劳动力问题,通货膨胀问题等;项目内部的不确定性。

3.2 常见软件风险

人力资源风险:

人员配备不合理,忽略或没有时间进行必要的项目培训;

项目组成员缺乏合作精神,人员缺乏必胜的进取心,人员工作环境低劣等;

过分自信的进度加上固定的成本预算,必然会导致进度与成本方面的风险;

不切实际的过高生产效率要求,把加班当作是克服进度过慢的标准过程;

缺乏项目分析时间可能导致对产品功能需求的片面理解;

需求风险:

模糊或变化的用户需求必然导致需求的混乱;文档没有准确记录系统的需求;接口文档不统一或存在二义性;客户方面人员的变动导致用户需求变更;软件可靠性分析和验收合格标准需求与定义不清楚;对系统不切实际的期望,包括进度、技术等;商业软件产品定位不清导致的需求混乱;

项目接口风险:

需要等待其他软件产品交付以便进行系统集成,很可能导致进度落后;软件外包商的技术能力低于期望值;硬件没有检验,文档记录不全;软件外包商的方法论、软件过程与客户要求的标准不符;

设计风险:

粗略的概要设计可能带来整个软件系统架构的不稳定;未经检验的设计可能会引发系统的性能问题,使之无法达到既定的性能要求;

管理风险:

角色与责任不明确或定义不当,会引起不协调的活动、不合理的工作负担以及工作重点不突出;项目角色与责任没有被充分理解;项目缺乏有效的人员激励机制;缺乏对软件项目必要的内部评审;项目报告不真实或重点不突出;管理制度不落实;

开发过程风险:

不切实际的进度与成本要求;项目缺少富于经验的资深开发人员;使用未经充分验证的新技术、新开发平台最终导致系统崩溃;软件开发计划的调整没有充分考虑项目的大小与实际情况;开发工具没有全集成;客户文件格式和维护能力与现有开发环境不合;

项目集成与测试风险:

集成与测试由于受到进度与成本的制约而受到压缩;测试过程没有良好的定义,缺少测试用例和测试计划;一些需求由于定义模糊,难以测试;由于时间限制,系统可靠性测试不充分。

3.3 风险识别过程

风险识别过程是将项目的不确定性转变为风险陈述的过程,它包括以下活动;进行风险评估:风险评估是以已建立的标准为基础,识别与估计风险;

它提供项目所管理的以评估风险的基线,一般适合在项目初期进行;后续的评估建议在主要的转折点或主要的项目变更时进行。这些变更通常指成本、进度、范围或人员等方面的变更;

系统地识别风险:通过核对清单、头脑风暴、Delphi 法、会议法以及匿名风险报告机制等识别风险;风险定义及分类:

一个问题被识别出来以后,可通过整理已辨识风险,将类似的风险归为一组;冗余的风险应予排除,但是应记录冗余的个数,同风险被多次识别可能在一定程度上反映了该风险的重要性;

确定风险驱动因素:

风险驱动因素是引起软件风险的可能性和后果剧烈波动的变量;可通过将风险背景输入相关模型得到;进度的驱动因素通常包括在项目关键路径上的节点当中;

将风险编写为文档:通过编写风险陈述和详细说明风险场景来记录已知风险。

3.4 风险识别方法与技术

风险识别的方法有很多,核对清单和 Delphi 法是比较常用的两种;

核对清单:

通过先前相似项目的历史数据和其他信息源,对照当前项目,项目管理人员很容易找出当前项目潜在风险;

风险核对清单能为识别风险提供系统的方法,通过评审项目的关键成功因素,可以列出关键路径上的所有项,逐条列出项目接口;

可以采用 SEI 软件风险分类系统将软件开发的风险按通用的种类和具体属性组织起来,将风险分为产品工程、开发环境和项目约束 3 类;

头脑风暴法:

该方法简单而有效;会议负责人召集项目组全体相关人员参加会议,进行关于项目风险的自由讨论;项目组成员在主持人的引导下自由发言,不受限制,产生关于项目风险的概念;然后风险管理人员将会议结果进行分类管理,作为风险识别的基础,并将这些结果和其他风险识别方法产生的结果一起进行风险分析;该方法一般在项目风险识别活动的早期进行;

匿名风险报告机制:

项目组建立一个匿名的风险交流渠道,使得每个成员都可以利用这个渠道向管理部门报告项目进展情况和风险消息;这一渠道可以是一个简单的“意见箱"。如果开发人员迟于进度表交付代码测试,有关的测试员可以报告此事;如果测试员在没有充分测试的情况下,就将产品构件写成书面文件,那么有关的开发人员可以提出来;实践表明,匿名风险报告机制对于识别与跟踪项目风险有良好的效果;

Delphi 法

Delphi 法本质上是一种使专家就一个“科目"达成一致意见的方法,这个“科目"可以是软件成本,也可以是软件项目风险等;首先任命一些项目风险识别专家,所有专家均匿名参加;通过函询的方式将调整表发给专家,专家完成后,由调查人员将专家意见汇集整理,然后再返回给专家,征求进一步意见,经过几轮反复,直至专家意见趋于稳定,达成专家一致意见;识别的结果可以用图表或文档的方式表达;

SWOT 分析法

SWOT(Strengths Weakness Opportunities Threats)分析法是分析项目内部优势、弱势、项目外部机会以及威胁等方面的代名词;SWOT 分析法作为一种系统分析工具,其主要目的是对项目的优势与劣势、机会与威胁各方面,从多个角度对项目风险进行识别。

3.5 英达公司用 TOP10 法识别项目风险

英达公司是一家专门开发仓储管理系统的软件公司,他们的仓储管理系统 eXtreme WMS 覆盖了专业仓储管理的各个方面,并提供良好的灵活度和扩展能力,即适用于用户单个仓库的业务管理,又可覆盖跨地域的多个仓库的业务;由于每个客户企业的运营模式不相同,需要针对每个客户企业单独引进和实施该系统。每一个系统的引进都是一个单独的实施项目,历时一般为2个月;在产品推广的初期,派驻到客户企业的项目组严格按照公司制定的标准过程实施:

进行售前系统演示和培训;需求调研和分析;部署标准版本 eXtreme WMS 的系统并导入测试数据;根据用户需求定制和修改标准版本部分功能;系统测试、验收测试,系统试运行;系统正式上线;

然而,在每个项目实施过程中,会出现或多或少的问题,影响项目的进展;经过一年摸索,实施项目组终于明白这些问题就是所谓的项目风险,只有在项目初期准确地识别这些风险,并事先制订风险应对预案才能做到处乱不惊,提出一种风险识别方法,即“TOP10 法”;

项目组首先反思过去实施项目中出现的种种风险,并一一作了记录;根据常见软件风险和 CMU/SEI 制定的风险核对清单,总结出今后在项目实施中可能会遇到的各种风险,并分门别类列出清单,作为风险备忘录;在随后的每一次实际项目实施中,项目组在经过需求调研和分析后就会马上召开风险分析会议,结合项目的特定需求及客户企业特点对照“风险备忘录”,采用头脑风暴法,为每一类型的风险找出最有可能发生的 10 种,并积极考虑应对方法,即 TOP10。就是说每一类项目风险,都要找出最可能的 10 项具体风险,并积极考虑应对方法。

4 风险分析

风险分析是分析每种风险可能发生的时间和概率,以评估项目可能结果的范围。它有助于确定哪些风险需要应对、哪些风险可以接受以及哪些风险可以忽略;风险分析活动的过程目标包括提炼风险背景,确定风险来源,确定行动时间框架和确定前 10 项首要风险名单等。

4.1 风险分析过程

包括确定风险的类别、找出风险驱动因素、判定风险来源、确定风险度量标准、预测风险造成的后果和影响以及评估风险的等级以便对风险进行高低排序等。具体步骤如下:

定义风险度量准则:风险度量准则是按照重要性对风险进行排序的基本依据,定义度量准则的目的是利用已知标准衡量每一项风险。风险度量准则包括:可能性、后果和行动时间框架;

可能性:即风险发生的概率,分定性(极低、低、中、高、极高 ,也可简化成低、中、高)和定量(用概率数值,像极低对应 0.1 、极高对应 0.9,如下表)两种度量方式,定量的更精准,适合复杂项目分析;

可能性概率极低0.1低0.3中0.5高0.7极高0.9

后果:后果反映了风险对项目目标的影响程度;

后果的度量可以是定性的,也可以是定量的,它与组织的文化因素有关;

按定量分级的值可以是线性(简单对应数值,即极低 1 、极高 9,如下表)的,但也常是非线性的,这反映了组织对规避高风险的重视程度;

后果取值极低1低3中5高7极高9

定性与定量两种方法的目的都是依据项目目标为风险对项目的影响指定一个相对值,严格的定义可以改善数据质量,确保过程的可重复性;

行动时间框架:行动时间框架是指采取有效措施规避风险的时限。阻止风险发生的行动时间也应随具体项目的不同而不同;

预测风险影响:

根据风险的定义,用风险发生的可能性与风险后果的乘积来度量风险的影响,公式:风险影响=风险发生的可能性×风险后果;可能性被定义为大于0,小于1。后果从 1 至 10 表示风险对成本,进度和技术目标的影响。两者的乘积可能是经济的损失,或时间的损失;

评估风险:

项目中各个风险的严重程度(如下图)是随着时间而动态变化的。时间框架是度量风险的又一个变量,它是指何时采取行动才能阻止风险的发生;

时间\风险低中等高短521中等743长986

风险影响和行动时间框架决定了风险的相对严重程度。利用风险严重程度可以区分当前风险的优先级别。随着时间的推移,风险严重程度发生变化,有利于显示当前项目面临的重点问题;

风险排序:依据评估标准确定风险排序,可保证高风险影响和短行动时间框架的风险能被最先处理。对风险进行排序,以有效集中项目资源,并考虑时间框架以得到一个最终的按优先顺序排列的风险评估清单;

风险当前优先级别以前优先级别进入前10名的周数行动计划状态风险等级不断增长的用户需求115利用用户界面原型收集高质量的需求;将需求置于明确的变更控制之下高无法按进度表完成262要避免在完成需求分析之前对进度作出约定;在早期进行评审,以发现并解决问题;在项目进行过程中,要对进度表反复估计;增加项目组成员高项目分包商无法提供合格产品351要对分包商的技术实力与信誉度充分评估;合同一定要明确双方的责、权、利高………………………………

制订风险计划:

风险计划是实施风险应对措施的依据与前提;

风险计划包括制订风险管理政策和过程的活动;

依据风险计划可以将管理的责任与权利分配到组织的各个层次;

制订风险计划的过程就是将风险列表转换为应对风险所采取措施的过程;

风险计划包括以下内容:

确定风险设想:风险设想是指对导致不如人意的结果的事件和情况的估计;

事件描述风险发生时必然导致的后果;情况描述使未来事件成为可能的环境;应对所有项目的成败是有关键作用的风险进行风险设想,风险设想是对风险的进一步认识,是风险计划的重要依据条件;

选择风险应对途径:选择风险应对途径,针对具体风险依据项目计划、项目约束选择一种策略,也可能将几种风险应对策略合并成一条综合途径。常用作选择风险应对途径的取舍标准是风险倍率和风险多样化;

风险倍率=风险影响(之前)−风险影响(之后)风险应对成本

风险倍率 = \frac{风险影响(之前) - 风险影响(之后)}{风险应对成本}

风险倍率=风险应对成本风险影响(之前)−风险影响(之后)​

风险倍率指执行不同风险应对活动的相对成本和利益的比较。风险倍率是一条风险应对法则,它通过减少风险影响来减少风险。风险应对成本是实施风险行动计划的成本。倍率的概念有助于确定获得最高回报的行动;

多样化是风险应对的规则之一,它通过分散风险来减少风险。多样化策略就是不要把所有的钱都装在一个钱包里。在软件系统,因为没有万灵的方案,那么项目就尽量不要过分依赖于一种方法、一种工具、一个人或一个产商。另一个多样化是对个人实现不同的培训,选择具有不同项目开发经验的人员组成项目组。多样化建立一条平衡的路径,强调了软件项目的基本原理;

设定风险阈值:

风险反应计划并不需要立即实施,有些风险可能始终都不会发生。正因如此,如果没有明确定义的风险端倪示警触发机制,一些风险或重要问题在项目风险跟踪中很容易被遗忘或忽略,直至出现无法补救的后果。要做到尽早警告,可使用以定量目标和阈值为基础的风险触发机制;

量化目标(如下图,软件产品的量化目标)是指用数量化方式表示的目标。它定义了由度量基准和度量规格确定的最佳目标。每个阶段的衡量或评估都应有与项目计划对应的最佳结果值,即量化目标。可接受的最低结果值定义了项目的风险警告,称之为风险阈值;

衡量项目目标阈值去除缺陷效率大于95%小于85%进度落后或成本超出风险储备的范围010%总需求增长每月小于1%每年大于50%总软件项目文档每功能点单词数小于1000每功能点单词数大于2000员工每年的自愿流动1%~3%10%

编写风险计划。

4.2 风险分析技巧与工具

常用的风险分析方法和工具有因果关系分析法、决策分析法差距分析法、Pareto 分析法和敏感度分析法;

因果关系分析法:用于揭示结果与原因之间的联系,以便追根朔源,找出风险的原因。通过找出问题的起因,从源头遏制问题的发生。常用的因果关系分析法有鱼骨图法,它可以帮助把问题追朔到最根本的原因上;

决策分析法:用于构建决策模型,该模型代表真实世界里的问题。通过分析模型认识与理解问题。决策模型的元素包括决策、不确定事件以及结果的价值。一旦辨识了决策元素,就可以利用影响图表或决策树构建决策模型;

差距分析法:用来确定变量的差距,在风险管理活动中,该方法描述了人们意识到的重要性和实际执行情况的差距,从而确定风险管理实践是否需要改进;

Pareto 分析法:对一个较大项目,可能识别出数十项风险,而每个风险通常又有若干驱动因子,那么风险管理本身就成了一个成本巨大的难以应对的问题。Pareto 分析法解决了这个问题。根据20/80定律,所有项风险的80%能够通过20%的已识别风险来说明,也就是说只要找出项目风险的 20%关键致因,就可以解决项目风险的大部分问题;

敏感度分析法:通过改变每一个输入变量,其他变量保持正常值,来帮助确定模型对输入变量的敏感度。对决策有影响的变量较为重要,其他变量则相对次要。对变化不敏感的变量设为正常值,将其作为已知变量而不是不确定变量进行处理。敏感度分析法将注意力放在最重要的变量上对风险分析有重要意义,从而可以列出按重要程度排列的输入变量的顺序。

4.3 风险分析成果

经过风险分析,可以得到一个按优先等级排序的风险列表,它表示一个详细的风险目录,其中包括所有已识别风险的相对排序:

风险可能性影响组织财政问题导致项目预算削减低灾难性的招聘不到所需技能的人员高灾难性的关键的人员在项目的关键时刻生病中严重的拟采用的系统组件存在缺陷,影响系统功能中严重的需求变更导致主要的设计和开发重做中严重的组织结构发生变化导致项目管理人员变化高严重的数据库事务处理速度不够中严重的开发所需时间估计不足高严重的CASE工具无法集成高可容忍的客户无法理解需求变更带来的影响中可容忍的无法进行所需的人员培训中可容忍的缺陷修复估计不足中可容忍的软件规模估计不足高可容忍的CASE工具生成的代码效率低中无关紧要

5 风险跟踪与应对

5.1 风险跟踪的目标和依据

风险跟踪的目标:

经过风险识别与分析,可以预测风险发生的背景、可能性及造成的后果;但想知道风险是否发生,什么时候会发生,以哪种形式表现,这需要通过风险跟踪才能得以正确的判断;风险跟踪的目标是:

监视风险设想的事件和情况;跟踪风险阈值参数;为触发机制提供通知;获得风险应对的结果;定期报告风险度量结果;使风险状态保持可见;

风险跟踪的依据:

风险设想:风险设想是动态监视那些导致的结果的事件与情况,以掌握风险发生的可能性。风险设想像线一样将风险串联成问题,风险设想中的事件和情况是通往问题之路上的检查点;风险阈值:阈值定义了风险发生的端倪,预先定义的闽值作为风险发生的警告,表示需要执行风险反应计划;风险状态:风险状态动态记录了项目有关风险的详细信息。

5.2 风险跟踪的结果

风险度量:风险度量提供了用于表示项目风险级别的客观和主观数据;

客观数据包括条目的实际数码,用于校正项目有关人员的主观理解,并深入调查;主观数据来源于个人或项目组对情况的认识,他们提供证实和解释客观数据的关键信息;风险度量为识别风险、启动风险计划提供了客观依据;

触发器:启动、解除或延缓风险计划活动的装置。

5.3 风险跟踪的过程

一般风险跟踪的过程包括监视风险设想、对比项目实际状态上风险阈值的关系、收集风险症状信息以及报告风险度量结果等;

监视风险设想:

风险设想像线一样将风险串联成问题,风险设想中的事件和情况是通往问题之路上的检查点;人们监视风险设想,确定风险发生的可能性是否在增大;跟踪风险设想的事件与情况,可确定是否有必要立即采取行动;

对比项目状态与风险阈值:

通过项目跟踪工具获得项目进行过程中产生的状态信息,将不同的状态信息与计划中的风险阌值进行比较;如果状态信息在可接受的风险阈值之内,表明项目进展正常;否则,表明出现了不可接受的情况;这就是一项风险示警系统,触发器是控制风险计划实施的装置。它可置于项目状态监视、计划的风险阈值、定量目标和项目进度中;

风险信息的通知:

风险信息通过触发器发出,触发器提供3种基本控制功能:

激活,提供执行风险反应计划的示警信号;解除,触发器可用于发送信号,终止风险应对活动;挂起,或称延缓,暂停执行风险计划;

用于提供风险通知的触发器:定期事件触发器、时间触发器、相对变化触发器、阈值触发器;

报告风险度量:

度量是确定大小、数量或容量的标准度量单位,通过与历史度量数据的比较可作为管理层的指导;

常用的风险度量及定义如下:

度量名称定义风险的数目当前管理的风险数记入日志的风险数目输入风险数据库的已识别问题的总数风险类别在每种风险类别中识别的风险数目,表明在某一特定类别中,风险对项目的影响究竟有多大风险影响由关系式 ( RE = P \times C ) 定义,( RE ) 是风险影响,( P ) 是风险发生的可能性,( C ) 是风险发生的后果风险严重程度包括时间在内的相对严重级别,如在一个 ( 1 \sim 9 ) 的数值范围内,风险严重类别为 1 的是最高风险,它的风险影响和行动时间框架都要优先风险倍率它是对实行不同的风险应对活动所得的相对成本和利益的度量风险阈值在定量的目标基础上进行确定。风险阈值是启动风险行动计划的值。超过阈值会作为示警通知进行传送风险指标为风险监视到的项目、过程和产品的当前度量值(如成本、进度、进展、变化、员工流动、质量和风险)风险管理指数所有风险的量化的风险影响的合计,用所占项目总成本的百分比来表示投资回报所有风险节省的总和除以风险管理的成本

5.4 风险应对策略

风险一旦发生,就需要主动应对,风险应对策略包括:避免、转移、缓解、接受、研究、储备以及退避等;避免:

风险避免是指通过改变项目计划或条件完全消除项目风险或保护项目目标不受风险影响;项目早期的风险可以通过澄清需求、获取信息、改善交流以及听取专家意见等方式处理;降低项目目标,缩小项目范围以避免高风险活动;增加资源或时间、用经过检验的熟悉方法代替创新方法;

转移:

风险转移是指将风险转移给另一方去承担;转移风险只是将风险给了另一方,它本身并没有消除风险;风险转移几乎总要给承担风险的一方支付额外的费用,包括保险投保、发行债券及担保等,可以通过合同的方式将特定的风险转移给另一方;如果项目的设计是可靠的,一个固定价格的合同就可将风险转移给另一方;

缓解:

风险缓解是指寻求降低一个不利风险事件的发生概率或产生的后果使它达到一个可接受的水平;尽早采取措施降低风险发生概率或者对项目的影响,比试图修补风险产生的后果要有效得多;风险缓解的成本应该适应风险发生的概率和它产生的后果;可以通过降低过程复杂程度、采取更有效及强有力的测试、选择一个更可靠的销售商等来降低风险发生的概率;

接受:

接受风险是指有意识选择承担风险后果,或项目组找不出任何风险应对策略;风险接受包括主动接受与被动接受;

主动接受包括开发一项风险应急处理计划,当风险发生时马上执行;被动接受不需要采取任何行动,当风险出现时再由项目组去处理;

可以制订一个应急处理计划,用于应对项目进行过程中出现的风险,这样一个应急处理计划可以大大降低风险处理行动的成本;

研究:

风险研究是指通过调查研究以获得更多信息的风险应对策略;研究是需要获取更多关于风险的信息时所用的一种决策;

储备:

风险储备是指对项目意外风险预留应急费用和进度计划;风险储备用于项目较新时,以防止项目进度或费用超支等风险;详细说明风险在系统内的位置,才能将风险和储备联合起来;

退避:

假如风险影响巨大,或采取的措施不完全有效,这种情况下就要开发风险退避计划;它可能包括应急补贴、可选择的开发以及改变项目范围。

5.5 风险应对过程

原型法是一种风险避免与缓解的应对行动。风险应对过程主要有对触发事件作出反应、执行风险计划、对照计划报告进展、修正与计划的偏差;对触发事件作出反应:

触发器提供风险通知,收到通知的人必须对触发事件作出反应;要执行风险计划,必须确定一名负责人;识别与分析风险的人不定是应对风险的人,风险应对行动应该落实到最底层的人员;

执行风险计划:要将风险应对具体活动与风险计划的目标一一对应,以保证行动覆盖全部目标,防止盲目性与偏差,需要遵循以下准则:

考虑更巧妙地工作;挑战自己,找出更完美的方式;充分利用机会;适应新情况;不要忽略常识;

对照计划,报告进展:必须报告风险应对的工作结果,确定与交流对照计划所取得的进展;修正与计划的偏差:结果不能令人满意,就必须换用其他途径,必要时还需采取校正行动。校正行动的过程包括:识别问题、评估问题、计划行动和监视进展。

5.6 案例:金融行业使用容灾系统有效应对突发事件

汶川地震带来的思考

2008年5月12日,汶川地震给当地及周边地区造成严重破坏电力、水利和通信设施损失尤为严重。由于当前企业的商业模式对信息系统充分依赖,在设施损毁的同时,企业的信息资产也遭到毁灭性打击,很多企业的业务无法正常进行;在信息化时代,最重要的不是厂房、机械设备和软硬件设施,而是存储与其中的信息资料。信息、数据的丢失成为企业面临的一项重大风险。容灾、备灾作为风险应对的主要措施,已经变得越来越重要了;

雷曼兄弟未雨绸缪

当生产系统的一个完整环境因突发的灾难遭到破坏,为迅速恢复应用系统的数据、环境和运行,需要进建立一个对能应对各种情况的本地或异地的容灾系统,保证企业数据安全和业务连续性;2001年9月11日,美国遭受“911”恐怖袭击,美国企业就意识到信息系统的脆弱。雷曼兄弟在“911”之前就已经考虑到容灾问题,他们在新泽西采用 Citrix XenApp 为远程用户部署了应急程序。灾难发生后,该服务程序为用户提供了应急服务,不仅保证业务得以持续运营,还借此提高运营效率,增强商业竞争力;

国内各大银行积极推进

鉴于银行在国民经济中的重要地位和银行业务对数据实时性的高要求,中国银行业对数据备份一直比较重视;在“911”事件后,国内各大银行经历了信息化基础建设及数据大集中阶段,开始积极着手灾难备份建设;目前,中国的各大银行基本上都有数据级的备份措施,一些银行的备份数据能做到异地存放。

6 风险管理验证

为了克服风险管理计划的缺陷和风险管理实践的不完善,需要实施风险管理验证活动。通过独立审计可以检验风险管理活动与计划的一致性,同时保证项目实施遵循风险管理计划;

评审风险计划:计划的质量在一定程度上决定着结果的质量。因此风险管理验证活动从评审风险计划开始,并为审计一致性做准备。计划应满足如下要素:

完整性可理解性详细程度一致性现实性

审计管理过程:

质量保证负责审计执行者的行为,并向管理层发出有关偏差的警告;针对质量审计,有 ISO9000、SEI-CMM 和 MIL-STD-498 标准;审计报告使项目风险管理实践结果一目了然,其目的是记录评审和审计的结果;项目审计结果总结实施情况,并详细说明与风险管理计划的差异;报告应表明要求是否已经达到以及所存在的差异的实质;

风险管理回报:

风险管理回报(Return OnInvestment,ROI)是所有风险管理的节约除以风险管理活动的总承包;

ROIRM=∑节约成本

\text{ROI}_{RM} = \frac{\sum \text{节约}}{\text{成本}}

ROIRM​=成本∑节约​

风险管理的成本是为风险评估和风险控制投入的所有资源的总和;

约是管理风险的回报,包括避免和减少。

7 案例:风险管理奥运场馆建设

2008年北京奥运会成功举办,全世界看到一个崛起的中国,像鸟巢、水立方等奥运场馆就被各大媒体竞相报道。在巨大成功的背后,是无数中国人勤劳和智慧的付出。2003年,国际奥委会在历史上首次明确要求主办城市奥组委对场馆建设项目进行定期的风险评估。北京奥组委成立了“奥运场馆建设风险研究”课题组,采用风险管理保障奥运场馆的顺利建设;明确风险管理目标:要管理风险,首先要确定风险管理的目标,然后再分析哪些因素会影响目标实现,进而分析这些因素中哪些是重要的,应如何采取措施降低风险。场馆风险管理的目标,主要集中在三个目标上:

奥运场馆建设符合奥运会使用功能及赛后可持续发展利用的建筑;场馆的规划、设计和建造是安全、质量、工期、功能和成本辩证统一的项目群管理过程;尊重生命,保护环境;

风险管理的三个特色:

建立项目群风险管理概念参与整个课题研究的专家规格和规模都是空前的奥运场馆建设风险管理系统联通了指挥部与各个场馆

多方努力汇成过硬成果:通过奥运场馆建设风险管理的研究和风险管理系统的应用,为我国大型工程项目的风险管理积累经验,也对未来的奥运场馆建设提供帮助。

8 案例故事解析

项目失败的原因有很多,其中缺少风险管理是一个重要的原因。在开篇的案例故事中,项目的利润值最后可能是负值的直接原因在于风险控制和风险处理机制上;在很多软件项目中,由于竞争和其他原因造成风险过度集中在相对弱势一方,福清公司一方面需要依赖代理 NaleNet 的网络产品生产,另一方面必须满足用户的具体需求。福清公司忽视的风险和管理过程需要我们引以为戒;

应识别的风险:如果在项目合同签订前,投标方了解自己公司在项目中的位置对投标方提出的要求认真回答,可以规避一些潜在的风险。对于招投标中过高的要求不能完全满足时,应充分说明并考虑以下几点:

合同的类型项目实施方对项目的熟悉程度具有明确的规范

风险的预警和量化:在项目进行过程中,项目经理和客户要将风险管理纳入日常工作,明确成本与风险、成本与时间的关系;

建立管理风险预警机制风险的量化

9 小结

软件风险是导致软件项目进度延迟、预算超支或项目部分/整体失败的原因之一。不确定性和损失是风险的两大属性。风险是项目固有的属性,风险管理就是让项目组在蕴含着风险和契机的环境中演绎成功的行为准则;软件项目风险管理过程是一个不断识别风险、分析风险、计划风险、跟踪风险和应对风险的过程。此外,还需要风险计划和风险管理验证。