-风险，不可回避

风险，通俗地讲，就是在项目里可能发生的一件与目标存在偏离且带去不好后果的事情。风险贯穿于整个项目生命周期，无论哪个行业、项目多大规模，只要是项目，就存在风险。

PMI项目管理协会对“项目”是如此定义的：项目是为创造独特的产品、服务或成果而进行的临时性工作。既然是独特的目标，那就意味着每个项目都是独立特有的事务，它不像流水线上的产品生产，有统一的工艺流程和操作手册，每个项目都有自己特有的属性，没有一个项目能完全参照其他项目的经验和方法去实现目标。从这层意义上来讲，项目本身是特别的、不确定的，它从一开始就伴随着各种风险发生，而项目管理中的成本、计划、资源、质量、沟通、干系人等常用的管理手段，本质上也是围绕控制项目不确定性而展开的工作。

所有参与项目的人员，都应该认识到项目风险产生的客观规律。

 

-管控风险比识别风险更重要

对项目经理而言，经常会谈“风险”色变，没有一个项目会随个人意志去发展变化，一旦识别到风险，项目经理就需要耗费大量的精力去规避它发生，或者降低它发生的概率。

识别风险很重要，能体现一个项目管理者或项目经理的专业素养，但识别项目风险往往可以从以往项目经验中获得，发现问题固然重要，但管控风险才是正视和解决问题的核心要义，管控风险是检验一个项目管理者的核心竞争能力之一。项目非常符合“熵增”定律，也就是说，项目如果任由它发展，不加任何人为干涉，那它最后一定是混乱无序的，甚至将走向灭亡，风险就是项目中那些我们不太容易觉察的“熵”，如果不强加管控，风险将由小变大，甚至会对项目后果产生无法估量的严重后果。

及时有效的管控能降低风险发生概率，甚至可以做到完全解除风险。

 

-如何管控项目中的风险

作为一个在政府行业信息化领域从业近十年的项目管理者，分享一些个人对项目的风险管控的经验和技巧，以供同行者交流学习：

1、风险登记

风险伴随项目整个生命周期，项目经理需要随时随地做好风险登记，这是做好风险管理的第一步。我个人喜欢建立个风险小手册，文档、表格形式不限，在风险识别上，不放过任何一点可能引起项目负偏离的风险，及时登记在册，后面再根据否对里程碑成本等项目基线造成影响、判断是否有客情问题等因素，决定是否转换为正式风险。很多项目经理没有养成风险随手登记的习惯，在后期风险真正出现时，延误了风险规避的最佳时机，不得已用更多的代价去弥补风险造成的影响。

如果组织有条件，提供线上项目管理系统，最好将平时的风险、问题都一一进行及时登记。相比离线的小手册，系统管理风险可确保信息长时间存储和共享，便于项目后期复盘和追溯。

2、风险定义和上升

风险不能只停留在自己的小手册上，风险需要正式定义，根据影响范围决定是否上升。在风险定义上，主要考虑几方面：

• 风险类型

从风险产生来源和类型来看，大概有以下几类：

客户侧：需求变更、基础环境未准备、拖欠验收等；

交付侧：交付延期、预算不足、人员离岗等；

产品侧：产品质量问题、国产化适配等；

供应侧：供应商能力不足、外包成本增加等。

• 风险等级

    建立风险等级，将风险定义低、中、高。低风险/中风险在项目组传阅，高风险上升领导层面。

• 状态

新建、挂起、关闭。

• 责任人

风险务必要建立责任到人，如产品侧的风险需要指定到产品经理，客户侧的风险指定到销售经理等。

• 影响范围

判断风险可能引起项目基线发生偏离的地方，主要有范围、里程碑、成本、质量几方面。

• 描述

风险描述尽量全面，表达简明扼要。特别是在公司项目较多的情况下，为便于领导领导对上升风险一目了然，降低二次沟通成本，推荐使用“5W”表达法，即：

Why：为什么会产生？告知风险发生的背景。

When：什么时间发生？明确风险发生的项目阶段。

Who：谁参与了？了解引起风险的主要参与者。

Where：在哪儿做？发生地点。

What：做了什么？影响到了什么？分析风险具体影响范畴。

• 措施和跟进

根据内部协商情况，制定风险应对措施。可以晚，但不能没有。

同时，做好风险定期跟踪，每周对高风险更新进展信息。

 

当判定为高风险，可能对项目造成重大影响的高风险，项目经理及时上升到管理层，做好风险预警，推动领导层进行相关干预，如资源调度、商务决策。

风险上升触发最好以邮件形式正式知会到管理层，有条件的可通过线上项目管理系统将风险发送给领导。

3、售前阶段风险管理

在大多数组织的分工界面上，前端负责完成招投标和合同签订后，项目交付和实施任务就会交接给项目经理。合同签订转向交付，在与前端进行合同交接过程中，除了确认合同目标、客户、需求等基本信息之外，务必要和前端了解对齐当前项目存在的风险，决不能将隐患藏着掖着。比如，一些客户提的系统需求并未体现在合同指标上，项目经理要充分基于合同建立基准需求，合同之外的需求从技术难度、工作量需要内部做好沟通确认，以邮件同步项目组，邮件内容要明确指出合同交接的风险点。

4、典型风险处理思路

场景1：客户侧需求变更或蔓延

整体思路：评估变更影响范围，超出边界优先变更合同

首先分析判断客户需求是否在合同范畴内，如果明显超出合同范畴，对项目工期、执行成本影响较大，从合同履约上优先要求商务侧推动客户进行合同变更。

如果需求对成本和进度影响范围可控，本着服务客户原则，可酌情响应。但需做好变更管理动作，对外做好客户预期管理，不过度吹嘘夸大效果，明确需求变更对进度的影响，务必将需求变更以邮件或变更函发到客户侧。对内要发起变更或报备流程，更新里程碑。

场景2、交付质量引起无法交付

整体思路：内部及时调整资源

第一，因质量问题无法交付存在很多情况，比如我方作为研制方，前期对技术难度评估不足，导致成果不符合客户要求，这种情况在公司内务必升级，向上级争取更高级的技术资源进行补救；如果是供应商/合作伙伴能力不足，重新评估合作伙伴能力，推动采购部门果断替换合作伙伴。

第二，这类问题本质上是售前阶段缺少风险管控， 1、售前阶段交付团队是否参与售前决策，对技术可行性、资源配置合理性以及风险点都需要进行全方位评估；2、交付团队核心成员尽量参与客户需求调研，防止过度承诺情况发生，发现情况及时将风险透传内部；3、起草合同的技术部分要具体，指标可量化，切勿模棱两可，需要技术团队评审。

【后言】

项目管理是一门实践的艺术，没有统一标准和模板，成功的项目肯定离不开科学有效的风险管控，希望大家在项目管理这条大道上勇于探索，大胆创新。

以上内容皆个人经验之谈，如有不同意见欢迎留言指教。