教育软件项目风险识别及其应对预防措施研究精编WORD版

教育软件项目风险识别及其应对预防措施研究精编WORD版电话址：某某广告设计有限公司教育软件项目风险识别及其应对预防措施研究摘要在项目的建设过程中，风险几乎无处不在。如何有效地识别、控制和管理风险，对项目的成功起着至关重要的影响。本文在参考了大量的国内外文献的基础上，结合自己多年软件项目工程经验，对软件项目在实施的各个阶段详细分析了其中可能存在的风险并进行分类，其中特别针对教育软件项目中某些特定项目(同时含有软件架构和课程设计的综合解决方案类软件项目)所遇到的特殊风险进行识别。本文第三章对在教育软件项目实施过程中经常遇到的一些风险，举例进行风险分析，并根据多年的实施经验提出了作者的观点和相应的预防措施。虽然其中涉及到的案例仅仅是整个教育软件项目实施过程中的小部分风险，但具有典型意义，期望能为教育软件项目经理制定项目风险计划和进行风险预防、控制等提供参考。关键词：教育软件项目风险管理风险识别预防措施Intheprojectconstruction'sprocesstheriskpossiblyexistingineaviewpointandthecorrespondingpreventivemeasure.Keywords:EducationSof言从概念上讲，软件项目管理是为了使软件项教育教学辅助软件项目同时还存在许多教学内容开发等风险因素在其中，特别是随着教育体制的改革，新技术、新的教学方式在院校中的推广，如何使教育教学辅助软件项目能够抗拒风险走在教学机构之前，是教育软件项目成败的另一大关键因素。在软件项目实施过程中，项目经理往往分为两类，由专业技术人员职业转型做项目管理工作或由业务人员或其他管理人员空降进行项目管理。这两类人在软件项目实施过程中各有特点。专业技术人员往往在管理技术环节或技术创新等方面游刃有余，但对项目团队管理、时间管理、资金控制等方面存在严重不足，往往出现由于追求新技术导致人员入口狭窄，培训周期拉长导致项目周期延误，购置新设备新开发工具导致资金消耗过快等不可预期的风险的发生，对整个项目产生严重后果，更有甚者项目亏损严重或项目流失。项目经理由业务人员提升或专职充当，在软件项目特别是教育软件项目管理方面有也存在很多问题。对于大型教育软件项目，往往需要在软件项目中含入课程设计环节，项目经理不但能够对开发人员、项目实施进行管理和控制，同时要能根据项目涉及到的专业方向，选择相关专业课程设计人员并安排课程设计的实施。除此以外项目说明书的编写技术环节、业务流程、课程体系之间的关系要能够总体把握。非技术类项目管理人员操作起来就会遇到不少问题，存在潜在的风险。当然，因为人为的因素会在项目操作过程中遇到不同的问题，但如果我们根据软件项目实施过程，将每个环节所可能发生的风险进行归类，我们会发现，无论哪种项目经理，只要项目中将每个环节可能遇到的风险做详细的分析，终究能将风险控制在最小范围，甚至在极大程度上避免导致项目失败的风险的发生。一个项目有可以预料的风险和不可预料的风险，以下作者总结自己多年的软件项目工程经验，分析研究了软件项目风险的相关理论，并针对教育软件项目的风险分类，对经常遇到的10种可预料的风险进行研究，提出相应的预防措施，期望能为教育软件项目经理制定项目风险计划和进行风险预防、控制等提供参考。风险的定义风险是指对目前所采取的行动，在未来没有达到预期结果(失败)的可能性。其大小可用失败的概率和失败的后果两个变量来标识。风险是带有不确定性的，但不确定的不一定都是风险。风险是一种不希望发生的结果而产生的一种潜在可能性。有关风险的问题可以具体描述为：风险是一种不确定性。从事某项活动既有可能获得预期的利益，也有可能蒙受意料不到的损失或损害。机会和威胁是在项目运行过程中同时存在的，承认有风险就是承认既蕴含机会又蕴含威胁；风险是损失或损害。一方面是因为人们从事各种活动的确有可能蒙受损失或损害，告诫人们提高警惕。另一方面，这种观点强调人类活动的不利后果，关心的重点是如何处理不利后果；风险是预期和后果之间的差异。行动和事件的后果与人们的期待预想之间总是存在着不一致和偏差。后果偏离预期越大，风险也越大，即风险是实际后果偏离预期有利结果的可能风险的属性做好项目分析风险可以使我们考虑更全面、决策更科学、合理。研究风险问题，我们首先有必要对风险的属性进行了解和把握。从风险的定义可知风险具有如下属性：自然属性，即自然界的不规则运动给人类和其他物质运动所带来的危害和障碍；社会属性，即社会的运动、发展必然导致人类的生命财产受到危害，而其影响结果通常将们主观意识的客观存在，而且在项目的全寿命周期内来环境认识的不充分性，导致人们对事件未来的结生的频率及其造成的损失程度做出统计分析和主观判断或估计，从而对可能发生的风险进第五，双重性。风险的双重性是指由风险所引发的结果可能是损失也可能是收益。传统上都把风险作为损失来看待，因此风险的双重性也指风险与收益机会共存。风险结果的双重性应使我们认识到，对待风险不应只是消极对待其损失一面，还应将风险当作是一种机会，通过风险管理尽量获得风险收益。第六，行为相关性。行为相关性是指决策者面临的风险与其决策行为是紧密关联的。不同的决策者对同一风险事件会有不同的决策行为，具体反映在其采取的不同策略和不同的管理方法上。因此也会面临不同的风险结果。风险的行为相关性表明，任何一种风险实质上都是由决策行为与风险状态结合而成的，是风险状态与决策行为的统一，风险状态是客观的，但其结果会因不同的风险态度和决策行为而不同。第七，可变性。这是指在项目实施的整个过程中各种风险在质和量上会发生变化，随着项目的进行，有些风险得到控制，有些风险会发生并得到处理，同时在项目的每一阶段都可第八，多样性和多层次性。这一特征主要体现在大型项目中，因重大项目周期长、规模大、涉及范围广、风险因素数量多且种类繁杂致使其在全寿命周期内面临的风险多种多样，而且大量风险因素之间的内在关系错综复杂、各风险因素之间并与外界交叉影响又使风险的分类根据风险，我们可以将风险分为项目风险、技术风险、商业风险、战略风险、管理风险、另外，我们还可以将风险分为已知风险、可预知风险和不可预知风险。软件项目中的风险软件项目的风险无非体现在以下四个方面：需求风险、技术风险、成本风险和进度风险。针对软件项目中的风险管理问题，不少专家、组织提出了自己的风险管理模型。主要的风其中RE表示风险或者风险所造成的影响，P(UO)表示令人不满意的结果所发生的概率，L(UO)表示糟糕的结果会产生的破坏性的程度。Bochm思想的核心是10大风险因素列表。针对每个风险因素，都给出了一系列的风险管理策略。在实际操作时，Boehm以10大风开的会议上再对这10大风险因素的解决情况进行总结，产生新的10大风险因素表，依此对于教育软件项目，存在通用型软件项目的风险，同时还存在若干教育软件项目特有的风险和引发风险的条件。根据软件项目的风险的研究和分类，下面我们具体对教育软件项目软件项目风险的多样性决定了识别风险方法的多样化。关于风险识别有许多常规的技术和工具，如风险识别专题讨论会、头脑风暴法、德尔菲法、SWOT法、检查表法、假设分析1.风险检查表法检查表是管理中用来记录和整理数据的常用工具。用它进行风险识别时，将项目可能发生的许多潜在风险列于一个表上，供识别人员进行检查核对，用来判别某项目是否存在表中所列或类似的风险。检查表中所列都是历史上类似项目曾发生过的风险，是项目风险管理经验的结晶，对项日管理人员具有开阔思路、启发联想、抛砖引玉的作用。一个成熟的项目公司或项目组织要掌握丰富的风险识别检查表工具。检查表可以包括多种内容：(1)项目成功或失败的原因；(2)项目其他方面规划的结果；(3)项目产品或服务的说明书；(4)项目组成员的技能；(5)项目的可用资源。(1)对问题准确表述，确保达到意见统一；(2)确定资料收集者和资料来源；(3)设计一个方便实用的检查表。2.头脑风暴法(1)人员选择。参加头脑风暴会议的人员主要由风险分析专家、风险管理专家、相关专(2)明确中心议题，并醒目标注。议题可以请两位组员复述，以确保每个人都正确理解(3)轮流发言并记录。无条件接纳任何意见，不加以评论。在轮流发言时，任何一个成(4)发言终止。循环进行轮流发言，但当每个人都曾在发言中跳过时，发言终止。(5)对意见进行评价。组员在发言停止后，共同评价每一条意见，最后由主持人总结出几条重要结论。应用头脑风暴法要遵循一个原则，即在发言过程中不进行任何判断性评论。3.德尔菲法德尔菲法又称函询调查法，是指把所要调查的问题编制成表，再将调查表和背景资料函寄给各位专家，通过多轮次的函询调查识别项目风险。这种方法的最大特点是专家与专家之间不见面，背靠背地进行，不发生任何关系，这就减少了权威、资历、口才、人数和心理等因素的影响，各位专家能大胆思考、各抒己见、畅所欲言，在整个应答过程中随时可以改变自己的意见，重新做出预判，也不至于损害自己的威望。应答结果完全是靠专家的经验和知识做出的主观判断和分析。这种方法对那些缺乏客观资料和历史数据的情况比较适用，尤其适用于项目启动阶段的风险预测。德尔菲法的两大关键是调查表的编制和专家的选择。调查表设计得如何会直接影响到调查结果，编制调查表要以方便专家应答为原则，再根据专家的应答意见做出预测。由于预测质量的好坏取决于专家的应答效果，所以选择合适的专家是提高预测质量的关键。由于不同的专家从不同角度考虑，所以对问题的理解不同，应答结果也不完全相同。实践这种方法一般可预测项目的风险、造成风险的因素、风险事件的概率、风险事件后果程度的评价、风险应对措施等等。2.2教育软件项目风险识别此处所讨论的教育软件项目不单纯指软件框架本身，而是包含教育教学软件、教学资源及教学方式的完整教育软件项目，即可以简单理解为教育解决方案项目。确定教育软件项目主要风险因素通过结合教育软件项目自身的特点、工作分解结构以及作者多年的实践经验，可以全面认识教育软件项目，识别出影响软件项目的主要风险因素：需求风险、计划编制风险、组织和管理风险、人员风险、开发环境风险、客户风险、产品风险、设计和实现风险、过程风险，这些风险因素考虑了教育软件项目的工作分解结构，通过彼此之间的联系和相互作用以及它们组成整体的方式，决定了教育软件项目整体的性质和功能，如果这些风险因素产生影响，则教育软件项目整体的性质和功能也要发生变化。所以，通过对这些风险因素的综合分析，可以识别出软件项目总体的风险水平。1.需求风险(1)需求已经成为项目基准，但需求还在继续变化；(2)软件项目框架标准，但需求中涉及到的教学内容随着教学存在不确定性；(3)需求定义欠佳，而进一步的定义会扩展项目范畴；(4)需求中不可估计教育体系更新时间，导致可扩展项目不确定；(5)产品定义含混的部分比预期需要更多的时间；(6)在做需求中教学机构参与不够；(7)缺少有效的需求变化管理过程。(1)计划、资源和产品定义不一致。此风险在教育软件项目中较突出，教育机构希望在(2)计划是优化的，是最佳状态，但计划不现实，只能算是期望状态；(3)计划基于使用特定的小组成员，而那个特定的小组成员其实指望不上，小组成员往(4)产品规模(代码行数、功能点、与前一产品规模的百分比)比估计的要大；(5)完成目标日期提前，但没有相应地调整产品范围或可用资源；(6)涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多；(7)计划周期过长导致已完成的教学素材落后于下年度学员持有的教学素材。(1)仅由管理层或市场人员进行技术决策，导致计划进度缓慢，计划时间延长；(2)低效的项目组结构降低生产率；(3)管理层审查决策的周期比预期的时间长；(4)预算削减，打乱项目计划；(5)管理层作出了打击项目组织积极性的决定；(6)缺乏必要的规范，导致工作失误与重复工作；(7)非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长。(1)作为先决条件的任务(如培训及其他项目)不能按时完成；(2)开发人员和管理层之间关系不佳，导致决策缓慢，影响全局；(3)缺乏激励措施，士气低下，降低了生产能力；(4)聘请有丰富经验的教学机构讲师做项目指导，但由于教师工作的特殊性(授课、巡讲、外出深造等原因),无法达到及时沟通；(5)课程设计人员具备系统化教学思路和经验，此类人才往往需要从教学机构聘请，人(6)项目后期加入新的开发人员，需进行培训并逐渐与现有成员沟通，从而使现有成员(7)由于项目组成员之间发生冲突，导致沟通不畅、设计欠佳、接口出现错误和额外的(8)没有找到项目急需的具有特定技能的人。(1)设施未及时到位；(2)设施虽到位，但不配套，如没有电话、网线、办公用品等；(3)设施拥挤、杂乱或者破损；(4)开发工具未及时到位；(5)开发工具不如期望的那样有效，开发人员需要时间创建工作环境或者切换新的工(6)新的开发工具的学习期比预期的长，内容繁多。6.客户风险(1)客户对于最后交付的产品不满意，要求重新设计和重做；(2)客户由于专业课程变更导致定制开发产品变更，需要重新设计重新开发；(3)客户的意见未被采纳，造成产品最终无法满足用户要求，因而必须重做；(4)多家客户存在需求差异，导致项目根据客户不同定向变更；每家教育机构课程体系(5)客户对规划、原型和规格的审核决策周期比预期的要长，对于大型教育软件项目，(6)客户答复的时间(如回答或澄清与需求相关问题的时间)比预期长；7.产品风险(1)矫正质量低下的不可接受的产品，需要比预期更多的测试、设计和实现工作；(2)开发额外的不需要的功能，延长了计划进度；(3)由于现有系统的约束，导致开发环境与实际应用环境的不统一，需要进行比预期更(4)要求与其他系统或不受本项目组控制的系统相连，教学机构当前多数使用多媒体或(5)在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题；(6)依赖正在开发中的技术将延长计划进度；(7)测试周期无教学机构参与，导致无法及时发现与教学计划相关的问题。(1)设计质量低下，导致重复设计；(2)一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新的库或者自行(3)教学机构第三方教学平台变更导致开发人员要对产品进行被动更新，或使用新技术(4)代码和库质量低下，导致需要进行额外的测试，修正错误，或重新制作；(5)教育软件项目存在课程进化性，旧系统开发的基础类课程变化速度慢，新系统开发(1)大量的纸面工作导致进程比预期的慢；(2)前期的质量保证行为不真实，导致后期的重复工作；(3)太不正规(缺乏对软件开发策略和标准的遵循),导致沟通不足，质量欠佳，甚至(4)过于正规(教条地坚持软件开发策略和标准),导致过多耗时于无用的工作；(5)向管理层撰写进程报告占用开发人员的时间比预期的多；(6)与原有教学体系磨合，使开发人员消耗更多的时间；(7)兼顾原有教学体系，同时需要引入企业应用寻求改变，两线作战导致开发和设计人教育软件项目风险分析及应对风险分析任务很艰巨，风险因素的性质在这一阶段要确定下来。没有正确的风险分析就不可能进行适当的风险应对和控制。风险应对是风险管理的关键步骤，它也是实现风险管理目标的直接手段。在应对阶段，管理人员已经掌握了一定的风险信息。在这个阶段则更强调风险管理人员、决策人员和基层风险应对是相关人员依据风险识别和风险评估得到的结论，制定风险应对方案并付诸实施这个定义包含以下几个方面内容：(1)风险应对方案是决策、分析和操作等多个方面人员在分工协作的基础上制定出来(2)风险应对阶段实际包含两个部分。第一个部分是风险管理方案的制定阶段，第二部分是把方案付诸实施阶段。要消除项目的风险，纸上谈兵达不到目的，必须在实践中展开方案。这两个部分不能截然分开，它们是一个问题的两个方面；(3)风险应对是过程。这句话包含两个意思：第一，风险应对具有时间的持续性，制定方案、管理风险具有一定的周期，需要消耗时间；第二，风险应对有开始、展开和结束的过程。传统的应对策略有风险规避、风险预防和风险转移等。每一种策略均有侧重点和适用范围，下面对上述风险应对策略简要分析：风险规避是指项目事先放弃某种行为从而完全躲避某种风险的侵扰。风险规避可以认为既是最积极的风险应对方法，又是最消极的应对方法。风险规避是最积极的风险应对方法，因为纯粹风险只会为项目带来损失不能为项目带来利益，躲避开它就能使项目避开损失，所以它是最积极的；而对于机会风险来说风险规避又是最消极的应对方法，因为机会风险的矛盾对立面是机会利益，因为害怕风险而完全放弃利益并不是最好的选择。风险预防是指项目不改变行动计划，而在事先制定出防止某种风险发生的措施，对风险进行预先控制的风险应对方法。风险预防的实施条件是管理人员对某种风险因素的发生和发展规律有较多的了解，能够制定出切实可行的风险预防方案。3.风险转移风险转移是将风险转移至该项目的其他人或其他组织，所以又叫分担风险。其目的不是降低风险发生的概率和减轻不利后果，而是借用合同或协议，在风险事故发生时将损失的一部分转移到有能力承受或控制项目风险的个人或组织。在选择风险应对的方法时，要避免两个极端：一是放任风险的发生和发展。这样对项目的危害可能很大，甚至造成无法挽回的损失；二是不计成本的管理。这样既浪费资源，不利于项目的运行，也不利于集中精力管理重大风险。本文主要采用风险预防的应对策略，分析与应对教育软件项目中的风险。3.2合同风险分析及预防措施1.合同风险分析对于教育软件项目，合同签订周期长，审批流程相对复杂，部分教育软件项目需采用政府采购的方式，签订的合同不科学、不严谨，项目边界和各方面责任界定不清等是影响项目成败的重大因素之一。2.预防措施预防这种风险的办法是项目建设之初项目经理就需要全面准确地了解合同各条款的内容、尽早和合同各方就模糊或不明确的条款签订补充协议，同时要做好招投标所应具备的资料文件，掌握招投标流程及政府采购流程。需求变更风险分析及预防措施1.需求变更风险分析需求变更是软件项目经常发生的事情。一个看似很有“钱途”的软件项目，往往由于无限度的需求变更而让项目承建方苦不堪言，甚至最终亏损。特别是针对IT类专业考试系统的开发，尤为凸显，随着教育主管部门对实际操作技能考核的需求不断加强，不同的专业采用的考试方式和开发技术差别较大，特别是操作类考试要结合针对考核实操内容类型的不同(如办公软件、网络设备、操作系统等)变更不同的套接接口。往往教学机构在购买考试系统后希望随专业的增加或变更，考核的专业或技术类别随之增加，在这种情况下，变更需求是不可避免的，更有甚者需要推翻已指定的需求重新开发新品，造成极大的资源、时间的浪费。2.预防措施(1)项目建设之初就和用户书面约定好需求变更控制流程、记录并归档用户的需求变更(2)系统设计初期具备更灵活的接口定义和库结构定义。采用第三方产品—开发技术分类表进行有效控制，预留跨平台的中间件。例如表1:表1:第三方产品—开发技术分类表考核分类产品特性开发技术参考开发语言中间件接口需求办公软件类支持二次开发接Microsoft开发工口具操作系统类支持本地磁盘操作底层开发网络设备类模拟器技术沟通不良风险分析及预防措施1.沟通不良风险分析项目组与项目各干系方沟通不良是影响项目顺利进展的一个非常重要的因素。项目涉及人员包括：公司高层、项目经理、课程指导(外聘专家)、课程开发、程序员(包括系统构架师)、测试工程师、教学结构系主任、教学机构任课教师等。2.预防措施预防这种风险的办法是项目建设之初就和项目各干系方约定好沟通的渠道和方式、项目建设过程中多和项目各干系方交流和沟通、注意培养和锻炼自身的沟通技巧。同时，建立快捷的沟通途径和负责制度，各相关人员在统一项目规划总表中，根据负责内容的不同对项目的进程进行签字确认。项目变更严格采用需求变更单的形式，并汇总于需求总表，抄送各相关人员更新，严格避免口头指挥、随意修改、相关人员信息不统一的问题。缺乏领导支持风险分析及预防措施1.缺乏领导支持风险分析上层领导的支持是项目获得资源(包括人力资源、财力资源和物料资源等)的有效保障，也是项目遇到困难时项目组最强有力的“后台支撑”。2.预防措施预防这种风险的办法是主动争取领导对项目的重视、确保和领导的沟通渠道畅通、经常向领导汇报工作进展。做到日报、周报、月报制度，日报负责人、周报主管、月报领导，突3.6进度风险分析及预防措施1.进度风险分析教育软件项目均有一定的周期性，其特点包括两个方面的风险：(1)采购进度周期：往往教学机构在采购过程中，需要在前一学年申报需求，下一学年开始前签订采购合同，产品设计周期、开发周期、交付存在较长的时间差，确保开发产品能够完全满足教学机构采购需求，力保开发产品完全满足和确保教学机构采购，对项目经理、课程设计人员具有极大地挑战。(2)开发进度周期：一旦教学机构确认采购意向或签订采购合同后，开发人员必须在下一学年度或合同限定期限内交付成熟产品，否则会涉及到教学机构无法按时开展相关教学内容。此周期限定严格，一般性商业产品可适当错后业务开展时间，但教学机构不存在此(1)项目经理要统筹安排产品设计和开发各时间段，控制开发资金利用，在确认销售前(2)对于此类第二种风险，有效安排分阶段交付产品、增加项目监控的频度和力度。在2.预防措施1.系统性能风险分析现有教学平台多为教学机构内局域网多用户教学及管理平台，存在多用户并发操作，对系统性能和代码优化的要求很高。另一类系统性能风险存在于与考试项目有关的系统开发中，除考虑安全性、稳定性等必要特性的基础上，对考试结果的精确性和真实性要做好足够的控制措施。这时项目组就需要2.预防措施预防这种风险的办法一般是在进行项目开发之前先设计和搭建出系统的基础架构并进行性能测试，确保架构符合性能指标后再进行后续工作。3.9工具风险分析及预防措施1.工具风险分析软件项目开发和实施过程，所必须用到的管理工具、开发工具、测试工具等是否能及时到位、到位的工具版本是否符合项目要求等，是项目组需要考虑的风险因素。开发工具的更新从很大程度上和本项目相关第三方系统的更新速度有极大关系，大多数时候，开发工具的更新都属于被动更新(如：教学机构服务器操作系统或硬件升级不再提供对现有工具的支持或旧开发工具未提供对新系统服务的接口),在这种情况下，开发工具开发工具的更新将涉及到新开发工具的熟悉、开发人员变更、新人员对旧系统的熟悉周期、新开发工具和旧应用的衔接接口等诸多问题。2.预防措施预防这种风险的办法一般是在项目的启动阶段就落实好各项工具的来源或可能的替代工具，在这些工具需要使用之前(一般需要提前一个月左右)跟踪并落实工具的到位事宜。同时，技术总监要对公司各项目小组的开发技术和方法要有总体安排，编制开发工具接口比对表(如表2)。定期对开发人员进行新技术培训，挖掘具有较强学习能力的开发人员，有意识的定向培养。建立人才库制度，定期由人事部门提供人才名录。表2:开发工具接口比对表开发环境对应开发模块开发语言开发工具**类二次开发模块操作系统底层模块C3.10团队成员能力和素质风险分析及预防措施1.团队成员能力和素质风险分析团队成员的能力(包括业务能力和技术能力)和素质，对项目的进展、项目的质量具有很大的影响，项目经理在项目的建设过程需要实时关注该因素。针对教育软件项目，同时对于项目经理的教学框架要明确，需要针对不同的专业聘请资深教育专家构建项目团队。同时针对不同专业课程设计负责人，需要具备相关专业课程的教学经验，以上成员的能力和素质将直接影响到团队的开发产品的专业性和理论深度。因此，团队成员管理在教育软件项目中的风险控制非常重要。2.预防措施预防这种风险的办法是在用人之前先选对人、开展有针对性的培训、将合适的人安排到合构建庞大的院校关系网，针对现有的或计划内的专业课程资深专家建立定期沟通机制。安排定期举办专业课教师交流会，以提升项目组成员的素质，同时不断扩大顾问团队数量。3.11人员流动风险分析及预防措施1.人员流动风险分析项目成员特别是核心成员的流动给项目造成的影响是非常可怕的。人员的流动轻则影响项目进度，重则导致项目无法继续甚至被迫夭折。2.预防措施结结论预防这种风险的办法是尽可能将项目的核心工作分派给多人(而不要集中在个别人身上)、加强同类型人才的培养和储备。同时有效利用外部资源，充分利用顾问团队的作用，将核心课程分散到顾问团队的各个层面。保证项目内部人员流动后，新成员能更快的从外部资源获取到必要信息，缩短培训周期。同时避免人员流动对公司核心产品造成的泄露损失。本文通过文献阅读以及本人在教育软件项目实施的经验，总结出了教育软件项目常见风险及其预防措施，包括合同风险，需求变更风险，沟通不良风险，缺乏领导支持风险，进度风险，质量风险，系统性能风险，工具风险，团队