项目风险管理相对于企业全面风险管理,主要关注项目范围之内的风险,所关注风险相对比较具体,涉及总的影响范围较小,一般地采用定性分析方法。在定性项目风险管理中,本文指出了五个方面的问题,并给出了对策。
项目风险管理问题一、用词
各大标准/最佳实践中也都有项目风险管理的内容,其中用词并不一致。在多个标准/最佳实践的导入中产生了由于用词理解不一致而发生的误解,在业界交流讨论时也多有不便。
风险,没有其它用词,但本身有二个不同含义:一种定义强调了风险表现为不确定性;而另一种定义则强调风险表现为损失的不确定性。这二个不同含义简直就是导致用词不一致的根源。现在大多数标准采用第一种定义,但停留在各级经理人头脑中的定义仍是第二种
风险管理,在有些地方又叫“危机管理”,不过一般对危机管理的理解与风险管理并不一样,危机管理更偏重于危机发生后的管理。
风险应对,在PMP中是指在风险识别以后到风险触发或关闭之间采取的促使风险向有利方面转化的方案和措施,在CMMI中相应的词是“风险缓解”,也有地方用“风险处置”,“风险处理”。本文下文中使用“风险应对”。
风险应急应对,在PMP中“对某些特定事件,专门设计一些应对措施。对于有些风险,项目团队可以制定应急应对策略,即只有在某些预定条件发生时才能实施的应对计划。如果确信风险的发生会有充分的预警信号,就应该制定应急应对策略。应该对触发应急策略的事件进行定义和跟踪,如未实现阶段性里程碑,或获得供应商更高程度的重视。”,一般而言,这是指风险触发后或预计必定触发后的方案和措施。其它用词有“风险应变”,“风险应急”。
风险可能性,指风险发生的可能性,其它用词有“风险概率”。
风险影响,指风险发生的冲击,其它用词有“风险影响的程度”,“风险严重级别”。
危险性,其它用词有“风险值”。
接受风险,其它用词有“承受风险”,“保留风险”,“保持风险”。
避免风险,有“回避风险”,“规避风险”。
转移风险,有偏转风险
减轻风险,有“缓解风险”,“控制风险”,“降低风险”注意:与前文有冲突。
风险触发器,其它用词有“风险征兆”,“警示信号”。
对此问题,对策是在一定的组织范围内对风险用词给出定义,比如在风险管理规程中专门进行词汇定义。
项目风险管理问题二、认识
20世纪80年代,软件项目风险管理之父Boehm将项目风险管理的概念引入软件界。Boehm认为:软件项目风险管理这门学科的出现就是试图将影响项目成功的风险形式化为一组易用的原则和实践的集合,目标是在风险成为软件项目返工的主要因素并由此威胁到项目的成功运作前,识别、描述并消除这些风险项。
在CMMI过程域中,项目风险管理过程域是关联度最高的过程域之一。与项目风险管理明确相关的过程域目标有:
1,需求分析过程域的特定目标3:分析并确认需求
2,需求管理过程域的特定目标1:管理需求
3,项目计划过程域的特定目标2:建立和维护开发项目计划
4,项目监控过程域的SG1:按照计划监控项目
5,供应商管理过程域的SG1:建立供应商协议
6,集成项目管理过程域的SG1:使用项目定义过程
7,技术解决方案过程域的SG1:选择产品组件解决方案
8,决策分析及决议过程域的SG1:评估备选方案
9,产品集成过程域的SG1:准备产品集成
10,组织过程焦点过程域的SG2:策划与执行过程改进
11,组织培训过程域的SG1:建立组织培训能力
等等不完全列举
在PMP中,项目风险管理是9大领域之一。
从以上大师的论述、CMMI的相关性、PMP中的篇幅,可以充分看到项目风险管理的重要性。
项目风险管理问题三、风险的表述
风险在表述时,用多个属性来综合说明风险的全部内容,常见的风险属性有:标题、说明、负责人、应对措施、时间要求、风险概率、风险影响度等等。
必备的属性有标题和说明(也有称为描述)
常见的一个突出问题是没有对风险的标题给出指导或要求,各项目识别的风险标题差异明显,如下面的例子:
存在工期延误的风险
过多的支持工作占用工作量可能导致工期延误
频繁的需求变更可能导致项目规模变大,成本超支,工期超期,人员士气低落而离职
频繁的需求变更、过多的故障现场支持还有人员意外离职都可能导致项目工期延误
类似第一个风险标题,没有说明风险来源,只说了后果,在实践中有如下不利之处:
不能直观理解,仅从标题不难了解可能的困难。
在风险的说明中,把多个风险来源写在一起,相应的应对措施也放在一起,不利于分别跟踪,可能导致只跟踪了部分诱发困素。
风险难于高效地有效地跟踪到关闭,由于多种风险来源能够导致相同的后果,风险长期得不到关闭,会产生风险麻痹。
类似第二个风险标题,说明了一个风险来源及相应的一个后果,这样应对措施可以针对这个诱发困素,应变计划针对这个后果,可以高效且有效的跟踪风险直到关闭。
类似第三个风险标题,说明了一个风险来源及相应的多个后果,这样应对措施可以针对这个风险来源,由于是同一因素引发的后果,应变计划虽然要处理多个后果,但是相对应容易制订。在着重预防的风险应对中,能够清晰识别并管理应对措施,也是不错的做法。
类似第四个风险标题,说明子多个风险来源及相应的一个后果,这个写法的不利之处与第一种写法相似,相对好一点的地方是限定了风险来源的范围,但总得说来,也是不推荐的写法。
对此问题,对策是优先采用上述类似第二个风险的写法,可以采用上述类似第三个风险的写法。
项目风险管理问题四、风险的跟踪
常见的风险跟踪问题主要有二类:第一类是轻视项目风险管理;第二类是没有预先考虑风险发生的条件。
对于第一类问题,主要发现为风险不及时跟踪,过程中不主动识别,认识问题是主因。前期加强宣导、培训,在过程中保持关注,恰当地进行监督是这类问题的对策。
对于第二类问题,过程中的风险发展是一个渐变的过程,有些风险的渐变比较缓慢,因此在风险跟踪中比较容易错过采取措施的第一时间。所以预先考虑风险发生的条件是很有必要的,做法是设立风险触发器,风险触发器说明风险已经发生或者将必然发生。比如对于第3章中第2个例子,风险触发器可以是“当连续两周支持工作量比重超过了50%”,或者是“到X年X月X日,累计支持工作量比重超过40%”。风险触发器中设立日期期限是个推荐的做法,这样会较容易监控这个触发器。为争取第一时间,风险触发器设立时,应优先更注预警信号。比如对于第3章中第3个例子,触发器1设成这样“一期工程完工日期较计划延迟二周”,触发器2是这样“变更后的项目规模超过了原计划估模的130%”,比较一下就发现,触发器2是能更早地捕捉风险的发生,也就能更多地争取到时间和调整空间。
项目风险管理问题五、可操作性
风险识别之后的应对措施是保证风险向有利方面转化的关键过程。以下是应对措施的实例。
1,加强交流,保持沟通
2,密切注意里程碑工期偏差
3,对新员工开展Java工作流方面的培训
以上应对措施的通病是不具备可操作性,可操作性有三个要素:人员、时间和任务,包括三个要素的应对措施一般来说都是可操作的。改定上述三个实例得下。
1,张三每双周电话联络用户代表李四
2,项目经理每周进行里程碑工期偏差估计
3,王五在6月底之前在Java工作流方面来培训新员工