项目风险评估表改

14/14工程风险评估表工程名称:报告人:日期(年/月/日):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〕来收集所有利益相关人的需求更频繁的与客户进行工程的预排在评估时安排更多的时间进行使用分析和设计活动H4.是否满足有关部门的要求：工程团队成员没有完全有关部门要求工程可能会在开