项目风险评估表.pdf

文档介绍：该【项目风险评估表 】是由【熙凤】上传分享，文档一共【15】页，该文档可以免费在线阅读，需要了解更多关于【项目风险评估表 】的内容，可以使用淘豆网的站内搜索功能，选择自己适合的文档，以下文字是截取该文章内的部分文字，如需要获得完整电子版，请下载此文档到您的设备，方便您编辑和打印。:.
项目风险评估表
项目名称:
报告人:
日期(年/月/日):

第一部分风险评估问卷
使用此表中的第一部分来识别项目风险及其对完成项目目标的影响程度。在这一部分中,将根据风险
特征来进行风险分类,共分为高,中,低三个档。这个风险分类表并非完全的,而只是风险识别的开
始。对于不同的组织或项目,必须因地制宜地添加具体的风险特征或指标。为了完成此问卷,要尽量
选择最能在项目评估时表现项目特征的描述词。同时要确保完成项目计划风险评估检查表。
完成后的问卷和检查表将会识别出项目风险要素。此结果应被用作风险管理和监控的指南;当然也许
还有其他要素会影响风险的影响程度。例如高度复杂的项目会有较高的内部风险,而当一个有经验的
项目经理来领导此项目时该风险就会降低。高风险特性多的项目并不意味着一定会失败,而是意味着
必须制定和执行一个计划来识别每个潜在的高风险因素。
第二部分常见的高风险问题/应对行动—注意:不同的风险承受度应制定不同的应对计划。
运用此表的第二部分来分析已识别的风险,并制定相契合的应对计划。在这个部分中列出了:可能会
导致某种高风险的早期预警信号,问题案例,以及可以用来降低或应对每个风险的行动案例。
在风险应对计划表中,需对每个在第一部分中识别的高风险要素制定应对计划,以降低此风险,从而
保障项目的成功。除了将第二部分中的行动案例作为可能的应对计划,项目团队也可以提出更多的建
议。在对所有高风险要素制定了应对计划后,项目团队应检查可能存在的中度风险,并且明确这些风
险是否严重到也需要使用风险应对计划表。如果是,请使用风险应对计划表为中度风险要素制定应对
计划。而低风险因素可能只是一些假设,也就是说它们可能会产生问题但因为影响程度低所以你“假
设”这种情况并不会发生。在整个项目过程都要使用风险应对计划来管理和监控风险。
Page1
:.
第一部分风险评估问卷
Characteristics风险特征LowRisk低MediumRisk中HighRisk高
ORGANIZATION组织

A1项目范围是:[]明确且了解的[]大部分确认但可能改[]不明确且/或可能改变
变
:[]了解且符合[]瞭解但极为复杂,或符[]非常复杂或非常模糊
合但未明确定义
[]可使用的通路及其停[]需连续使用
工期
:[]低于1,000小时[]1,000至5,000小时[]远大于5,000小时
:[]好且易于使用[]明确但难以使用,或不[]差或难以使用
明确但易于使用
:[]不需客制化[]需要客制化[]需要高度客制化
:[]稳定的产品或市场宣[]新产品或新的市场宣
传模式传模式

[]弹性–可由用户和项[]确定–已定且脱期后可[]刚性–已由具体的营运
期:目组员商议后决定能会影响商机委员会决定,或规定的要
求超过项目团队的掌控能
力
:[]低于3个月[]3到12个月[]远大于12个月

,使用[]是–由有经验的人操[]有一些经验或程序[]否–人员无经验且无
已证实有效的成本预估程序作有效的预算程序程序
来生成:
[]预算大于需求且/或预[]预算等于成本且预期[]预算低于需求且/或稳
.

Page2
:.
第一部分风险评估问卷
Characteristics风险特征LowRisk低MediumRisk中HighRisk高
[]轻微依赖,即使没有相[]有些依赖,没有相关项[]高度依赖,无相关项目
可以形容为:关项目的产出仍可完成目的产出可能造成延期的产出无法继续进行

:[]最近在类似项目管理[]最近在非类似项目管[]无近期经验或未经项
上取得了成功理上取得了成功或经过培目管理培训
训但无经验
[]熟练使用工具和技术[]对使用工具和技术经[]无正式培训或无实际
,但少或无使用经验
实际经验
:[]同处一地[]分处多处

:[]明确的,对项目认可[]明确的,但缺乏热情[]既不明确也缺乏热情
且充满热情的的

[]项目中不需要或项目[]在某些方面经验不足[]没有或当下没有找到
相关知识技能的项目参与组成员已经具有丰富的相合适的人选
人:关知识
G2是否需要改变组织流程和政[]完全不需要或很少[]偶尔到经常性的改变[]实质性的改变
策:
[]没有或只是很微小的[]中度变迁[]重大变革或目前还不
组织变革的影响:变迁清楚
:[]一个或两个[]三个或四个[]五个以上
[]高接受度(充满热情[]一般接受度[]低接受度(消极且很
部门对于该项目将带来的变和期待)难融入)
化的接受度,你会怎么评
分?
Page3
:.
第一部分风险评估问卷
Characteristics风险特征LowRisk低MediumRisk中HighRisk高
GENERAL–TechnicalandPerformanceRisks整体–技术和绩效风险

:[]成熟的(已在使用的[]演进中的[]实验性的(新的软
软件,硬件,专业术语,件,硬件,语言,数据
数据库和工具)库,工具或最新推出的)
:[]与公司其他使用的类[]全新的,复杂的
似
:[]项目组成员都很清楚[]项目组成员并不清楚

:[]明确,合理[]不清晰,不明确,不
现实(例如:每件事都要
很完美)
项目管理—计划,问题和变革管理,质量保障

[]制定了很完整的项目[]合理的,基本完成的[[]没有连续性的完整的
表来进行项目风险管理的整计划,并且能够运用组织项目计划和流程,但是仍项目计划,即使有质量也
体评估中的项目管理方法来实现然有一些问题没有明确不高,同时/或者在项目
流程中有许多关键性的问
题没有明确
外部—供应商,法律,环境,条例

:[]供应商对市场很熟悉[]供应商刚刚进入该市
场
?承包[]不需要承包商[]需要一些承包商(少[]50%以上的项目工作
商是否对项目做出了承诺?于50%),而且在项目将交给承包商,但是在项
开始之前承包商会接到明目开始之前承包商并不清
确的任务楚其全部任务
(根据项目实际情况来添加)
L1.
Page4
:.
第二部分典型的高风险问题/应对行动
高风险要素/潜在问题风险应对行动

A1项目范围模糊不清:在计划中严格地定义项目范围
.
难以作出合理的预测评估明确项目范围的各要素,例如哪些部门
会受到影响,需要哪些项目交付品,需
可能会花时间和成本在项目范围之外
要哪类信息
难以收集准确的需求信息
清晰明确哪些是项目范围之外的(本项目
难以明确项目定义和工作计划不包含:…)
难以制定范围变更程序从一开始就将业务需求定义在较高的层
无法明确项目交付品次,然后以此由下至上的来定义项目范
围
让项目发起人对冲突的项目范围作出决
策
在对项目任务,成本或周期进行评估时
记录下所有的范围假设
运用图表来标识项目范围和替代方法
预先制定严格的范围变更程序
确保正式性地通过项目定义和业务需求
并且获得相应的资源配备
将范围说明分发给所有的项目利益相关
人以获得确认
在项目范围没有清晰明确之前不要开始
项目
A2项目的业务需求很模糊或复杂:运用合作应用程序设计(JAD)来收集
.所有项目利益相关人的需求
难以正确地记录相关需求
使用原型—重复式开发的技术来帮助发
难以使用工具来记录相关需求
掘使用者对新系统的需求
难以明确项目期望是什么
与项目发起人,高层管理者沟通以获得
有可能项目最终交付品无法达到业务的要求全面的指导
可能是缺乏客户关注和信息的信号为客户提供培训,让其明白如何思考和
表达其业务需求
确保将最终明确的业务需求记录在案,
并执行相应的变更管理程序
Page5
:.
第二部分典型的高风险问题/应对行动
高风险要素/潜在问题风险应对行动
A3需要连续地使用系统:分配更多的时间来分析,设计,测试系
.统并实施全面质量保障行动
检修或事故问题可能会导致产量的降低或收益的减少
可能需要创造部分冗余,因此增加系统的复杂度将更多的时间和精力放在技术架构上
将更多的时间和精力放在数据库设计上
可能需要更新,更先进的技术
需要更多的程序和流程来维护系统环境使用行业最优的技术和流程
为项目组提供相应的培训,使其了解连
续地使用系统意味着什么
准确地指出究竟需要连续地使用系统的
哪个部分
寻求内部或外部的专家来验收整体的技
术设计和架构
制定坚实可靠的灾难复原计划
与软件和硬件供应商建立和发展良好的
伙伴关系
A4高预期工作量:使用项目管理工具来控制资源的使用
.
高工作量意味着项目很复杂,需要投入大量的人力让项目组成员使用周报表来监控他们所
分配的工作任务的进展程度
更难以有效地与团队沟通
任命小组长来管理下属小组
当需要快速决策时瓶颈就会出现
通过组织团队建设活动来建立团队凝聚
更可能出现人员问题
力
可能会有更高的人员流动率
召开计划进度会议,让人们知晓项目进
需要培训更多的人展状况
使用内部系统流程进行范围,问题,质
量和风险管理
将项目分解成更小的,周期更短的小项
目
为了让项目组成员意识到其他相关的人
员和小组活动,减少每个人每天可用的
项目工作时间
Page6
:.
第二部分典型的高风险问题/应对行动
高风险要素/潜在问题风险应对行动
A5目前数据质量太低难以进行转换:确保所有旧数据都毫无差错地转换到了
.新的系统中
需要做更多的工作来把旧的数据转换到新的系统中
过滤后的数据仍然可能在新系统中造成问题在进行最终的转换前要严格地测试转换
程序
数据转换问题能够导致严重的项目延期
评估由于转换数据而花费的成本和造成
的困难是有价值的。弄清楚新的系统是
否只能运转新的数据
让旧的系统维持运转一段时间以获取旧
的数据
在数据转换之前尽可能地对旧的数据进
行人工过滤
A6需要高度定制化的打包执行:考虑其他的打包工具
.
定制化会使项目更加复杂考虑定制化的发展
对某一部分的修改可能会导致其他部分的问题减少业务需求,这样也不用定制化了
定制化会导致绩效低下从供应商处获得确定的修改成本和周
期,并将其记录进你的整体工作计划
定制化会让新技术的运用变得更复杂
管理与供应商的关系,确保所有必须的
大量的定制化可能意味着之前选择了错误的打包工具
工作都能按时完成
很有可能要花更长的时间来实施打包工具
确保项目发起人通过定制化方案
定制化会需要更多地依赖供应商
为保证正常运作和绩效,全面彻底地测
试修改后的打包工具
利用供应商日志来追踪问题和项目里程
碑
A7打包执行是一个全新的产品:尽早为项目组成员安排打包工具的相关
.培训
会有更大的问题风险
为项目增派一个有相关产品经验的内部
更多地依赖供应商来确保迅速地解决问题
资源或咨询师
安装,测试和配置使用将需要更长的周期
在全面实施之前安排打包工具的试点,
几乎很难预知这个打包工具是否符合所有的业务需求使项目组尽快熟悉起来
与供应商就支持度和问题解决时间达成
共识
如果有其他公司也在使用同样的产品,
看看能不能将项目延期到其使用时间之
后
搜寻其他使用过该产品的公司,寻求他
们的反馈和关键所得

Page7
:.
第二部分典型的高风险问题/应对行动
高风险要素/潜在问题风险应对行动
B1项目重要里程碑和/或完成日期是固定的,但这是由于业根据必需的项目活动对排程再进行协商
.务承诺或法律要求而被事先固定的,不受项目组的控和谈判
制:
对范围再进行协商和谈判,使项目活动
工作必须以这个日期期限为指导能够在规定的时间内完成
可能无法在期限内完成所有必需的项目活动根据实际的预测评估与客户/项目所有者/
很有可能无法达到排程的要求项目发起人重新建立新的共识
执行积极的项目跟踪和监控计划
赶工和时程的压力很有可能导致项目工作中无法改正
的错误进行常规性的时程报告及沟通
B2预测项目周期会很长:将项目分解成更小的,周期更短的小项
.目
更难管理项目排程
明确项目里程碑,使其按进度发展和完
使项目组和客户更加容易失去焦点和重心
成
项目很有可能会失去组织的支持和承诺
要持续不断地使用正式的变动管理程序
业务需求很有可能会变化
轮换项目组成员的角色,保持其持续较
软件或硬件版本(技术和工具)很有可能会变化高的兴趣度
很难在项目开始时营造紧迫感尽可能地走在预计进度前面
很有可能造成项目组成员和客户的流失在项目初始阶段就营造一种紧迫感
组织团队建设活动,建立团队凝聚力防
止人心涣散
确保所有的重要交付品都正式通过,然
后再引入变革管理
使技术设计和架构决策尽可能的灵活,
为潜在的变更做好准备

C1预算不是使用已证实有效的成本预估程序或有经验的个使用成熟的工具或有经验的个人重新评
.人建立的:估项目
预算很有可能不准确修改项目范围,使其能够纳入可用的资金
范围内
设计的预算计划不便于跟踪和监控
对于哪些工作能在预算内完成会有不现实的期望在未优化原预算计划之前不要开始项目
C2项目资金到位比预算少,而且不稳定:对项目范围再进行协商和谈判,使其能
.够纳入可用的资金范围内
项目不可能完成预期的目标
在获得充足的预算或减少项目范围之前
项目很有可能超出其预备资金
不要开始项目

Page8
:.
第二部分典型的高风险问题/应对行动
高风险要素/潜在问题风险应对行动
D1项目高度依赖于另外一个独立的关联项目,如果没有收修改其中一个或所有的项目排程,使项
.到关联项目的最终交付品就无法展开:目交付品能够整合起来
不在项目控制范围内的事情能够严重地影响项目的产对项目范围和/或排程再次进行协商和谈
出和实现目标的能力判
关联项目的交付品如果延期就很有可能造成项目进度就满足项目的需求与关联项目达成共
的延迟识,并将其记录在案
为了最大限度地减少冲突,两个项目要
紧密合作和相互监控

E1缺乏项目管理经验:提供事前的项目管理培训
.
可能要花更长的时间来定义项目和建立工作计划指派一个更高层管理者来辅导项目经理
可能会有更多判断上的失误,导致返工或项目延期建立并执行有力的质量保障流程来确保
项目正常的开展
更难以组织和管理一个复杂的项目
确保重要交付品正式通过
可能对全面的项目管理实践不熟悉
通过有力的团队领导和团队成员带来更
可能不知道何时应该寻求帮助
多相关经验
E2不熟悉或并不准备使用项目管理流程:向项目经理和项目团队提供完整的项目
.管理流程和程序培训
项目团队可能无法知晓如何提出问题,范围变更和风
险为项目分派一位有经验的项目管理教练
当内部流程越来越复杂和难以管理时,项目有可能不或导师
受控制将整体项目分解成更小的项目,从而能
够进行较不严谨的项目管理
将缺乏良好的沟通
在项目开始之前明确并认同一套项目管
完成的项目交付品可能样式不统一
理程序,包括问题管理,变更管理,风
无法及时地提出问题,由于无法考量对项目的影响,险管理,和质量管理
范围变更也可能无法实行,风险可能被忽略,最终无
建立一个强有力的沟通计划,以确保每
法实现最优的质量
个成员都知道项目的进展并提供反馈
很有可能无法预期项目潜在的问题和困难
申请并获得随时对问题,风险,范围变
更和质量管理的投入
Page9
:.
第二部分典型的高风险问题/应对行动
高风险要素/潜在问题风险应对行动
E3分处多地的项目团队:试着将团队聚集到一个地方,或至少在
.项目启动的阶段
更难以有效地沟通
缺乏充分的团队互动和凝聚力建立一个积极的沟通计划确保有效地团
队沟通
很难与整个团队建立私人的关系
召开例会,让整个团队能够进行面对面
有些成员可能会感到被孤立,而非团队的一员的沟通
技术问题可能导致生产力下降安排团队建设活动,让整个项目组碰面
准备后备的沟通工具和方式,以防主要
的技术出现问题
与远距离的团队成员保持经常性的电话
联系
建立一个中央数据库,方便所有的团队
成员来查阅存储项目文件

F1没有明确的或正式授权的项目发起人:建立一个强有力的指导委员会来帮助指
.导整个项目
项目也许无法获得其所需的资源
为解决部门间的冲突建立一套流程
项目也许无法获得所必需的长期的承诺
政治斗争可能会使项目延期尝试更换成另一个发起人
请求发起人向另一个能够从项目利益出
问题和变更申请可能无法及时地得到解决
发的人授权
不要开始项目

G1提供项目知识的项目参与人或是无法加入项目或是仍未为了获得所需的项目知识,就资源承诺
.明确:进行再次协商和谈判
缺乏所需的项目知识将会为准确的完成项目带来负面为获得所需的项目知识,就项目进展进
的影响行再次协商或谈判
项目接收人将不会满意不要开始项目
Page10
:.
第二部分典型的高风险问题/应对行动
高风险要素/潜在问题风险应对行动
G2业务流程和政策需要实质性的改变:记录目前所有的政策和流程,确保他们
.的正确性
政策的改变会使项目延期
新的流程会使人们感到困惑,从而影响他们使用此流准确地阐述新旧流程之间的差别
程的能力尽可能早地就潜在的变迁进行沟通
有可能开始时无法完全地整合新的流程确保客户了解流程和政策的改变
如果新的流程无法完全地应对所有的突发状况,那它指定一个人来负责所有流程和政策的改
将是无用的变
如果没有正确的程序支持,系统功能将会瘫痪建立一个积极的沟通计划,使客户能够
随时了解和获得相关的信息
实质性的流程改变可能会导致破坏性行为
对新的流程进行试点,以确保他们的有
效性和准确性
将是否成功的实施新的政策和流程作为
项目经理绩效评估的一部分
向客户公开流程的改变以获得更好的建
议,同时让他们感到自己的影响力
G3组织结构需要实质性的改变:记录新的组织中存在的担忧,并寻找相
.应的办法来减轻这些担忧
组织的不确定会导致组织内的畏惧感
尽早地经常性地就潜在的变革和相应的
如果项目团队的注意力都放在了组织层面,那他们将
不会集中精力于项目上业务原因进行沟通
让所有利益相关者的代表都投入到组织
在新的组织中人们可能会担忧失去工作
的设计和规划中
如果人们不欢迎组织的变革,那他们可能不会使用新
投入人力资源来解决潜在的人员问题
的系统
不确定性可能会延迟决策
组织变革可能会造成以政治为目的的决策
G4大量的部门将会受到影响:建立一个正式的决议批准流程
.
协同合作会更加复杂建立一个代表整个利益相关团体的指导
委员会
通过或批准某项决议会更加麻烦和费时
让项目发起人参与到项目中,并随时准
更难以达成共识
备干涉不同的部门
计划和需求将涉及更多的人和团队
让每个组织的代表参与需求提出,质量
更难以了解不同部门的主要利益相关人保证和测试
执行会更加困难和复杂让来自不同部门的人有机会见面和互动
让项目组严格遵循整个项目目标和优先
顺序
在所有可能的情况下使用建立共识的技
巧
Page11
:.
第二部分典型的高风险问题/应对行动
高风险要素/潜在问题风险应对行动
G5客户的对项目的认可度低/很难互动:建立一个积极的沟通计划,让客户参与
.到项目中,并让其了解其中的商业利益
可能会导致对商业价值的信心不足
更难以从客户处获得所需的时间和资源建立用户小组,明确其关心的问题并激
发其积极性
更难以收集业务需求
让用户加入到计划和需求收集过程中
客户可能会破坏或阻碍项目的开展
让项目发起人帮助激起客户对项目的积
极性
寻找机会在轻松有趣的环境中推销项目
当需要客户的资源时,要积极地去得到
客户对此的承诺
不要开始项目

H1新的和不熟悉的项目技术(或新发布的):尽早提供对于新技术的实践性的培训
.
学****曲线可能会导致较低的初期产出向需要对新技术进行安装,使用和支持
的人员进行培训
可能存在新旧技术整合的问题
当需要时要充分利用供应商的技术专家
对技术变化的抵制可能会导致项目的延期
利用外部熟悉此技术的专业顾问
在测试新技术时可能会有困难
确保有足够的测试环境,这样使用新的
可能无法正确的安装或架构技术,而导致项目的延期
技术也不会影响产出
新的技术工具会导致更长的交付时间
确保对新技术的功能,特性和性能都进
新的技术可能会需要大量的转换工作行了彻底扎实的分析
当专业技术都用于优化和架构技术时,系统绩效可能对如何使用新的技术建立一套程序和规
会很差范
一开始在小范围对新技术实行试点
Page12
:.
第二部分典型的高风险问题/应对行动
高风险要素/潜在问题风险应对行动
H2新的,复杂的技术:利用系统和技术设计档案来弄清各项技
.术是如何组合起来的
可能很难理解需求和所需的设计
新旧技术间可能有整合问题明确整体系统技术架构,并请公司中有
经验的专业人员进行审查通过
可能很难测试复杂的技术
请外部的顾问审查架构建议书以获得更
技术越复杂,问题风险越大多的反馈和确认
在整合或系统测试完成后才能发现技术无法解决的问一开始在小范围内对新的技术进行试点
题
尽可能多的在架构中使用经过验证的和
熟悉的技术
使用同一供应商的复合产品以使整合系
统的过程更加流畅和容易
使用有公开标准和架构的产品以减少整
合问题带来的风险
H3项目团队对项目重点并不了解:尽早地提供实践性的培训
.
项目团队成员需要更长的学****曲线将关键客户带入项目团队中
项目可能会在开始阶段就脱节花额外的时间来了解和记录需求
无法了解业务需求是否有意义对所需的多重项目重点建立相关专家审
批的流程
关键的特性和功能可能会被遗漏
通过合作应用程序设计(JAD)来收集
需要从最初就依靠客户来提供有关项目重点所有的专
所有利益相关人的需求
业知识和技术
更频繁的与客户进行项目的预排
在评估时安排更多的时间进行使用分析
和设计活动

,不明确或不现实(例如一切都要完美):确保所有的绩效目标都被记录在案,并
经由项目团队同意,由项目发起人审批
项目团队会因为主次目标不清而陷入困境
通过
如果绩效需求没有在一开始就记录在案,那项目团队
坚持任何有关绩效目标的变更都必须通
更易于在项目进行过程中被迫接受新的绩效需求
过正式的变更申请
既然项目目标无法实现,项目将会失败
Page13
:.
第二部分典型的高风险问题/应对行动
高风险要素/潜在问题风险应对行动

,不完整或无法达成质量要求;或者项遵循组织的项目管理方法论
目流程中有必须弄清的问题:
完成推荐的项目表格,并获得关键利益
项目工作可能无法协调,毫无成效相关人的通过
项目范围可能更容易在不知不觉中扩大明确并更正任何已识别的项目流程问题
没有完整的项目计划就不可能实现项目的绩效目标在项目执行的过程中跟踪和更新项目计
划

K1由新的供应商来执行打包技术:确保与供应商的所有协议都记录在案
.
可能供应商无法完成任务并无法向你提供所需的支持坚持将原始代码放进契约中以防供应商
无法完成任务
如果市场中没有足够的产品销售,那升级将会受到威
胁让供应商成为项目组的一员
没有能够迅速建立伙伴关系的基础使用供应商日志来跟踪打包中出现的问
题
法律和财务的考虑可能会导致合同和项目的延期
确保供应商的财务可靠
与供应商就支持程度和问题解决时间达
成协议
K2超过50%的的项目工作需委托承包商,而他们对投入项Increaseprojectmanagementoversight
.目仍未承诺:ofcontractorpersonnel
在项目初始就缺少所需的人员Startofprojectshouldbedelayeduntil
staffed
可能会对项目排程造成极负面的影响
Increasedcommunicationsfocusisa
must
增强对承包商人员的项目管理监察
在人员到位之前不要开始项目
必须增加对承包商的沟通
(根据项目的实际情况进行添加)
L1
.
Page14
:.

项目名称:
项目经理:
我已经审阅过此项目风险评估表的信息并同意:
姓名职务签名日期(年/月/
日)
以上签名表示签名人了解此文件的目的和内容,并承认此为正式的项目风险评估表。