XX项目评价表

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

1. 项目风险评估表使用指南风险评估问卷第一部分

第二部分应对行动—注意:不同的风险承受度应制定不同的应对计划。/常见的高风险问题

第二部分典型的高风险问题/应对行动风险应对行高风险要潜在问题 A. 范围在计划中严格地定义项目范围A1 项目范围模糊不清:?.

明确项目范围的各要素,例如哪些部门难以作出合理的预测评估??

会受到影响,需要哪些项目交付品,需可能会花时间和成本在项目范围之外?要哪类信息难以收集准确的需求信息?本项目清晰明确哪些是项目范围之外的(?

难以明确项目定义和工作计划?)

…不包含: 难以制定范围变更程序从一开始就将业务需求定义在较高的层??次,然后以此由下至上的来定义项目范无法明确项目交付品?围让项目发起人对冲突的项目范围作出决?策在对项目任务,成本或周期进行评估时?记录下所有的范围假设运用图表来标识项目范围和替代方法?预先制定严格的范围变更程序?确保正式性地通过项目定义和业务需求?并且获得相应的资源配备将范围说明分发给所有的项目利益相关?人以获得确认在项目范围没有清晰明确之前不要开始?项目

)来收集运用合作应用程序设计(JADA2项目的业务需求很模糊或复杂:?

.

所有项目利益相关人的需求难以正确地记录相关需求?使用原型—重复式开发的技术来帮助发?难以使用工具来记录相关需求?掘使用者对新系统的需求难以明确项目期望是什么?与项目发起人,高层管理者沟通以获得?有可能项目最终交付品无法达到业务的要求?全面的指导可能是缺乏客户关注和信息的信号为客户提供培训,让其明白如何思考和??表达其业务需求确保将最终明确的业务需求记录在案,?并执行相应的变更管理程序

第二部分典型的高风险问题/应对行动

风险应对行动高风险要素/潜在问题分配更多的时间来分析,设计,测试系A3需要连续地使用系统:?

.

统并实施全面质量保障行动检修或事故问题可能会导致产量的降低或收益的减少?将更多的时间和精力放在技术架构上?可能需要创造部分冗余,因此增加系统的复杂度?将更多的时间和精力放在数据库设计上?可能需要更新,更先进的技术?使用行业最优的技术和流程?需要更多的程序和流程来维护系统环境?连为项目组提供相应的培训,使其了解?

续地使用系统意味着什么准确地指出究竟需要连续地使用系统的?

哪个部分寻求内部或外部的专家来验收整体的技?

术设计和架构制定坚实可靠的灾难复原计划?

与软件和硬件供应商建立和发展良好的?

伙伴关系

使用项目管理工具来控制资源的使用A4高预期工作量:?

.

高工作量意味着项目很复杂,需要投入大量的人力让项目组成员使用周报表来监控他们所??

分配的工作任务的进展程度更难以有效地与团队沟通?任命小组长来管理下属小组?当需要快速决策时瓶颈就会出现?通过组织团队建设活动来建立团队凝聚?更可能出现人员问题?力可能会有更高的人员流动率?召开计划进度会议,让人们知晓项目进?需要培训更多的人?展状况使用内部系统流程进行范围,问题,质?量和风险管理将项目分解成更小的,周期更短的小项?目为了让项目组成员意识到其他相关的人?员和小组活动,减少每个人每天可用的项目工作时间.

第二部分典型的高风险问题/应对行动

风险应对行动潜在问题高风险要素/确保所有旧数据都毫无差错地转换到了A5目前数据质量太低难以进行转换:?.

新的系统中需要做更多的工作来把旧的数据转换到新的系统中?在进行最终的转换前要严格地测试转换?过滤后的数据仍然可能在新系统中造成问题?程序数据转换问题能够导致严重的项目延期?评估由于转换数据而花费的成本和造成?的困难是有价值的。弄清楚新的系统是否只能运转新的数据让旧的系统维持运转一段时间以获取旧?

的数据在数据转换之前尽可能地对旧的数据进?

行人工过滤

考虑其他的打包工具A6需要高度定制化的打包执行:?

.

定制化会使项目更加复杂考虑定制化的发展??

对某一部分的修改可能会导致其他部分的问题减少业务需求,这样也不用定制化了??定制化会导致绩效低下从供应商处获得确定的修改成本和周??

期,并将其记录进你的整体工作计划定制化会让新技术的运用变得更复杂?管理与供应商的关系,确保所有必须的?大量的定制化可能意味着之前选择了错误的打包工具?工作都能按时完成很有可能要花更长的时间来实施打包工具?确保项目发起人通过定制化方案?定制化会需要更多地依赖供应商?为保证正常运作和绩效,全面彻底地测?试修改后的打包工具利用供应商日志来追踪问题和项目里程?碑

尽早为项目组成员安排打包工具的相关A7打包执行是一个全新的产品:?

.

培训会有更大的问题风险?为项目增派一个有相关产品经验的内部?更多地依赖供应商来确保迅速地解决问题?资源或咨询师安装,测试和配置使用将需要更长的周期?在全面实施之前安排打包工具的试点,?几乎很难预知这个打包工具是否符合所有的业务需求?使项目组尽快熟悉起来与供应商就支持度

和问题解决时间达成?共识如果有其他公司也在使用同样的产品,?看看能不能将项目延期到其使用时间之后搜寻其他使用过该产品的公司,寻求他?

们的反馈和关键所得B. 时程

第二部分典型的高风险问题/应对行动

风险应对行动/潜在问题高风险要素根据必需的项目活动对排程再进行协商B1项目重要里程碑和/或完成日期是固定的,但这是由于业?

. 务承诺或法律要求而被事先固定的,不受项目组的控和谈判制:对范围再进行协商和谈判,使项目活动?

工作必须以这个日期期限为指导能够在规定的时间内完成?可能无法在期限内完成所有必需的项目活动根据实际的预测评估与客户/项目所有者/ ??项目发起人重新建立新的共识很有可能无法达到排程的要求?执行积极的项目跟踪和监控计划?赶工和时程的压力很有可能导致项目工作中无法改正?进行常规性的时程报告及沟通的错误?

将项目分解成更小的,周期更短的小项B2:

预测项目周期会很长?.

目更难管理项目排程?明确项目里程碑,使其按进度发展和完?使项目组和客户更加容易失去焦点和重心?成项目很有可能会失去组织的支持和承诺?要持续不断地使用正式的变动管理程序?业务需求很有可能会变化?轮换项目组成员的角色,保持其持续较?软件或硬件版本(技术和工具)很有可能会变化?高的兴趣度很难在项目开始时营造紧迫感尽可能地走在预计进度前面??很有可能造成项目组成员和客户的流失在项目初始阶段就营造一种紧迫感??组织团队建设活动,建立团队凝聚力防?止人心涣散确保所有的重要交付品都正式通过,然?后再引入变革管理使技术设计和架构决策尽可能的灵活,?为潜在的变更做好准备 C. 预算使用成熟的工具或有经验的个人重新评C1预算不是使用已证实有效的成本预估程序或有经验的个?. 估项目人建立的:

修改项目范围, 使其能够纳入可用的资金预算很有可能不准确??范围内设计的预算计划不便于跟踪和监控?在未优化原预算计划之前不要开始项目?对于哪些工作能在预算内完成会有不现实的期望?

对项目范围再进行协商和谈判,使其能C2项目资金到位比预算少,而且不稳定:?.

够纳入可用的资金范围内项目不可能完成预期的目标?在获得充足的预算或减少项目范围之前?项目很有可能超出其预备资金?不要开始项目 D. 项目关联性.

第二部分典型的高风险问题/应对行动

风险应对行动高风险要素/潜在问题修改其中一个或所有的项目排程,使项D1项目高度依赖于另外一个独立的关联项目,如果没有收?. 到关联项目的最终交付品就无法展开:目交付品能够整合起来

不在项目控制范围内的事情能够严重地影响项目的产对项目范围和/或排程再次进行协商和谈??

出和实现目标的能力判

关联项目的交付品如果延期就很有可能造成项目进度就满足项目的需求与关联项目达成共??

的延迟识,并将其记录在案

为了最大限度地减少冲突,两个项目要?

紧密合作和相互监控E. 人力资源提供事前的项目管理培训E1 缺乏项目管理经验:?.

指派一个更高层管理者来辅导项目经理可能要花更长的时间来定义项目和建立工作计划??建立并执行有力的质量保障流程来确保可能会有更多判断上的失误,导致返工或项目延期??项目正常的开展更难以组织和管理一个复杂的项目?确保重要交付品正式通过?可能对全面的项目管理实践不熟悉?通过有力的团队领导和团队成员带来更?可能不知道何时应该寻求帮助?多相关经验

相关文档
最新文档