《Tool9-项目风险评估表》由会员分享，可在线阅读，更多相关《Tool9-项目风险评估表（11页珍藏版）》请在金锄头文库上搜索。
1、 项目风险评估表项目名称:报告人:日期 (年/月/日):1. 项目风险评估表使用指南第一部分风险评估问卷 使用此表中的第一部分来识别项目风险及其对完成项目目标的影响程度。在这一部分中，将根据风险特征来进行风险分类，共分为高，中，低三个档。这个风险分类表并非完全的，而只是风险识别的开始。对于不同的组织或项目，必须因地制宜地添加具体的风险特征或指标。为了完成此问卷，要尽量选择最能在项目评估时表现项目特征的描述词。同时要确保完成项目计划风险评估检查表。 完成后的问卷和检查表将会识别出项目风险要素。此结果应被用作风险管理和监控的指南；当然也许还有其他要素会影响风险的影响程度。例如高度复杂的项目会有较高
2、的部风险，而当一个有经验的项目经理来领导此项目时该风险就会降低。高风险特性多的项目并不意味着一定会失败，而是意味着必须制定和执行一个计划来识别每个潜在的高风险因素。 第二部分常见的高风险问题/应对行动注意：不同的风险承受度应制定不同的应对计划。 运用此表的第二部分来分析已识别的风险，并制定相契合的应对计划。在这个部分中列出了：可能会导致某种高风险的早期预警信号，问题案例，以及可以用来降低或应对每个风险的行动案例。 在风险应对计划表中，需对每个在第一部分中识别的高风险要素制定应对计划，以降低此风险，从而保障项目的成功。除了将第二部分中的行动案例作为可能的应对计划，项目团队也可以提出更多的建议。在
3、对所有高风险要素制定了应对计划后，项目团队应检查可能存在的中度风险，并且明确这些风险是否严重到也需要使用风险应对计划表。如果是，请使用风险应对计划表为中度风险要素制定应对计划。而低风险因素可能只是一些假设，也就是说它们可能会产生问题但因为影响程度低所以你“假设”这种情况并不会发生。在整个项目过程都要使用风险应对计划来管理和监控风险。第一部分风险评估问卷Characteristics 风险特征Low Risk 低Medium Risk 中High Risk 高ORGANIZATION 组织A. 围A1项目围是: 明确且了解的 大部分确认但可能改变 不明确且/或可能改变A2.公司/商务需求: 了解
4、且符合 瞭解但极为复杂,或符合但未明确定义 非常复杂或非常模糊A3.系统可用性包括 可使用的通路及其停工期 需连续使用A4.预估总需求人力小时数: 低于1,000小时 1,000 至 5,000小时 远大于5,000小时A5.现有资料的质量: 好且易于使用 明确但难以使用,或不明确但易于使用 差或难以使用A6.项目的执行: 不需客制化 需要客制化 需要高度客制化A7.项目的执行: 稳定的产品或市场宣传模式 新产品或新的市场宣传模式B. 时程B1.项目主要里程碑和完成日期: 弹性 可由用户和项目组员商议后决定 确定 已定且脱期后可能会影响商机 刚性 已由具体的营运委员会决定,或规定的要求超过项目
5、团队的掌控能力B2.预估项目周期: 低于 3 个月 3 到 12 个月 远大于 12 个月C. 预算C1.预算是由有经验的人,使用已证实有效的成本预估程序来生成: 是 由有经验的人操作有效的预算程序 有一些经验或程序 否 人员无经验且无程序C2.项目资金符合或大于成本预算和稳定性. 预算大于需求且/或预期稳定. 预算等于成本且预期相对稳定. 预算低于需求且/或稳定性高度不确定.D. 项目关联性D1.本项目依赖相关项目的关系可以形容为: 轻微依赖, 即使没有相关项目的产出仍可完成 有些依赖,没有相关项目的产出可能造成延期 高度依赖, 无相关项目的产出无法继续进行E. 人力资源E1.项目经理的经验
6、和培训是: 最近在类似项目管理上取得了成功 最近在非类似项目管理上取得了成功或经过培训但无经验 无近期经验或未经项目管理培训E2.依需要管理工具和技术的使用来描绘项目组员. 熟练使用工具和技术 对使用工具和技术经过正式的培训,但少或无实际经验 无正式培训或无实际使用经验E3.项目组员是: 同处一地 分处多处F. 发起人/高层领导的支持F1.项目发起人是: 明确的，对项目认可且充满热情的 明确的，但缺乏热情的 既不明确也缺乏热情G. 其他生意或组织上的影响G1.是否需要能够提供项目所需相关知识技能的项目参与人： 项目中不需要或项目组成员已经具有丰富的相关知识 在某些方面经验不足 没有或当下没有找
7、到合适的人选G2是否需要改变组织流程和政策： 完全不需要或很少 偶尔到经常性的改变 实质性的改变G3.描述项目结果对业务流程或组织变革的影响： 没有或只是很微小的变迁 中度变迁 重大变革或目前还不清楚G4.将受到此改变影响的部门： 一个或两个 三个或四个 五个以上G5.项目的接收部门和利益相关部门对于该项目将带来的变化的接受度，你会怎么评分？ 高接受度（充满热情和期待） 一般接受度 低接受度（消极且很难融入）GENERAL Technical and Performance Risks 整体 技术和绩效风险H. 技术H1.将会用到的技术是： 成熟的（已在使用的软件，硬件，专业术语，数据库和工具
8、） 演进中的 实验性的（新的软件，硬件，语言，数据库，工具或最新推出的） H2.对技术的要求： 与公司其他使用的类似 全新的，复杂的H3.技术的重点： 项目组成员都很清楚 项目组成员并不清楚I. 绩效I1.绩效目标： 明确，合理 不清晰，不明确，不现实（例如：每件事都要很完美） 项目管理计划，问题和变革管理，质量保障J. 风险评估J1.通过项目管理风险评估检查表来进行项目风险管理的整体评估 制定了很完整的项目计划，并且能够运用组织中的项目管理方法来实现 合理的，基本完成的项目计划和流程，但是仍然有一些问题没有明确 没有连续性的完整的项目计划，即使有质量也不高，同时/或者在项目流程中有许多关键性
9、的问题没有明确外部供应商，法律，环境，条例K. 供应商K1.如果需要局部的委外执行： 供应商对市场很熟悉 供应商刚刚进入该市场K2.项目是否需要承包商？承包商是否对项目做出了承诺？ 不需要承包商 需要一些承包商（少于50%），而且在项目开始之前承包商会接到明确的任务 50%以上的项目工作将交给承包商，但是在项目开始之前承包商并不清楚其全部任务L. 其他（根据项目实际情况来添加）L1.第二部分典型的高风险问题/应对行动高风险要素/潜在问题 风险应对行动A. 围A1.项目围模糊不清： 难以作出合理的预测评估 可能会花时间和成本在项目围之外 难以收集准确的需求信息 难以明确项目定义和工作计划 难以制
10、定围变更程序 无法明确项目交付品 在计划中严格地定义项目围 明确项目围的各要素，例如哪些部门会受到影响，需要哪些项目交付品，需要哪类信息 清晰明确哪些是项目围之外的(本项目不包含:) 从一开始就将业务需求定义在较高的层次，然后以此由下至上的来定义项目围 让项目发起人对冲突的项目围作出决策 在对项目任务，成本或周期进行评估时记录下所有的围假设 运用图表来标识项目围和替代方法 预先制定严格的围变更程序 确保正式性地通过项目定义和业务需求并且获得相应的资源配备 将围说明分发给所有的项目利益相关人以获得确认 在项目围没有清晰明确之前不要开始项目A2.项目的业务需求很模糊或复杂： 难以正确地记录相关需求
11、 难以使用工具来记录相关需求 难以明确项目期望是什么 有可能项目最终交付品无法达到业务的要求 可能是缺乏客户关注和信息的信号 运用合作应用程序设计（JAD）来收集所有项目利益相关人的需求 使用原型重复式开发的技术来帮助发掘使用者对新系统的需求 与项目发起人，高层管理者沟通以获得全面的指导 为客户提供培训，让其明白如何思考和表达其业务需求 确保将最终明确的业务需求记录在案，并执行相应的变更管理程序A3.需要连续地使用系统： 检修或事故问题可能会导致产量的降低或收益的减少 可能需要创造部分冗余，因此增加系统的复杂度 可能需要更新，更先进的技术 需要更多的程序和流程来维护系统环境 分配更多的时间来分
12、析，设计，测试系统并实施全面质量保障行动 将更多的时间和精力放在技术架构上 将更多的时间和精力放在数据库设计上 使用行业最优的技术和流程 为项目组提供相应的培训，使其了解连续地使用系统意味着什么 准确地指出究竟需要连续地使用系统的哪个部分 寻求部或外部的专家来验收整体的技术设计和架构 制定坚实可靠的灾难复原计划 与软件和硬件供应商建立和发展良好的伙伴关系A4.高预期工作量： 高工作量意味着项目很复杂，需要投入大量的人力 更难以有效地与团队沟通 当需要快速决策时瓶颈就会出现 更可能出现人员问题 可能会有更高的人员流动率 需要培训更多的人 使用项目管理工具来控制资源的使用 让项目组成员使用周报表来监控他们所分配的工作任务的进展程度 任命小组长来管理下属小组 通过组织团队建设活动来建立团队凝聚力 召开计划进度会议，让人们知晓项目进展状况 使用部系统流程进行围，问题，质量和风险管理 将项目分解成更小的，周期更短的小项目 为
