IT项目风险管理——中培教育案例展示

在项目管理过程中，风险管理是其中核心内容之一。2013月，中培教育《IT项目管理最佳实践》培训专家张老师承接了某保险行业特大型央企的一个开发项目。在本项目中，张老师被任命为项目经理，负责项目的各项风险管理、对内外沟通等工作，在工作中实际确立定期召开项目例会，双方唯一接口负责人等制度。计划投资3000万元，采用C/S结构。张老师作为乙方项目负责人，参与了项目的管理工作。张老师在这里就该项目的风险管理分享了自己的经验。

风险在一个实际项目中的发生，几乎是不可避免，我们要通过编制风险计划等手段，来预期在什么样的项目中会产生哪些风险。同时，在项目执行过程中，我们要正确的对待风险的发生，主动去观察，以便发现可能的风险，即风险的识别。

对于已经认识到的风险，我们接下来要做的就是进行定量和定性分析，通过分析找出原因，并进一步找出应对方案和计划的建议。然后通过项目例会等手段，在甲乙双方之间共同确认最佳的解决方案，并实际落实到具体的负责人来解决问题。最后我们通过对此项目的风险化解过程提炼出一些对今后工作有意义的借鉴之处。

在该项目中张老师曾经遇到了成本、时间、需求范围等方面的风险。成本风险常来源于前期成本估算不准，实际发生成本严重超出原有预算；时间风险，多受到后期需求变更、项目进度计划不合理、关键人员流失等因素影响； 需求在系统集成项目中具有渐进明晰的特征，应做好用户的全程参与、加强需求的前期沟通工作。

1、关于成本风险

IT 项目成本管理是为了保证完成 IT 项目所花费的实际成本不超过其预算成本而展开的一系列管理活动，它主要包括：成本估算，编制完成 IT 项目各项活动所需资源的大致费用；成本预算，将总的成本估算分配到各项活动或工作包上，来建立一个成本基线；成本控制，分析造成成本偏差的因素，控制 IT 项目预算的变更。

在项目进行中张老师发现，由于在项目起始之初，公司为了急于拿下该项目开拓新的市场领域，承诺了满足大量的应用范围，而此类型软件并非公司的既有产品，此时进行项目开发已安排的人力资源并不能满足需要，因此建议公司加大人力投入以便保证项目的正常交付。随后此建议提交到公司办公会议加以讨论，通过讨论大家认为自行投入人力开发全新软件，带来的包括人力资源（新开发人员招聘、培训的准备等）成本投入巨大。经过仔细计算，大家一致认为可以通过外包一些有相关经验的公司的人员的方式解决开发主力人员的问题，这样做人员即入手快，同时又不必大量的增加人员，可有效地解决人力投入的成本过度增加问题。

2、时间问题带来的风险的管控

IT 项目进度控制是依据 IT 项目进度基准对 IT 项目的实际进展情况进行控制，使 IT 项目能够按时完成。进度控制包括定期收集 IT 项目完成情况的数据，将实际完成情况与计划进行比较。在制定计划时，资源平衡非常重要。初始计划所需要的资源往往超过实际可利用资源，尝试在 IT 项目进度计划和实际可用资源之间进行平衡和优化。进度计划在 IT 项目管理团队认可和批准之后，当作进度基准使用，表明 IT 项目中各个活动的基准开始时间和基准完成时间。 指明在制定进度计划时，常采用一些适用的方法，以确保进度合理可行。

由于客户企业是一个非常传统的央企，内部办事效率不高、沟通不畅、审批环节复杂，比如保险业务员的佣金定义方面在不同部门之间存在巨大争议，项目进行中张老师发现当初给客户承诺的 3 个月全交付的时间存在巨大的时间风险，几乎全部完成是一个不可能完成的任务。

由此，张老师与甲方共同召开项目例会，在会上双方通过讨论共同认定此项目的最大目的是为了搭建一套电话营销项目，销售功能是其最主要任务所在，保证销售功能在元旦上线是我们最主要的目标，因此，对于项目涉及到的其他的附加功能根据其是否为主要功能的部分必备条件之一，确定其是否排在 3 个月的项目进度计划内。通过指定新的项目排期，并在甲乙双方的认可下，确定了一个可以在 3 个月内实现的可行性计划。通过后来实践，我们发现后来随后部分功能存在逾期现象，但是销售系统的主要功能还是在客户要求的时间点顺利上线，并开始为客户创造效益。

3、需求范围带来的风险

需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。由于软件系统的复杂性，在需求分析阶段可能存在着开发方对委托方的业务需求理解不全面、不准确的情况。在这种情况下，如果不通过需求评审进行相关的质量控制，往往造成开发结果与用户需求不一致的情况。

在项目进行中张老师发现，前期一些需求也存在不合理之处，其范围定义过大，导致产品臃肿，同时这样大范围的需求，也和甲方已有的内部其他系统存在冲突，比如人员绩效管理就和甲方已有的 ERP 系统相冲突，同时有些和销售相关的功能又没有在需求中体现，比如保单配送等功能，因此在随后召开的项目例会中，通过对具体应用的分析，与甲方达成了一致认可。随后经过修改需求说明书，调整了产品的规划，终于制定了一个较为可行的可实际操作的需求列表，并按照执行，最终保证了产品与项目真实需求的一致性，而且在随后的执行中不断跟踪这些需求的变化，及时加以调整，来达到正式的产品需求。

综上所述，通过以上案例介绍，张老师总结了一下该项目在风险管理方面的经验，首先任何项目都会遇到人力等因素造成的成本问题，因此在适当追加成本的情况下，合理的选择多种解决方案中最优者，以便达到最节省成本的目标；其次，项目由于过度承诺等问题会带来追赶时间进度的问题，要做到双方妥善沟通，找出主要完成的任务，完成它就保证了整体的时间进度；最后，在需求风险管理方面，在项目立项阶段制定的需求范围，都会存在一定欠缺，要在项目过程中根据实际需求加以改进，并在双方认同的前提下，加以实施，同时跟踪其执行情况，不断修正需求，来达到正式的产品需求。

通过本项目的经验总结，为张老师今后执行类似的项目的风险管理带来了一些可供借鉴的经验：首先，及时注意风险的发生，识别风险，然后分析这些风险的产生原因，制定有针对性的解决计划，并且跟踪风险的处理，并不断的进行修正，最后及时补充进项目执行计划中；同时，良好的沟通是解决化解风险的重要手段，因为只有在多方认可的情况下采取有效地措施，才能真正的化解一系列的风险，达到有效风险管理，无论任何的能力、手段都要进行实有成效内部和外部沟通才会被他人获知并且确认、落实。

必须承认的是，在项目开发过程中也遇到一些问题，比如因为工期紧，任务重，所以团队经常加班，大家非常疲惫，导致团队成员做事效率低下，积极性不高，项目出现了团队风险。我也采取了一些补救措施，如请示管理层在精神方面做了一些鼓励和表扬，适当组织聚餐、看电影、健身等活动，一定程度上缓解了紧张的氛围，大家也没了太多的怨言。

总之，项目风险的管理方式多种多样，因人而异、因项目规模而异，管理方式不是一成不变的。适合自己的管理模式才是最好的模式，这些都有待于我们进一步研究、探索、实践和总结。