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