01-项目风险管理过程.doc

01-项目风险管理过程
文件名称
项目风险管理过程
密级
机密
现行版本
F01.00
文件编号
TO-03-W
项目风险管理过程
拟　制

编订单位

初版日期

修订日期

审　核

批　准

修订记录
日　期
修订
版本
修改
章节
修改描述
修订人

目　　 录
1 目的 4n0gPGXi。
2 范围 4MlzYbak。
3 角色与职责 4dX2mvjy。
3.1 项目负责人 4Ncpb2Ya。
4 入口准则 4mpy5d7L。
5 输入 46Vuxlmg。
6 活动步骤 5Mu1m7ma。
6.1 风险识别与分析 6vU4GwfA。
6.2 风险追踪处理 9SNBqtLO。
6.3 风险归档 9jvVJfOX。
7 输出 9P3WE23l。
8 出口准则 10Ly0QPyP。
9 文档模版和表格 10nDUfRXh。
10 相关规范 10RmYadcG。
1 目的
本过程描述了项目风险管理的一般过程，用于识别项目风险、跟踪项目风险并制定风险的缓解计划和应急计划。
2 范围
本过程适用于本组织内的所有类型的项目。
3 角色与职责
3.1 项目负责人
在项目立项之后，识别项目风险，执行项目风险计划，包括风险列表、缓解计划和应急计划。
根据项目风险计划中的缓解计划，在项目进度计划为缓解活动安排资源和进度，并按计划执行缓解活动。
在日常项目管理中，跟踪项目风险计划，记录缓解状况，识别新风险。
当项目风险被触发时，在项目进度计划为应急活动安排资源和进度，并按计划执行应急活动。
4 入口准则
项目负责人制定项目计划
项目负责人跟踪项目计划
事件触发
5 输入
项目计划
过程数据库
6 活动步骤
序号
活动
输入
输出
责任人
参与人
1
制定项目风险计划
项目计划
过程数据库（目前没有构建）
项目状态报告（项目风险计划）
项目负责人
QA
2
根据项目风险计划，执行风险缓解、应急活动
项目状态报告（项目风险计划）
项目计划
项目负责人
QA
3
跟踪项目风险
项目状态报告（项目风险计划）
项目状态报告（项目风险计划）
项目负责人
QA
4
当项目结束时，放入PAL库
项目状态报告（项目风险计划）
项目风险数据
项目负责人
QA
流程图

6.1 风险识别与分析
6.1.1 项目负责人或其它项目成员定期（如周例会）识别本项目的风险。项目风险记录在《项目状态报告》风险管理表中；H1RvIYf
6.1.1 风险主要来自以下几方面
n 不确定的需求
n 未曾使用过的新技术或方法或应用领域
n 不合理的设计
n 不切实际的进度估算和分配
n 可用的人员和技能不足
n 成本和资金的问题
6.1.2 项目负责人参照以下的风险标准列表页，根据项目目前已知的情况识别可预测的风险，并将识别的风险记录在《项目状态报告》风险管理表中；a13GHA3。
分类
风险描述
缓解计划
客户风险
用户参与少或和用户沟通少，导致项目后期客户对产品的验收不通过
和客户确立适当的沟通流程
安排客户参与里程碑评审
客户风险
用户需求变化频繁，导致进度延迟
明确需求的提供者；在需求阶段让客户参与需求的评审，并对需求说明书进行确认；
分析每次需求变更造成的影响，并要求得到客户的确认。
管理风险
估算不准确，导致工作量、进度延迟
设定缓冲时间，以应对估算外的工时。
管理风险
流程可能在开发中发生改变
和SEPG达成一致，过程或模板一旦被使用将不能修改
估算修改的工作量并延迟进度或增加人手
资源风险
评审和测试实施不足
提前计划外部资源参与的评审，并在评审之前3天提前通知评审人员。
资源风险
关键人员发生流动
安排人员作为后备资源，并将其负责的任务尽量安排在非关键路径上。
资源风险
项目团队士气不足，效率低下
进行一定的团队建设活动
资源风险
关键设备没有按时到货
定期跟踪关键设备的准备情况
资源风险
项目成员不熟悉公司开发流程（如比例不足50%）、技术领域，导致项目的生产率降低
安排组织过程和技术的培训
加强QA的指导和监督(增加Review的频率)
技术风险
技术难度过大，在组织中没有历史经验
请项目外有相关经验者进行指导
技术风险
开发环境没有具备好
在开发环境没有完全建立以前，建立简易环境进行工作。
技术风险
某项功能可能无法用现有技术来实现
将该功能作为Research进行预先的调查
考虑外包的可能性
6.1.3 项目风险计划内容包括：类型、状态、严重程度、发生概率、风险值、最近跟踪日期、应对措施、缓解计划、应急计划等内容；iQGCXzl。
6.1.3.a 类型：将风险分为4种类型
n 管理风险，如：项目管理、过程、进度、成本
n 技术风险，如：新技术、方法
n 资源风险、如：人员、技能
n 客户风险，如：合同、需求、客户参与等
6.1.3.b 状态：将风险分为3种状态
n 跟踪：风险识别后，正处于跟踪状态
n 关闭：风险已被消除
n 发生：风险已发生，也就是触发了应急计划的触发条件，启动应急计划
6.1.3.c 严重程度：被识别风险对项目的影响严重程度，从1至5依次递增，其划分标准为：
n 1－忽略，发生后， 将影响项目的进度或者质量，但不影响项目的里程碑事件和工作产品交付。
n 2—较小，发生后，将导致项目里程碑事件不能按时完成，或者工作产品不能及时交付，但拖延工时（预计结束/验收日期－计划结束/验收日期）低于整个项目计划工时的20%。fYZxZIL。
n 3—中等，发生后，将导致整个项目的结束/验收日期发生严重拖延，拖延工时（预计结束/验收日期－计划结束/验收日期）达到或者超过整个项目计划工时的20%。EblO4GQ。
n 4—严重，发生后，将导致项目一个或多个阶段的已开发工作产品必须废弃并且重新开发。
n 5—致命，发生后，将导致项目非正常关闭或被取消。
6.1.3.d 发生概率：被识别风险可能发生的概率，从1到5依次递增其划分标准为：
n 1—很低，有可能发生，但概率介于0%到20%。
n 2—低，有可能发生，但概率介于21%到40%。
n 3—中等，很有可能发生，概率介于41%到60%。
n 4—高，很有可能发生，概率介于61%到80%。
n 5—很高，随时可能发生，概率大于80%。
6.1.3.e 风险等级：风险等级＝严重程度×发生概率，根据计算结果分为高、中、低三档
n 低风险：风险值介于0至8；白色区域。
n 中风险：风险值介于9至15；橙色区域。
n 高风险：风险值大于等于15；红色区域。
严重程度发生概率
1 – 忽略
2 – 较小
3 – 中等
4 – 严重
5 – 致命
1 – 很低
1
2
3
4
5
2 – 低
2
4
6
8
10
3 – 中等
3
6
9
12
15
4 – 高
4
8
12
16
20
5 – 很高
5
10
15
20
25
6.1.3.f 风险防范及控制计划：
n 对于低风险，应对措施可以为“接受”；
n 对于中风险，应对措施应该为“缓解”，而项目负责人要制定项目风险缓解计划；
n 对于高风险，应对措施应该为“缓解并制定应急计划”，项目负责人除了要制定项目风险缓解计划之外，还要制定风险应急计划。X5WbwlF。
n 同时对于其他部分风险，应对措施可以为“转嫁”，就是把风险转移到第三方。项目负责人也可以根据项目实际情况调整风险的应对措施；dLPRPLW。
6.1.3.g 缓解计划：缓解计划包含了负责人、限制日期和一组用于缓解项目风险的相关活动，缓解活动通过降低风险严重程度或者减少风险发生概率来降低风险值，使风险降低等级，达到可接受的程度；7itg8yS。
6.1.3.h 应急计划：应急计划定义了风险触发的条件、触发后的应急措施，以及应急措施执行的负责人。
6.2 风险追踪处理
6.1.4 当缓解计划需要执行时，项目负责人在项目计划中增加该风险缓解活动任务（任务名称可以根据所需缓解的项目风险在项目风险计划中的序号命名为风险缓解活动），并为该任务分配资源和进度；Ug7ttrF。
6.1.5 通过风险跟踪，项目负责人控制和跟踪缓解活动的执行情况。并记录缓解后的风险严重程度和发生概率：
n 判断项目风险计划中的风险是否仍然存在，对于已经从中、高风险降低为低风险的项目风险项，可以修改其应对措施为“接受”，并清除其缓解计划和应急计划；L9a3eYT。
n 判断风险计划中的风险项是否被触发，如果发现有风险发生，需要执行应急计划；
n 识别项目的新增风险，并把新增风险加入项目风险计划中；
n 当项目发生人员变更时，跟踪项目风险缓解计划、应急计划的负责人的变更情况，修改风险计划中各风险项的最近跟踪日期。ErBmQsm。
6.1.6 当风险被触发时，执行风险应急计划
6.1.6.a 同缓解计划一样，当应急计划需要执行时，需要项目负责人在项目计划中增加该应急措施活动任务，并为该任务分配资源和进度0DkLvzz。
6.1.7 项目负责人应定期重新评估每个风险的发生可能性、影响程度，将风险跟踪情况记录于本周的《项目状态报告》中；vU273EU。
6.1.8 虽然采取规避措施，风险依然发生时，需要将其升级为问题管理；
6.3 风险归档
6.1.9 项目结束时，项目中的风险记录需要提交到公司财富库PAL中，供以后的项目参考。
7 输出
序 号
名 称
编 号
1
《项目状态报告》
TO-02-E005
8 出口准则
Ø 项目风险计划制定并通过审核
Ø 项目风险计划得到跟踪
9 文档模版和表格
序 号
名 称
编 号
1
《项目状态报告》
TO-02-E005
10 相关规范
序 号
名 称
编 号
1
《项目计划与监控过程》
TO-02-W