项目评估表样本.docx

项目评估表样本.docx

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

项目评估表样本

XX项目风险评估表

项目名称:

报告人:

日期（年/月/日）:

1.项目风险评估表使用指南

第一某些

风险评估问卷

第二某些

常用高风险问题/应对行动—注意：

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

第一某些

风险评估问卷

Characteristics风险特性

LowRisk低

MediumRisk中

HighRisk高

ORGANIZATION组织

A.范畴

A1

项目范畴是:

[]明确且理解

[]大某些确认但也许变化

[]不明确且/或也许变化

A2.

公司/商务需求:

[]理解且符合

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

[]非常复杂或非常模糊

A3.

系统可用性涉及

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

[]需持续使用

A4.

预估总需求人力小时数:

[]低于1,000小时

[]1,000至5,000小时

[]远不不大于5,000小时

A5.

既有资料质量:

[]好且易于使用

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

[]差或难以使用

A6.

项目执行:

[]不需客制化

[]需要客制化

[]需要高度客制化

A7.

项目执行:

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

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

 B.时程

B1.

项目重要里程碑和完毕日期:

[]弹性–可由顾客和项目成员商量后决定

[]拟定–已定且脱期后也许会影响商机

[]刚性–已由详细营运委员会决定,或规定规定超过项目团队掌控能力

B2.

预估项目周期:

[]低于3个月

[]3到12个月

[]远不不大于12个月

 C.预算

C1.

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

[]是–由有经验人操作有效预算程序

[]有某些经验或程序

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

C2.

项目资金符合或不不大于成本预算和稳定性.

[]预算不不大于需求且/或预期稳定.

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

[]预算低于需求且/或稳定性高度不拟定.

D.项目关联性

D1.

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

[]轻微依赖，虽然没有有关项目产出仍可完毕

[]有些依赖,没有有关项目产出也许导致延期

[]高度依赖，无有关项目产出无法继续进行

E.人力资源

E1.

项目经理经验和培训是:

[]近来在类似项目管理上获得了成功

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

[]无近期经验或未经项目管理培训

E2.

依需要管理工具和技术使用来描绘项目成员.

[]纯熟使用工具和技术

[]对使用工具和技术通过正式培训,但少或无实际经验

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

E3.

项目成员是:

[]同处一地

[]分处多处

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

F1.

项目发起人是:

[]明确，对项目承认且布满热情

[]明确，但缺少热情

[]既不明确也缺少热情

G.其她生意或组织上影响

G1.

与否需要可以提供项目所需有关知识技能项目参加人：

[]项目中不需要或项目构成员已经具备丰富有关知识

[]在某些方面经验局限性

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

G2

与否需要变化组织流程和政策：

[]完全不需要或很少

[]偶尔到经常性变化

[]实质性变化

G3.

描述项目成果对业务流程或组织变革影响：

[]没有或只是很微小变迁

[]中度变迁

[]重大变革或当前还不清晰

G4.

将受到此变化影响部门：

[]一种或两个

[]三个或四个

[]五个以上

G5.

项目接受部门和利益有关部门对于该项目将带来变化接受度，你会怎么评分？

[]高接受度（布满热情和期待）

[]普通接受度

[]低接受度（悲观且很难融入）

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

H.技术

H1.

将会用到技术是：

[]成熟（已在使用软件，硬件，专业术语，数据库和工具）

[]演进中

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

H2.

对技术规定：

[]与公司其她使用类似

[]全新，复杂

H3.

技术重点：

[]项目构成员都很清晰

[]项目构成员并不清晰

I.绩效

I1.

绩效目的：

[]明确，合理

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

每件事都要很完美）

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

J.风险评估

J1.

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

[]制定了很完整项目筹划，并且可以运用组织中项目管理办法来实现

[]合理，基本完毕项目筹划和流程，但是依然有某些问题没有明确

[[]没有持续性完整项目筹划，虽然有质量也不高，同步/或者在项目流程中有许多核心性问题没有明确

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

K.供应商

K1.

如果需要局部委外执行：

[]供应商对市场很熟悉

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

K2.

项目与否需要承包商？

承包商与否对项目做出了承诺？

[]不需要承包商

[]需要某些承包商（少于50%），并且在项目开始之前承包商会接到明确任务

[]50%以上项目工作将交给承包商，但是在项目开始之前承包商并不清晰其所有任务

L.其她（依照项目实际状况来添加）

L1.

第二某些

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

高风险要素/潜在问题

风险应对行动

A.范畴

A1.

项目范畴模糊不清：

▪难以作出合理预测评估

▪也许会花时间和成本在项目范畴之外

▪难以收集精确需求信息

▪难以明确项目定义和工作筹划

▪难以制定范畴变更程序

▪无法明确项目交付品

▪在筹划中严格地定义项目范畴

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

▪清晰明确哪些是项目范畴之外（本项目不包括:

…）

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

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

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

▪运用图表来标记项目范畴和代替办法

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

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

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

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

A2.

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

▪难以对的地记录有关需求

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

▪难以明确项目盼望是什么

▪有也许项目最后交付品无法达到业务规定

▪也许是缺少客户关注和信息信号

▪运用合伙应用程序设计（JAD）来收集所有项目利益有关人需求

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

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

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

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

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.

项目筹划不统一，不完整或无法达到质量规定；或者项目流程中有必要弄清问题：

▪项目工作也许无法协调，毫无成效

▪项目范畴也许更容易在不知不觉中扩大

▪没有完整项目筹划就不也许实现项目绩效目的

▪遵循组织项目管理办法论

▪完毕推荐项目表格，并获得核心利益有关人通过

▪明确并改正任何已辨认项目流程问题

▪在项目执行过程中跟踪和更新项目筹划

K.

供应商

K1.

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

▪也许供应商无法完毕任务并无法向你提供所需支持

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

▪没有可以迅速建立伙伴关系基本

▪法律和财务考虑也许会导致合同和项目延期

▪保证与供应商所有合同都记录在案

▪坚持将原始代码放进契约中以防供应商无法完毕任务

▪让供应商成为项目组一员

▪使用供应商日记来跟踪打包中浮现问题

▪保证供应商财务可靠

▪与供应商就支持限度和问题解决时间达到合同

K2.

超过50%项目工作需委托承包商，而她们对投入项目仍未承诺：

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

▪也许会对项目排程导致极负面影响

▪Increas