项目评估表样本

XX项目风险评估表1. 项目风险评估表使用指南第一某些风险评估问卷第二某些常用高风险问题/应对行动—注意：不同风险承受度应制定不同应对筹划。

A1 . 项目范畴模糊不清：▪难以作出合理预测评估▪也许会花时间和成本在项目范畴之外▪难以收集精确需求信息▪难以明确项目定义和工作筹划▪难以制定范畴变更程序▪无法明确项目交付品▪在筹划中严格地定义项目范畴▪明确项目范畴各要素，例如哪些部门会受到影响，需要哪些项目交付品，需要哪类信息▪清晰明确哪些是项目范畴之外(本项目不包括:…)▪从一开始就将业务需求定义在较高层次，然后以此由下至上来定义项目范畴▪让项目发起人对冲突项目范畴作出决策▪在对项目任务，成本或周期进行评估时记录下所有范畴假设▪运用图表来标记项目范畴和代替办法▪预先制定严格范畴变更程序▪保证正式性地通过项目定义和业务需求并且获得相应资源配备▪将范畴阐明分发给所有项目利益有关人以获得确认▪在项目范畴没有清晰明确之前不要开始项目A2 . 项目业务需求很模糊或复杂：▪难以对的地记录有关需求▪难以使用工具来记录有关需求▪难以明确项目盼望是什么▪有也许项目最后交付品无法达到业务规定▪也许是缺少客户关注和信息信号▪运用合伙应用程序设计（JAD）来收集所有项目利益有关人需求▪使用原型—重复式开发技术来协助发掘使用者对新系统需求▪与项目发起人，高层管理者沟通以获得全面指引▪为客户提供培训，让其明白如何思考和表达其业务需求▪保证将最后明确业务需求记录在案，并执行相应变更管理程序A3 . 需要持续地使用系统：▪检修或事故问题也许会导致产量减少或收益减少▪也许需要创造某些冗余，因而增长系统复杂度▪也许需要更新，更先进技术▪需要更多程序和流程来维护系统环境▪分派更多时间来分析，设计，测试系统并实行全面质量保障行动▪将更多时间和精力放在技术架构上▪将更多时间和精力放在数据库设计上▪使用行业最优技术和流程▪为项目组提供相应培训，使其理解持续地使用系统意味着什么▪精确地指出究竟需要持续地使用系统哪个某些▪谋求内部或外部专家来验收整体技术设计和架构▪制定坚实可靠劫难复原筹划▪与软件和硬件供应商建立和发展良好伙伴关系A4 . 高预期工作量：▪高工作量意味着项目很复杂，需要投入大量人力▪更难以有效地与团队沟通▪当需要迅速决策时瓶颈就会浮现▪更也许浮现人员问题▪也许会有更高人员流动率▪需要培训更多人▪使用项目管理工具来控制资源使用▪让项目构成员使用周报表来监控她们所分派工作任务进展限度▪任命小组长来管理下属小组▪通过组织团队建设活动来建立团队凝聚力▪召开筹划进度会议，让人们知晓项目进展状况▪使用内部系统流程进行范畴，问题，质量和风险管理▪将项目分解成更小，周期更短小项目▪为了让项目构成员意识到其她有关人员和小组活动，减少每个人每天可用项目工作时间A5.当前数据质量太低难以进行转换： ▪ 需要做更多工作来把旧数据转换到新系统中▪ 过滤后数据依然也许在新系统中导致问题 ▪数据转换问题可以导致严重项目延期▪ 保证所有旧数据都毫无差错地转换到了新系统中▪ 在进行最后转换前要严格地测试转换程序▪评估由于转换数据而耗费成本和导致困难是有价值。

弄清晰新系统与否只能运转新数据▪ 让旧系统维持运转一段时间以获取旧数据▪在数据转换之前尽量地对旧数据进行人工过滤A6.需要高度定制化打包执行： ▪ 定制化会使项目更加复杂▪ 对某一某些修改也许会导致其她某些问题 ▪ 定制化会导致绩效低下▪ 定制化会让新技术运用变得更复杂▪ 大量定制化也许意味着之前选取了错误打包工具 ▪ 很有也许要花更长时间来实行打包工具 ▪定制化会需要更多地依赖供应商▪ 考虑其她打包工具 ▪ 考虑定制化发展▪ 减少业务需求，这样也不用定制化了 ▪ 从供应商处获得拟定修改成本和周期，并将其记录进你整体工作筹划 ▪ 管理与供应商关系，保证所有必要工作都能准时完毕▪ 保证项目发起人通过定制化方案 ▪ 为保证正常运作和绩效，全面彻底地测试修改后打包工具▪运用供应商日记来追踪问题和项目里程碑A7.打包执行是一种全新产品： ▪会有更大问题风险▪ 更多地依赖供应商来保证迅速地解决问题 ▪ 安装，测试和配备使用将需要更长周期▪几乎很难预知这个打包工具与否符合所有业务需求▪ 尽早为项目构成员安排打包工具有关培训▪ 为项目增派一种有有关产品经验内部资源或征询师▪ 在全面实行之前安排打包工具试点，使项目组尽快熟悉起来▪ 与供应商就支持度和问题解决时间达到共识▪ 如果有其她公司也在使用同样产品，看看能不能将项目延期到其使用时间之后 ▪搜寻其她使用过该产品公司，谋求她们反馈和核心所得B1. 项目重要里程碑和/或完毕日期是固定，但这是由于业务承诺或法律规定而被事先固定，不受项目组控制：▪ 工作必要以这个日期期限为指引 ▪ 也许无法在期限内完毕所有必须项目活动 ▪ 很有也许无法达到排程规定▪赶工和时程压力很有也许导致项目工作中无法改正错误▪ 依照必须项目活动对排程再进行协商和谈判▪ 对范畴再进行协商和谈判，使项目活动可以在规定期间内完毕▪依照实际预测评估与客户/项目所有者/项目发起人重新建立新共识 ▪执行积极项目跟踪和监控筹划 ▪ 进行常规性时程报告及沟通B2.预测项目周期会很长: ▪ 更难管理项目排程▪ 使项目组和客户更加容易失去焦点和重心 ▪ 项目很有也许会失去组织支持和承诺 ▪ 业务需求很有也许会变化▪ 软件或硬件版本(技术和工具)很有也许会变化 ▪ 很难在项目开始时营造急迫感 ▪很有也许导致项目构成员和客户流失▪ 将项目分解成更小，周期更短小项目 ▪ 明确项目里程碑，使其按进度发展和完毕▪ 要持续不断地使用正式变动管理程序 ▪ 轮换项目构成员角色，保持其持续较高兴趣度▪ 尽量地走在预测进度前面 ▪在项目初始阶段就营造一种急迫感 ▪ 组织团队建设活动，建立团队凝聚力防止人心涣散▪ 保证所有重要交付品都正式通过，然后再引入变革管理▪使技术设计和架构决策尽量灵活，为潜在变更做好准备C1. 预算不是使用已证明有效成本预估程序或有经验个人建立：▪ 预算很有也许不精确▪ 设计预算筹划不便于跟踪和监控▪对于哪些工作能在预算内完毕会有不现实盼望▪ 使用成熟工具或有经验个人重新评估项目▪ 修改项目范畴，使其可以纳入可用资金范畴内▪ 在未优化原预算筹划之前不要开始项目 C2.项目资金到位比预算少，并且不稳定： ▪ 项目不也许完毕预期目的▪项目很有也许超过其预备资金▪ 对项目范畴再进行协商和谈判，使其可以纳入可用资金范畴内▪在获得充分预算或减少项目范畴之前不要开始项目D1 . 项目高度依赖于此外一种独立关联项目，如果没有收到关联项目最后交付品就无法展开：▪不在项目控制范畴内事情可以严重地影响项目产出和实现目的能力▪关联项目交付品如果延期就很有也许导致项目进度延迟▪修改其中一种或所有项目排程，使项目交付品可以整合起来▪对项目范畴和/或排程再次进行协商和谈判▪就满足项目需求与关联项目达到共识，并将其记录在案▪为了最大限度地减少冲突，两个项目要紧密合伙和互相监控E1 . 缺少项目管理经验：▪也许要花更长时间来定义项目和建立工作筹划▪也许会有更多判断上失误，导致返工或项目延期▪更难以组织和管理一种复杂项目▪也许对全面项目管理实践不熟悉▪也许不懂得何时应当谋求协助▪提供事前项目管理培训▪指派一种更高层管理者来辅导项目经理▪建立并执行有力质量保障流程来保证项目正常开展▪保证重要交付品正式通过▪通过有力团队领导和团队成员带来更多有关经验E2 . 不熟悉或并不准备使用项目管理流程：▪项目团队也许无法知晓如何提出问题，范畴变更和风险▪当内部流程越来越复杂和难以管理时，项目有也许不受控制▪将缺少良好沟通▪完毕项目交付品也许样式不统一▪无法及时地提出问题，由于无法考量对项目影响，范畴变更也也许无法实行，风险也许被忽视，最后无法实现最优质量▪很有也许无法预期项目潜在问题和困难▪向项目经理和项目团队提供完整项目管理流程和程序培训▪为项目分派一位有经验项目管理教练或导师▪将整体项目分解成更小项目，从而可以进行较不严谨项目管理▪在项目开始之前明确并认同一套项目管理程序，涉及问题管理，变更管理，风险管理，和质量管理▪建立一种强有力沟通筹划，以保证每个成员都懂得项目进展并提供反馈▪申请并获得随时对问题，风险，范畴变更和质量管理投入E3.分处多地项目团队： ▪ 更难以有效地沟通▪ 缺少充分团队互动和凝聚力 ▪ 很难与整个团队建立私人关系▪ 有些成员也许会感到被孤立，而非团队一员 ▪技术问题也许导致生产力下降▪ 试着将团队汇集到一种地方，或至少在项目启动阶段▪ 建立一种积极沟通筹划保证有效地团队沟通▪ 召开例会，让整个团队可以进行面对面沟通▪ 安排团队建设活动，让整个项目组碰面 ▪ 准备后备沟通工具和方式，以防重要技术浮现问题▪ 与远距离团队成员保持经常性电话联系 ▪建立一种中央数据库，以便所有团队成员来查阅存储项目文献F1. 没有明确或正式授权项目发起人：▪ 项目也许无法获得其所需资源 ▪ 项目也许无法获得所必须长期承诺 ▪ 政治斗争也许会使项目延期▪问题和变更申请也许无法及时地得到解决▪ 建立一种强有力指引委员会来协助指引整个项目▪ 为解决部门间冲突建立一套流程 ▪ 尝试更换成另一种发起人▪ 祈求发起人向另一种可以从项目利益出发人授权 ▪不要开始项目G1. 提供项目知识项目参加人或是无法加入项目或是仍未明确：▪ 缺少所需项目知识将会为精确完毕项目带来负面影响 ▪项目接受人将不会满意▪为了获得所需项目知识，就资源承诺进行再次协商和谈判▪ 为获得所需项目知识，就项目进展进行再次协商或谈判 ▪不要开始项目G2 . 业务流程和政策需要实质性变化：▪政策变化会使项目延期▪新流程会使人们感到困惑，从而影响她们使用此流程能力▪有也许开始时无法完全地整合新流程▪如果新流程无法完全地应对所有突发状况，那它将是无用▪如果没有对的程序支持，系统功能将会瘫痪▪实质性流程变化也许会导致破坏性行为▪记录当前所有政策和流程，保证她们对的性▪精确地阐述新旧流程之间差别▪尽量早地就潜在变迁进行沟通▪保证客户理解流程和政策变化▪指定一种人来负责所有流程和政策变化▪建立一种积极沟通筹划，使客户可以随时理解和获得有关信息▪对新流程进行试点，以保证她们有效性和精确性▪将与否成功实行新政策和流程作为项目经理绩效评估一某些▪向客户公开流程变化以获得更好建议，同步让她们感到自己影响力G3 . 组织构造需要实质性变化：▪组织不拟定会导致组织内畏惧感▪如果项目团队注意力都放在了组织层面，那她们将不会集中精力于项目上▪在新组织中人们也许会担忧失去工作▪如果人们不欢迎组织变革，那她们也许不会使用新系统▪不拟定性也许会延迟决策▪组织变革也许会导致以政治为目决策▪记录新组织中存在担忧，并寻找相应办法来减轻这些担忧▪尽早地经常性地就潜在变革和相应业务因素进行沟通▪让所有利益有关者代表都投入到组织设计和规划中▪投入人力资源来解决潜在人员问题G4 . 大量部门将会受到影响：▪协同合伙会更加复杂▪通过或批准某项决策会更加麻烦和费时▪更难以达到共识▪筹划和需求将涉及更多人和团队▪更难以理解不同部门重要利益有关人▪执行会更加困难和复杂▪建立一种正式决策批准流程▪建立一种代表整个利益有关团队指引委员会▪让项目发起人参加到项目中，并随时准备干涉不同部门▪让每个组织代表参加需求提出，质量保证和测试▪让来自不同部门人有机会会面和互动▪让项目组严格遵循整个项目目的和优先顺序▪在所有也许状况下使用建立共识技巧G5 . 客户对项目承认度低/很难互动：▪也许会导致对商业价值信心局限性▪更难以从客户处获得所需时间和资源▪更难以收集业务需求▪客户也许会破坏或阻碍项目开展▪建立一种积极沟通筹划，让客户参加到项目中，并让其理解其中商业利益▪建立顾客小组，明确其关怀问题并激发其积极性▪让顾客加入到筹划和需求收集过程中▪让项目发起人协助激起客户对项目积极性▪寻找机会在轻松有趣环境中推销项目▪当需要客户资源时，要积极地去得到客户对此承诺▪不要开始项目H1 . 新和不熟悉项目技术（或新发布）：▪学习曲线也许会导致较低初期产出▪也许存在新旧技术整合问题▪对技术变化抵制也许会导致项目延期▪在测试新技术时也许会有困难▪也许无法对的安装或架构技术，而导致项目延期▪新技术工具会导致更长交付时间▪新技术也许会需要大量转换工作▪当专业技术都用于优化和架构技术时，系统绩效也许会很差▪尽早提供对于新技术实践性培训▪向需要对新技术进行安装，使用和支持人员进行培训▪当需要时要充分运用供应商技术专家▪运用外部熟悉此技术专业顾问▪保证有足够测试环境，这样使用新技术也不会影响产出▪保证对新技术功能，特性和性能都进行了彻底夯实分析▪对如何使用新技术建立一套程序和规范▪一开始在小范畴对新技术实行试点H2 . 新,复杂技术：▪也许很难理解需求和所需设计▪新旧技术间也许有整合问题▪也许很难测试复杂技术▪技术越复杂，问题风险越大▪在整合或系统测试完毕后才干发现技术无法解决问题▪运用系统和技术设计档案来弄清各项技术是如何组合起来▪明确整体系统技术架构，并请公司中有经验专业人员进行审查通过▪请外部顾问审查架构建议书以获得更多反馈和确认▪一开始在小范畴内对新技术进行试点▪尽量多在架构中使用通过验证和熟悉技术▪使用同一供应商复合产品以使整合系统过程更加流畅和容易▪使用有公开原则和架构产品以减少整合问题带来风险H3.项目团队对项目重点并不理解： ▪ 项目团队成员需要更长学习曲线▪ 项目也许会在开始阶段就脱节 ▪ 无法理解业务需求与否故意义 ▪ 核心特性和功能也许会被漏掉▪需要从最初就依托客户来提供关于项目重点所有专业知识和技术▪ 尽早地提供实践性培训 ▪ 将核心客户带入项目团队中▪ 花额外时间来理解和记录需求 ▪ 对所需多重项目重点建立有关专家审批流程▪ 通过合伙应用程序设计（JAD ）来收集所有利益有关人需求 ▪ 更频繁与客户进行项目预排▪在评估时安排更多时间进行使用分析和设计活动I1. 绩效目的不清,不明确或不现实（例如一切都要完美）： ▪项目团队会由于主次目的不清而陷入困境▪ 如果绩效需求没有在一开始就记录在案，那项目团队更易于在项目进行过程中被迫接受新绩效需求 ▪既然项目目的无法实现，项目将会失败▪保证所有绩效目的都被记录在案，并经由项目团队批准，由项目发起人审批通过▪坚持任何关于绩效目的变更都必要通过正式变更申请J1. 项目筹划不统一，不完整或无法达到质量规定；或者项目流程中有必要弄清问题：▪ 项目工作也许无法协调，毫无成效 ▪ 项目范畴也许更容易在不知不觉中扩大 ▪没有完整项目筹划就不也许实现项目绩效目的▪ 遵循组织项目管理办法论▪ 完毕推荐项目表格，并获得核心利益有关人通过▪ 明确并改正任何已辨认项目流程问题 ▪在项目执行过程中跟踪和更新项目筹划K1.由新供应商来执行打包技术： ▪ 也许供应商无法完毕任务并无法向你提供所需支持▪ 如果市场中没有足够产品销售，那升级将会受到威胁 ▪ 没有可以迅速建立伙伴关系基本▪法律和财务考虑也许会导致合同和项目延期▪ 保证与供应商所有合同都记录在案 ▪ 坚持将原始代码放进契约中以防供应商无法完毕任务▪ 让供应商成为项目组一员▪ 使用供应商日记来跟踪打包中浮现问题 ▪ 保证供应商财务可靠▪与供应商就支持限度和问题解决时间达到合同K2. 超过50%项目工作需委托承包商，而她们对投入项目仍未承诺：▪ 在项目初始就缺少所需人员 ▪也许会对项目排程导致极负面影响▪ Increase project management oversight of contractor personnel▪ Start of project should be delayed until staffed▪ Increased communications focus is a must▪ 增强对承包商人员项目管理监察 ▪ 在人员到位之前不要开始项目 ▪必要增长对承包商沟通L1. ▪2. 项目风险评估表/会签 项目名称: 项目经理：我已经审视过此项目风险评估表信息并批准：以上签名表达签名人理解此文献目和内容，并承认此为正式项目风险评估表。