风险管理指南最新版

卷号卷内编号密级 分类:<指南>使用者:<项目组、项目管理部、技术委员会>文档编号：<P&C_Risk_GUI_1.1>©托普信息（iTOP）集团,2002 风险管理指南Version1.1技术委员会 文档信息 标 题 快递公司问题件快递公司问题件货款处理关于圆的周长面积重点题型关于解方程组的题及答案关于南海问题 :风险管理指南 作者:技术委员会 创建日期:2002-4-23 上次更新日期: 版本:1.1 部门名称:托普信息（iTOP）集团修订文档历史记录 日期 版本 说明 作者 2002-4-23 1.0 创建 孟胜 2002-8-29 1.1 为了iTOP集团推广CMM成果，对封面及部分内容作了调整 托普信息（iTOP）集团技术委员会 目录11.简介11.1目的11.2定义、首字母缩写词和缩略语11.3参考资料12.风险管理准备12.1风险管理的组成22.2风险种类22.2.1资源风险22.2.2业务风险22.2.3技术风险32.2.4进度风险32.3定义风险参数42.4风险管理策略42.5风险管理角色及 职责 岗位职责下载项目部各岗位职责下载项目部各岗位职责下载建筑公司岗位职责下载社工督导职责.docx 42.5.1项目经理42.5.2项目组开发人员42.5.3SQA43.风险识别44.风险 分析 定性数据统计分析pdf销售业绩分析模板建筑结构震害分析销售进度分析表京东商城竞争战略分析 54.1发生的可能性54.2影响的严重性55.风险的优先级56.风险的控制56.1控制方法56.1.1风险管理 计划 项目进度计划表范例计划下载计划下载计划下载课程教学计划下载 66.1.2风险的化解66.2风险监控66.2.1周例会检查风险66.2.2阶段/迭代完成后重新评估风险风险管理指南1.简介1.1目的风险管理的目标是在潜在问题发作以前就标志它们，这样就可以在生命周期中可以适时地计划和启用风险处理活动。1.2定义、首字母缩写词和缩略语PMProjectManager1.3参考资料RUP《快速软件开发》SW-CMMCMMI2.风险管理准备2.1风险管理的组成2.2风险种类2.2.1资源风险组织·对该项目是否有足够的支持（包括管理人员、测试员、QA和其他外部的相关各方）？·这是否是该组织尝试过的最大项目？·软件 工程 路基工程安全技术交底工程项目施工成本控制工程量增项单年度零星工程技术标正投影法基本原理 是否有明确定义的流程？需求记录和管理？资金·完成项目所需的资金是否到位？·是否为培训和指导分配了资金？·是否有预算限制使得系统必须以固定的成本交付，否则将被取消？·成本估算是否准确？人员·是否可以获得足够的人员？·他们是否具备合适的技能和经验？·他们以前是否在一起工作过？·他们是否相信项目会成功？·是否可以找到用户代表来担任复审员？·是否可以找到领域专家？时间·时间表制定得是否现实？·是否可以为了满足时间表而对功能进行规模管理？·对交付日期的要求有多严格？·是否有时间“把工作做好”？2.2.2业务风险·如果竞争对手抢先将产品推向市场怎么办？·如果项目资金处于危险境地怎么办（换句话说，“如何确保有足够的资金”）？·系统的预计价值是否大于预计成本？（务必要考虑货币的时间价值和资金的成本）。·如果无法同关键的供应商签定合同怎么办？2.2.3技术风险规模风险·成功是否能够被评测？·是否有关于如何评测成功的协议？·需求是否相当稳定并得到了充分的了解？·项目规模是固定不变还是在不断扩展？·项目开发的时间范围是否太短、不够灵活？技术风险·技术是否已经过证明？·重复使用目标是否合理？·工件必须要使用一次后才能被重复使用。·构件可能要在若干次发布后才能变得稳定，以致无需重大变更即可复用。·需求中的事务量是否合理？·事务比率的估计值是否可靠？这些估计是否过于乐观？·数据量是否合理？当前可用的框架是否能够保存这些数据，或者，如果需求使您相信工作站或部门系统将成为设计的一部分，那么是否能够在这些地方合理地保存数据？·是否有特殊或苛刻的技术需求（如要求项目团队处理他们不熟悉的问题）？·成功是否依赖于新的或未经试验的产品、服务或技术？是否依赖于新的或未被证明的硬件、软件或技术？·对于与其他系统（包括企业以外的系统）的接口是否存在外部依赖性？是否存在必需的接口或必须创建它们？·是否存在极不灵活的可用性和安全性需求（例如“系统必须永远不出现故障”）？·系统的用户是否对正在开发的系统类型没有经验？·应用程序的大小或复杂性，或者技术的新颖性是否导致了风险的增加？·是否存在对国家语言支持的需求？·是否可能设计、实施和运行该系统？某些系统只由于太大或太复杂而无法正常工作。外部依赖性风险·该项目是否依赖于其他（平行的）开发项目？·成功是否依赖于市售产品或外部开发的构件？·成功是否依赖于开发工具（设计工具、编译器等）和实施技术（操作系统、数据库、进程间通信机制等）的成功集成。您是否有替代计划，可以在没有这些技术的情况下交付项目？2.2.4进度风险·功能是否无限追加·计划是否过于乐观；·是否缺乏计划·在压力下是否放弃计划·是否追赶计划2.3定义风险参数风险参数可用于评估、分类和划分风险的优先级；TP集团将风险参数分为：“发生的可能性”和“影响的严重性”两类 发生的可能性 影响的严重性 名称 等级 名称 等级 非常可能发生 3 非常严重 4 可能发生 2 严重 3 不太可能发生 1 中等 2 轻微 1 2.4风险管理策略有三种主要的策略：·风险规避：使其不再受到该风险的影响。·风险转移：让其他方（客户、厂商、银行、其他主体等）承担该风险。·风险接受：决定将该风险当作意外事件来接受。监测风险征兆，并制定应急计划，以确定在风险发生时将采取何种行动。2.5风险管理角色及职责2.5.1项目经理项目经理对风险管理工作负全部责任。2.5.2 2.5.3项目组开发人员项目组开发人员将被要求作为项目风险分析组的成员，对项目工作中存在的风险进行分析，并整理成书面材料。2.5.4SQASQA经理将定期对风险管理工作开展情况进行评审，确保所开展的风险管理工作符合组织的要求。3.风险识别（1）在项目计划制定阶段由项目风险管理经理召开有项目组相关人员参加的项目风险管理工作会议（可以含在其它会议中进行）。（2）在会议中，项目风险管理经理向项目组相关成员介绍项目风险分类方法，并向所有到会人员分发一张项目风险分类表（见“2.2风险种类”）或列出组织建议的风险分类，供风险分析组成员在识别项目风险时使用。（3）这次会议将通过讨论，产生一个初步的项目风险清单，以便将来做进一步的分析。“阶段/迭代风险管理清单”的例子： 排序 风险名称 停留周数 风险描述 风险得分 降低措施 责任人 风险状态 1 2 9 10 4.风险分析风险分析的依据是“风险识别”出来的“风险清单”。4.1发生的可能性根据“风险清单”每一项，项目组成员评估风险项，列出风险发生的可能性的三种状态“非常可能、可能发生、不太可能发生”，依据状态填写等级分“3、2、1”。 名称 等级 非常可能发生 3 可能发生 2 不太可能发生 14.2影响的严重性在评估了“发生可能性”后，，项目组成员再根据“风险清单”每一项评估风险项，列出风险影响严重性的四种状态“非常严重、严重、中等、轻微”，依据状态填写等级分“4、3、2、1”。 名称 等级 非常严重 4 严重 3 中等 2 轻微 15.风险的优先级依据“发生可能性”和“影响的严重性”计算风险的得分，依据风险得分由高到低排列风险项（如果得分相同，则项目组讨论决定风险的前后顺序）公式：风险得分=发生可能性等级分*影响的严重性等级分注意：风险的优先级只是一个估计值，不要在具体的得分和顺序上争论不下，优先级划分只是帮助项目组发现前10大风险。6.风险的控制6.1控制方法6.1.1风险管理计划重点是制定一个计划，以处理在排位靠前的高风险项。风险管理计划的例子： 序号 风险名称 风险得分 风险描述 谁引起 发生表现 可能发生时候 建议的降低措施 责任人 风险状态/日期 备注：风险状态：监控、发生、关闭风险管理计划每阶段/迭代重新评估一次。风险监控时选取风险管理计划中没有关闭的前10大风险进行监控即可。每阶段/迭代启动时，选取“风险管理计划”中处于“监控”状态的前10大风险，用于本阶段/迭代的周例会上进行跟踪和监控（注意：周例会时只监控阶段/迭代启动时监控的前10大风险）。风险管理计划的维护：·在周工作例会发现的新风险加入风险管理，重复“4节，5节”；·阶段/迭代对风险进行进行重新评估，重复“3节，4节，5节”6.1.2风险的化解·避免风险（即：不要做冒险的活动）·将风险从系统的一部分转移到另一部分（可能对于系统的其他部分此风险不会发生或发生时影响不大）·购买关于风险的信息（例如：做实验性项目，请咨询专家等）·消除风险的根源·接受风险（如果风险后果较小，而处理它可能代价很大，滚动处理可能是最有效的途径）·发布风险（将风险发布给相关涉众，如：管理者、市场人员、客户{特别注意策略}等）·控制风险·制定风险无法化解时的“风险应急计划”·分配额外的资源来处理风险·为处理风险留出额外的时间·等等·记住风险（为将来的项目积累）6.2风险监控6.2.1周例会检查风险在周工作例会上，项目经理需要跟踪项目的风险。1．根据风险列表，逐一分析前10大风险，确认已经风险状态是否“发生”或“关闭”；a)如果风险发生则启动“风险应急计划”或项目组协商解决办法，必要时PM请求相关高级管理者解决已发生的风险，并且PM负责在风险管理计划中将此条风险标示为“发生”。b)如果风险已经消除，则PM负责在风险管理计划中将此条风险标示为“关闭”。2．识别当前还存在的风险，如果有进行“6.1.1节”的措施。3．统计每项风险的停留时间(周数)。6.2.2阶段/迭代完成后重新评估风险每阶段/迭代结束时，依据本阶段的成果和项目进行的实际情况，重新评估风险，重复“3节，4节，5节”。PAGE_1081237696.vsd���������������������������������������������������������������������������������������������������������