XX项目评价表.docx

XX项目评价表.docx

《XX项目评价表.docx》由会员分享，可在线阅读，更多相关《XX项目评价表.docx（13页珍藏版）》请在冰豆网上搜索。

XX项目评价表

XX项目风险评估表

:

项目名称

:

报告人

）:

/月/日日期年（

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

第二部分应对行动—注意：

不同的风险承受度应制定不同的应对计划。

/常见的高风险问题

第一部分风险评估问卷

Characteristics风险特征

ORGANIZATION组织

A.范围

A1项目范围是:

A2.公司/商务需求:

A3.系统可用性包括

A4.预估总需求人力小时数:

A5.现有资料的质量:

A6.项目的执行:

A7.:

项目的执行

LowRisk低[]明确且了解的[]了解且符合可使用的通路及其停工[]期

小时[]低于1,000[]好且易于使用不需客制化[]稳定的产品或市场宣[]传模式

MediumRisk中[]大部分确认但可能改变

[]瞭解但极为复杂,或符合但未明确定义

[]1,000至5,000小时[]明确但难以使用,或不明确但易于使用

[]需要客制化

HighRisk高[]不明确且/或可能改变[]非常复杂或非常模糊[]需连续使用[]远大于5,000小时[]差或难以使用[]需要高度客制化[]新产品或新的市场宣传模式

B.时程B1.[]弹性–可由用户和项[]确定–项目主要里程碑和完成日已定且脱期后可[]刚性–已由具体的营运目组员商议后决定:

能会影响商机委员会决定,或规定的要期求超过项目团队的掌控能力

B2.预估项目周期个月12[]3到个月:

[]远大于12[]低于3个月

C.预算

C1.预算是由有经验的人,使用[]是–由有经验的人操[]有一些经验或程序[]否–人员无经验且无程序作有效的预算程序已证实有效的成本预估程序:

来生成

C2.项目资金符合或大于成本预[]预算大于需求且/或预[]预算等于成本且预期[]预算低于需求且/或稳算和稳定性.期稳定.相对稳定.定性高度不确定.

项目关联性D.

第一部分风险评估问卷

Characteristics风险特征

D1.本项目依赖相关项目的关系可以形容为:

LowRisk低[]轻微依赖,即使没有相关项目的产出仍可完成

MediumRisk中[]有些依赖,没有相关项目的产出可能造成延期

HighRisk高[]高度依赖,无相关项目的产出无法继续进行

E.人力资源

E1.项目经理的经验和培训是:

[]最近在类似项目管理[]最近在非类似项目管[]无近期经验或未经项上取得了成功理上取得了成功或经过培目管理培训

训但无经验

E2.依需要管理工具和技术的使[]熟练使用工具和技术[]对使用工具和技术经[]无正式培训或无实际用来描绘项目组员.过正式的培训,但少或无使用经验

实际经验

E3.项目组员是:

[][]同处一地分处多处

F.发起人/高层领导的支持

F1.项目发起人是:

[]明确的，对项目认可且[]明确的，但缺乏热情[]既不明确也缺乏热情

充满热情的的

其他生意或组织上的影响G.

G1.是否需要能够提供项目所需[]项目中不需要或项目组[]在某些方面经验不足[]没有或当下没有找到相关知识技能的项目参与成员已经具有丰富的相关合适的人选

人：

知识

G2是否需要改变组织流程和政[]完全不需要或很少[]偶尔到经常性的改变[]实质性的改变

策：

G3.描述项目结果对业务流程或[]没有或只是很微小的[]中度变迁重大变革或目前还不清[]

组织变革的影响：

楚变迁

G4.将受到此改变影响的部门：

[]一个或两个[][]五个以上三个或四个

G5.项目的接收部门和利益相关[]低接受度（消极且很[]高接受度（充满热情和[]一般接受度

部门对于该项目将带来的变难融入）期待）

化的接受度，你会怎么评分？

第一部分风险评估问卷

Characteristics风险特征

LowRisk低

MediumRisk中

HighRisk高

GENERAL–TechnicalandPerformanceRisks整体–技术和绩效风险

H.技术

H1.将会用到的技术是：

[]成熟的（已在使用的[]演进中的[]实验性的（新的软件，硬件，语言，数据库，工软件，硬件，专业术语，具或最新推出的）数据库和工具）

H2.与公司其他使用的类[]对技术的要求：

[]全新的，复杂的

似

H3.[]项目组成员都很清楚项目组成员并不清楚技术的重点：

[]

绩效I.

I1.[]绩效目标：

不清晰，不明确，不现[]明确，合理实（例如：

每件事都要很完美）

项目管理—计划，问题和变革管理，质量保障

J.风险评估

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

外部—供应商，法律，环境，条例

K.供应商

K1.[]供应商刚刚进入该市供应商对市场很熟悉[]如果需要局部的委外执行：

场

K2.[]不需要承包商[]需要一些承包商（少[]50%以上的项目工作项目是否需要承包商？

承包于50%商是否对项目做出了承诺？

），而且在项目将交给承包商，但是在项开始之前承包商会接到明目开始之前承包商并不清确的任务楚其全部任务

L.其他（根据项目实际情况来添加）

L1.

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

?

.

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

?

会受到影响，需要哪些项目交付品，需可能会花时间和成本在项目范围之外?

要哪类信息难以收集准确的需求信息?

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

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

）

…不包含:

难以制定范围变更程序从一开始就将业务需求定义在较高的层?

?

次，然后以此由下至上的来定义项目范无法明确项目交付品?

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

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

记录下所有的范围假设运用图表来标识项目范围和替代方法?

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

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

并且获得相应的资源配备将范围说明分发给所有的项目利益相关?

人以获得确认在项目范围没有清晰明确之前不要开始?

项目）来收集运用合作应用程序设计（JADA2项目的业务需求很模糊或复杂：

?

.

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

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

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

掘使用者对新系统的需求难以明确项目期望是什么?

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

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

全面的指导可能是缺乏客户关注和信息的信号为客户提供培训，让其明白如何思考和?

?

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

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

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

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

?

.

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

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

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

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

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

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

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

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

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

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

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

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

伙伴关系使用项目管理工具来控制资源的使用A4高预期工作量：

?

.

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

?

分配的工作任务的进展程度更难以有效地与团队沟通?

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

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

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

更可能出现人员问题?

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

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

需要培训更多的人?

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

量和风险管理将项目分解成更小的，周期更短的小项?

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

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

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

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

?

.

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

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

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

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

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

的困难是有价值的。

弄清楚新的系统是否只能运转新的数据让旧的系统维持运转一段时间以获取旧?

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

行人工过滤考虑其他的打包工具A6需要高度定制化的打包执行：

?

.

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

?

对某一部分的修改可能会导致其他部分的问题减少业务需求，这样也不用定制化了?

?

定制化会导致绩效低下从供应商处获得确定的修改成本和周?

?

期，并将其记录进你的整体工作计划定制化会让新技术的运用变得更复杂?

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

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

工作都能按时完成很有可能要花更长的时间来实施打包工具?

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

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

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

试修改后的打包工具利用供应商日志来追踪问题和项目里程?

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

?

.

培训会有更大的问题风险?

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

更多地依赖供应商来确保迅速地解决问题?

资源或咨询师安装，测试和配置使用将需要更长的周期?

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

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

使项目组尽快熟悉起来与供应商就支持度和问题解决时间达成?

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

看看能不能将项目延期到其使用时间之后搜寻其他使用过该产品的公司，寻求他?

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