该帖子同步发自：(qiaodong的博客  访问该博客)

4.10 企业级的项目风险管理

4.10.1 企业级项目风险管理的职责
对于一个项目来说，如果所有的事情都能够像项目计划中预期的那样顺利执行，项目的实际执行过程与计划之间没有差异，这种理想的情况几乎是不存在的。导致这种差异存在的原因，就是现实世界中的不确定性，风险管理的本质就是关注不确定性并及时处理差异，甚至可以说，项目管理过程的两大基点，就是设定计划基线和管理差异。这是一个控制系统必备的基本功能。
公司、部门（包括相关部门）和项目组，都是项目的重要干系人，都会受到项目成败的直接影响，因此都要关注项目风险，进行风险管理。我们前面已经多次提到，实际的项目是处在一个非常复杂的环境当中，受到方方面面因素的影响。为了在这样一个环境当中能够及时发现风险、缓解风险，能够及时做出决策处理新出现的各种问题，仅凭项目经理往往是不够的，需要方方面面的共同配合。也就是说，企业中所有的相关组织和人员，都看作是项目的资源，都要参与项目的风险管理。特别是企业中项目之外的高层领导，更应具备这种意识，把自身也作为项目的重要参与者，能够运用自身在信息、资源、权力等方面的优势，配合做好项目管理。
首先设想一种理想的情况。如果是在一个管理体系清晰、严谨、规范的企业中，从上到下各个的管理层次，横向各个相关的职能部门，所有的各个工作岗位，他们的职责能够完整的覆盖项目管理所需的各项管理内容，那么此时只需要给所有这些岗位职责增加一条要求，“负责向项目经理及时提供相关信息，并协助项目经理解决问题”。但是，这种理想的情况难得一见，更普遍的情况是需要依赖各方的工作主动性，而非强制的规定。此时就需要项目经理更加主动的去收集信息，项目管理的难度相对就比较大。
这方面一直也没有找到一种非常明确、可行的办法，更多的做法是从企业文化、工作态度方面提出一些要求，例如要求不论是否与本职工作相关，所有知情人必须主动将情况通报相关负责人，至少要向自己的直接上级报告，否则出了问题也难辞其咎，各级管理者在用人方面也将这种沟通的主动性作为一项重要的考察内容，影响人员的聘用、考核与升迁。另一方面，就是在各个具体的项目中，由项目经理结合项目的具体情况，基于识别的项目风险，将各级领导和各相关部门、人员都作为项目的资源，纳入风险管理计划当中，并在项目执行过程中获得各方面的配合。

4.10.2 企业风险管理的不断积累
对于项目经理个人来说，经验的不断积累是非常重要的，见多识广是个人职业发展的重要财富。特别是在风险管理当中，由于风险本身涉及的因素无奇不有，遇到的各种情况也可谓千奇百怪，对于具体的风险的处理，更多要依赖于个人管理的艺术性。而且项目本身的独特性和临时性，又往往难以在项目之间建立必然的联系，使得各个项目当中所取得的经验教训往往也是散落的，只有有心的项目经理会注意收集整理并加以总结，“前事不忘，后事之师”，通过不断的积累使自己不断的提高。这就是个人的知识管理。
同样，对于企业来说，面对不断流动的项目管理队伍，不断成长的新人，这种学习的过程是不可避免的，因此就更是需要将众多项目的经验教训加以积累和借鉴，缩短学习过程，降低学习成本，从而使得企业也能够不断提升整体的项目管理能力，而不是完全依赖于项目经理们的个人水平。
凡是重视企业级能力的管理者，都会重视这些经验教训的收集、整理和总结工作。在项目过程当中，特别是在项目的收尾阶段，会对项目过程“复盘”，对于项目当中遇到的各种风险、问题进行总结分析，对于其中有借鉴价值的部分，就会被收集起来，充实到企业级的知识库当中，补充项目风险识别检查表中的风险点，丰富项目风险缓解方法和应对措施，从而帮助其他的项目经理尽量不要重蹈覆辙。从这一点也可以看出，项目收尾的过程其实很重要，直接关系到企业级的项目管理能力的提升，但是许多企业中都忽视了这一点，到了项目该收尾的时候，项目已经不被关注，项目成员也各奔东西了。

举例：项目风险检查表
某公司在长期的项目管理实践过程中，不断收集、整理项目当中遇到的各种情况，形成风险识别列表，提供给项目经理参考。项目经理在项目管理过程中，可以对照该列表进行检查，帮助识别项目中存在的风险。风险检查表中的风险点被分成几大类，下面是技术风险类别中的部分风险点清单：

该技术对于项目组而言是否是新的；
客户的需求是否需要创建新的算法或输入、输出技术；
待开发的软件是否需要使用新的或未经证实的硬件接口；
待开发的软件是否需要与开发商提供的未经证实的软件产品接口；
待开发的软件是否需要与功能和性能均未在本领域得到证实的数据库系统接口；
产品的需求是否要求采用特定的用户界面；
产品的需求中是否要求开发某些程序构件，这些构件与以前开发的构件完全不同；
项目中是否要求采用新的分析、设计、测试方法；
项目中是否要求使用非传统的软件开发方法；
需求中是否有苛刻的产品性能约束；