logo资料库

项目风险评估表.doc

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

    相关推荐

    资料库

    信息化

    共收录1827份资料，累计6个分类，关注成员有19位，主要包括：管理软件,企业管理,电子商务,其它,IT管理,项目管理

    热门标签

    管理软件 企业管理 电子商务 其它 IT管理 项目管理

    最新资料