美国项目管理大师马克思·怀德曼将项目风险定义为：某一事件发生给项目目标带来不利影响的可能性。通过合适的方法，我们可以增加对风险的掌握度，做到未雨绸缪，在问题发生时能够游刃有余。
风险控制要落实到项目计划中
风险识别出来了，没有落实到项目计划中，没有具体措施去执行，就好比敌人兵临城下，你的城门还在大开。
比如，项目中的一个模块开发给了一家新的外包公司，这家新公司的开发水平就是一个风险因素，我们在列风险清单时会将这项列进去，并在计划中增加“加强沟通，及时检查”等计划。但“加强”、“及时”这些词都太笼统了，没有分解成可执行的工作包，最好将计划分解，用量化体现，看一眼就知道该怎么做。
比如以前和外包公司一周开一次会，现在改成一周三次（两次电话会议、一次视频会议；以前只在里程碑节点进行验收，现在每一个任务节点都测试性验收，直至供应商的模块最终交付。
风险控制一定要落实到具体工作中，用WBS体现，有时候项目完成依靠的不是别的，恰好是看似死板、规规矩矩的风险控制计划。
风险控制要有合理的流程和机制
风险控制是一个长期的过程，它需要合理的流程和机制来支撑。
比如你要请一个国外专家来调试设备，专家口头承诺了你，但你意识到，如果专家不来，将对项目进度产生很大的负面影响。这时候有以下两种解决方案：
尽量获得专家的正式承诺，并通过邮件等形式确定时间和行程。
把这件事写进风险清单，开会的时候进行讨论，并确定专家来不了的解决方案
第一种是个人行为，可能比较高效。我们通过自己的努力把专家请来了，得到了老板的表扬和认可，但风险也同时存在，万一到最后专家变卦了呢？这是个人行为，需要个人负责。第二种是公司行为，我们经过开会，确定了专家来不了的解决方案，即使发生变故，也能拿出Plan B。
当你每天忙的昏天黑地的时候，很多事情会被忽略，合理的流程和机制才能保障项目经理的安全。
风险控制根植于周期汇报中
周期汇报是项目控制的一个基础过程，而风险控制是其中一个非常重要的环节。
比如，在每周的例会上，我们把风险清单上的问题拿出来讨论一遍，虽然很烦琐，但一定不能忽略，保证有问题尽在掌握之中。没有新问题出现的时候用不了很长时间，即使有问题出现，团队成员也能及时知道。在一次又一次的风险讨论中，它们会被“大事化小，小事化了”。
很多事情事到临头是没有解决方案的，但提前了解就会有解决方案。风险控制不能保证问题不出现，但可以保证在问题出现的最早时间就了解，及时做出应对。
我们虽不能让风险消失，但可以减少它的不利影响，把风险落实到计划中，遵循合理的流程和机制，在汇报中定期体现，在风险出现的时候，找到能替代它的Plan B。
