it项目的不确定性非常大，因此风险的发生可能性就大起来了。而对于大型it项目管理来说，风险管理就更应该引起注意。由于项目规模大，人员多，技术难度大，因此，面临的不确定会更大。那么，该如何去应对大型it项目管理的风险，对其做好管理呢?下文会从大型it项目管理的六大风险管理出发，介绍一些解决方法，主要是以银行核心系统升级项目来为例。
项目的成功离不开项目组所有成员的拼搏努力，同时也离不开成功的项目管理，尤其是风险管理。从项目启动阶段，制定了定性的风险计划，识别出风险级别最高的几个风险。为了减轻技术风险的影响，在项目计划阶段，所有开发小组都对上一代系统认真进行了梳理，分析出系统升级的影响，制定了相应的应对方案。同时，在项目执行过程中，高层管理人员也很注意对风险的监控，确保在风险变成问题时能有效应对，并指示PMO认真做好所有问题记录工作。在项目中被识别的主要风险有：技术风险;沟通风险;需求变更风险;进度风险;数据迁移风险;人力资源风险。
(1)技术风险。核心系统升级引入了外包厂商的最新产品，使用了很多新技术，行内研发人员熟悉这些技术需要一定的时间，而在项目过程中却不可避免地会遇到一些技术问题。如何能快速解决这些棘手的技术问题?项目部具体做法是：第一，指定行内外包厂商接头人，由接头人负责和外包厂商的技术人员进行沟通，同时该接头人也是行内对厂商产品最熟悉的人，一般性的小问题基本上此人就可以解决，比较复杂的问题才提交给厂商解决，这样比起全部问题都去找厂商解决，节省了时间。第二，购买厂商的人力进行技术支持，请厂商的研发人员来到开发现场和我们一块研发。第三，预约厂商在系统上线期间到现场待命，以应对紧急问题发生，对可能出现的问题进行第一时间的响应。
(2)沟通风险。参与项目的外包厂商有多个，沟通渠道多，沟通成本大，而且容易出现理解不一致的情况。所以，项目组成立了专门的PMO，负责制定相应的沟通计划，为每个厂商指定行内的接头人，对内部人员实行分级管理，组织定期例会解决项目过程中出现的问题，防范由于对需求理解不一致造成的项目延误，充分利用已有的邮件、会议、电话和短信等沟通工具，并推广使用某即时通讯工具以作为主要的工作沟通工具。
(3)需求变更风险。针对IT软件项目中不可避免的需求变更活动，在项目开始后，项目部就停止了除政策性需求以外的所有规模超过20人/天的新业务需求，同时制定了需求变更流程：所有业务需求的变更必须由业务方的代表统一提出，变更必须有书面记录，开发人员仔细评估是否接受，最后由总管变更的领导(CCB)复审，总管领导具有一票否决权，从而精简了一些不合理的需求变更。在项目中期引入了IBM的配置管理工具CCCQ来管理代码和缺陷，所有Bug都进行了分类，并录入CQ系统，防止重复修改和修改后无记录等情况的发生。迁移演练之后的缺陷都由各个系统的负责人统一对缺陷进行分析评审，消除Bug修复可能导致的系统关联问题。
(4)进度风险。项目进行核心升级，引起了客户面数据结构和一些外部接口的变化，同时前端业务平台也做了很大的调整，如开发了新的权限系统、迁移主机老权限系统上的权限数据到微机、替换传输协议XML为JSON、改造微机调用主机框架等。主机平台和开放平台开发工作量巨大，需要留有足够的ST、UAT测试时间，项目开发时间有限，为了应对可能造成的进度延误，项目部采用了以下应对方法：一是制定详细的进度计划，明确每个人的任务，各项目组每周定期检视项目进度，如出现偏差及时纠正;二是与外包公司合作，引入外包人力，为项目临时增派了多名生力军;三是强制加班;四是并行化详细设计和编码同时加强代码评审，在加快进度的同时减少返工。
(5)数据迁移风险。项目涉及的系统多达上百个，系统集成环境复杂，需要迁移的数据量庞大，而且数据迁移对数据的准确性和完整性有着很高的要求。项目制定了分阶段集成和多次迁移演练的策略：将迁移工作进行提前预演，模拟真实上线迁移场景。经过多次演练以后，问题大大减少，减轻了系统上线的数据迁移风险。
(6)人力资源风险。项目建设周期长，历时两年，大范围人员流动可能会造成项目延误。针对这一风险，应对的方法是：做两手准备，尽力挽留要走的人员，晓之以理，动之以情，请求公司人力资源部提升员工待遇;同时加紧社会招聘，在重要的岗位上安排备份，防止由于成员生病、离职等意外造成的减员。最终这个风险没有成为问题。
上诉的对大型it项目管理的六大风险管理的处理方式，可以给一些参考意见。但是在具体的项目管理中，需要结合具体的实际情况、行业背景和干系人特点，灵活采用相应的对策才行，切记不可行盲目照搬。
本文转载自拓源优课：www.toyoke.com