风险管理指南

1、卷号卷号 卷内编号卷内编号 密级密级 风险管理指南风险管理指南 Version 1.1 作者:技术委员会 分类: 使用者: 文档编号： 托普信息 （iTOP）集团, 2002 文档信息文档信息 标题:风险管理指南 作者:SEPG 创建日期: 2002-4-23 上次更新日期: 版本:1.0 部门名称: 修订文档历史记录修订文档历史记录 日期日期版本版本说明说明作者作者 2002-4-231.0创建孟胜 文档信息文档信息 标题:风险管理指南 作者:技术委员会 创建日期: 2002-4-23 上次更新日期: 版本:1.1 部门名称: 托普信息（iTOP）集团 修订文档历史记录修订文档历史记录 日期

2、日期版本版本说明说明作者作者 2002-4-231.0创建孟胜 2002-8-291.1为了 iTOP 集团推广 CMM 成果，对封面及部分 内容作了调整 托普信息（iTOP）集 团技术委员会 目录目录 1.简介简介.1 1.1目的.1 1.2定义、首字母缩写词和缩略语.1 1.3参考资料.1 2.风险管理准备风险管理准备.1 2.1风险管理的组成.1 2.2风险种类.2 2.2.1资源风险.2 2.2.2业务风险.2 2.2.3技术风险.2 2.2.4进度风险.3 2.3定义风险参数.3 2.4风险管理策略.4 2.5风险管理角色及职责.4 2.5.1项目经理.4 2.5.2项目组开发人员.

3、4 2.5.3SQA.4 3.风险识别风险识别.4 4.风险分析风险分析.4 4.1发生的可能性.5 4.2影响的严重性.5 5.风险的优先级风险的优先级.5 6.风险的控制风险的控制.5 6.1控制方法.5 6.1.1风险管理计划.5 6.1.2风险的化解.6 6.2风险监控.6 6.2.1周例会检查风险.6 6.2.2阶段/迭代完成后重新评估风险.6 风险管理指南风险管理指南 1.简介简介 1.1目的目的 风险管理的目标是在潜在问题发作以前就标志它们，这样就可以在生命周期中可以适时地计划 和启用风险处理活动。 1.2定义、首字母缩写词和缩略语定义、首字母缩写词和缩略语 PM Project

4、 Manager 1.3参考资料参考资料 RUP 快速软件开发 SW-CMM CMMI 2.风险管理准备风险管理准备 2.1风险管理的组成风险管理的组成 风险评估 风 险 识 别 风险控制 风险管理 风 险 分 析 风 险 优 先 级 风 险 监 控 风 险 化 解 风 险 管 理 计 划 2.2风险种类风险种类 2.2.1资源风险 组织组织 对该项目是否有足够的支持（包括管理人员、测试员、QA 和其他外部的相关各方）？ 这是否是该组织尝试过的最大项目？ 软件工程是否有明确定义的流程？需求记录和管理？ 资金资金 完成项目所需的资金是否到位？ 是否为培训和指导分配了资金？ 是否有预算限制使得系统

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

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

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

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

9、非常严重4 可能发生2 严重3 不太可能发生1 中等2 轻微 1 2.4风险管理策略风险管理策略 有三种主要的策略： 风险规避风险规避：使其不再受到该风险的影响。 风险转移：风险转移：让其他方（客户、厂商、银行、其他主体等）承担该风险。 风险接受：风险接受：决定将该风险当作意外事件来接受。监测风险征兆，并制定应急计划，以确定 在风险发生时将采取何种行动。 2.5风险管理角色及职责风险管理角色及职责 2.5.1项目经理 项目经理对风险管理工作负全部责任。 2.5.2风险管理经理 2.5.2风险管理经理的工作就是警告项目风险，防止项目经理和其他开发人员忽略风险管理。 2.5.2 2.5.2建议：建

10、议： 2.5.2一般大型项目（30 人以上），风险管理经理应该全职；其它项目，风险管理经理可以 兼职（但一般“项目经理”不担任此角色） 2.5.2 2.5.2项目组开发人员 项目组开发人员将被要求作为项目风险分析组的成员，对项目工作中存在的风险进行分析，并 整理成书面材料。 2.5.3SQA经理 SQA 经理将定期对风险管理工作开展情况进行评审，确保所开展的风险管理工作符合组织的要 求。 3.风险识别风险识别 （1）在项目计划制定阶段由项目风险管理经理召开有项目风险分析组全体相关人员参 加的项目风险管理工作启动会议（可以含在其它会议中进行）。 （2）在会议中，项目风险管理经理向项目风险分析组全

11、体相关成员介绍项目风险分类 方法，并向所有到会人员分发一张项目风险分类表（见“2.2 风险种类”）或列出组 织建议的风险分类，供风险分析组成员在识别项目风险时使用。 （3）这次会议将通过讨论，产生一个初步的项目风险清单，以便将来做进一步的分析。 “阶段/迭代风险管理清单”的例子： 排 序 风险名 称 停留 周数 风险描述 风险 得分 降低措施 责任 人 风险 状态 1 2 排 序 风险名 称 停留 周数 风险描述 风险 得分 降低措施 责任 人 风险 状态 9 10 4.风险分析风险分析 风险分析的依据是“风险识别”出来的“风险清单”。 4.1发生的可能性发生的可能性 根据“风险清单”每一项，

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

13、序） 公式：风险得分公式：风险得分 = 发生可能性等级分发生可能性等级分 * 影响的严重性等级分影响的严重性等级分 注意：风险的优先级只是一个估计值，不要在具体的得分和顺序上争论不下，优先级划分只是 帮助项目组发现前 10 大风险。 6.风险的控制风险的控制 6.1控制方法控制方法 6.1.1风险管理计划 重点是制定一个计划，以处理在排位靠前的高风险项。 风险管理计划的例子： 序 号 风险 名称 风险 得分 风险描述 谁引 起 发生 表现 可能 发生 时候 建议的降 低措施 责任 人 风险状态/ 日期 备注：风险状态：监控、发生、关闭 风险管理计划每阶段/迭代重新评估一次。 风险监控时选取风险

14、管理计划中没有关闭的前 10 大风险进行监控即可。每阶段/迭代启动时， 选取“风险管理计划”中处于“监控”状态的前 10 大风险，用于本阶段/迭代的周例会上进行 跟踪和监控（注意：周例会时只监控阶段/迭代启动时监控的前 10 大风险）。 风险管理计划的维护： 在周工作例会发现的新风险加入风险管理，重复“4 节，5 节”； 阶段/迭代对风险进行进行重新评估，重复“3 节，4 节，5 节” 6.1.2风险的化解 避免风险避免风险（即：不要做冒险的活动） 将风险从系统的一部分转移到另一部分将风险从系统的一部分转移到另一部分（可能对于系统的其他部分此风险不会发生或发生 时影响不大） 购买关于风险的信息

15、购买关于风险的信息（例如：做实验性项目，请咨询专家等） 消除风险的根源消除风险的根源 接受风险接受风险（如果风险后果较小，而处理它可能代价很大，滚动处理可能是最有效的途径） 发布风险发布风险（将风险发布给相关涉众，如：管理者、市场人员、客户特别注意策略等） 控制风险控制风险 制定风险无法化解时的“风险应急计划” 分配额外的资源来处理风险 为处理风险留出额外的时间 等等 记住风险记住风险（未为将来的项目积累） 6.2风险监控风险监控 6.2.1周例会检查风险 在周工作例会上，项目经理需要跟踪项目的风险。 1 根据风险列表，逐一分析前 10 大风险，确认已经风险状态是否“发生”或“关闭”； a)如果风险发生则启动“