- 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
- 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
项目风险管理计划 腾龙软件
[项目风险管理计划]
文件状态: [ ] 草稿
[√] 正式发布[ ] 正在修改
文档编号: TL4070503 当前版本: 1.0
作 者: 李爽
完成日期: 2022-04-26
1
项目风险管理计划腾龙软件
项目风险管理计划
腾龙软件
PAGE 6
PAGE 6
版 本 历 史
版本/状态 作者
1.0 李爽
正式发布
参与者 起止日期 备注2022-04-26
目 录
0. 文档介绍 4
0.1 文档目的 4
0.2 文档范围 4
0.3 读者对象 4
0.4 参考文献 4
0.5 术语与缩写解释 4
项目风险管理计划 4
目的 4
角色与职责 5
启动准则 5
输入 5
主要步骤 5
风险识别 5
风险分析 5
风险减缓 5
风险监控 6
输出 6
结束准则 6
度量 6
实施建议 6
附录 1:常见风险举例 6
文档介绍
文档目的
文档范围
读者对象
参考文献
提示:列出本文档的所有参考文献(可以是非正式出版物),格式如下: [标识符] 作者,文献名称,出版单位(或归属单位),日期
术语与缩写解释
缩写、术语
缩写、术语
解 释
项目风险管理计划
目的
在项目的生命周期内,循环执行风险识别、风险分析、风险减缓和风险跟踪,直到项目的所有风险都被识别与解决为止。
角色与职责
项目负责人负责风险管理。
项目成员协助项目负责人处理风险。
启动准则
《项目计划》已经制定,项目研发已经开始。
输入
《项目计划》
项目监控过程产生的文档如《项目问题列表》 、《项目质量报告》和《项目周报》等
主要步骤
风险识别
项目负责人根据“风险跟踪列表” ,定期(例如每周一次)识别本项目的风险。
风险分析
项目负责人评估每个风险的严重性、可能性和风险系数,并按照风险系数从高到低的顺序排列风险。
风险减缓
对于风险系数超过“容许值”(建议为 10)的每一个风险,项目负责人应当给出风险减缓措施,并指定责任人。风险系数越高,越先处理。
风险监控
项目负责人跟踪风险减缓过程,直到风险已经解决为止。如果风险的性质发生变化,应当及时更新风险减缓措施
输出
《风险管理报告》
结束准则
所有风险都已经解决,相关信息已经记录到《风险管理报告》之中。
度量
项目负责人统计工作量。
实施建议
对风险管理过程域产生的所有有价值的文档进行配置管理。
项目负责人根据本项目的特征,确定风险识别的频度(通常为每周一次) ,适当修改“风险登记表”。
选用合适的软件工具,尽量减少风险管理过程域的工作量。
项目监控和风险管理均由项目负责人负责,建议同步执行。
附录 1:常见风险举例
▲进度安排制定得是否合理?
▲WBS 的分析是否足够细,以便对进度做较贴切的安排?
进度风险 ▲对交付日期的要求是否严格?
▲是否可以为了满足严格进度安排而对产品功能进行让步放行?
▲计划是否为过程管理预留时间?
▲对产品的需求是否和涉众认同一致?
▲需求是否有优先级排列?
▲对需求的变化是否建立了相应的管理机制并实施?
规模风险
外部依赖风险
▲对需求的变化是否做相应的分析?
▲需求是否稳定并达到了充分的共识?
▲规模的估计方法是否正确掌握和使用?
▲项目规模是固定不变还是在不断扩展或变更?
▲项目开发规模或范围预估是否正确?
▲系统是否依赖于新的或未经试验的产品、 服务或技术?是否依赖于新的或未被证明的硬件、软件或技术?
▲对于与其他系统(包括企业以外的系统)的接口是否存在外部依赖性?
▲该项目是否依赖于其他(平行的)开发项目?
▲所采用技术是否已经过使用?
▲使用的组件是否被成功的重复使用?重复使用的组件是否合理?
▲数据量是否合理?当前可用的系统框架是否能够保存这些数据?
▲是 否有 特殊 或苛刻 的技术 需求 (如 要求项 目团队 处理 他们 不熟悉 的问题)?
技术风险 ▲是否存在极不灵活的可用性和安全性需求(如“系统必须永远不出现故 障”)?
▲系统的用户是否对正在开发的系统类型没有经验?
▲应用程序的大小或复杂性是否导致了风险的增加?
▲成功是否依赖于开发工具 (设计工具、编译器等) 和实施技术(操作系统、数据库、进程间通信机制等)的成功集成。是否有替代计划,可以在没有这些
技术的情况下交付项目?
▲是否获得必要的人员(测试人员、 QA、SCM 人员)?
▲项目人员是否具备合适的技能和经验以及接受过相应培训?
人员
▲项目人员是否会有突然接受其他任务的可能性?
▲他们对项目成功是否有信心和决心?
▲完成项目所需的资金能否到位?
▲完成项目所需的资金能否到位?
▲是否有预算限制?
资金
▲项目的成本预算是否准确?
▲是否有预留风险管理等资金?
▲用户的
文档评论(0)