应该重视项目管理中的风险管理

  以我不长的项目管理经历来看,很多软件开发项目在实施过程中是没有风险管理的,我作为甲方项目联系人,目前在跟这个项目,进度要求很紧,面临着太多的风险,如果不搞好,我估计得吃不了兜着走,我也头一次感受到了风险的压力。

  记得有人和我聊过一次风险管理,他和我说项目管理就是风险管理,因为在理想状态下,项目里每一个人都知道该干什么,都按着计划执行,这时候不需要管理,但事实是,任何一个项目,都会因各种各样的原因,造成进度的延迟,而太多的延迟往往造成了项目的失败。这些原因也就是所谓的风险。

  有些人也许对风险的概念不能理解,我一开始也是,直到有一天我读到一个例子,这个例子是:比如一个体育场,在正常情况下,供电应该是正常的,但存在着停电的可能,对体育场来说,这个风险就是:有可能停电,这时候就有两个途径,一是体育场的业务没这么重要,就算停电也没什么大不了,这种情况下就可以不管这个风险。二是体育场的业务绝对不能容忍停电的发生,这时候就必然需要建设后备电力系统,第二种就是规避风险的手段,同时也可以看到,规避风险带来了项目成本的上升。我认为这是一个很典型的例子了,大家分析风险的时候,可以想想这个例子。

  通过这个例子,也许对风险就有了更客观的认识,这个例子应该也可以从某个方面证明风险管理的重要性,除非一个项目没有进度要求,否则项目管理就势在必行,我们真的应该把风险管理当做项目管理里最重要的部分来认真处理。具体理论上的东西下面我整理的资料里也有说明。

  我也找了一些关于风险管理的资料,挺杂的,我摘录一下,自己喷一些,总结在下面:

  一、风险管理概述:软件项目风险是指在软件开发过程中遇到的预算和进度等方面的问题以及这些问题对软件项目的影响。项目风险管理是指为了最好的达到项目的目标,识别、分配、应对项目生命周期内风险的科学与艺术(我渐渐感觉到真是门艺术)。项目风险管理的目标是使潜在机会或回报最大化,使潜在风险最小化。风险管理涉及四个过程:风险识别、风险量化、风险应对计划的制定和风险监控。风险管理应该贯穿于项目管理的全过程,不是说在项目计划阶段搞个文档,写上几个不痛不痒的风险就打发了,这只是在自欺欺人。

  二、风险管理的一般过程如下:

  (1)风险识别:风险识别包括确定风险的来源,风险产生的条件,描述其风险特征和确定哪些风险事件有可能影响本项目。风险识别不是一次就可以完成的事,应当在项目的自始至终定期进行。

  (2)风险量化:涉及对风险及风险的相互作用的评估,是衡量风险概率和风险对项目目标影响程度的过程。风险量化的基本内容是确定那些事件需要制定应对措施。。

  (3)风险应对计划制定:针对风险量化的结果,为降低项目风险的负面效应制定风险应对策略和技术手段的过程。风险应对计划依据风险管理计划、风险排序、风险认知等依据,得出风险应对计划、剩余风险、次要风险以及为其它过程提供得依据。

  (4)风险监控:涉及整个项目管理过程中的风险进行应对。该过程的输出包括应对风险的纠正措施以及风险管理计划的更新。

  三、风险管理模型:

  微软信息技术风险管理过程
  
  第1步:确定风险。首先要分析风险来源,然后要识别过时的风险、一般风险和关键风险(或顶级风险),确保最重要的风险得以重点关注。信息技术风险可能来源于物理设施、设备、程序、操作流程、管理制度、人为因素等多个方面。
  
  第2步:风险分析。主要包括风险概率分析、风险影响分析和风险严重性分析。风险概率也就是条件实际发生的可能性。风险概率一定大于零,小于百分之百。风险影响衡量结果所导致的负面作用的严重性或损失的大小。风险严重性是风险影响和风险概率相乘的结果。一般来说,风险管理的重点是概率高且影响大的风险,概率高而影响很小或影响很大而概率很低的风险可以做备案处理,但不可忽视小概率事件。
  
  第3步:风险规划。主要任务是制定风险解决方案,包括缓解方案、触发器方案和和应急方案。缓解方案的核心是在风险出现前通过积极的措施最大程度降低风险概率或(和)影响、规避风险直至转移风险。触发器方案的核心是确立风险发生的临界条件。应急方案的核心是在风险发生时如何作出快速反应的一套应急措施。
  
  第4步:风险跟踪。追踪风险的变化,撰写和提交风险状态报告,为续后的决策和行动提供信息支持。主要任务是监测3个方面的变化:触发器值,如果触发器变为真,则需执行应急规划;风险的条件、结果、概率和影响,如果其中任何一个发生更改(或者发现该值不确切),则需对其重新评估;缓解方案的进展, 如果该方案落后于日程或者没有达到预期效果,则需要重新评估。
  
  第5步:风险控制。主要任务是按计划对下述变化作出反应:如果触发器值变为真,则执行应急规划;如果风险变得不相关,则使该风险变为过时风险;如果条件或结果改变了,则需重新执行确定步骤并重新评估该元素;如果概率或影响改变,则重新执行分析步骤来更新分析;如果缓解规划不再适用,则需重新执行规划步骤来检查和修正该规划。

  四、风险的来源:

  软件项目的风险主要包括技术风险、管理风险、组织风险和外部风险。细化下去的话,分别有:

  1、技术风险:采用复杂或高新技术、非常规方法、目标过高和技术标准变化快等。

  2、管理风险:进度和资源配置不合理、计划质量差和项目管理原则使用不当。

  3、组织风险:内部目标不一致,对项目不重视、资金不足、与其他项目资源冲突。

  4、外部风险:法律法规变化、相关接口方变化。

  以上这些,我自己掌握的东西也不多,写下来也就是把学到的这些东西整理整理,尝试着变成自己能够掌握的,懂归懂,等啥时候能够灵活应用的,才真正是自己掌握的东西。

  

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/1673/viewspace-259957/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/1673/viewspace-259957/

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值