项目评估表样本.docx
- 文档编号:28076509
- 上传时间:2023-07-08
- 格式:DOCX
- 页数:27
- 大小:28.17KB
项目评估表样本.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
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 项目 评估 样本