项目评估表

来源：华佗健康网

XX项目风险评估表项目名称: 报告人: 日期 (年/月/日):

第一部分

第二部分

常见的高风险问题/应对行动—注意：不同的风险承受度应制定不同的应对计划。风险评估问卷

第一部分风险评估问卷 Low Risk 低 Medium Risk 中 High Risk 高 Characteristics 风险特征 ORGANIZATION 组织 A. 范围 A1 项目范围是: [ ] 明确且了解的 [ ] 大部分确认但可能[ ] 不明确且/或可能改改变变 [ ] 了解且符合 A2. 公司/商务需求: [ ] 瞭解但极为复杂,或[ ] 非常复杂或非常模符合但未明确定义糊 [ ]需连续使用 A3. 系统可用性包括 [ ]可使用的通路及其停工期 [ ]低于1,000小时 A4. 预估总需求人力小时数: [ ] 1,000 至 5,000小[ ] 远大于5,000小时时 [ ] 好且易于使用 A5. 现有资料的质量: [ ] 明确但难以使用,或[ ] 差或难以使用不明确但易于使用 [ ]不需客制化 [ ] 需要客制化 [ ] 需要高度客制化 [ ]新产品或新的市场宣传模式 A6. 项目的执行: A7. 项目的执行: [ ] 稳定的产品或市场宣传模式 B. 时程第一部分风险评估问卷 Low Risk 低 Medium Risk 中 High Risk 高 Characteristics 风险特征 B1. 项目主要里程碑和完成日[ ] 弹性 – 可由用户[ ]确定 –已定且脱期[ ]刚性 –已由具体的期: 和项目组员商议后决定后可能会影响商机营运委员会决定,或规定的要求超过项目团队的掌控能力 [ ] 低于 3 个月 [ ] 3 到 12 个月 [ ] 远大于 12 个月 B2. 预估项目周期: C. 预算 C1. 预算是由有经验的人,使用[ ] 是 – 由有经验的[ ] 有一些经验或程序 [ ] 否 – 人员无经验已证实有效的成本预估程序人操作有效的预算程序来生成: 且无程序 C2. 项目资金符合或大于成本预[ ] 预算大于需求且/或[ ] 预算等于成本且预[ ] 预算低于需求且/或算和稳定性. D. 项目关联性 D1. 本项目依赖相关项目的关系[ ] 轻微依赖, 即使没[ ] 有些依赖,没有相关[ ] 高度依赖, 无相关可以形容为: 有相关项目的产出仍可完项目的产出可能造成延期项目的产出无法继续进行成 E. 人力资源 E1. 项目经理的经验和培训是: [ ] 最近在类似项目管[ ] 最近在非类似项目[ ] 无近期经验或未经理上取得了成功管理上取得了成功或经过项目管理培训培训但无经验预期稳定. 期相对稳定. 稳定性高度不确定. 第一部分风险评估问卷 Low Risk 低 Medium Risk 中 High Risk 高 Characteristics 风险特征 E2. 依需要管理工具和技术的使[ ] 熟练使用工具和技[ ] 对使用工具和技术[ ] 无正式培训或无实用来描绘项目组员. 术经过正式的培训,但少或际使用经验无实际经验 [ ] 同处一地 [ ] 分处多处 E3. 项目组员是: F. 发起人/高层领导的支持 F1. 项目发起人是: [ ]明确的，对项目认可 [ ]明确的，但缺乏热 [ ]既不明确也缺乏热且充满热情的情的情 G. 其他生意或组织上的影响 G1. 是否需要能够提供项目所需[ ]项目中不需要或项目 [ ]在某些方面经验不 [ ]没有或当下没有找相关知识技能的项目参与组成员已经具有丰富的相足人：关知识到合适的人选 G2 是否需要改变组织流程和政 [ ]完全不需要或很少 [ ]偶尔到经常性的改变 [ ]实质性的改变策： [ ]重大变革或目前还不清楚 [ ]三个或四个 [ ]五个以上 G3. 描述项目结果对业务流程或 [ ]没有或只是很微小 [ ]中度变迁组织变革的影响：的变迁 G4. 将受到此改变影响的部门： [ ]一个或两个第一部分风险评估问卷 Low Risk 低 Medium Risk 中 High Risk 高 [ ]低接受度（消极且很难融入） Characteristics 风险特征 G5. 项目的接收部门和利益相关[ ]高接受度（充满热情 [ ]一般接受度部门对于该项目将带来的变和期待）化的接受度，你会怎么评分 GENERAL – Technical and Performance Risks 整体 – 技术和绩效风险 H. 技术 H1. 将会用到的技术是： [ ]成熟的（已在使用[ ]演进中的的软件，硬件，专业术语，数据库和工具） [ ]实验性的（新的软件，硬件，语言，数据库，工具或最新推出的） [ ]全新的，复杂的 H2. 对技术的要求： [ ]与公司其他使用的类似 [ ]项目组成员并不清楚 H3. 技术的重点： I. 绩效 I1. 绩效目标： [ ]项目组成员都很清楚 [ ]明确，合理 [ ]不清晰，不明确，不现实（例如：每件事都要很完美）项目管理—计划，问题和变革管理，质量保障 J. 风险评估第一部分风险评估问卷 Low Risk 低 Medium Risk 中 High Risk 高 Characteristics 风险特征 J1. 通过项目管理风险评估检 [ ]制定了很完整的项 [ ]合理的，基本完成[ [ ]没有连续性的完整查表来进行项目风险管理的目计划，并且能够运用组的项目计划和流程，但是的项目计划，即使有质量整体评估织中的项目管理方法来实仍然有一些问题没有明确也不高，同时/或者在项现目流程中有许多关键性的问题没有明确外部—供应商，法律，环境，条例 K. 供应商 K1. 如果需要局部的委外执行： [ ]供应商对市场很熟悉 [ ]供应商刚刚进入该市场 [ ]需要一些承包商 [ ]50%以上的项目工作（少于50%），而且在项将交给承包商，但是在项目开始之前承包商会接到目开始之前承包商并不清明确的任务 L. 其他（根据项目实际情况来添加） L1.

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

风险应对行动楚其全部任务 K2. 项目是否需要承包商承包商 [ ]不需要承包商是否对项目做出了承诺高风险要素/潜在问题 A. 范围第二部分典型的高风险问题/应对行动

风险应对行动在计划中严格地定义项目范围

明确项目范围的各要素，例如哪些部门

高风险要素/潜在问题 A1项目范围模糊不清： .

难以作出合理的预测评估

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

难以明确项目定义和工作计划难以制定范围变更程序无法明确项目交付品

会受到影响，需要哪些项目交付品，需要哪类信息

清晰明确哪些是项目范围之外的(本项目

不包含:…)

从一开始就将业务需求定义在较高的层

次，然后以此由下至上的来定义项目范围

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

策

在对项目任务，成本或周期进行评估时

记录下所有的范围假设

运用图表来标识项目范围和替代方法预先制定严格的范围变更程序

确保正式性地通过项目定义和业务需求

并且获得相应的资源配备

将范围说明分发给所有的项目利益相关

人以获得确认

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

项目

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

风险应对行动运用合作应用程序设计（JAD）来收集所

高风险要素/潜在问题 A2项目的业务需求很模糊或复杂： .

难以正确地记录相关需求有项目利益相关人的需求

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

难以使用工具来记录相关需求难以明确项目期望是什么

有可能项目最终交付品无法达到业务的要求可能是缺乏客户关注和信息的信号

掘使用者对新系统的需求

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

全面的指导

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

表达其业务需求

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

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

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

风险应对行动分配更多的时间来分析，设计，测试系

高风险要素/潜在问题 A3需要连续地使用系统： .

检修或事故问题可能会导致产量的降低或收益的减少统并实施全面质量保障行动

将更多的时间和精力放在技术架构上可能需要创造部分冗余，因此增加系统的复杂度可能需要更新，更先进的技术

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

将更多的时间和精力放在数据库设计上使用行业最优的技术和流程

为项目组提供相应的培训，使其了解连续地使用系统意味着什么

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

哪个部分

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

术设计和架构

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

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

伙伴关系

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

风险应对行动使用项目管理工具来控制资源的使用让项目组成员使用周报表来监控他们所

高风险要素/潜在问题 A4高预期工作量： .

高工作量意味着项目很复杂，需要投入大量的人力更难以有效地与团队沟通当需要快速决策时瓶颈就会出现更可能出现人员问题可能会有更高的人员流动率

需要培训更多的人

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

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

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

力

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

展状况

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

量和风险管理

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

目

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

员和小组活动，减少每个人每天可用的项目工作时间

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

风险应对行动确保所有旧数据都毫无差错地转换到了

高风险要素/潜在问题 A5目前数据质量太低难以进行转换： .

需要做更多的工作来把旧的数据转换到新的系统中过滤后的数据仍然可能在新系统中造成问题数据转换问题能够导致严重的项目延期

新的系统中

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

程序

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

的困难是有价值的。弄清楚新的系统是否只能运转新的数据

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

的数据

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

行人工过滤

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

定制化会使项目更加复杂

对某一部分的修改可能会导致其他部分的问题定制化会导致绩效低下

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

大量的定制化可能意味着之前选择了错误的打包工具很有可能要花更长的时间来实施打包工具

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

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

为保证正常运作和绩效，全面彻底地测考虑其他的打包工具考虑定制化的发展

减少业务需求，这样也不用定制化了从供应商处获得确定的修改成本和周

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

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

工作都能按时完成

试修改后的打包工具

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

碑

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

风险应对行动尽早为项目组成员安排打包工具的相关

高风险要素/潜在问题 A7打包执行是一个全新的产品： .

会有更大的问题风险

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

培训

为项目增派一个有相关产品经验的内部

资源或咨询师

在全面实施之前安排打包工具的试点，

几乎很难预知这个打包工具是否符合所有的业务需求

使项目组尽快熟悉起来

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

共识

如果有其他公司也在使用同样的产品，

看看能不能将项目延期到其使用时间之后

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

们的反馈和关键所得

B. 时程 B1项目重要里程碑和/或完成日期是固定的，但这是由于业.

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

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

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

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

根据必需的项目活动对排程再进行协商

和谈判

对范围再进行协商和谈判，使项目活动

能够在规定的时间内完成

根据实际的预测评估与客户/项目所有者

/项目发起人重新建立新的共识

执行积极的项目跟踪和监控计划进行常规性的时程报告及沟通

的错误

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

风险应对行动将项目分解成更小的，周期更短的小项

高风险要素/潜在问题 B2预测项目周期会很长: .

更难管理项目排程

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

目

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

成

要持续不断地使用正式的变动管理程序

业务需求很有可能会变化

轮换项目组成员的角色，保持其持续较

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

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

高的兴趣度

尽可能地走在预计进度前面在项目初始阶段就营造一种紧迫感组织团队建设活动，建立团队凝聚力防

止人心涣散

确保所有的重要交付品都正式通过，然

后再引入变革管理

使技术设计和架构决策尽可能的灵活，

为潜在的变更做好准备

C. 预算 C1预算不是使用已证实有效的成本预估程序或有经验的个.

人建立的：

预算很有可能不准确

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

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

使用成熟的工具或有经验的个人重新评

估项目

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

金范围内

在未优化原预算计划之前不要开始项目

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

风险应对行动对项目范围再进行协商和谈判，使其能

高风险要素/潜在问题 C2项目资金到位比预算少，而且不稳定： .

项目不可能完成预期的目标项目很有可能超出其预备资金

够纳入可用的资金范围内

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

不要开始项目

D. 项目关联性 D1项目高度依赖于另外一个的关联项目，如果没有收.

到关联项目的最终交付品就无法展开：

不在项目控制范围内的事情能够严重地影响项目的产

修改其中一个或所有的项目排程，使项

目交付品能够整合起来

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

出和实现目标的能力

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

判

就满足项目的需求与关联项目达成共

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

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

紧密合作和相互监控

E. 人力资源 E1缺乏项目管理经验： .

可能要花更长的时间来定义项目和建立工作计划可能会有更多判断上的失误，导致返工或项目延期更难以组织和管理一个复杂的项目可能对全面的项目管理实践不熟悉可能不知道何时应该寻求帮助

提供事前的项目管理培训

指派一个更高层管理者来辅导项目经理建立并执行有力的质量保障流程来确保

项目正常的开展

确保重要交付品正式通过

通过有力的团队领导和团队成员带来更

多相关经验

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

风险应对行动向项目经理和项目团队提供完整的项目

高风险要素/潜在问题 E2不熟悉或并不准备使用项目管理流程： .

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

管理流程和程序培训

为项目分派一位有经验的项目管理教练

险

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

受控制

将缺乏良好的沟通

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

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

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

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

或导师

将整体项目分解成更小的项目，从而能

够进行较不严谨的项目管理

在项目开始之前明确并认同一套项目管

理程序，包括问题管理，变更管理，风险管理，和质量管理

建立一个强有力的沟通计划，以确保每

个成员都知道项目的进展并提供反馈

申请并获得随时对问题，风险，范围变

更和质量管理的投入

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

风险应对行动试着将团队聚集到一个地方，或至少在

高风险要素/潜在问题 E3分处多地的项目团队： .

更难以有效地沟通

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

项目启动的阶段

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

队沟通

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

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

的沟通

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

的技术出现问题

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

联系

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

成员来查阅存储项目文件

F. 发起人/高层领导支持 F1没有明确的或正式授权的项目发起人： .

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

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

建立一个强有力的指导委员会来帮助指

导整个项目

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

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

发的人授权

不要开始项目

G. 业务或组织的影响第二部分典型的高风险问题/应对行动

风险应对行动为了获得所需的项目知识，就资源承诺

高风险要素/潜在问题 G1提供项目知识的项目参与人或是无法加入项目或是仍未.

明确：

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

进行再次协商和谈判

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

的影响

项目接收人将不会满意

行再次协商或谈判

不要开始项目

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

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

的改变会使项目延期

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

的正确性

准确地阐述新旧流程之间的差别尽可能早地就潜在的变迁进行沟通确保客户了解流程和的改变指定一个人来负责所有流程和的改

程的能力

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

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

将是无用的

如果没有正确的程序支持，系统功能将会瘫痪实质性的流程改变可能会导致破坏性行为

变

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

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

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

效性和准确性

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

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

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

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

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

风险应对行动记录新的组织中存在的担忧，并寻找相

高风险要素/潜在问题 G3组织结构需要实质性的改变： .

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

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

应的办法来减轻这些担忧

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

不会集中精力于项目上

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

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

业务原因进行沟通

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

的设计和规划中

的系统

不确定性可能会延迟决策

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

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

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

协同合作会更加复杂

通过或批准某项决议会更加麻烦和费时更难以达成共识

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

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

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

委员会

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

备干涉不同的部门

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

更难以了解不同部门的主要利益相关人执行会更加困难和复杂

保证和测试

让来自不同部门的人有机会见面和互动让项目组严格遵循整个项目目标和优先

顺序

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

巧

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

风险应对行动建立一个积极的沟通计划，让客户参与

高风险要素/潜在问题 G5客户的对项目的认可度低/很难互动： .

可能会导致对商业价值的信心不足更难以从客户处获得所需的时间和资源更难以收集业务需求

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

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

发其积极性

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

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

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

极性

寻找机会在轻松有趣的环境中推销项目当需要客户的资源时，要积极地去得到

客户对此的承诺

不要开始项目

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

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

高风险要素/潜在问题 H1新的和不熟悉的项目技术（或新发布的）： .

学习曲线可能会导致较低的初期产出可能存在新旧技术整合的问题

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

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

新的技术可能会需要大量的转换工作

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

会很差

的人员进行培训

当需要时要充分利用供应商的技术专家利用外部熟悉此技术的专业顾问确保有足够的测试环境，这样使用新的

技术也不会影响产出

确保对新技术的功能，特性和性能都进

行了彻底扎实的分析

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

范

一开始在小范围对新技术实行试点

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

风险应对行动利用系统和技术设计档案来弄清各项技

高风险要素/潜在问题 H2新的,复杂的技术： .

可能很难理解需求和所需的设计新旧技术间可能有整合问题可能很难测试复杂的技术

术是如何组合起来的

明确整体系统技术架构，并请公司中有

经验的专业人员进行审查通过

请外部的顾问审查架构建议书以获得更

技术越复杂，问题风险越大

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

多的反馈和确认

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

题

熟悉的技术

使用同一供应商的复合产品以使整合系

统的过程更加流畅和容易

使用有公开标准和架构的产品以减少整

合问题带来的风险

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

项目团队成员需要更长的学习曲线项目可能会在开始阶段就脱节无法了解业务需求是否有意义关键的特性和功能可能会被遗漏

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

尽早地提供实践性的培训将关键客户带入项目团队中花额外的时间来了解和记录需求对所需的多重项目重点建立相关专家审

批的流程

通过合作应用程序设计（JAD）来收集所

业知识和技术

有利益相关人的需求

更频繁的与客户进行项目的预排在评估时安排更多的时间进行使用分析

和设计活动

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

风险应对行动确保所有的绩效目标都被记录在案，并

高风险要素/潜在问题 I. 绩效 I1绩效目标不清,不明确或不现实（例如一切都要完美）： .

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

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

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

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

既然项目目标无法实现，项目将会失败

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

过正式的变更申请

J. 项目管理 J1项目计划不统一，不完整或无法达成质量要求；或者项.

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

项目工作可能无法协调，毫无成效项目范围可能更容易在不知不觉中扩大

没有完整的项目计划就不可能实现项目的绩效目标

遵循组织的项目管理方

完成推荐的项目表格，并获得关键利益