项目风险评估表改.doc

文档介绍：项目风险评估表改
2 / 14
项目风险评估表
项目名称:
报告人:
日期 (年/月/日):
1. 项目风险评估表使用指南
第一部分
风险评估问卷
使用此表中的第一部分来识别项目风险及
H2.
对技术的要求：
[ ]与公司其他使用的类似
[ ]全新的，复杂的
 
 
 
 
 
H3.
技术的重点：
[ ]项目组成员都很清楚
[ ]项目组成员并不清楚
I. 绩效
I1.
绩效目标：
[ ]明确，合理
[ ]不清晰，不明确，不现实（例如：每件事都要很完美）
项目管理—计划，问题和变革管理，质量保障
J. 风险评估
 
J1.
通过项目管理风险评估检查表来进行项目风险管理的整体评估
[ ]制定了很完整的项目计划，并且能够运用组织中的项目管理方法来实现
[ ]合理的，基本完成的项目计划和流程，但是仍然有一些问题没有明确
[ [ ]没有连续性的完整的项目计划，即使有质量也不高，同时/或者在项目流程中有许多关键性的问题没有明确
外部—供应商，法律，环境，条例
K. 供应商
 
K1.
如果需要局部的委外执行：
[ ]供应商对市场很熟悉
[ ]供应商刚刚进入该市场
K2.
项目是否需要承包商？承包商是否对项目做出了承诺？
[ ]不需要承包商
[ ]需要一些承包商（少于50%），而且在项目开始之前承包商会接到明确的任务
[ ]50%以上的项目工作将交给承包商，但是在项目开始之前承包商并不清楚其全部任务
L. 其他（根据项目实际情况来添加）
L1.
第二部分
典型的高风险问题/应对行动
高风险要素/潜在问题
风险应对行动
A. 范围
5 / 14
第二部分
典型的高风险问题/应对行动
高风险要素/潜在问题
风险应对行动
A1.
项目范围模糊不清：
难以作出合理的预测评估
可能会花时间和成本在项目范围之外
难以收集准确的需求信息
难以明确项目定义和工作计划
难以制定范围变更程序
无法明确项目交付品
在计划中严格地定义项目范围
明确项目范围的各要素，例如哪些部门会受到影响，需要哪些项目交付品，需要哪类信息
清晰明确哪些是项目范围之外的(本项目不包含:…)
从一开始就将业务需求定义在较高的层次，然后以此由下至上的来定义项目范围
让项目发起人对冲突的项目范围作出决策
在对项目任务，成本或周期进行评估时记录下所有的范围假设
运用图表来标识项目范围和替代方法
预先制定严格的范围变更程序
确保正式性地通过项目定义和业务需求并且获得相应的资源配备
将范围说明分发给所有的项目利益相关人以获得确认
在项目范围没有清晰明确之前不要开始项目
A2.
项目的业务需求很模糊或复杂：
难以正确地记录相关需求
难以使用工具来记录相关需求
难以明确项目期望是什么
有可能项目最终交付品无法达到业务的要求
可能是缺乏客户关注和信息的信号
运用合作应用程序设计（JAD）来收集所有项目利益相关人的需求
使用原型—重复式开发的技术来帮助发掘使用者对新系统的需求
与项目发起人，高层管理者沟通以获得全面的指导
为客户提供培训，让其明白如何思考和表达其业务需求
确保将最终明确的业务需求记录在案，并执行相应的变更管理程序
A3.
需要连续地使用系统：
检修或事故问题可能会导致产量的降低或收益的减少
可能需要创造部分冗余，因此增加系统的复杂度
可能需要更新，更先进的技术
需要更多的程序和流程来维护系统环境
分配更多的时间来分析，设计，测试系统并实施全面质量保障行动
将更多的时间和精力放在技术架构上
将更多的时间和精力放在数据库设计上
使用行业最优的技术和流程
为项目组提供相应的培训，使其了解连续地使用系统意味着什么
准确地指出究竟需要连续地使用系统的哪个部分
寻求内部或外部的专家来验收整体的技术设计和架构
制定坚实可靠的灾难复原计划
与软件和硬件供应商建立和发展良好的伙伴关系
6 / 14
第二部分
典型的高风险问题/应对行动
高风险要素/潜在问题
风险应对行动
A4.
高预期工作量：
高工作量意味着项目很复杂，需要投入大量的人力
更难以有效地与团队沟通
当需要快速决策时瓶颈就会出现
更可能出现人员问题
可能会有更高的人员流动率
需要培训更多的人
使用项目管理工具来控制资源的使用
让项目组成员使用周报表来监