233风险管理指南.doc

风险管理指南

1. 目的 2
2. 适用范围 2
3. 术语 2
4. 项目风险管理描述 2
4.1. 风险分类 2
4.2. 风险识别 3
4.3. 风险分析 4
4.4. 风险处理和减缓活动 5
5. 风险监控 6
6. 附录 6
6.1. 项目风险分析列表 6
6.2. 参照资料 9
7. 修订记录 9

1. 目的
描述项目进行过程中可能产生的风险的识别方法，制定预防风险的措施，及风险发生时的解决方法，供项目策划时依据具体项目的状况选择或裁剪使用。由此确定项目采纳科学的风险识别方法，制定具体的预防措施和解决方法，以避免风险的发生，或者当风险发生时，将损失减小到最低程度。 
2. 适用范围
适用于公司的所有合同项目和产品项目, 风险管理贯穿于项目的整个生命周期。 
3. 术语
1) 项目风险：指项目中不利事件发生的不确定性。
2) 软件风险：指软件开发过程中及软件产品本身可能造成的伤害或损失。
3) 风险管理：对项目风险进行识别、分析和处理的过程。 
4. 项目风险管理描述
为了管理项目可能存在的风险，在进行项目策划时，需要进行风险分析，并制订风险管理计划，该计划可作为项目计划的一部分。
风险管理应贯穿于项目工程的始终，它不是项目经理一人的任务，也不是一次性的任务，而是一个迭代的过程，任一项目成员都有责任进行风险管理。

制定风险管理计划包括：风险识别、风险分析、风险处理、风险跟踪。
4.1. 风险分类
要进行风险管理， 先明确项目风险怎么分类。
4.1.1. 按内容分
范围风险：与范围变更有关的风险；
质量风险：影响按照要求的技术性能和质量水平完成任务；
进度风险：影响在预算的时间范围内完成任务；
成本风险：影响在预算的成本范围内完成任务；
技术风险：技术变化；
法律风险：许可权、专利、合同失效、诉讼、不可抗力；
外部可猜测风险：市场风险〔原材料可利用性、需求〕、日常运作〔修理需求〕、环境影响、社会影响、货币变动、通货膨胀、税收；
外部不可猜测风险：规章〔不可猜测的政府干预〕、自然灾害
内部非技术风险：战略风险〔公司的经营战略发生了变化〕、管理风险〔公司管理人员是否成熟等〕。
4.1.2. 按可确定性分
已知风险：如当前测试环境不能满足用户真实使用环境的模拟。
可预知风险：如使用技术存在的缺陷。
不可预知风险：如外购进口设备运输途中可能出现的不能如期到达或损坏的风险。 
4.2. 风险识别
风险识别是管理风险的第一步，即识别整个项目过程中可能存在的风险。一般是依据项目的性质，从潜在的事件及其产生的后果和潜在的后果及其产生的原因来检查风险。收集、整理项目可能的风险并充分征求各方看法后形成项目的《风险和问题跟踪列表》。
【过程管理平台中，填写和维护“风险列表〞
4.2.1. 要进行风险识别的阶段
在项目开始、每个阶段一开始、主要范围变更批准之前都要进行风险识别，实际上它在整个项目生命周期内都是一个连续的过程。
4.2.2. 风险事件或风险来源
要识别风险，就应该了解在项目各个阶段都有可能发生哪些风险。以软件开发为例：
l         初始阶段
这个阶段包括立项和需求分析及《软件需求规格说明书》的制定〔大部分业务建模和需求、少部分分析制定〕。可能的风险事件有：项目目标不清；项目范围不明确〔范围太大太小都不可以〕； 用户参加少或和用户沟通少；对业务了解不够；对需求了解不够等。
l         制定阶段
在这个阶段进行总体制定和具体制定。可能的风险事件有：项目队伍缺乏经验，如缺乏有经验的系统分析员；没有变更控制计划，以至于变更没有依据，该变更的不变，不该变的也变，这样得来的制定势必会失败或者偏离用户需求；仓促计划，可能带来进度方面的风险；漏项，由于制定人员的疏忽某个功能没有合计进去等。
l         实施阶段
在这个阶段进行大部分编码和测试，可能有制定变更或补充制定。可能的风险事件有：开发环境没有具备好；制定错误带来的实施困难；程序员开发能力差，或程序员对开发工具不熟；项目范围改变〔突然要增加或修改一些功能，需要重新合计制定〕；项目进度改变〔要求提前完成任务等〕；人员离开，在一个项目内软件开发工作有一定的连续性，需要移交和交接，有时人员离开对项目的影响会很大；开发团队内部沟通不够，导致程序员对系统制定的理解上有偏差；没有有效的备份方案；没有切实可行的测试计划；测试人员经验不够；没有进行可行性研究等。
l         收尾阶段
在这个阶段进行安装及维护〔大部分布暑〕。可能的风险事件有：质量差；客户不满意；设备没有按时到货；资金不能回收；客户返馈看法引起大的变更等。
4.2.3. 风险识别的方法
不同项目可能发生的风险事件不同，应该对具体项目识别出真正有可能发生在该项目的风险事件。风险识别的有效方法有很多，如：
l         建立风险项目检查表：可以从以下几方面来检查，产品规模风险，业务影响风险，与客户相关的风险，过程风险，技术风险，开发环境风险，与人员的模式和经验有关的风险。
l         建立因果分析图。
l         征求看法：就项目可能存在的问题和不确定因素，征求项目组成员的看法。
l         参照以往项目的风险状况。
l         提问的方式：针对所识别的潜在风险，采纳提问的方式确定是否应认定为风险。
4.2.4. 确定所识别的风险类型
软件项目一般有如下五类风险：
l 规模风险：项目产品本身〔大系统和小系统〕或由项目团队引起的风险；项目的风险是直接与产品的规模成正比的。风险因素有：估计产品的规模的方法〔代码行，功能点，程序或文件的数目〕，产品规模估计的信任度，产品规模与以前产品规模平均值的偏差，产品的用户数，复用的软件有多少，产品的需求改变多少。
l 需求风险：不确定的客户需求引起的风险。很多项目在确定需求时都面临着一些不确定性。当在项目早期的需求不确定性在项目进展过程当中得不到解决时，就会对项目的成功造成很大威胁。与客户相关的风险因素有：对产品缺少清楚的熟悉，对产品需求缺少认同，在做需求中客户参加不够，没有优先需求，由于不确定的需要导致新的市场，不断变化需求，缺少有效的需求变化管理过程，对需求的变化缺少相关分析。
l 相关性风险：项目的外部环境或因素的相关性产生的风险。我们常常不能很好地控制外部的相关性，因此缓解策略应该包括可能性计划，以便从第二资源或协同工作资源中取得必要的组成部分，并且觉察潜在的问题。与外部环境相关的因素有：客户供应条目或信息，内部或外部转包商的关系，交互成员或交互团体依赖性，经验丰富人员的可得性，项目的复用性；
l 管理风险：组织自身的管理水平、能力成熟度引发的风险。应定义项目追踪过程并且明晰项目角色和责任，以能处理这些风险因素：计划和任务定义不够充分，实际项目状态，项目所有者和决策者分不清，不切实际的承诺，员工之间的冲突。
l 技术风险：由人员的技术水平和经验、使用的工具和技术的成熟度等引发的风险。在早期，识别风险从而采用合适的预防措施是解决风险领域问题的关键，比如：培训、雇佣顾问以及为项目团队招聘合适的人才等。主要有下面这些风险因素：缺乏培训，对方法、工具和技术理解的不够，应用领域的经验不够，新的技术和开发方法，不能正确工作的方法。 
4.3. 风险分析
风险分析是对识别出来的风险事件做风险影响分析，确定避免或减轻风险的策略及措施以达到降低风险，确保项目顺利进行的目的。对确定的风险事件还要进行描述，如：可能性、可能后果范围、估计发生时间、发生频率等。
4.3.1. 和风险相关的因素
和风险相关的主要四个因素：
l 风险事件，破坏或影响项目的事件
l 风险概率〔%〕，事件发生的可能性
l 风险得失量〔金额〕，说明可能造成的损失
l 风险影响〔周〕，等于风险概率 × 风险得失量周。
4.3.2. 风险分析步骤
风险分析要确定每个风险对项目的影响大小，一般是对已经识别出来的项目风险进行量化估计。
通过对风险及风险的互相作用的估算来评价项目可能结果的范围，从成本、进度及性能三个方面对风险进行评价。
l 评价风险影响：指一旦风险发生可能对项目造成的影响大小。如果损失的大小不容易直接估计，可以将损失分解为更小部分再评估它们。风险影响可用相对数值表示，建议将损失大小折算成对计划影响的时间表示。
l 估计风险概率：它是风险发生可能性的百分比表示，是一种主观推断。
l 计算风险值和和风险等级：它是评估风险的重要参数。“风险值〞=“风险概率〞ד风险影响〞。如：某一风险概率是25%，一旦发生会导致项目计划延长4周，因而，风险值=25%×4周=1周。风险等级〔分为1级、2级、3级〕。
l 确定风险优先级。哪些风险事件或来源可以避免，哪些可以忽略不合计〔包括可以承受〕，哪些要采用应对措施。 
4.3.3. 风险分析方法
l 确定型风险的分析方法：盈亏平衡分析〔计算和分析产量、成本和盈利这三者之间的关系〕；敏感性分析〔视察与软件项目有关的一个或多个主要因素发生变化时对该项目投资价值指标的影响程度〕；概率分析〔运用概率论及数理统计方法，来猜测和研究各种不确定因素对软件项目投资价值指标影响的一种定量分析〕。
l 不确定型风险的分析方法：有小中取大原则、大中取小原则、遗憾原则、最大数学期望原则、最大可能原则。
l 随机型风险的分析方法：最大可能原则、最大数学期望原则、最大效用数学期望原则、贝叶斯后验概率法等。
4.3.4. 建立风险跟踪列表
当风险分析完成后，将风险名称、风险的分类、风险值、风险等级和排出的风险优先级记录到《风险和问题跟踪列表》中的“风险跟踪列表〞部分。
【在过程管理平台中，填写和维护“风险列表〞。】
一旦完成了《风险和问题跟踪列表》，就可以依据概率及影响来进行综合合计，风险影响和出现概率从风险管理的角度来看，它们各自起着不同的作用。一个具有高影响但低概率的风险因素不应当占用太多的风险管理时间 ，但具有中到高概率、高影响的风险和具有高概率及低影响的风险，就应该进行风险处理。 
4.4. 风险处理和减缓活动
当完成了风险分析后，就已经确定了项目中存在的风险以及它们发生的可能性和对项目的风险冲击，并可排出风险的优先级。就可以依据风险性质和项目对风险的承受能力制定相应的预防措施和解决方法的计划，即风险处理和减缓。
对每个高优先级风险，项目组都要制定出处理和减缓风险的活动计划。
4.4.1. 风险规避的策略
一旦监视到风险，就应采用合理措施进行风险规避，可以从改变风险性质、改变风险发生的概率、改变风险的影响大小等多方面着手。风险规避的策略一般有：
l 避免：通过分析找出来发生风险事件的原因，消除这些原因来避免一些特定的风险事件发生。如避免客户不满意，可采纳这些措施，客户参加业务建模阶段，需求阶段要多和客户沟通，了解客户真正的需求， 目标系统的模型或DEMO系统要向客户演示，并得到反馈看法，如果反馈的看法和DEMO系统出入比较大时，一定要将修改后的DEMO系统在次向客户演示，直到双方都达成共识为止，要有双方认可的验收方案和验收标准，做好变更控制和配置管理。
l 减缓：通过降低风险事件发生的概率或得失量来减轻对项目的影响。如经过风险识别发现，项目组的程序员对所需开发技术不熟。可以采纳熟悉的技术来减缓项目在成本或进度方面的影响。也可以事先进行培训来减缓对项目的影响
l 接受：接收风险造成的后果。如自然灾害造成的风险，在一个大的软件项目中，为了避免自然灾害造成的后果，合计异地备份中心。
l 转移：使用合作伙伴、项目外包、保险与担保等手段来转移风险的方法，以减轻风险对项目带来的影响。
l 回避：当项目风险潜在威胁的可能性极大，并会带来严重的后果，无法转移又不能承受时，通过改变项目来规避风险。通常会通过修改项目目标、项目范围、项目结构等方式来回避风险的威胁。
l 后备措施：主要体现在后备费用、预留进度时间、后备技术力量三个方面，这些后备措施在项目计划中就应预留，确保在项目实施过程中，能充分调用后备力量解决问题。
4.4.2. 制定风险规避计划
针对需要采用规避策略的风险事件，要制定规避计划，一旦发生风险事件，就实施规避计划。比如：在一个软件开发项目中，某开发人员有可能离职，离职后会对项目造成一定的影响，则应该对这个风险事件开发应对计划，过程可以参照如下：
1) 进行调研，确定流动原因。
2) 在项目开始前，把缓解这些流动原因的工作列入风险管理计划。
3) 项目开始时，做好计划一旦人员离开时便可执行，以确保人员离开后项目仍能继续进行。
4) 制定文档标准，并建立一种机制，确保文档及时产生。
5) 对所有工作进行细小详审，使更多人能够按计划进度完成自己的工作。
6) 对每个关键性技术人员培养后备人员。
在合计风险成本之后，决定是否采纳上述策略。
4.4.3. 风险管理报告
无论项目进展的状况如何，都必需将风险管理的计划、行动、结果记录到《风险和问题跟踪列表》,在过程管理平台中填写和维护“风险列表〞。风险管理的继续性要求《风险和问题跟踪列表》的连贯性和不间断性，因此，该报表为项目的实施、控制、管理、决策提供信息基础。关于项目采纳的特别的风险管理问题和措施，可在项目/开发计划的风险管理部分说明，参见《项目/开发策划书》，也可以形成单独的风险管理计划文档。   
5. 风险监控
制定了风险防范计划后，风险并非不存在，在项目推动过程中还可能会增大或者衰退。因此，在项目执行过程中，需要随时监督风险的发展与变化状况，并确定随着某些风险的消失而带来的新的风险。   
风险监控包括两个层面的工作：
其一是跟踪已识别风险的发展变化状况，包括在整个项目周期内，风险产生的条件和导致的后果变化，衡量风险减缓计划需求。
其二是依据风险的变化状况及时调整风险应对计划，并对已发生的风险及其产生的遗留风险和新增风险及时识别、分析，并采用适当的应对措施。关于已发生过和已解决的风险也应及时在《风险和问题跟踪列表》进行记录, 在过程管理平台中填写和维护“风险列表〞。 
风险贯穿于项目的整个生命周期中，因而风险管理是个继续的过程，建立优良的风险管理机制以及基于风险的决策机制是项目成功的重要确保。风险管理是项目管理流程与规范中的重要组成部分，制定风险管理规则、明确风险管理岗位与使命是做好风险管理的基本确保。 
6. 附录
6.1. 项目风险分析列表
风险分类
潜在风险因素
规避措施建议
商业风险
合同类型风险

合同的约束风险

合同中与第三方的合作风险

主承包商风险

子承包商风险

相关承包商风险

协作管理方风险

卖方因素风险

政治因素风险

目标、范围不明确，不知项目何时终结
规范销售、采纳标准合同、工作任务书模板。签订补充协议、说明、备忘录
客户方风险
客户的技术素养不够

客户的承诺风险

客户内部对需求理解不一致

客户的需求不明确

对客户需求变化缺少控制机制

客户需求频繁变更

客户需求发生重大变化

无法与客户就交付形式、交付时间和交付内容达成共识

客户对软件产品不认可，不在交付清单和试运行报告上签字

客户不验收或拖延验收

客户期望与产品功能差距太大，客户反映激烈
高级工程师介入售前，提供业务咨询、实施策略、方案制定等支持，尽量不开空头支票。
变通解决、说服客户、降低客户需求。
客户对实施人员、最后应用效果不满意、发生投诉的状况。
执行工程师认证上岗制度，提升实施工程师的素养和工作能力；对项目实施质量管理，由高级工程师对方案进行审核；及时改换实施工程师、由高级工程师对方案进行优化调整
人力资源风险
人员时间和精力不能满足

人员的质量意识不强

人员的协作意识不强

人员的沟通意识不强

人员的积极性不够

人员没有接受过必要的培训

人员不稳定，发生变动
在项目组成立时要求所有项目组成员坚持固定；健全项目组成员的激励措施。发生人员变动前及早安排其它人员接替工作，离开时办理工作交接。
人员数量紧张

软硬件资源和环境风险
缺少必要的软件

硬件设备不具备

测试所需的资源要求和安排不能满足

测试环境准备不充分

关键计算机资源〔指对计算机内存和硬盘空间这些资源可能超过目前可能提供的数量这种风险〕

进度风险
项目时间紧张

来自项目进度监控的风险

软件产品生命周期各个阶段发生进度延迟

项目计划任务不明确，进度安排和资源配置不合理

计划没有得到切实执行，实施进度延期，不能如期完成阶段工作
制定计划时尽量合计全面，留有余地；取得客户高层的支持和推动，克服障碍；及时调整下步计划，并将计划调整原因形成备忘录，提交客户确认。
如涉及到工作量的增加，合计是否追加实施费用。
成本风险
项目费用是否超过预算

是否有足够的资金可用

技术风险
系统所采纳的软件技术风险

系统所采纳新技术

系统所采纳的技术是否成熟

项目经理、项目人员技术能力不够

专利风险

软件需求阶段过程风险
需求的范围界定

需求的稳定性〔能否获得客户对需求文档的承诺，以确保客户不随便变更需求〕

需求的完整性

需求的清楚性 (需求是否模糊不清〕

需求的合理性

需求的可行性

需求的可描述性〔文档能否正确、完备地表达用户需求〕

需求开发人员对项目所涉及的具体业务以及对用户需求的理解

没有正确理解客户需求

没有合适的需求分析方法和建模工具

需求的变更
实施范围在工作任务书中明确定义；需求调研结果进行确认；需求、实施范围的调整必需执行项目变动控制程序、合计是否追加实施费用、签订补充协议
软件制定阶段过程风险
制定的功能性

制定的难度

制定的接口

制定的性能

制定的易测性

制定的硬件约束

制定的可实现性

编码及单元测试的可行性

制定方案是否能满足客户需求

制定的变更

软件的易用性

软件的可扩大性

软件编码阶段过程风险
源代码书写的规范性

源代码的可读性

单元测试覆盖率

代码管理风险

软件测试阶段过程风险
集成测试的环境风险

测试范围不合理，无法明确定义测试项

测试用例的选择缺乏代表性、不完备

测试人员的培训不充分

测试所需的资源要求和安排不能满足

软件维护过程风险
工程特性的可维护性

工程特性的可靠性

工程特性的保险措施

工程特性的安全性

质量风险
软件产品出现功能性错误

软件产品出现性能问题

单元测试问题报告数量过多

各单元模块集成后，整个系统出现重大问题

系统的某些性能指标不能达到客户需求明确定义的验收指标

软件产品复制过程中发生质量问题

系统出错甚至数据丢失
完善产品、上线前的测试、建立规范操作、数据备份等系统运行制度。
其他风险
公司高级管理层对本项目不够重视

人员管理风险

配置管理风险

无法正确标识本项目的风险

不能正确评价项目风险

选择的风险对策不能有效地化解或减轻风险

无法发现风险管理计划中风险识别、风险评价、风险策略的问题

项目失败导致的市场风险
提供合适的、稳定的产品；按实施方法论规范实施；合同、工作任务书的定义和约束：目标、范围、客户方的责任。宣扬成功案例，抵消项目失败的负面影响；
总结教训
6.2. 参照资料
1) 《风险管理——软件系统开发方法》，著，王海鹏 周靖译，清华大学出版社，2002年9月
2) 《项目风险管理》，卢有杰等著，清华大学出版社，1998年7月
3) 《CMM Implementation Guide: Choreographing Software Process Improvement》Kim Caputo著，高等教育出版社，1997年4月
4) 《现代软件工程(一)管理技术篇》，周之英著，科学出版社，1999年9月
5) 《项目管理—计划、进度和控制的系统方法》，Harold Kerzner 著， 电子工业出版社，2002年9月
7. 修订记录
版本
变更原因和内容
修订人
审批人
生效日期

机构调整,体系整合
孙蔚、孟志华、杜晓辉、邢彬彬
审核人：彭凯、闫飞、李迎顺、张建钢
评审委员会