IT项目管理的风险有哪些

1、IT项目管理的风险有哪些IT项目管理的风险有哪些项目风险是一种不确定事件或状况，一旦发生，会对至少一个项目 目标，如进度、成本、范围或质量目标产生积极或消极影响。那么IT 项目管理的风险有哪些呢？ 一起来了解下吧：(1) 技术风险。核心系统升级引入了外包厂商的最新产品，使用了很多新技术，行 内研发人员熟悉这些技术需要一定的时间，而在项目过程中却不可避免 地会遇到一些技术问题。如何能快速解决这些棘手的技术问题?我们的 做法是：第一 5指定行内外包厂商接头人5由接头人负责和外包厂商的 技术人员进行沟通，同时该接头人也是行内对厂商产品最熟悉的人，一 般性的小问题基本上此人就可以解决，比较复杂的问题才

2、提交给厂商解 决，这样比起全部问题都去找厂商解决，节省了时间。第二，购买厂商 的人力进行技术支持，请厂商的研发人员来到幵发现场和我们一块研 发。第三，预约厂商在系统上线期间到现场待命，以应对紧急问题发 生，对可能出现的问题进行第一时间的响应。(2) 沟通风险。参与项目的外包厂商有多个，沟通渠道多，沟通成本大，而且容易 出现理解不一致的情况。所以，项目组成立了专门的PMO,负责制定相应 的沟通计划，为每个厂商指定行内的接头人，对内部人员实行分级管 理，组织定期例会解决项目过程中出现的问题，防范由于对需求理解不 一致造成的项目延误，充分利用己有的邮件、会议、电话和短信等沟通 工具，并推广使用某即时

3、通讯工具以作为主要的工作沟通工具。(3) 需求变更风险。针对IT软件项目中不可避免的需求变更活动，在项目开始后，我部 就停止了除政策性需求以外的所有规模超过20人/天的新业务需求，同 时制定了需求变更流程：所有业务需求的变更必须由业务方的代表统一 提出，变更必须有书面记录，幵发人员仔细评估是否接受，最后由总管 变更的领导(8B)复审，总管领导具有一票否决权，从而精简了一些不合 理的需求变更。在项目中期引入了 1珈的配置 管理工具CCCQ来管理代 码和缺陷，所有Bug都进行了分类，并录入CQ系统，防止重复修改和修 改后无记录等情况的发生。迁移演练之后的缺陷都由各个系统的负责人 统一对缺陷进行分析

4、评审，消除Bug修复可能导致的系统尖联问题。(4) 进度风险。项目进行核心升级，引起了客户而数据结构和一些外部接口的变 化，同时前端业务平台也做了很大的调整，如幵发了新的权限系统、迁 移主机老权限系统上的权限数据到微机、替换传输协议XML为JSON、改 造微机调用主机框架等。主机平台和幵放平台幵发工作量巨大，需要留 有足够的ST、UAT测试时间，项目开发时间有限，为了应对可能造成的 进度延误，我们采用了以下应对方法：一是制定详细的进度计划，明确 侮个人的任务，各项目组每周定期检视项目进度，如出现偏差及时纠 正;二是与外包公司合作，引入外包人力，为项目临时增派了多名生力 军;三是强制加班；四是并

5、行化详细设计和编码同时加强代码评审，在 加快进度的同时减少返工。(5) 数据迁移风险。项目涉及的系统多达上百个，系统集成环境复杂，需要迁移的数据 量庞大，而且数据迁移对数据的准确性和完整性有着很高的要求。项目 制定了分阶段集成和多次迁移演练的策略：将迁移工作进行提前预演， 模拟真实上线迁移场景。经过多次演练以后，问题大大减少，减轻了系 统上线的数据迁移风险。(6) 人力资源风险。项目建设周期长，历时两年，大范围人员流动可能会造成项目延 误。针对这一风险，应对的方法是：做两手准备，尽力挽留要走的人 员，晓之以理，动之以情，请求公司人力资源部提升员工待遇；同时加 紧社会招聘，在重要的岗位上安排备份

6、，防止由于成员生病、离职等意 外造成的减员。最终这个风险没有成为问题。在项目升级项目中，我负责两个子系统的幵放部分'由于高层对 风 险管理的重视，我在执行的时候也特别重视对风险的'控制。项目组有 四个人，沟通成本比较低，所以我们每隔一周进行一次代码评审，解决 遇到的一些技术难题和编码规范问题，在实际幵发中使用Checkstyle进 行代码规范检视，及早扼杀了可能出现的Bug和不规范的代码;制定组 员每周报告进度制度，防范进度偏差;而对前端最可能出现的需求变更 一一 UI变更，我尝试在设计初期使用原型方法和业务进行有效沟通， 大大减少了后期UAT阶段UI变更需求。回想刚进公司时我

7、做过的某个项 目，由于没有考虑到UI类需求变更风险，前期没有进行UI设计的交流， 导致UAT阶段大量返工，使项目延误了一个多月，并且浪费了不少人力 资源。设想如果当时识别了这类风险，在早期就把风险发生的概率降 低，那么项目可能会顺利得多。由于前期风险控制得当，一直到迁移演练前我负责的项目都很顺 利，但是在迁移演练过程中出现了一些问题，其中一个问题是导库程序 不能正常执行，并多次发生。我和同事花了很多时间研究问题，最后找 到的原因是某个配置参数的问题，研发人员使用了错误的配置参数， ST、UAT期间导库的数据量比真实演练期间的数据量小太多，所以没有 被发现，修改配置后再演练环境导库成功。还有一些

8、问题是没有有效沟 通导致的。例如，在演练的时候用户反映某个查询交易很慢，经排查， 后台人员说前台调错了交易，前台人员提出异议：为什么ST环境查询 很快?原来后台人员写了多个查询交易，新交易确实能提升查询速度， 但是没有在正式的文档上注明前台应使用新交易替换老交易，也没有通 过别的途径告知前台，这样前台调用的还是老交易，导致了查询性能问 题。由于ST ' UAT环境和生产环境的差异性，上述两类问题很难暴露， 试想如果没有进行迁移演练，这个问题恐怕要在生产上出现了。迁移演 练提前暴露了 ST、UAT所不能测出的系统缺陷，使得研发人员能有充分 的时间去排查问题和修复缺陷，有效降低了系统上线风险。经过这次核心升级项目的洗礼，我深深认识到风险管理在IT项目中的重要性，正因为对风险管理足够重视，提前制定了风