项目风险管理计划.docVIP

[工程风险管理方案]

文件状态：

[]草稿

[√]正式发布

[]正在修改

文档编号：

TL4070503

当前版本：

1.0

作者：

李爽

完成日期：

DATE\@yyyy-MM-dd2010-05-19

版本历史

版本/状态

作者

参与者

起止日期

备注

1.0

正式发布

李爽

DATE\@yyyy-MM-dd2010-05-19

目录

TOC\o1-3\h\z0.文档介绍 3

0.1文档目的 3

0.2文档范围 3

0.3读者对象 4

0.4参考文献 4

0.5术语与缩写解释 4

1工程风险管理方案 4

1.1 目的 4

1.2 角色与职责 4

1.3 启动准那么 5

1.4 输入 5

1.5 主要步骤 5

1.5.1风险识别 5

1.5.2风险分析 5

1.5.3风险减缓 5

1.5.4风险监控 5

1.6 输出 6

1.7 结束准那么 6

1.8 度量 6

2 实施建议 6

3 附录1：常见风险举例 6

0.文档介绍

0.1文档目的

0.2文档范围

0.3读者对象

0.4参考文献

提示：列出本文档的所有参考文献〔可以是非正式出版物〕，格式如下：

[标识符]作者，文献名称，出版单位〔或归属单位〕，日期

0.5术语与缩写解释

缩写、术语

解释

1工程风险管理方案

目的

在工程的生命周期内，循环执行风险识别、风险分析、风险减缓和风险跟踪，直到工程的所有风险都被识别与解决为止。

角色与职责

工程负责人负责风险管理。

工程成员协助工程负责人处理风险。

启动准那么

《工程方案》已经制定，工程研发已经开始。

输入

《工程方案》

工程监控过程产生的文档如《工程问题列表》、《工程质量报告》和《工程周报》等

主要步骤

风险识别

工程负责人根据“风险跟踪列表”，定期〔例如每周一次〕识别本工程的风险。

风险分析

工程负责人评估每个风险的严重性、可能性和风险系数，并按照风险系数从高到低的顺序排列风险。

1.5.3风险减缓

对于风险系数超过“容许值”〔建议为10〕的每一个风险，工程负责人应当给出风险减缓措施，并指定责任人。风险系数越高，越先处理。

1.5.4风险监控

工程负责人跟踪风险减缓过程，直到风险已经解决为止。如果风险的性质发生变化，应当及时更新风险减缓措施

输出

《风险管理报告》

结束准那么

所有风险都已经解决，相关信息已经记录到《风险管理报告》之中。

度量

工程负责人统计工作量。

实施建议

对风险管理过程域产生的所有有价值的文档进行配置管理。

工程负责人根据本工程的特征，确定风险识别的频度〔通常为每周一次〕，适当修改“风险登记表”。

选用适宜的软件工具，尽量减少风险管理过程域的工作量。

工程监控和风险管理均由工程负责人负责，建议同步执行。

附录1：常见风险举例

进度风险

▲进度安排制定得是否合理？

▲WBS的分析是否足够细，以便对进度做较贴切的安排？

▲对交付日期的要求是否严格？

▲是否可以为了满足严格进度安排而对产品功能进行让步放行？

▲方案是否为过程管理预留时间？

规模风险

▲对产品的需求是否和涉众认同一致？

▲需求是否有优先级排列？

▲对需求的变化是否建立了相应的管理机制并实施？

▲对需求的变化是否做相应的分析？

▲需求是否稳定并到达了充分的共识？

▲规模的估计方法是否正确掌握和使用？

▲工程规模是固定不变还是在不断扩展或变更？

▲工程开发规模或范围预估是否正确？

外部依赖风险

▲系统是否依赖于新的或未经试验的产品、效劳或技术？是否依赖于新的或未被证明的硬件、软件或技术？

▲对于与其他系统〔包括企业以外的系统〕的接口是否存在外部依赖性？

▲该工程是否依赖于其他〔平行的〕开发工程？

技术风险

▲所采用技术是否已经过使用？

▲使用的组件是否被成功的重复使用？重复使用的组件是否合理？

▲数据量是否合理？当前可用的系统框架是否能够保存这些数据？

▲是否有特殊或苛刻的技术需求〔如要求工程团队处理他们不熟悉的问题〕？

▲是否存在极不灵活的可用性和平安性需求〔如“系统必须永远不出现故障”〕？

▲系统的用户是否对正在开发的系统类型没有经验？

▲应用程序的大小或复杂性是否导致了风险的增加？

▲成功是否依赖于开发工具〔设计工具、编译器等〕和实施技术〔操作系统、数据库、进程间通信机制等〕的成功集成。是否有替代方案，可以在没有这些技术的情况下交付工程？

人员

▲是否获得必要的人员〔测试人员、QA、SCM人员〕？

▲工程人员是否具备适宜的技能和经验以及接受过相应培训？

▲工程人员是否会有突然接受其他任