项目评估表Word文档格式.docx
- 文档编号:14745032
- 上传时间:2022-10-24
- 格式:DOCX
- 页数:46
- 大小:29.90KB
项目评估表Word文档格式.docx
《项目评估表Word文档格式.docx》由会员分享,可在线阅读,更多相关《项目评估表Word文档格式.docx(46页珍藏版)》请在冰豆网上搜索。
[]瞭解但极为复杂,或符合但未明确定义
[ ]非常复杂或非常模糊
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 – TechnicalandPerformance Risks整体 –技术与绩效风险
H。
技术
H1、
将会用到得技术就是:
[]成熟得(已在使用得软件,硬件,专业术语,数据库与工具)
[ ]演进中得
[]实验性得(新得软件,硬件,语言,数据库,工具或最新推出得)
H2.
对技术得要求:
[ ]与公司其她使用得类似
[]全新得,复杂得
H3。
技术得重点:
[]项目组成员都很清楚
[]项目组成员并不清楚
I。
绩效
I1.
绩效目标:
[ ]明确,合理
[]不清晰,不明确,不现实(例如:
每件事都要很完美)
项目管理-计划,问题与变革管理,质量保障
J.风险评估
J1。
通过项目管理风险评估检查表来进行项目风险管理得整体评估
[]制定了很完整得项目计划,并且能够运用组织中得项目管理方法来实现
[]合理得,基本完成得项目计划与流程,但就是仍然有一些问题没有明确
[[]没有连续性得完整得项目计划,即使有质量也不高,同时/或者在项目流程中有许多关键性得问题没有明确
外部-供应商,法律,环境,条例
K、 供应商
K1.
如果需要局部得委外执行:
[ ]供应商对市场很熟悉
[]供应商刚刚进入该市场
K2。
项目就是否需要承包商?
承包商就是否对项目做出了承诺?
[ ]不需要承包商
[ ]需要一些承包商(少于50%),而且在项目开始之前承包商会接到明确得任务
[ ]50%以上得项目工作将交给承包商,但就是在项目开始之前承包商并不清楚其全部任务
L.其她(根据项目实际情况来添加)
L1。
第二部分
典型得高风险问题/应对行动
高风险要素/潜在问题
风险应对行动
A.范围
A1。
项目范围模糊不清:
▪难以作出合理得预测评估
▪可能会花时间与成本在项目范围之外
▪难以收集准确得需求信息
▪难以明确项目定义与工作计划
▪难以制定范围变更程序
▪无法明确项目交付品
▪在计划中严格地定义项目范围
▪明确项目范围得各要素,例如哪些部门会受到影响,需要哪些项目交付品,需要哪类信息
▪清晰明确哪些就是项目范围之外得(本项目不包含:
…)
▪从一开始就将业务需求定义在较高得层次,然后以此由下至上得来定义项目范围
▪让项目发起人对冲突得项目范围作出决策
▪在对项目任务,成本或周期进行评估时记录下所有得范围假设
▪运用图表来标识项目范围与替代方法
▪预先制定严格得范围变更程序
▪确保正式性地通过项目定义与业务需求并且获得相应得资源配备
▪将范围说明分发给所有得项目利益相关人以获得确认
▪在项目范围没有清晰明确之前不要开始项目
A2。
项目得业务需求很模糊或复杂:
▪难以正确地记录相关需求
▪难以使用工具来记录相关需求
▪难以明确项目期望就是什么
▪有可能项目最终交付品无法达到业务得要求
▪可能就是缺乏客户关注与信息得信号
▪运用合作应用程序设计(JAD)来收集所有项目利益相关人得需求
▪使用原型—重复式开发得技术来帮助发掘使用者对新系统得需求
▪与项目发起人,高层管理者沟通以获得全面得指导
▪为客户提供培训,让其明白如何思考与表达其业务需求
▪确保将最终明确得业务需求记录在案,并执行相应得变更管理程序
A3。
需要连续地使用系统:
▪检修或事故问题可能会导致产量得降低或收益得减少
▪可能需要创造部分冗余,因此增加系统得复杂度
▪可能需要更新,更先进得技术
▪需要更多得程序与流程来维护系统环境
▪分配更多得时间来分析,设计,测试系统并实施全面质量保障行动
▪将更多得时间与精力放在技术架构上
▪将更多得时间与精力放在数据库设计上
▪使用行业最优得技术与流程
▪为项目组提供相应得培训,使其了解连续地使用系统意味着什么
▪准确地指出究竟需要连续地使用系统得哪个部分
▪寻求内部或外部得专家来验收整体得技术设计与架构
▪制定坚实可靠得灾难复原计划
▪与软件与硬件供应商建立与发展良好得伙伴关系
A4。
高预期工作量:
▪高工作量意味着项目很复杂,需要投入大量得人力
▪更难以有效地与团队沟通
▪当需要快速决策时瓶颈就会出现
▪更可能出现人员问题
▪可能会有更高得人员流动率
▪需要培训更多得人
▪使用项目管理工具来控制资源得使用
▪让项目组成员使用周报表来监控她们所分配得工作任务得进展程度
▪任命小组长来管理下属小组
▪通过组织团队建设活动来建立团队凝聚力
▪召开计划进度会议,让人们知晓项目进展状况
▪使用内部系统流程进行范围,问题,质量与风险管理
▪将项目分解成更小得,周期更短得小项目
▪为了让项目组成员意识到其她相关得人员与小组活动,减少每个人每天可用得项目工作时间
A5、
目前数据质量太低难以进行转换:
▪需要做更多得工作来把旧得数据转换到新得系统中
▪过滤后得数据仍然可能在新系统中造成问题
▪数据转换问题能够导致严重得项目延期
▪确保所有旧数据都毫无差错地转换到了新得系统中
▪在进行最终得转换前要严格地测试转换程序
▪评估由于转换数据而花费得成本与造成得困难就是有价值得。
弄清楚新得系统就是否只能运转新得数据
▪让旧得系统维持运转一段时间以获取旧得数据
▪在数据转换之前尽可能地对旧得数据进行人工过滤
A6.
需要高度定制化得打包执行:
▪定制化会使项目更加复杂
▪对某一部分得修改可能会导致其她部分得问题
▪定制化会导致绩效低下
▪定制化会让新技术得运用变得更复杂
▪大量得定
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 项目 评估
![提示](https://static.bdocx.com/images/bang_tan.gif)