XX项目评估表

整理文档很辛苦,赏杯茶钱您下走!

免费阅读已结束,点击下载阅读编辑剩下 ...

阅读已结束,您可以下载文档离线阅读编辑

资源描述

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

1 / 12
下载文档,编辑使用

©2015-2020 m.777doc.com 三七文档.

备案号:鲁ICP备2024069028号-1 客服联系 QQ:2149211541

×
保存成功