IT项目管理的风险有哪些.docx

IT项目管理的风险有哪些

项目风险是一种不确定事件或状况，一旦发生，会对至少一个项目

目标，如进度、成本、范围或质量目标产生积极或消极影响。那么IT

项目管理的风险有哪些呢？一起来了解下吧：

?(1)技术风险。

?核心系统升级引入了外包厂商的最新产品，使用了很多新技术，

行内研发人员熟悉这些技术需要一定的时间，而在项目过程中却不可避

免地会遇到一些技术问题。如何能快速解决这些棘手的技术问题?我们

的做法是：第一，指定行内外包厂商接头人，由接头人负责和外包厂商

的技术人员进行沟通，同时该接头人也是行内对厂商产品最熟悉的人，

一般性的小问题基本上此人就可以解决，比较复杂的问题才提交给厂商

解决，这样比起全部问题都去找厂商解决，节省了时间。第二，购买厂

商的人力进行技术支持，请厂商的研发人员来到开发现场和我们一块研

发。第三，预约厂商在系统上线期间到现场待命，以应对紧急问题发

生，对可能出现的问题进行第一时间的响应。

?(2)沟通风险。

?参与项目的外包厂商有多个，沟通渠道多，沟通成本大，而且容

易出现理解不一致的情况。所以，项目组成立了专门的PMO，负责制

定相应的沟通计划，为每个厂商指定行内的接头人，对内部人员实行分

级管理，组织定期例会解决项目过程中出现的问题，防范由于对需求理

解不一致造成的项目延误，充分利用已有的邮件、会议、电话和短信等

沟通工具，并推广使用某即时通讯工具以作为主要的工作沟通工具。

?(3)需求变更风险。

?针对IT软件项目中不可避免的需求变更活动，在项目开始后，

我部就停止了除政策性需求以外的所有规模超过20人/天的新业务需

求，同时制定了需求变更流程：所有业务需求的变更必须由业务方的代

表统一提出，变更必须有书面记录，开发人员仔细评估是否接受，最后

由总管变更的领导(CCB)复审，总管领导具有一票否决权，从而精简了

一些不合理的需求变更。在项目中期引入了IBM的配置管理工具

CCCQ来管理代码和缺陷，所有Bug都进行了分类，并录入CQ系统，

防止重复修改和修改后无记录等情况的发生。迁移演练之后的缺陷都由

各个系统的负责人统一对缺陷进行分析评审，消除Bug修复可能导致的

系统关联问题。

?(4)进度风险。

?项目进行核心升级，引起了客户面数据结构和一些外部接口的变

化，同时前端业务平台也做了很大的调整，如开发了新的权限系统、迁

移主机老权限系统上的权限数据到微机、替换传输协议XML为

JSON、改造微机调用主机框架等。主机平台和开放平台开发工作量巨

大，需要留有足够的ST、UAT测试时间，项目开发时间有限，为了应

对可能造成的进度延误，我们采用了以下应对方法：一是制定详细的进

度计划，明确每个人的任务，各项目组每周定期检视项目进度，如出现

偏差及时纠正;二是与外包GS合作，引入外包人力，为项目临时增派了

多名生力军;三是强制加班;四是并行化详细设计和编码同时加强代码评

审，在加快进度的同时减少返工。

?(5)数据迁移风险。

?项目涉及的系统多达上百个，系统集成环境复杂，需要迁移的数

据量庞大，而且数据迁移对数据的准确性和完整性有着很高的要求。项

目制定了分阶段集成和多次迁移演练的策略：将迁移工作进行提前预

演，模拟真实上线迁移场景。经过多次演练以后，问题大大减少，减轻

了系统上线的数据迁移风险。

?(6)人力资源风险。

?项目建设周期长，历时两年，大范围人员流动可能会造成项目延

误。针对这一风险，应对的方法是：做两手准备，尽力挽留要走的人

员，晓之以理，动之以情，请求GS人力资源部提升员工待遇;同时加紧

社会招聘，在重要的岗位上安排备份，防止由于成员生病、离职等意外

造成的减员。最终这个风险没有成为问题。

?在项目升级项目中，我负责两个子系统的开放部分，由于高层对

风险管理的重视，我在执行的时候也特别重视对风险的控制。项目组有

四个人，沟通成本比较低，所以我们每隔一周进行一次代码评审，解决

遇到的一些技术难题和编码规范问题，在实际开发中使用Checkstyle进

行代码规范检视，及早扼杀了可能出现的Bug和不规范的代码;制定组

员每周报告进度制度，防范进度偏差;面对前端最可能出现的需求变更

——UI变更，我尝试在设计初期使用原型方法和业务进行有效沟通，

大大减少了后期UAT阶段UI变更需求。回想刚进GS时我做过的某个

项目，由于没有考虑到UI类需求变更风险，前期没有进行UI设计的交

流，导致UAT阶段大量返工，使项目延误了一个多月，并且浪费了不

少人力资源。设想如果当时识别了这类风险，在早期就把风险发生的概

率降低，那么项目可能会顺利得多。

?由于前期风险控制得当，