项目评估表

XX项目风险评估表

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

. ?难以作出合理的预测评估

?可能会花时间和成本在项目范围之外?难以收集准确的需求信息

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

?难以制定范围变更程序

?无法明确项目交付品?明确项目范围的各要素，例如哪些部门会受到影响，需要哪些项目交付品，需

要哪类信息

?清晰明确哪些是项目范围之外的(本项目不包含:…)

?从一开始就将业务需求定义在较高的层次，然后以此由下至上的来定义项目范

围

?让项目发起人对冲突的项目范围作出决策

?在对项目任务，成本或周期进行评估时记录下所有的范围假设

?运用图表来标识项目范围和替代方法

?预先制定严格的范围变更程序

?确保正式性地通过项目定义和业务需求并且获得相应的资源配备

?将范围说明分发给所有的项目利益相关人以获得确认

?在项目范围没有清晰明确之前不要开始项目

A2 . 项目的业务需求很模糊或复杂：

?难以正确地记录相关需求

?难以使用工具来记录相关需求

?难以明确项目期望是什么

?有可能项目最终交付品无法达到业务的要求

?可能是缺乏客户关注和信息的信号

?运用合作应用程序设计（JAD）来收集所

有项目利益相关人的需求

?使用原型—重复式开发的技术来帮助发

掘使用者对新系统的需求

?与项目发起人，高层管理者沟通以获得

全面的指导

?为客户提供培训，让其明白如何思考和

表达其业务需求

?确保将最终明确的业务需求记录在案，

并执行相应的变更管理程序

A3 . 需要连续地使用系统：

?检修或事故问题可能会导致产量的降低或收益的减少

?可能需要创造部分冗余，因此增加系统的复杂度

?可能需要更新，更先进的技术

?需要更多的程序和流程来维护系统环境

?分配更多的时间来分析，设计，测试系

统并实施全面质量保障行动

?将更多的时间和精力放在技术架构上

?将更多的时间和精力放在数据库设计上

?使用行业最优的技术和流程

?为项目组提供相应的培训，使其了解连

续地使用系统意味着什么

?准确地指出究竟需要连续地使用系统的

哪个部分

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

术设计和架构

?制定坚实可靠的灾难复原计划

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

伙伴关系

A4 . 高预期工作量：

?高工作量意味着项目很复杂，需要投入大量的人力

?更难以有效地与团队沟通

?当需要快速决策时瓶颈就会出现

?更可能出现人员问题

?可能会有更高的人员流动率

?需要培训更多的人

?使用项目管理工具来控制资源的使用

?让项目组成员使用周报表来监控他们所

分配的工作任务的进展程度

?任命小组长来管理下属小组

?通过组织团队建设活动来建立团队凝聚

力

?召开计划进度会议，让人们知晓项目进

展状况

?使用内部系统流程进行范围，问题，质

量和风险管理

?将项目分解成更小的，周期更短的小项

目

?为了让项目组成员意识到其他相关的人

员和小组活动，减少每个人每天可用的

项目工作时间

A5 . 目前数据质量太低难以进行转换：

?需要做更多的工作来把旧的数据转换到新的系统中

?过滤后的数据仍然可能在新系统中造成问题

?数据转换问题能够导致严重的项目延期

?确保所有旧数据都毫无差错地转换到了

新的系统中

?在进行最终的转换前要严格地测试转换

程序

?评估由于转换数据而花费的成本和造成

的困难是有价值的。弄清楚新的系统是

否只能运转新的数据

?让旧的系统维持运转一段时间以获取旧

的数据

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

行人工过滤

A6 . 需要高度定制化的打包执行：

?定制化会使项目更加复杂

?对某一部分的修改可能会导致其他部分的问题

?定制化会导致绩效低下

?定制化会让新技术的运用变得更复杂

?大量的定制化可能意味着之前选择了错误的打包工具

?很有可能要花更长的时间来实施打包工具

?定制化会需要更多地依赖供应商

?考虑其他的打包工具

?考虑定制化的发展

?减少业务需求，这样也不用定制化了

?从供应商处获得确定的修改成本和周

期，并将其记录进你的整体工作计划

?管理与供应商的关系，确保所有必须的

工作都能按时完成

?确保项目发起人通过定制化方案

?为保证正常运作和绩效，全面彻底地测

试修改后的打包工具

?利用供应商日志来追踪问题和项目里程

碑

A7. 打包执行是一个全新的产品： ? 会有更大的问题风险

? 更多地依赖供应商来确保迅速地解决问题 ? 安装，测试和配置使用将需要更长的周期

? 几乎很难预知这个打包工具是否符合所有的业务需求 ? 尽早为项目组成员安排打包工具的相关培训

? 为项目增派一个有相关产品经验的内部资源或咨询师

?

在全面实施之前安排打包工具的试点，使项目组尽快熟悉起来

? 与供应商就支持度和问题解决时间达成共识

?

如果有其他公司也在使用同样的产品，看看能不能将项目延期到其使用时间之后

?

搜寻其他使用过该产品的公司，寻求他

务承诺或法律要求而被事先固定的，不受项目组的控制：

? 工作必须以这个日期期限为指导

? 可能无法在期限内完成所有必需的项目活动 ? 很有可能无法达到排程的要求

? 赶工和时程的压力很有可能导致项目工作中无法改正

的错误

和谈判

? 对范围再进行协商和谈判，使项目活动能够在规定的时间内完成

? 根据实际的预测评估与客户/项目所有者/项目发起人重新建立新的共识 ? 执行积极的项目跟踪和监控计划 ? 进行常规性的时程报告及沟通

B2. 预测项目周期会很长:

? 更难管理项目排程

? 使项目组和客户更加容易失去焦点和重心 ? 项目很有可能会失去组织的支持和承诺 ? 业务需求很有可能会变化

? 软件或硬件版本(技术和工具)很有可能会变化 ? 很难在项目开始时营造紧迫感

? 很有可能造成项目组成员和客户的流失

? 将项目分解成更小的，周期更短的小项目

? 明确项目里程碑，使其按进度发展和完成

? 要持续不断地使用正式的变动管理程序 ? 轮换项目组成员的角色，保持其持续较高的兴趣度

? 尽可能地走在预计进度前面

? 在项目初始阶段就营造一种紧迫感

? 组织团队建设活动，建立团队凝聚力防止人心涣散

? 确保所有的重要交付品都正式通过，然后再引入变革管理

?

使技术设计和架构决策尽可能的灵活，. 人建立的：

?

预算很有可能不准确

? 设计的预算计划不便于跟踪和监控

? 对于哪些工作能在预算内完成会有不现实的期望 估项目

? 修改项目范围, 使其能够纳入可用的资金范围内

? 在未优化原预算计划之前不要开始项目 C2. 项目资金到位比预算少，而且不稳定： ? 项目不可能完成预期的目标

? 项目很有可能超出其预备资金 ? 对项目范围再进行协商和谈判，使其能够纳入可用的资金范围内

?

在获得充足的预算或减少项目范围之前

D1. 项目高度依赖于另外一个独立的关联项目，如果没有收到关联项目的最终交付品就无法展开：

? 不在项目控制范围内的事情能够严重地影响项目的产出和实现目标的能力

? 关联项目的交付品如果延期就很有可能造成项目进度的延迟

? 修改其中一个或所有的项目排程，使项目交付品能够整合起来

?

对项目范围和/或排程再次进行协商和谈判

?

就满足项目的需求与关联项目达成共识，并将其记录在案

?

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

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

? 确保重要交付品正式通过

? 通过有力的团队领导和团队成员带来更多相关经验

E2. 不熟悉或并不准备使用项目管理流程：

? 项目团队可能无法知晓如何提出问题，范围变更和风

险

? 当内部流程越来越复杂和难以管理时，项目有可能不

受控制

? 将缺乏良好的沟通

? 完成的项目交付品可能样式不统一

? 无法及时地提出问题，由于无法考量对项目的影响，

范围变更也可能无法实行，风险可能被忽略，最终无法实现最优的质量

? 很有可能无法预期项目潜在的问题和困难

? 向项目经理和项目团队提供完整的项目管理流程和程序培训

? 为项目分派一位有经验的项目管理教练或导师

? 将整体项目分解成更小的项目，从而能够进行较不严谨的项目管理

?

在项目开始之前明确并认同一套项目管理程序，包括问题管理，变更管理，风险管理，和质量管理

? 建立一个强有力的沟通计划，以确保每个成员都知道项目的进展并提供反馈 ?

申请并获得随时对问题，风险，范围变更和质量管理的投入

E3. 分处多地的项目团队：

? 更难以有效地沟通

? 缺乏充分的团队互动和凝聚力 ? 很难与整个团队建立私人的关系

? 有些成员可能会感到被孤立，而非团队的一员 ? 技术问题可能导致生产力下降

? 试着将团队聚集到一个地方，或至少在项目启动的阶段

? 建立一个积极的沟通计划确保有效地团队沟通

? 召开例会，让整个团队能够进行面对面的沟通

? 安排团队建设活动，让整个项目组碰面 ? 准备后备的沟通工具和方式，以防主要的技术出现问题

? 与远距离的团队成员保持经常性的电话联系

?

建立一个中央数据库，方便所有的团队

? 项目也许无法获得其所需的资源

? 项目也许无法获得所必需的长期的承诺 ? 政治斗争可能会使项目延期

? 问题和变更申请可能无法及时地得到解决

导整个项目

? 为解决部门间的冲突建立一套流程 ? 尝试更换成另一个发起人

? 请求发起人向另一个能够从项目利益出发的人授权

G1 . 提供项目知识的项目参与人或是无法加入项目或是仍未

明确：

?缺乏所需的项目知识将会为准确的完成项目带来负面

的影响

?项目接收人将不会满意

?为了获得所需的项目知识，就资源承诺

进行再次协商和谈判

?为获得所需的项目知识，就项目进展进

行再次协商或谈判

?不要开始项目

G2 . 业务流程和政策需要实质性的改变：

?政策的改变会使项目延期

?新的流程会使人们感到困惑，从而影响他们使用此流

程的能力

?有可能开始时无法完全地整合新的流程

?如果新的流程无法完全地应对所有的突发状况，那它

将是无用的

?如果没有正确的程序支持，系统功能将会瘫痪

?实质性的流程改变可能会导致破坏性行为

?记录目前所有的政策和流程，确保他们

的正确性

?准确地阐述新旧流程之间的差别

?尽可能早地就潜在的变迁进行沟通

?确保客户了解流程和政策的改变

?指定一个人来负责所有流程和政策的改

变

?建立一个积极的沟通计划，使客户能够

随时了解和获得相关的信息

?对新的流程进行试点，以确保他们的有

效性和准确性

?将是否成功的实施新的政策和流程作为

项目经理绩效评估的一部分

?向客户公开流程的改变以获得更好的建

议，同时让他们感到自己的影响力

G3 . 组织结构需要实质性的改变：

?组织的不确定会导致组织内的畏惧感

?如果项目团队的注意力都放在了组织层面，那他们将

不会集中精力于项目上

?在新的组织中人们可能会担忧失去工作

?如果人们不欢迎组织的变革，那他们可能不会使用新

的系统

?不确定性可能会延迟决策

?组织变革可能会造成以政治为目的的决策

?记录新的组织中存在的担忧，并寻找相

应的办法来减轻这些担忧

?尽早地经常性地就潜在的变革和相应的

业务原因进行沟通

?让所有利益相关者的代表都投入到组织

的设计和规划中

?投入人力资源来解决潜在的人员问题

G4 . 大量的部门将会受到影响：

?协同合作会更加复杂

?通过或批准某项决议会更加麻烦和费时

?更难以达成共识

?计划和需求将涉及更多的人和团队

?更难以了解不同部门的主要利益相关人

?执行会更加困难和复杂

?建立一个正式的决议批准流程

?建立一个代表整个利益相关团体的指导

委员会

?让项目发起人参与到项目中，并随时准

备干涉不同的部门

?让每个组织的代表参与需求提出，质量

保证和测试

?让来自不同部门的人有机会见面和互动

?让项目组严格遵循整个项目目标和优先

顺序

?在所有可能的情况下使用建立共识的技

巧

G5 . 客户的对项目的认可度低/很难互动：

?可能会导致对商业价值的信心不足

?更难以从客户处获得所需的时间和资源

?更难以收集业务需求

?客户可能会破坏或阻碍项目的开展

?建立一个积极的沟通计划，让客户参与

到项目中，并让其了解其中的商业利益

?建立用户小组，明确其关心的问题并激

发其积极性

?让用户加入到计划和需求收集过程中

?让项目发起人帮助激起客户对项目的积

极性

?寻找机会在轻松有趣的环境中推销项目

?当需要客户的资源时，要积极地去得到

客户对此的承诺

H1. 新的和不熟悉的项目技术（或新发布的）： ? 学习曲线可能会导致较低的初期产出

? 可能存在新旧技术整合的问题

? 对技术变化的抵制可能会导致项目的延期 ? 在测试新技术时可能会有困难

? 可能无法正确的安装或架构技术，而导致项目的延期 ? 新的技术工具会导致更长的交付时间 ? 新的技术可能会需要大量的转换工作

? 当专业技术都用于优化和架构技术时，系统绩效可能

会很差

? 尽早提供对于新技术的实践性的培训 ? 向需要对新技术进行安装，使用和支持的人员进行培训

? 当需要时要充分利用供应商的技术专家 ? 利用外部熟悉此技术的专业顾问

? 确保有足够的测试环境，这样使用新的技术也不会影响产出

? 确保对新技术的功能，特性和性能都进行了彻底扎实的分析

? 对如何使用新的技术建立一套程序和规范

?

一开始在小范围对新技术实行试点 H2. 新的,复杂的技术：

? 可能很难理解需求和所需的设计

? 新旧技术间可能有整合问题 ? 可能很难测试复杂的技术 ? 技术越复杂，问题风险越大

? 在整合或系统测试完成后才能发现技术无法解决的问

题

? 利用系统和技术设计档案来弄清各项技术是如何组合起来的

? 明确整体系统技术架构，并请公司中有经验的专业人员进行审查通过

? 请外部的顾问审查架构建议书以获得更多的反馈和确认

? 一开始在小范围内对新的技术进行试点 ? 尽可能多的在架构中使用经过验证的和熟悉的技术

? 使用同一供应商的复合产品以使整合系统的过程更加流畅和容易

?

使用有公开标准和架构的产品以减少整合问题带来的风险

H3. 项目团队对项目重点并不了解：

? 项目团队成员需要更长的学习曲线

? 项目可能会在开始阶段就脱节 ? 无法了解业务需求是否有意义 ? 关键的特性和功能可能会被遗漏

? 需要从最初就依靠客户来提供有关项目重点所有的专

业知识和技术

? 尽早地提供实践性的培训 ? 将关键客户带入项目团队中

? 花额外的时间来了解和记录需求

? 对所需的多重项目重点建立相关专家审批的流程

? 通过合作应用程序设计（JAD ）来收集所有利益相关人的需求

? 更频繁的与客户进行项目的预排

?

在评估时安排更多的时间进行使用分析

? 项目团队会因为主次目标不清而陷入困境

? 如果绩效需求没有在一开始就记录在案，那项目团队

更易于在项目进行过程中被迫接受新的绩效需求

经由项目团队同意，由项目发起人审批通过

?

坚持任何有关绩效目标的变更都必须通

目流程中有必须弄清的问题：

? 项目工作可能无法协调，毫无成效

? 项目范围可能更容易在不知不觉中扩大

? 没有完整的项目计划就不可能实现项目的绩效目标 ? 完成推荐的项目表格，并获得关键利益相关人的通过

? 明确并更正任何已识别的项目流程问题 ?

在项目执行的过程中跟踪和更新项目计

K1 . 由新的供应商来执行打包技术：

?可能供应商无法完成任务并无法向你提供所需的支持

?如果市场中没有足够的产品销售，那升级将会受到威

胁

?没有能够迅速建立伙伴关系的基础

?法律和财务的考虑可能会导致合同和项目的延期

?确保与供应商的所有协议都记录在案

?坚持将原始代码放进契约中以防供应商

无法完成任务

?让供应商成为项目组的一员

?使用供应商日志来跟踪打包中出现的问

题

?确保供应商的财务可靠

?与供应商就支持程度和问题解决时间达

成协议

K2 . 超过50%的的项目工作需委托承包商，而他们对投入项

目仍未承诺：

?在项目初始就缺少所需的人员

?可能会对项目排程造成极负面的影响

?Increase project management oversight of

contractor personnel

?Start of project should be delayed until

staffed

?Increased communications focus is a must

?增强对承包商人员的项目管理监察

?在人员到位之前不要开始项目

L1.

项目名称:

项目经理：

我已经审阅过此项目风险评估表的信息并同意：

以上签名表示签名人了解此文件的目的和内容，并承认此为正式的项目风险评估表。