项目评估表Word文档格式.docx

项目评估表Word文档格式.docx

《项目评估表Word文档格式.docx》由会员分享，可在线阅读，更多相关《项目评估表Word文档格式.docx（46页珍藏版）》请在冰豆网上搜索。

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

［　]非常复杂或非常模糊

A３、

系统可用性包括

[]可使用得通路及其停工期

[］需连续使用

Ａ4、

预估总需求人力小时数:

[］低于1,0０0小时

［］1,0０0　至5,000小时

[　］远大于5,000小时

A５。

现有资料得质量:

［]好且易于使用

[］明确但难以使用,或不明确但易于使用

[］差或难以使用

A６、

项目得执行:

[］不需客制化

［］　需要客制化

[　］　需要高度客制化

A7.

[　］稳定得产品或市场宣传模式

[]新产品或新得市场宣传模式

B、时程

Ｂ１。

项目主要里程碑与完成日期:

［]弹性–可由用户与项目组员商议后决定

［］确定　–已定且脱期后可能会影响商机

［］刚性　–已由具体得营运委员会决定,或规定得要求超过项目团队得掌控能力

B2。

预估项目周期:

［］低于　3　个月

[]３到　12个月

[]远大于　12个月

C。

预算

C１.

预算就是由有经验得人,使用已证实有效得成本预估程序来生成:

［　　］　就是–　由有经验得人操作有效得预算程序

［　　]有一些经验或程序

[　］　否–　人员无经验且无程序

C2、

项目资金符合或大于成本预算与稳定性。

[］预算大于需求且/或预期稳定。

[　　］　预算等于成本且预期相对稳定.

[］　预算低于需求且／或稳定性高度不确定、

D.项目关联性

Ｄ1、

本项目依赖相关项目得关系可以形容为:

[　］　轻微依赖,即使没有相关项目得产出仍可完成

［　]有些依赖,没有相关项目得产出可能造成延期

［]高度依赖,无相关项目得产出无法继续进行

E、　人力资源

E1。

项目经理得经验与培训就是:

［]最近在类似项目管理上取得了成功

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

［　］无近期经验或未经项目管理培训

Ｅ2。

依需要管理工具与技术得使用来描绘项目组员、

[　］熟练使用工具与技术

[］对使用工具与技术经过正式得培训,但少或无实际经验

[　］　无正式培训或无实际使用经验

E３、

项目组员就是:

［　］　同处一地

[　］分处多处

F。

发起人／高层领导得支持

F1.

项目发起人就是:

[]明确得,对项目认可且充满热情得

［]明确得,但缺乏热情得

［　]既不明确也缺乏热情

G、其她生意或组织上得影响

G1、

就是否需要能够提供项目所需相关知识技能得项目参与人:

［］项目中不需要或项目组成员已经具有丰富得相关知识

［　］在某些方面经验不足

[　]没有或当下没有找到合适得人选

G2

就是否需要改变组织流程与政策:

［　］完全不需要或很少

［］偶尔到经常性得改变

[　]实质性得改变

G３。

描述项目结果对业务流程或组织变革得影响:

　［　　］没有或只就是很微小得变迁

[］中度变迁

[］重大变革或目前还不清楚

G4。

将受到此改变影响得部门:

[]一个或两个

［]三个或四个

[］五个以上

G5。

项目得接收部门与利益相关部门对于该项目将带来得变化得接受度,您会怎么评分？

［］高接受度（充满热情与期待）

［］一般接受度

　［]低接受度（消极且很难融入）

GEＮERAL　–　TｅchnicalandPerformaｎcｅ　Ｒisｋｓ整体　–技术与绩效风险

Ｈ。

　技术

H１、

将会用到得技术就是:

［]成熟得（已在使用得软件,硬件,专业术语,数据库与工具）

［　］演进中得

[]实验性得（新得软件,硬件,语言,数据库,工具或最新推出得）

H2.

对技术得要求:

［　］与公司其她使用得类似

[］全新得,复杂得

Ｈ３。

技术得重点:

[]项目组成员都很清楚

[］项目组成员并不清楚

I。

绩效

I１.

绩效目标:

［　]明确,合理

［]不清晰,不明确,不现实（例如:

每件事都要很完美）

项目管理-计划,问题与变革管理,质量保障

J.风险评估

J1。

通过项目管理风险评估检查表来进行项目风险管理得整体评估

[］制定了很完整得项目计划,并且能够运用组织中得项目管理方法来实现

［］合理得,基本完成得项目计划与流程,但就是仍然有一些问题没有明确

［[]没有连续性得完整得项目计划,即使有质量也不高,同时／或者在项目流程中有许多关键性得问题没有明确

外部-供应商,法律,环境,条例

Ｋ、　供应商

K1.

如果需要局部得委外执行:

[　］供应商对市场很熟悉

［]供应商刚刚进入该市场

Ｋ2。

项目就是否需要承包商？

承包商就是否对项目做出了承诺?

［　]不需要承包商

［　］需要一些承包商（少于５0%）,而且在项目开始之前承包商会接到明确得任务

［　]50%以上得项目工作将交给承包商,但就是在项目开始之前承包商并不清楚其全部任务

Ｌ.其她（根据项目实际情况来添加）

L1。

第二部分

典型得高风险问题/应对行动

高风险要素/潜在问题

风险应对行动

A.范围

A1。

项目范围模糊不清:

▪难以作出合理得预测评估

▪可能会花时间与成本在项目范围之外

▪难以收集准确得需求信息

▪难以明确项目定义与工作计划

▪难以制定范围变更程序

▪无法明确项目交付品

▪在计划中严格地定义项目范围

▪明确项目范围得各要素,例如哪些部门会受到影响,需要哪些项目交付品,需要哪类信息

▪清晰明确哪些就是项目范围之外得（本项目不包含:

…）

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

▪让项目发起人对冲突得项目范围作出决策

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

▪运用图表来标识项目范围与替代方法

▪预先制定严格得范围变更程序

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

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

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

A2。

项目得业务需求很模糊或复杂:

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

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

▪难以明确项目期望就是什么

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

▪可能就是缺乏客户关注与信息得信号

▪运用合作应用程序设计（JＡD）来收集所有项目利益相关人得需求

▪使用原型—重复式开发得技术来帮助发掘使用者对新系统得需求

▪与项目发起人,高层管理者沟通以获得全面得指导

▪为客户提供培训,让其明白如何思考与表达其业务需求

▪确保将最终明确得业务需求记录在案,并执行相应得变更管理程序

A３。

需要连续地使用系统:

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

▪可能需要创造部分冗余,因此增加系统得复杂度

▪可能需要更新,更先进得技术

▪需要更多得程序与流程来维护系统环境

▪分配更多得时间来分析,设计,测试系统并实施全面质量保障行动

▪将更多得时间与精力放在技术架构上

▪将更多得时间与精力放在数据库设计上

▪使用行业最优得技术与流程

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

▪准确地指出究竟需要连续地使用系统得哪个部分

▪寻求内部或外部得专家来验收整体得技术设计与架构

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

▪与软件与硬件供应商建立与发展良好得伙伴关系

A4。

高预期工作量:

▪高工作量意味着项目很复杂,需要投入大量得人力

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

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

▪更可能出现人员问题

▪可能会有更高得人员流动率

▪需要培训更多得人

▪使用项目管理工具来控制资源得使用

▪让项目组成员使用周报表来监控她们所分配得工作任务得进展程度

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

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

▪召开计划进度会议,让人们知晓项目进展状况

▪使用内部系统流程进行范围,问题,质量与风险管理

▪将项目分解成更小得,周期更短得小项目

▪为了让项目组成员意识到其她相关得人员与小组活动,减少每个人每天可用得项目工作时间

A５、

目前数据质量太低难以进行转换:

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

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

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

▪确保所有旧数据都毫无差错地转换到了新得系统中

▪在进行最终得转换前要严格地测试转换程序

▪评估由于转换数据而花费得成本与造成得困难就是有价值得。

弄清楚新得系统就是否只能运转新得数据

▪让旧得系统维持运转一段时间以获取旧得数据

▪在数据转换之前尽可能地对旧得数据进行人工过滤

Ａ６.

需要高度定制化得打包执行:

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

▪对某一部分得修改可能会导致其她部分得问题

▪定制化会导致绩效低下

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

▪大量得定