极客时间已完结课程限时免费阅读

10 | 风险管理:冰山下的风险,如何系统化应对?

10 | 风险管理:冰山下的风险,如何系统化应对?-极客时间

10 | 风险管理:冰山下的风险,如何系统化应对?

讲述:雷蓓蓓

时长16:05大小14.69M

你好,我是雷蓓蓓,今天我们来聊一聊风险管理。
艾文所在的项目已经进行到中期了,目前来看进行得很顺利,不过她内心却有些隐隐的不安:“蓓蓓,你知道吗,项目现在进展得越是平稳,我越觉得不安。我担心项目会不会存在什么风险,而自己却没有发现。”
事实上,艾文这种担心是十分必要的,因为项目从构思的那一刻起,就存在着风险。不过光担心没有用,作为项目管理人员,需要做的是识别风险,以便更好地应对,甚至将可能出现的风险,尽早扼杀在摇篮里。
因为项目风险是一种不确定的事件或条件,一旦发生,就会对至少一个项目目标造成影响,比如范围、进度、成本、质量等。除此之外,项目风险也可能对组织或组织的目标造成影响,比如财务、声誉等。
而应对风险的方式,并不总是规避。如果风险给项目造成的威胁在可以承受的范围内,并且与可能得到的收获是相平衡的,那么这个风险就是可以接受的。
要想在充满不确定性的大环境下取得成功,组织应该致力于在整个项目期间,积极而又持续地开展风险管理。这个时候,如何识别风险,以及如何应对风险,就显得尤为重要了。那么这些,也正是这节课我想和你分享的内容。

系统化风险识别

风险识别的主体,应该包含项目中的团队成员在内的各方干系人,而不只是项目经理。组织中的每个层级,都必须有意识地积极识别,并有效管理风险。系统化的风险识别,是一个反复进行的过程,应该从项目构思阶段开始,贯穿规划和执行的始终。
结合执行中常见的各类风险,我给出了一份项目典型风险列表。你可以对照这个风险清单,对你的项目情境下可能出现的风险,进行概率及影响程度的量化分析,形成你的初始风险清单。
识别风险过程的主要输出,就是初始的风险登记册,包括已识别的风险清单,以及潜在应对措施清单。对于已识别的每个风险,都要评估其概率和影响,并进行优先排序
来自《项目管理知识体系指南》
其中,风险概率是指每个具体风险发生的可能性,风险影响则是风险对于项目目标(进度、成本、范围、质量)的潜在影响。上图中是《项目管理知识体系指南》中给出的,风险对项目目标影响程度的评估量表,你可以对照量表来计算相应的风险指数,比如造成成本增加大于 40%、进度拖延大于 20% 的风险,属于最高影响程度级别,风险指数为 0.80。
你可以通过访谈或会议的形式来进行风险概率和影响的评估,参与人员包括熟悉相应风险类别的人员,以及项目外部的经验丰富人员。以下是一个风险登记册的示例:

冰山下的风险

实际上,执行中最大的风险,不是那些显而易见的风险,而是冰山下看不见的风险,往往才是最要命的。通常,项目组中最坏的情况是,大家对项目里的风险避而不谈。原因可能是:
缺乏风险的沟通渠道;
提出来也没有用;
老板会认为我没能力管好当前的项目。
试想一下,你的项目中鼓励坦诚沟通项目的风险吗?你的项目中有恰当的程序和渠道,可以让你跟干系人沟通项目风险吗?
没有人反馈风险,不代表没有风险。我曾经见过一个项目组,在某个时间段,他们的业务迅猛扩张,临时招了一大批实习生,从事内容基础建设工作。日常工作时,管理者只是把任务交待下去,不进行深度沟通。再加上业务繁忙,很少有人带这些实习生,他们逐渐就形成了一个与外界隔绝的小集体。直到一次重要里程碑交付前,大量实习生离职,影响到了部门重要 KPI 的达成,这个问题才引起了部门的管理层关注。
如果一个项目经理只能依靠正常的渠道识别项目风险,那么这类问题就不可避免。但所以我们就需要那该如何识别冰山下的风险呢?
其实,当寻常的渠道不管用的时候,就要看 PM 的信息网络了。项目经理一定不能脱离团队,如果没有群众基础,只是坐等着别人给你上报风险,那你的工作就远远没有做到位。一个优秀的项目经理,必须是一个优秀的“情报人员”,上至最高的项目发起人及组织各层决策者,下至项目最边缘的人群,比如外包、实习生、短期借调支持人员等,你都要跟他们建立广泛且深入的联系。
你可能会问:“我这个人不擅长人际交往,那是不是就没办法做到这些呢?”当然不是。我们有很多内向型的项目经理,也做得非常好。其实,你需要的是一颗真诚交流的心,去关注项目中的每个角色、每个成员的需求,理解他们的困难,愿意为他们提供发展的机会,帮助他们去获得更大的成功,仅此而已。
如果说,你还需要一个简单有效的办法,那就先去观察下,你的团队在吃饭的时候都会分成哪些群体。这些自然划分的群体中,哪些是你经常交流的?哪些是你缺少交流的?在工作之余,你要多关注下和你缺少交流的群体,抽时间和他们多吃饭多沟通,让自己站在他们的视角想问题。这样一来,很快你就可以扩展自己对于冰山下项目风险的理解。
记住,你识别出的风险越多,项目的风险就越低。

风险应对措施

接下来,你需要为识别出的每个风险,制定相应的风险应对措施。对于发生概率很高的严重风险,一定要提前准备风险应对方案和危机应急预案,一旦风险和危机来临,应急预案就可以有效地降低风险的损失和危机的灾难。
比如“双十一”之前的故障演练应急预案,你就需要针对每一种可能发生的线上突发状况,提前确定好处理步骤、责任人、预计时长,甚至是每一步的指令或脚本,以免在出现突发问题时,手忙脚乱导致出错。
同时,在项目排期时,确保有相应的故障演练计划,做好充足的准备。也许有些风险预案永远也用不上,但是这并不是说它们是多余的。在风险降临的危机关头,它们的价值就会凸显出来。
在项目执行期间,已识别的风险会不断地变化,新的风险也会产生,你需要在每周的项目状态同步会议上,对风险进行再评估,并通过周期性的风险审查,来识别新的风险

树立正确的风险观

治未病,建立系统性保健机制

举世瞩目的“阿波罗”登月计划,让项目管理开始风靡全球。当时的肯尼迪航天中心,流传着两个很有意思的黑话:沙包、打伞。
“沙包”指的是把任务的延期藏起来,不到最后一刻不做汇报;
“打伞”是说虽然你延期了,但还有更倒霉的家伙也延期了,而且率先被暴露出来。
你看,即便在“阿波罗”计划里,瞒报延迟、寄希望于他人“打伞”也是无法杜绝的事情。
可是,为什么那么多瞒报呢?因为在当时,及时汇报延期往往只会招来一顿责骂。实际上,越是严格控制的系统,越是有问题都窝着藏着,很可能一出问题就是大问题。事物的发展,总是从量变开始的。为了防止风险演变成问题,就要在项目早期,建立系统性的保健机制。所谓的“治未病”,就是说要未病先防,事后不如事中控制,事中不如事前控制。
“春江水暖鸭先知”,关于执行中的风险,群众永远是最有发言权的。如果这个系统是健康的,一定是可以自行去呈现和反馈风险的。而建立系统性保障机制的关键就在于,你要致力于持续改善人与人之间的互动品质,提升项目团队的健康度。
经常做匿名的问卷收集或访谈,定期做一场坦诚布公的复盘会,都是系统性保健的好方法。
调查问卷的方式,是项目经理了解团队的重要方式之一。在每个重要版本结束时,你都可以用调查问卷的形式,收集大家的意见,其中有两个典型的问题:
对这个版本研发过程的综合评分(包括迭代方式、工作量、工作压力、团队配合、时间管理等各个方面),这反映了过程满意度;
对这个版本功能设计的满意度,即产品认可度。
你要坚持在多个版本中反复使用,积累数据。这样一来,你就可以通过各个版本的数据变化,看到团队状态的起伏和健康度的走势。当团队对产品的发展方向产生疑虑或不认可,或是对过程中的管理方式或协作状态不满时,你要允许团队各抒己见,充分沟通表达。事先预防永远胜过事后纠正,如果你有意识地在团队中构建这样的常规反馈渠道,系统性风险提示和保健的作用就会逐渐发挥出来。
上医治未病,如果你还不具备“望闻问切”的功力,那么匿名问卷,就是一个非常简单的措施,你一定可以做到。

积极管理致命风险

其实,项目经理不只是要管理好常规执行风险就可以了,真正会导致项目失败的致命风险,在项目一开始就埋下了。比如,公司高层对于项目的态度和预期、项目目标与组织战略目标的一致性、项目所依赖的重要资源方的合作关系、竞争对手及行业市场状况的变化、政策变化或监管风险等。
我作为项目经理的第一个项目,开工半年多就被紧急叫停,这让我对项目的致命风险有了深刻的体感。要管理好这些致命风险,确实不是仅凭项目经理一人之力就可以做到的。但是,如果我们只是一直做容易的事,做会做的事,对这些致命风险视而不见,就会把项目置身于危险的境地。
一旦致命风险真的发生,很可能会回天乏力。有经验的项目经理,可以从过往经历的失败中,敏锐地嗅到危险的味道。那么,项目经理可以做些什么呢?
挖掘出这些致命风险,把它们变为可见的、可谈的。很多管理者非常关心执行中的风险,却对于这类致命风险讳莫如深,只留在自己脑子里,这样反而是最危险的。致命风险的挖掘,通常会让我们对于项目背景的理解更加透彻,并对那些影响到项目生死存亡的关键要事,有更加清晰的认知和规划部署。
正视风险,不存侥幸心理。你要和发起人一起想办法,发动核心团队,合力去制定应对策略。
在项目核心团队中,周期性地梳理和同步风险状态。
其实在互联网领域,真正成功突围者大多都是一路坎坷,从各种致命风险中爬出来,九死一生。致命风险的存在,本身就是一种警醒。加速构建核心能力,不断拓宽护城河,才是最根本的应对之道

总结

总结一下,今天,我给你介绍了系统化风险识别的方法,以及项目典型风险列表。根据风险概率和影响,你需要召集项目组成员完成风险登记册以及风险具体评估,制定相应的风险应对措施及应急预案,同时对冰山下的风险保持敏感。
实际上,风险是一种不确定的事件或条件,用辩证的眼光看,风险的另外一面就是“机”。互联网领域的产品创新,大多是一场跳进未知的冒险,这给传统的风险观带来了极大的冲击。在项目管理的过程中,步步为营的风险管理之外,积极把握不确定性带来的机会,提升系统的反脆弱能力,达到最优的效果,是项目经理需要持续修炼的功课。

畅所欲言

最后,我想请你来聊一聊,你自己所在的项目组中,是否存冰山下的风险?你有哪些识别风险的好办法?
欢迎你畅所欲言,我在留言区等你,也欢迎你把文章分享给你的朋友。
分享给需要的人,Ta购买本课程,你将得18
生成海报并分享

赞 30

提建议

上一篇
09 | 需求变更:三个锦囊,让需求变更不再是洪水猛兽
下一篇
11 | 质量管理:层层卡点,一次把事情做对
unpreview
 写留言

精选留言(28)

  • 穷查理
    2019-11-19
    我当前参与的一个项目主要风险如下: 1、不可控因素太多,功能集成和需求设计严重依赖其他部门; 2、项目发起人始终不知道自己想要的产品是什么样的,每次询问,就说让开发自己去想; 目前主要风险识别途径: 1、组织“吐槽大会”; 2、找一两个小伙伴小规模沟通; 3、每日困难反馈。
    展开
    11
  • Cy23
    2019-11-19
    原来风险管理里填写的内容,我一直不知道怎么填写,写的都是自己因为可能会影响项目进度的事件,虽然填写的都是正规风险管理的表格,听完你的课,感觉自己写的不够饱满、没有层次、不够系统。回头再有机会写的时候,我会回来复盘的。
    10
  • 小文同学
    2019-12-05
    旧上司曾经说过:不上线的项目说明不了任何技术问题。 前几周对外测试开发了大半年的项目,各种异常和警报不断,正是这篇专栏所提及的风险管理不足的问题。我认真浏览了 风险清单,逐一对照后,发觉项目和团队都存在很多的bug。昨晚临时开会提出了内部沟通问题,今天看了清单,觉得得马上再开一次会。泪崩... 最近算是不断地吃了缺少项目管理经验的亏,今年的开发经历还是让自己成长了很多,在年末可以有蓓蓓姐的专栏辅助整理一年的经历,非常幸运。 现在项目的风险很多: 1、沟通成本过高; 2、人员默契不足,太新; 3、工作流程没被完善和强调,很多问题依靠核心人员的决策而不是流程自动驱使人员去闭环一个个的问题; 4、技术问题上:作为负责人技术构建的框架过于灵活,导致学习成本高,代码审核的难度过大,应该限制灵活性,强调规范。 5、发布工具不足,人手操作,容易手抖。 .... 简直是太多了,项目确实出于危急的状态,希望最后一切能够顺利度过
    展开

    作者回复: 路要一步一步走,待办清单要一个一个done!

    共 2 条评论
    7
  • quietwater
    2019-12-15
    关于团队内部风险的收集,团队氛围很重要,开放的心态,公开透明,这样才能畅所欲言。 外部风险主要来自需求的变化,需求分析,验收标准,运营数据,持续反馈,提高需求的质量才是根本。

    作者回复: 对的

    5
  • Raymond吕
    2019-12-24
    其实只要不是关系生命安全的领域,风险管理的与追求利益和交付往往更重要。 并不是风险管理不重要,而是团队里很少有人对“风险管理”这件事有深入的了解和思考。 先明确风险管理的范围,就是要管理可控的风险,什么是可控的?可控的就是系统中发生的。而不可控的事系统外,比如政策、市场、竞争对手等等。 总之,我认为PM先要对系统中的风险进行梳理,评估概率和影响,制定应对措施,形成风险登记册,并在项目过程中持续更新风险登记册,总结经验。
    展开
    共 1 条评论
    3
  • 源以南
    2020-11-07
    识别各个干系人,让我想到了以前在做项目的过程中,有一个大牛跟我说过,在干系人中哪一类的人是最需要被关注的。一定是那个对你项目会造成阻力的人,是需要被特别关注的。因为他有可能会使你的项目失败,所以说这类的人要特别进行管理是一个系统性风险。
    2
  • 牺牲
    2020-04-13
    之前经常听说计划中的末项风险预估,绞尽脑汁也想不出来有哪些风险,怎么预估,又如何来应对。 这篇内容简直打开了新世界,从风险列表,到等级,再到应对措施,全面解答了我对风险的疑问。 我们项目并没有专职的项目经理,而是业务经理、产品或者技术负责人来关注项目整体状况。而这些职位来做项目经理,可谓都是二把刀。没有系统地做风险管理,就是最大的风险。 每篇课程都是三遍起步,能够尽可能的理解透,做到学以致用,举一反三。
    展开
    2
  • 霸波儿奔
    2019-11-19
    项目中有遇到过需求考虑不充分,调整某一块的功能时,未考虑其它模块,需求评估测试不充分,着急上线,导致某个需求上线后其它模块一堆问题 风险识别最重要的还是做好与项目干系人沟通,做好需求评审和项目上线前的代码评估

    作者回复: 对的,通常最大的风险都来自于需求环节,风险管理重在早期。

    共 2 条评论
    2
  • zhengxm_16
    2021-07-24
    风险管理与质量管理一样都是项目管理关注领域里庞大到可以独立成为一个单独学科的话题。项目经理的风险管理能力强与弱确实是一个项目成败的关键因素之一!
    1
  • 谭鹏
    2020-07-07
    我个人的看法 项目三要素 范围 时间 成本 那么识别风险就可以从三要素入手。 是否变更了范围。是否增加了时间。是否增大了成本 一步一步细化的去识别和挖掘
    1
  • 三寸光阴
    2019-12-27
    现在手上项目的主要风险: 1、产品规划不清晰,2、项目启动人指定的架构师未符合项目预期;3、需求沟通成本高 主要风险识别途径: 1、从类似项目的总结经验对照,2、定期复盘回顾
    1
  • maks
    2019-11-20
    蓓格格,你好,在文中你给出了风险评级,但是风险指数如何计算呢? 例如 成本等. 我对今天风险管理的理解: 风险管理有点类似 软件开发过程中最佳实践 -- 问题越早暴露越好. 对于上级来说早知道总比晚知道要好, 对于下级来说早汇报也比晚汇报要好, 至于说担心被BOOS或上级认为自己能力不足? 这一点在我看来完全是不必要的担心,因为就算你隐瞒不报,那么问题还是问题.它还会在哪里,并不会消失不见. 与其寄希望与在别人发现它之前改掉,倒不如提前汇报上去,然后加紧改掉 如此就算万一你在规定时间内没有完成整改导致问题爆发,那对于上级来说他也早有准备. 如果你在规定时间内规避掉了风险,那么上级说不定会对你的能力高看一层
    展开

    作者回复: 风险指数 = 风险发生的概率 × 风险发生后造成的影响,其中风险对进度、质量、成本、范围的影响程度判定,可以参考我在文中给出的量表。

    1
  • 桃子-夏勇杰
    2019-11-19
    面对风险需要勇气
    1
  • leslie
    2019-11-19
    风险管理源自何处?好的监控才能做好风险管理。 我们经常说系统风险。。。风险各种风险,可是任何事情都是有风险的,其实对于风险我们应当如下方式去看待:首先应当确认它有多大的风险,其次对于风险有哪些监控措施/预防措施,最后风险发生了处理风险的流程是怎样。只有整体且全面认识风险,我们才能处理好风险。 以上是个人对此的一些薄见:期待老师下次的分享。
    展开

    作者回复: Bingo!

    1
  • 吃藕大哥
    2022-09-23 来自湖南
    把部分风险提前识别出来,防止风险成长为脱离控制的“斗士”。
  • Geek6792
    2022-02-11
    最近遇到了一件事,某项目前期是另一个同事跟进的,过程中他将我们这个子系统的排期调整了,该调整会导致项目不能如期交付,但是他没有上报,这个阶段我也没有参与。后来他把项目交给我,我拿到的就是他改过之后的排期,并且按照这个排期在推进。直到领导按照原有排期来找我要东西,我才发现这么大的问题,并且作为背锅侠被项目经理批评了”有延期为什么没有及时反馈“。这种风险该如何识别?
  • 小木房
    2021-11-10
    可以推荐一个考项目管理,产品经理证书的机构咩
  • Terry郑💫
    2021-10-19
    有些不可控的风险确实是高层紧急叫停,或者因政策变化导致的不可预测。要积极对待出现的这种情况。
  • 2021-07-23
    说的好,项目中的风险 日常参与者最有亲身体会。可是管理层往往最容易忽略他们的声音。 前几课也有提到"闭环"的重要性。我觉得这就是信息层面的闭环。
  • leesper
    2021-01-27
    故明君贤将,能以上智为间者,必成大功。此兵之要,三军之所恃而动也。