XX项目风险评估表
第一部分风险评估问卷
第二部分常见的高风险问题/应对行动—注意:不同的风险承受度应制定不同的应对计划。
第二部分典型的高风险问题/应对行动
A1 .项目范围模糊不清:
难以作出合理的预测评估
可能会花时间和成本在项目范围之外
难以收集准确的需求信息
难以明确项目定义和工作计划
难以制定范围变更程序
无法明确项目交付品
在计划中严格地定义项目范围
明确项目范围的各要素,例如哪些部门
会受到影响,需要哪些项目交付品,需
要哪类信息
清晰明确哪些是项目范围之外的(本项目
不包含:…)
从一开始就将业务需求定义在较高的层
次,然后以此由下至上的来定义项目范
围
让项目发起人对冲突的项目范围作出决
策
在对项目任务,成本或周期进行评估时
记录下所有的范围假设
运用图表来标识项目范围和替代方法
预先制定严格的范围变更程序
确保正式性地通过项目定义和业务需求
并且获得相应的资源配备
将范围说明分发给所有的项目利益相关
人以获得确认
在项目范围没有清晰明确之前不要开始
项目
A2 .项目的业务需求很模糊或复杂:
难以正确地记录相关需求
难以使用工具来记录相关需求
难以明确项目期望是什么
有可能项目最终交付品无法达到业务的要求
可能是缺乏客户关注和信息的信号
运用合作应用程序设计(JAD)来收集所
有项目利益相关人的需求
使用原型—重复式开发的技术来帮助发
掘使用者对新系统的需求
与项目发起人,高层管理者沟通以获得
全面的指导
为客户提供培训,让其明白如何思考和
表达其业务需求
确保将最终明确的业务需求记录在案,
并执行相应的变更管理程序
A3 .需要连续地使用系统:
检修或事故问题可能会导致产量的降低或收益的减少
可能需要创造部分冗余,因此增加系统的复杂度
可能需要更新,更先进的技术
需要更多的程序和流程来维护系统环境
分配更多的时间来分析,设计,测试系
统并实施全面质量保障行动
将更多的时间和精力放在技术架构上
将更多的时间和精力放在数据库设计上
使用行业最优的技术和流程
为项目组提供相应的培训,使其了解连
续地使用系统意味着什么
准确地指出究竟需要连续地使用系统的
哪个部分
寻求内部或外部的专家来验收整体的技
术设计和架构
制定坚实可靠的灾难复原计划
与软件和硬件供应商建立和发展良好的
伙伴关系
A4 .高预期工作量:
高工作量意味着项目很复杂,需要投入大量的人力
更难以有效地与团队沟通
当需要快速决策时瓶颈就会出现
更可能出现人员问题
可能会有更高的人员流动率
需要培训更多的人
使用项目管理工具来控制资源的使用
让项目组成员使用周报表来监控他们所
分配的工作任务的进展程度
任命小组长来管理下属小组
通过组织团队建设活动来建立团队凝聚
力
召开计划进度会议,让人们知晓项目进
展状况
使用内部系统流程进行范围,问题,质
量和风险管理
将项目分解成更小的,周期更短的小项
目
为了让项目组成员意识到其他相关的人
员和小组活动,减少每个人每天可用的
项目工作时间
A5 .目前数据质量太低难以进行转换:
需要做更多的工作来把旧的数据转换到新的系统中
过滤后的数据仍然可能在新系统中造成问题
数据转换问题能够导致严重的项目延期
确保所有旧数据都毫无差错地转换到了
新的系统中
在进行最终的转换前要严格地测试转换
程序
评估由于转换数据而花费的成本和造成
的困难是有价值的。弄清楚新的系统是
否只能运转新的数据
让旧的系统维持运转一段时间以获取旧
的数据
在数据转换之前尽可能地对旧的数据进
行人工过滤
A6 .需要高度定制化的打包执行:
定制化会使项目更加复杂
对某一部分的修改可能会导致其他部分的问题
定制化会导致绩效低下
定制化会让新技术的运用变得更复杂
大量的定制化可能意味着之前选择了错误的打包工具
很有可能要花更长的时间来实施打包工具
定制化会需要更多地依赖供应商
考虑其他的打包工具
考虑定制化的发展
减少业务需求,这样也不用定制化了
从供应商处获得确定的修改成本和周
期,并将其记录进你的整体工作计划
管理与供应商的关系,确保所有必须的
工作都能按时完成
确保项目发起人通过定制化方案
为保证正常运作和绩效,全面彻底地测
试修改后的打包工具
利用供应商日志来追踪问题和项目里程
碑
A7 .打包执行是一个全新的产品:
会有更大的问题风险
更多地依赖供应商来确保迅速地解决问题
安装,测试和配置使用将需要更长的周期
几乎很难预知这个打包工具是否符合所有的业务需求
尽早为项目组成员安排打包工具的相关
培训
为项目增派一个有相关产品经验的内部
资源或咨询师
在全面实施之前安排打包工具的试点,
使项目组尽快熟悉起来
与供应商就支持度和问题解决时间达成
共识
如果有其他公司也在使用同样的产品,
看看能不能将项目延期到其使用时间之
后
搜寻其他使用过该产品的公司,寻求他
们的反馈和关键所得
B1 .项目重要里程碑和/或完成日期是固定的,但这是由于业
务承诺或法律要求而被事先固定的,不受项目组的控
制:
工作必须以这个日期期限为指导
可能无法在期限内完成所有必需的项目活动
很有可能无法达到排程的要求
赶工和时程的压力很有可能导致项目工作中无法改正
的错误
根据必需的项目活动对排程再进行协商
和谈判
对范围再进行协商和谈判,使项目活动
能够在规定的时间内完成
根据实际的预测评估与客户/项目所有者
/项目发起人重新建立新的共识
执行积极的项目跟踪和监控计划
进行常规性的时程报告及沟通
B2.
预测项目周期会很长: 更难管理项目排程
使项目组和客户更加容易失去焦点和重心 项目很有可能会失去组织的支持和承诺
业务需求很有可能会变化
软件或硬件版本(技术和工具)很有可能会变化 很难在项目开始时营造紧迫感
很有可能造成项目组成员和客户的流失
将项目分解成更小的,周期更短的小项
目
明确项目里程碑,使其按进度发展和完
成
要持续不断地使用正式的变动管理程序
轮换项目组成员的角色,保持其持续较
高的兴趣度
尽可能地走在预计进度前面 在项目初始阶段就营造一种紧迫感 组织团队建设活动,建立团队凝聚力防
止人心涣散
确保所有的重要交付品都正式通过,然
后再引入变革管理
使技术设计和架构决策尽可能的灵活,
为潜在的变更做好准备
C1.
预算不是使用已证实有效的成本预估程序或有经验的个人建立的:
预算很有可能不准确
设计的预算计划不便于跟踪和监控
对于哪些工作能在预算内完成会有不现实的期望
使用成熟的工具或有经验的个人重新评
估项目
修改项目范围, 使其能够纳入可用的资
金范围内
在未优化原预算计划之前不要开始项目
C2 .项目资金到位比预算少,而且不稳定:
项目不可能完成预期的目标
项目很有可能超出其预备资金
对项目范围再进行协商和谈判,使其能
够纳入可用的资金范围内
在获得充足的预算或减少项目范围之前
不要开始项目
D1 .项目高度依赖于另外一个独立的关联项目,如果没有收
到关联项目的最终交付品就无法展开:
不在项目控制范围内的事情能够严重地影响项目的产
出和实现目标的能力
关联项目的交付品如果延期就很有可能造成项目进度
的延迟
修改其中一个或所有的项目排程,使项
目交付品能够整合起来
对项目范围和/或排程再次进行协商和谈
判
就满足项目的需求与关联项目达成共
识,并将其记录在案
为了最大限度地减少冲突,两个项目要
紧密合作和相互监控
E1 .缺乏项目管理经验:
可能要花更长的时间来定义项目和建立工作计划
可能会有更多判断上的失误,导致返工或项目延期
更难以组织和管理一个复杂的项目
可能对全面的项目管理实践不熟悉
可能不知道何时应该寻求帮助
提供事前的项目管理培训
指派一个更高层管理者来辅导项目经理
建立并执行有力的质量保障流程来确保
项目正常的开展
确保重要交付品正式通过
通过有力的团队领导和团队成员带来更
多相关经验
E2 .不熟悉或并不准备使用项目管理流程:
项目团队可能无法知晓如何提出问题,范围变更和风
险
当内部流程越来越复杂和难以管理时,项目有可能不
受控制
将缺乏良好的沟通
完成的项目交付品可能样式不统一
无法及时地提出问题,由于无法考量对项目的影响,
范围变更也可能无法实行,风险可能被忽略,最终无
法实现最优的质量
很有可能无法预期项目潜在的问题和困难
向项目经理和项目团队提供完整的项目
管理流程和程序培训
为项目分派一位有经验的项目管理教练
或导师
将整体项目分解成更小的项目,从而能
够进行较不严谨的项目管理
在项目开始之前明确并认同一套项目管
理程序,包括问题管理,变更管理,风
险管理,和质量管理
建立一个强有力的沟通计划,以确保每
个成员都知道项目的进展并提供反馈
申请并获得随时对问题,风险,范围变
更和质量管理的投入
E3.
分处多地的项目团队: 更难以有效地沟通
缺乏充分的团队互动和凝聚力 很难与整个团队建立私人的关系
有些成员可能会感到被孤立,而非团队的一员 技术问题可能导致生产力下降
试着将团队聚集到一个地方,或至少在
项目启动的阶段
建立一个积极的沟通计划确保有效地团
队沟通
召开例会,让整个团队能够进行面对面
的沟通
安排团队建设活动,让整个项目组碰面 准备后备的沟通工具和方式,以防主要
的技术出现问题
与远距离的团队成员保持经常性的电话
联系
建立一个中央数据库,方便所有的团队
成员来查阅存储项目文件
F1.
没有明确的或正式授权的项目发起人: 项目也许无法获得其所需的资源 项目也许无法获得所必需的长期的承诺 政治斗争可能会使项目延期
问题和变更申请可能无法及时地得到解决
建立一个强有力的指导委员会来帮助指
导整个项目
为解决部门间的冲突建立一套流程 尝试更换成另一个发起人
请求发起人向另一个能够从项目利益出
发的人授权
不要开始项目
G1 .提供项目知识的项目参与人或是无法加入项目或是仍未
明确:
缺乏所需的项目知识将会为准确的完成项目带来负面
的影响
项目接收人将不会满意
为了获得所需的项目知识,就资源承诺
进行再次协商和谈判
为获得所需的项目知识,就项目进展进
行再次协商或谈判
不要开始项目
G2 .业务流程和政策需要实质性的改变:
政策的改变会使项目延期
新的流程会使人们感到困惑,从而影响他们使用此流
程的能力
有可能开始时无法完全地整合新的流程
如果新的流程无法完全地应对所有的突发状况,那它
将是无用的
如果没有正确的程序支持,系统功能将会瘫痪
实质性的流程改变可能会导致破坏性行为
记录目前所有的政策和流程,确保他们
的正确性
准确地阐述新旧流程之间的差别
尽可能早地就潜在的变迁进行沟通
确保客户了解流程和政策的改变
指定一个人来负责所有流程和政策的改
变
建立一个积极的沟通计划,使客户能够
随时了解和获得相关的信息
对新的流程进行试点,以确保他们的有
效性和准确性
将是否成功的实施新的政策和流程作为
项目经理绩效评估的一部分
向客户公开流程的改变以获得更好的建
议,同时让他们感到自己的影响力
G3 .组织结构需要实质性的改变:
组织的不确定会导致组织内的畏惧感
如果项目团队的注意力都放在了组织层面,那他们将
不会集中精力于项目上
在新的组织中人们可能会担忧失去工作
如果人们不欢迎组织的变革,那他们可能不会使用新
的系统
不确定性可能会延迟决策
组织变革可能会造成以政治为目的的决策
记录新的组织中存在的担忧,并寻找相
应的办法来减轻这些担忧
尽早地经常性地就潜在的变革和相应的
业务原因进行沟通
让所有利益相关者的代表都投入到组织
的设计和规划中
投入人力资源来解决潜在的人员问题
G4 .大量的部门将会受到影响:
协同合作会更加复杂
通过或批准某项决议会更加麻烦和费时
更难以达成共识
计划和需求将涉及更多的人和团队
更难以了解不同部门的主要利益相关人
执行会更加困难和复杂
建立一个正式的决议批准流程
建立一个代表整个利益相关团体的指导
委员会
让项目发起人参与到项目中,并随时准
备干涉不同的部门
让每个组织的代表参与需求提出,质量
保证和测试
让来自不同部门的人有机会见面和互动
让项目组严格遵循整个项目目标和优先
顺序
在所有可能的情况下使用建立共识的技
巧
G5.
客户的对项目的认可度低/很难互动: 可能会导致对商业价值的信心不足 更难以从客户处获得所需的时间和资源 更难以收集业务需求
客户可能会破坏或阻碍项目的开展
建立一个积极的沟通计划,让客户参与
到项目中,并让其了解其中的商业利益
建立用户小组,明确其关心的问题并激
发其积极性
让用户加入到计划和需求收集过程中
让项目发起人帮助激起客户对项目的积
极性
寻找机会在轻松有趣的环境中推销项目 当需要客户的资源时,要积极地去得到
客户对此的承诺
不要开始项目
H1 .新的和不熟悉的项目技术(或新发布的):
学习曲线可能会导致较低的初期产出
可能存在新旧技术整合的问题
对技术变化的抵制可能会导致项目的延期
在测试新技术时可能会有困难
可能无法正确的安装或架构技术,而导致项目的延期
新的技术工具会导致更长的交付时间
新的技术可能会需要大量的转换工作
当专业技术都用于优化和架构技术时,系统绩效可能
会很差
尽早提供对于新技术的实践性的培训
向需要对新技术进行安装,使用和支持
的人员进行培训
当需要时要充分利用供应商的技术专家
利用外部熟悉此技术的专业顾问
确保有足够的测试环境,这样使用新的
技术也不会影响产出
确保对新技术的功能,特性和性能都进
行了彻底扎实的分析
对如何使用新的技术建立一套程序和规
范
一开始在小范围对新技术实行试点