Tool9 项目风险评估表

1、项目风险评估表?使用此表中得第一部分来识别项目风险及其对完成项目目标得影响程度。在这一部分中，将根据风险特征来进行风险分类，共分为高，中，低三个档。这个风险分类表并非完全得,而只就是风险识别得开始 于不同得组织或项目，必须因地制宜地添加具体得风险特征或指标。为了完成此问卷 项目评估时表现项目特征得描述词。同时要确保完成项目计划风险评估检查表?完成后得问卷与检查表将会识别岀项目风险要素。此结果应被用作风险管理与监控得指南 有其她要素会影响风险得影响程度。例如高度复杂得项目会有较高得内部风险,经理来领导此项目时该风险就会降低。高风险特性多得项目并不意味着一定会失败 制定与执行一个计划来识别每个潜在

2、得高风险因素。常见得高风险问行题一注意：不同得风险承受度应制定不同得应对计划。?运用此表得第二部分来分析已识别得风险，并制定相契合得应对计划。在这个部分中列岀了某种高风险得早期预警信号，问题案例，以及可以用来降低或应对每个风险得行动案例。在风险应对计划表中，需对每个在第一部分中识别得高风险要素制定应对计划，以降低此风险，从而保障项目得成功。除了将第二部分中得行动案例作为可能得应对计划，项目团队也可以提岀更多得建议。在对所有高风险要素制定了应对计划后，项目团队应检查可能存在得中度风险，并且明确这些风险就是否严重到也需要使用风险应对计划表。如果就是，请使用风险应对计划表为中度风险要素制定应对计划。

3、而低 风险因素可能只就是一些假设，也就就是说它们可能会产生问题但因为影响程度低所以您“假设”这种情况并不会发生。在整个项目过程都要使用风险应对计划来管理与监控风险。ORGANIZATION组织范围A1 项目范围就是：明确且了解得:大部分确认但可能改变A2、公司/商务需求：:了解且符合:瞭解但极为复杂，或符合但未明确定义A3、系统可用性包括可使用得通路及其停工期A4、预估总需求人力小时数：H 氐于 1,000 小时:1,000 至 5,000 小时不明确且/或可能改变 非常复杂或非常模糊需连续使用远大于 5,000 小时项目名称：报告人：。对,要尽量选择最能在;当然也许还，而当一个有经验得项目，

4、而就是意味着必须第二部分:可能会导致第一部分风险评估问卷Characteristics风险特征Low Risk低Medium Risk中High Risk高日期（年/月 /第一部分风险评估问卷A5、现有资料得质量：好且易于使用明确但难以使用， 或不明确但 易于使用差或难以使用A6、项目得执行：不需客制化需要客制化需要高度客制化A7、项目得执行：稳定得产品或市场宣传模式新产品或新得市场宣传模式B、时程B1、项目主要里程碑与完成日期：弹性-可由用户与项目组员 商议后决定确定-已定且脱期后可能会 影响商机刚性-已由具体得营运委员 会决定，或规定得要求超过项目 团队得掌控能力B2、预估项目周期：低于

5、3 个月3 到 12 个月远大于 12 个月C、预算C1、预算就是由有经验得人，使用已证 实有效得成本预估程序来生成：就是-由有经验得人操作有 效得预算程序有一些经验或程序否-人员无经验且无程序C2、项目资金符合或大于成本预算与稳 定性、预算大于需求且/或预期稳 定、预算等于成本且预期相对稳 定、预算低于需求且/或稳定性高 度不确定、D、项目关联性D1、本项目依赖相关项目得关系可以形 容为：轻微依赖，即使没有相关项 目得产出仍可完成有些依赖,没有相关项目得产 出可能造成延期高度依赖，无相关项目得产 出无法继续进行E、人力资源E1、项目经理得经验与培训就是：最近在类似项目管理上取得 了成功最近在

6、非类似项目管理上取 得了成功或经过培训但无经验无近期经验或未经项目管理 培训E2、依需要管理工具与技术得使用来描 绘项目组员、熟练使用工具与技术对使用工具与技术经过正式 得培训,但少或无实际经验无正式培训或无实际使用经 验E3、项目组员就是：同处一地分处多处F、发起人/高层领导得支持F1、项目发起人就是：明确得,对项目认可且充满热 情得明确得，但缺乏热情得既不明确也缺乏热情G、其她生意或组织上得影响G1、就是否需要能够提供项目所需相关 知识技能得项目参与人：项目中不需要或项目组成员 已经具有丰富得相关知识在某些方面经验不足没有或当下没有找到合适得 人选第二部分典型得高风险问题/应对行动G2 就

7、是否需要改变组织流程与政策：完全不需要或很少H 禺尔到经常性得改变实质性得改变G3、描述项目结果对业务流程或组织变 革得影响：没有或只就是很微小得变迁冲度变迁重大变革或目前还不清楚G4、将受到此改变影响得部门：:一个或两个三个或四个五个以上G5、项目得接收部门与利益相关部门对 于该项目将带来得变化得接受度， 您会怎么评分？:高接受度（充满热情与期待） 一般接受度低接受度（消极且很难融入）GENERAL -Technical and Performance Risks整体 -技术与绩效风险H、 技术H1、将会用到得技术就是：成熟得（已在使用得软件，硬件，专业术语,数据库与工具）演进中得实验性得（

8、新得软件,硬件,语言,数据库，工具或最新推出得）H2、对技术得要求：与公司其她使用得类似全新得,复杂得H3、技术得重点：:项目组成员都很清楚项目组成员并不清楚、绩效11、 绩效目标:明确，合理 不清晰， 不明确,不现实 （例如：每件事都要很完美）项目管理一计划，问题与变革管理，质量保障J、风险评估J1、通过项目管理风险评估检查表 来 进行项目风险管理得整体评估制定了很完整得项目计划，并且能够运用组织中得项目管理 方法来实现合理得，基本完成得项目计划与流程,但就是仍然有一些问题 没有明确没有连续性得完整得项目计划， 即使有质量也不高， 同时/或者在项目流程中有许多关键性得 问题没有明确外部一供应

9、商，法律，环境，条例K、 供应商K1、如果需要局部得委外执行：供应商对市场很熟悉供应商刚刚进入该市场K2、项目就是否需要承包商？承包商就 是否对项目做出了承诺？不需要承包商需要一些承包商（少于 50%）,而且在项目开始之前承包商会 接到明确得任务50%以上得项目工作将交给 承包商， 但就是在项目开始之前 承包商并不清楚其全部任务、 其她（根据项目实际情况来添加）L1、高风险要素/潜在问题风险应对行动A、范围A1项目范围模糊不清：?在计划中严格地定义项目范围、?难以作出合理得预测评估?明确项目范围得各要素，例如哪些部门会受到影响，?可能会花时间与成本在项目范围之外需要哪些项目交付品，需要哪类信息

10、?难以收集准确得需求信息?清晰明确哪些就是项目范围之外得（本项目不包含:）从一开始就将业务需求定义在较高得层次，然后以?难以明确项目定义与工作计划?难以制定范围变更程序此由下至上得来定义项目范围?无法明确项目交付品?让项目发起人对冲突得项目范围作出决策?在对项目任务，成本或周期进行评估时记录下所有 得范围假设?运用图表来标识项目范围与替代方法?预先制定严格得范围变更程序?确保正式性地通过项目定义与业务需求并且获得相 应得资源配备?将范围说明分发给所有得项目利益相关人以获得确 认?在项目范围没有清晰明确之前不要开始项目A2项目得业务需求很模糊或复杂：?运用合作应用程序设计（JAD）来收集所有项目

11、利益、?难以正确地记录相关需求相关人得需求?难以使用工具来记录相关需求?使用原型一重复式开发得技术来帮助发掘使用者对 新系统得需求?难以明确项目期望就是什么?与项目发起人，高层管理者沟通以获得全面得指导?有可能项目最终交付品无法达到业务得要求?为客户提供培训，让其明白如何思考与表达其业务?可能就是缺乏客户关注与信息得信号需求?确保将最终明确得业务需求记录在案，并执行相应 得变更管理程序A3需要连续地使用系统：?分配更多得时间来分析，设计,测试系统并实施全面、?检修或事故问题可能会导致产量得降低或收益得减少质量保障行动?可能需要创造部分冗余，因此增加系统得复杂度?将更多得时间与精力放在技术架构上

12、?可能需要更新，更先进得技术?将更多得时间与精力放在数据库设计上?需要更多得程序与流程来维护系统环境?使用行业最优得技术与流程?为项目组提供相应得培训，使其了解连续地使用系 统意味着什么?准确地指出究竟需要连续地使用系统得哪个部分?寻求内部或外部得专家来验收整体得技术设计与架 构?制定坚实可靠得灾难复原计划?与软件与硬件供应商建立与发展良好得伙伴关系A4 高预期工作量：?使用项目管理工具来控制资源得使用、?高工作量意味着项目很复杂，需要投入大量得人力?让项目组成员使用周报表来监控她们所分配得工作?更难以有效地与团队沟通任务得进展程度?当需要快速决策时瓶颈就会出现?任命小组长来管理下属小组?更可

13、能出现人员问题?通过组织团队建设活动来建立团队凝聚力?可能会有更高得人员流动率?召开计划进度会议，让人们知晓项目进展状况?需要培训更多得人?使用内部系统流程进行范围，问题，质量与风险管理?将项目分解成更小得，周期更短得小项目?为了让项目组成员意识到其她相关得人员与小组活 动，减少每个人每天可用得项目工作时间A5目前数据质量太低难以进行转换：?确保所有旧数据都毫无差错地转换到了新得系统中、?需要做更多得工作来把旧得数据转换到新得系统中?在进行最终得转换前要严格地测试转换程序?过滤后得数据仍然可能在新系统中造成问题?评估由于转换数据而花费得成本与造成得困难就是?数据转换问题能够导致严重得项目延期有

14、价值得。弄清楚新得系统就是否只能运转新得数 据?让旧得系统维持运转一段时间以获取旧得数据?在数据转换之前尽可能地对旧得数据进行人工过滤A6需要高度定制化得打包执行：?考虑其她得打包工具、?定制化会使项目更加复杂?考虑定制化得发展?对某一部分得修改可能会导致其她部分得问题?减少业务需求，这样也不用定制化了?定制化会导致绩效低下?从供应商处获得确定得修改成本与周期，并将其记?定制化会让新技术得运用变得更复杂录进您得整体工作计划?大量得定制化可能意味着之前选择了错误得打包工具?管理与供应商得关系，确保所有必须得工作都能按 时完成?很有可能要花更长得时间来实施打包工具?确保项目发起人通过定制化方案?定

15、制化会需要更多地依赖供应商?为保证正常运作与绩效，全面彻底地测试修改后得 打包工具?利用供应商日志来追踪问题与项目里程碑A7打包执行就是一个全新得产品：?尽早为项目组成员安排打包工具得相关培训、?会有更大得问题风险?为项目增派一个有相关产品经验得内部资源或咨询?更多地依赖供应商来确保迅速地解决问题师?安装,测试与配置使用将需要更长得周期?在全面实施之前安排打包工具得试点，使项目组尽 快熟悉起来?几乎很难预知这个打包工具就是否符合所有得业务需求?与供应商就支持度与问题解决时间达成共识如果有其她公司也在使用同样得产品，瞧瞧能不能 将项目延期到其使用时间之后搜寻其她使用过该产品得公司，寻求她们得反馈

16、与 关键所得B时程根据实际得预测评估与客户/项目所有者/项目发起 人重新建立新得共识赶工与时程得压力很有可能导致项目工作中无法改正得错误进行常规性得时程报告及沟通B2 预测项目周期会很长：?将项目分解成更小得，周期更短得小项目、? 更难管理项目排程?明确项目里程碑，使其按进度发展与完成? 使项目组与客户更加容易失去焦点与重心?要持续不断地使用正式得变动管理程序? 项目很有可能会失去组织得支持与承诺?轮换项目组成员得角色，保持其持续较高得兴趣度?业务需求很有可能会变化?尽可能地走在预计进度前面?软件或硬件版本（技术与工具）很有可能会变化?在项目初始阶段就营造一种紧迫感?彳艮难在项目开始时营造紧迫

17、感?组织团队建设活动，建立团队凝聚力防止人心涣散? 很有可能造成项目组成员与客户得流失?确保所有得重要交付品都正式通过，然后再引入变 革管理?使技术设计与架构决策尽可能得灵活，为潜在得变 更做好准备C、预算C1预算不就是使用已证实有效得成本预估程序或有经验得个人建立得?使用成熟得工具或有经验得个人重新评估项目、?预算很有可能不准确?修改项目范围，使其能够纳入可用得资金范围内? 设计得预算计划不便于跟踪与监控?在未优化原预算计划之前不要开始项目?对于哪些工作能在预算内完成会有不现实得期望C2项目资金到位比预算少，而且不稳定：?对项目范围再进行协商与谈判，使其能够纳入可用、? 项目不可能完成预期得

18、目标得资金范围内?项目很有可能超出其预备资金?在获得充足得预算或减少项目范围之前不要开始项 目D、项目关联性D1 项目高度依赖于另外一个独立得关联项目，如果没有收到关联项目得最、终交付品就无法展开：不在项目控制范围内得事情能够严重地影响项目得产出与实现目 标得能力关联项目得交付品如果延期就很有可能造成项目进度得延迟B1 项目重要里程碑与/或完成日期就是固定得，但这就是由于业务承诺或法 、律要求而被事先固定得，不受项目组得控制：根据必需得项目活动对排程再进行协商与谈判工作必须以这个日期期限为指导对范围再进行协商与谈判，使项目活动能够在规定得时间内完成可能无法在期限内完成所有必需得项目活动很有可能

19、无法达到排程得要求执行积极得项目跟踪与监控计划修改其中一个或所有得项目排程，使项目交付品能够整合起来对项目范围与/或排程再次进行协商与谈判就满足项目得需求与关联项目达成共识， 并将其记 录在案为了最大限度地减少冲突，两个项目要紧密合作与 相互监控E人力资源E1 缺乏项目管理经验：?可能会有更多判断上得失误，导致返工或项目延期?建立并执行有力得质量保障流程来确保项目正常得?更难以组织与管理一个复杂得项目开展?可能对全面得项目管理实践不熟悉?确保重要交付品正式通过?可能不知道何时应该寻求帮助?通过有力得团队领导与团队成员带来更多相关经验E2 不熟悉或并不准备使用项目管理流程 ：?向项目经理与项目团

20、队提供完整得项目管理流程与、?项目团队可能无法知晓如何提出问题，范围变更与风险程序培训?当内部流程越来越复杂与难以管理时，项目有可能不受控制?为项目分派一位有经验得项目管理教练或导师?将缺乏良好得沟通?将整体项目分解成更小得项目，从而能够进行较不 严谨得项目管理?完成得项目交付品可能样式不统一?在项目开始之前明确并认同一套项目管理程序，包?无法及时地提出问题，由于无法考量对项目得影响，范围变更也可能括问题管理，变更管理，风险管理，与质量管理无法实行，风险可能被忽略，最终无法实现最优得质量?建立一个强有力得沟通计划，以确保每个成员都知?很有可能无法预期项目潜在得问题与困难道项目得进展并提供反馈?

21、申请并获得随时对问题，风险,范围变更与质量管理 得投入E3 分处多地得项目团队：?试着将团队聚集到一个地方，或至少在项目启动得、?更难以有效地沟通阶段?缺乏充分得团队互动与凝聚力?建立一个积极得沟通计划确保有效地团队沟通?彳艮难与整个团队建立私人得关系?召开例会,让整个团队能够进行面对面得沟通?有些成员可能会感到被孤立，而非团队得一员?安排团队建设活动，让整个项目组碰面?技术问题可能导致生产力下降?准备后备得沟通工具与方式，以防主要得技术出现 问题?与远距离得团队成员保持经常性得电话联系?建立一个中央数据库，方便所有得团队成员来查阅 存储项目文件可能要花更长得时间来定义项目与建立工作计划指派一

22、个更高层管理者来辅导项目经理F发起人/高层领导支持提供事前得项目管理培训F1 没有明确得或正式授权得项目发起人建立一个强有力得指导委员会来帮助指导整个项目项目也许无法获得其所需得资源为解决部门间得冲突建立一套流程项目也许无法获得所必需得长期得承诺尝试更换成另一个发起人政治斗争可能会使项目延期请求发起人向另一个能够从项目利益出发得人授权问题与变更申请可能无法及时地得到解决不要开始项目G业务或组织得影响G1 提供项目知识得项目参与人或就是无法加入项目或就是仍未明确缺乏所需得项目知识将会为准确得完成项目带来负面得影响为了获得所需得项目知识，就资源承诺进行再次协商与谈判项目接收人将不会满意为获得所需得

23、项目知识，就项目进展进行再次协商或谈判不要开始项目对新得流程进行试点，以确保她们得有效性与准确 性将就是否成功得实施新得政策与流程作为项目经理 绩效评估得一部分向客户公开流程得改变以获得更好得建议，同时让 她们感到自己得影响力G3 组织结构需要实质性得改变：、? ?记录新得组织中存在得担忧，并寻找相应得办法来 减轻这些担忧尽早地经常性地就潜在得变革与相应得业务原因进 行沟通让所有利益相关者得代表都投入到组织得设计与规 划中投入人力资源来解决潜在得人员问题?组织得不确定会导致组织内得畏惧感如果项目团队得注意力都放在了组织层面，那她们将不会集中精力 于项目上在新得组织中人们可能会担忧失去工作如果人

24、们不欢迎组织得变革，那她们可能不会使用新得系统不确定性可能会延迟决策组织变革可能会造成以政治为目得得决策G4大量得部门将会受到影响：?建立一个正式得决议批准流程、?协同合作会更加复杂?建立一个代表整个利益相关团体得指导委员会?通过或批准某项决议会更加麻烦与费时?让项目发起人参与到项目中，并随时准备干涉不同?更难以达成共识得部门?计划与需求将涉及更多得人与团队?让每个组织得代表参与需求提出，质量保证与测试?更难以了解不同部门得主要利益相关人?让来自不同部门得人有机会见面与互动?执行会更加困难与复杂?让项目组严格遵循整个项目目标与优先顺序?在所有可能得情况下使用建立共识得技巧G5客户得对项目得认可

25、度低/很难互动：?建立一个积极得沟通计划，让客户参与到项目中，并、?可能会导致对商业价值得信心不足让其了解其中得商业利益?更难以从客户处获得所需得时间与资源?建立用户小组，明确其关心得问题并激发其积极性?更难以收集业务需求?让用户加入到计划与需求收集过程中?客户可能会破坏或阻碍项目得开展?让项目发起人帮助激起客户对项目得积极性?寻找机会在轻松有趣得环境中推销项目?当需要客户得资源时，要积极地去得到客户对此得 承诺?不要开始项目H技术G2 业务流程与政策需要实质性得改变记录目前所有得政策与流程，确保她们得正确性政策得改变会使项目延期准确地阐述新旧流程之间得差别新得流程会使人们感到困惑，从而影响她

26、们使用此流程得能力尽可能早地就潜在得变迁进行沟通有可能开始时无法完全地整合新得流程确保客户了解流程与政策得改变如果新得流程无法完全地应对所有得突发状况，那它将就是无用得指定一个人来负责所有流程与政策得改变如果没有正确得程序支持，系统功能将会瘫痪实质性得流程改变可能会导致破坏性行为建立一个积极得沟通计划，使客户能够随时了解与获得相关得信息当专业技术都用于优化与架构技术时，系统绩效可能会很差一开始在小范围对新技术实行试点H2 新得，复杂得技术：?利用系统与技术设计档案来弄清各项技术就是如何、?可能很难理解需求与所需得设计组合起来得?新旧技术间可能有整合问题?明确整体系统技术架构，并请公司中有经验得

27、专业 人员进行审查通过? 可能很难测试复杂得技术?请外部得顾问审查架构建议书以获得更多得反馈与? 技术越复杂，问题风险越大确认? 在整合或系统测试完成后才能发现技术无法解决得问题?一开始在小范围内对新得技术进行试点?尽可能多得在架构中使用经过验证得与熟悉得技术?使用同一供应商得复合产品以使整合系统得过程更 加流畅与容易?使用有公开标准与架构得产品以减少整合问题带来 得风险H3项目团队对项目重点并不了解：?尽早地提供实践性得培训、?项目团队成员需要更长得学习曲线?将关键客户带入项目团队中? 项目可能会在开始阶段就脱节?花额外得时间来了解与记录需求?无法了解业务需求就是否有意义?对所需得多重项目重

28、点建立相关专家审批得流程? 关键得特性与功能可能会被遗漏?通过合作应用程序设计（JAD）来收集所有利益相关? 需要从最初就依靠客户来提供有关项目重点所有得专业知识与技人得需求术?更频繁得与客户进行项目得预排?在评估时安排更多得时间进行使用分析与设计活动1、 绩效I1绩效目标不清，不明确或不现实（例如一切都要完美）:?确保所有得绩效目标都被记录在案，并经由项目团、? 项目团队会因为主次目标不清而陷入困境队同意，由项目发起人审批通过?如果绩效需求没有在一开始就记录在案，那项目团队更易于在项目?坚持任何有关绩效目标得变更都必须通过正式得变 更申请进行过程中被迫接受新得绩效需求?既然项目目标无法实现，项目将会失败J、 项目管理J1项目计划不统一，不完整或无法达成质量要求；或者项目流程中有必须弄?遵循组织得项目管理方法论、清得问题：?完成推荐得项目表格，并