风险管理指南

1、卷号卷内编号密级风险管理指南Versio n 1.1技术委员会分类：指南使用者：项目组、项目 管理部、技术委员 会 文档编号：P&C_Risk_GUl_1.1?托普信息 （iTOP ）集团,2002文档信息标题：风险管理指南 作者:技术委员会创建日期:2002-4-23上次更新日期：版本：1.1 部门名称：托普信息（iTOP ）集团修订文档历史记录W版本说明作者2002-4-2310创建孟胜2002-8-291.1为了iTOP集团推广CMM成果，对封面及部分托普信息（iTOP ）集内容作了调整团技术委员会目录1 简介11.1 目的 11.2 定义、首字母缩写词和缩略语 11.3 参考资

2、料 12. 风险管理准备 12.1 风险管理的组成 12.2 风险种类 12.2.1 资源风险 12.2.2 业务风险 22.2.3 技术风险 22.2.4 进度风险 32.3 定义风险参数 32.4 风险管理策略 32.5 风险管理角色及职责 42.5.1 项目经理 42.5.2 项目组开发人员42.5.3 SQA 42风,险识别 44.1 发生的可能性 44.2 影响的严重性 55. 风险的优先级 56. 风险的控制 56.1 控制方法56.1.1 风险管理计划56.1.2 风险的化解 56.2 风险监控 66.2.1 周例会检查风险66.2.2 阶段/迭代完成后重新评估风险6风险管理指南

3、1. 简介1.1 目的风险管理的目标是在潜在问题发作以前就标志它们，这样就可以在生命周期中可以适时地计划 和启用风险处理活动。1.2 定义、首字母缩写词和缩略语PM Project Ma nager1.3 参考资料RUP快速软件开发SW-CMMCMMI2. 风险管理准备2.1风险管理的组成风险管理风险评估风险控制风险识别2.2风险种类资源风险组织? 对该项目是否有足够的支持（包括管理人员、测试员、? 这是否是该组织尝试过的最大项目？? 软件工程是否有明确定义的流程？需求记录和管理？ 资金风 险 化 解风 险 监 控QA和其他外部的相关各方）？? 完成项目所需的资金是否到位？? 是否为培训和指导

4、分配了资金？? 是否有预算限制使得系统必须以固定的成本交付，否则将被取消？? 成本估算是否准确？人员? 是否可以获得足够的人员？? 他们是否具备合适的技能和经验？? 他们以前是否在一起工作过？? 他们是否相信项目会成功？? 是否可以找到用户代表来担任复审员？? 是否可以找到领域专家？时间? 时间表制定得是否现实？? 是否可以为了满足时间表而对功能进行规模管理？? 对交付日期的要求有多严格？? 是否有时间“把工作做好”？2.2.2 业务风险? 如果竞争对手抢先将产品推向市场怎么办？? 如果项目资金处于危险境地怎么办（换句话说，“如何确保有足够的资金”）？? 系统的预计价值是否大于预计成本？（务必

5、要考虑货币的时间价值和资金的成本）。? 如果无法同关键的供应商签定合同怎么办？2.2.3 技术风险规模风险? 成功是否能够被评测？? 是否有关于如何评测成功的协议？? 需求是否相当稳定并得到了充分的了解？? 项目规模是固定不变还是在不断扩展？? 项目开发的时间范围是否太短、不够灵活？技术风险? 技术是否已经过证明？? 重复使用目标是否合理？? 工件必须要使用一次后才能被重复使用。? 构件可能要在若干次发布后才能变得稳定，以致无需重大变更即可复用。? 需求中的事务量是否合理？? 事务比率的估计值是否可靠？这些估计是否过于乐观？? 数据量是否合理？当前可用的框架是否能够保存这些数据，或者，如果需求

6、使您相信 工作站或部门系统将成为设计的一部分，那么是否能够在这些地方合理地保存数据？? 是否有特殊或苛刻的技术需求（如要求项目团队处理他们不熟悉的问题）？? 成功是否依赖于新的或未经试验的产品、服务或技术？是否依赖于新的或未被证明的 硬件、软件或技术？? 对于与其他系统（包括企业以外的系统）的接口是否存在外部依赖性？是否存在必需 的接口或必须创建它们？? 是否存在极不灵活的可用性和安全性需求（例如“系统必须永远不岀现故障”）？? 系统的用户是否对正在开发的系统类型没有经验？? 应用程序的大小或复杂性，或者技术的新颖性是否导致了风险的增加？? 是否存在对国家语言支持的需求？? 是否可能设计、实施

7、和运行该系统？某些系统只由于太大或太复杂而无法正常工作。 外部依赖性风险? 该项目是否依赖于其他（平行的）开发项目？? 成功是否依赖于市售产品或外部开发的构件？? 成功是否依赖于开发工具（设计工具、编译器等）和实施技术（操作系统、数据库、 进程间通信机制等）的成功集成。您是否有替代计划，可以在没有这些技术的情况下 交付项目？224 进度风险? 功能是否无限追加? 计划是否过于乐观；? 是否缺乏计划? 在压力下是否放弃计划? 是否追赶计划2.3 定义风险参数风险参数可用于评估、分类和划分风险的优先级；TP集团将风险参数分为：“发生的可能性”和“影响的严重性”两类名称等级名称等级非常可能发生3非常

8、严重4可能发生2严重3不太可能发生1中等2轻微12.4 风险管理策略有三种主要的策略：? 风险规避：使其不再受到该风险的影响。? 风险转移：让其他方（客户、厂商、银行、其他主体等）承担该风险。? 风险接受：决定将该风险当作意外事件来接受。监测风险征兆，并制定应急计划，以确定 在风险发生时将米取何种行动。2.5 风险管理角色及职责2.5.1 项目经理项目经理对风险管理工作负全部责任。2.5.2 项目组开发人员项目组开发人员将被要求作为项目风险分析组的成员，对项目工作中存在的风险进行分析，并 整理成书面材料。2.5.3 SQASQA经理将定期对风险管理工作开展情况进行评审，确保所开展的风险管理工作

9、符合组织的要 求。3. 风险识别（1）在项目计划制定阶段由项目风险管理经理召开有项目组相关人员参加的项目风险 管理工作会议（可以含在其它会议中进行）。（2）在会议中，项目风险管理经理向项目组相关成员介绍项目风险分类方法，并向所有到会人员分发一张项目风险分类表（见“2.2风险种类”）或列岀组织建议的风险分类，供风险分析组成员在识别项目风险时使用。（3）这次会议将通过讨论，产生一个初步的项目风险清单，以便将来做进一步的分 析。阶段/迭代风险管理清单”的例子129104. 风险分析风险分析的依据是“风险识别”岀来的“风险清单”。4.1 发生的可能性根据“风险清单”每一项，项目组成员评估风险项，列岀风

10、险发生的可能性的三种状态“非常 可能、可能发生、不太可能发生”，依据状态填写等级分“3、2、1 ”。名称等级非常可能发生3可能发生2不太可能发生14.2影响的严重性在评估了 “发生可能性”后，项目组成员再根据“风险清单”每一项评估风险项，列岀风险 影响严重性的四种状态“非常严重、严重、中等、轻微”，依据状态填写等级分“4、3、2、名称等级非常严重4严重3中等2轻微15. 风险的优先级依据“发生可能性”和“影响的严重性”计算风险的得分，依据风险得分由高到低排列风险项 （如果得分相同，则项目组讨论决定风险的前后顺序）公式：风险得分 =发生可能性等级分 *影响的严重性等级分注意：风险的优先级只是一个

11、估计值，不要在具体的得分和顺序上争论不下，优先级划分只是 帮助项目组发现前 io大风险。6. 风险的控制6.1 控制方法6.1.1 风险管理计划重点是制定一个计划，以处理在排位靠前的高风险项 风险管理计划的例子：风险管理计划每阶段/迭代重新评估一次。风险监控时选取风险管理计划中没有关闭的前10大风险进行监控即可。每阶段 /迭代启动时，选取“风险管理计划”中处于“监控”状态的前10大风险，用于本阶段/迭代的周例会上进行跟踪和监控（注意：周例会时只监控阶段 /迭代启动时监控的前 10大风险）。风险管理计划的维护：? 在周工作例会发现的新风险加入风险管理，重复“4节，5节”；? 阶段/迭代对风险进行

12、进行重新评估，重复“ 3节，4节，5节”6.1.2 风险的化解避免风险（即：不要做冒险的活动）将风险从系统的一部分转移到另一部分（可能对于系统的其他部分此风险不会发生或发生时影响不大）购买关于风险的信息（例如：做实验性项目，请咨询专家等）消除风险的根源接受风险（如果风险后果较小，而处理它可能代价很大，滚动处理可能是最有效的途径）发布风险 （将风险发布给相关涉众，如：管理者、市场人员、客户特别注意策略 等）控制风险? 制定风险无法化解时的“风险应急计划”? 分配额外的资源来处理风险? 为处理风险留出额外的时间? 等等记住风险 （为将来的项目积累）6.2 风险监控6.2.1 周例会检查风险在周工作例会上，项目经理需要跟踪项目的风险。1 根据风险列表，逐一分析前 10 大风险，确认已经风险状态是否“发生”或“关闭”；a） 如果风险发生则启动“风险应急计划”或项目组协商解决办法，必要时 PM 请求相关 高级管理者解决已发生的风