IT项目管理中有哪些常见的风险，如何规避？

“成功的项目总有相似的特点，但失败的项目却总是各不相同。”多数半截项目意味着已经失败了一半，接手半截项目的风险是不言而喻的。了解项目的进展情况，确切存在的问题：一、需求没基线；二、架构选错；三、项目主要负责人及关键任务突然离职。解决之道：对策一：重视理论方法，调整IT项目的架构，重视理论的格局界面；对策二：谋定而后动，一定要物色好接受人，各方面情况想清楚之后再开始行动。

无论是国内还是国外，软件开发失败的比例都非常高，部分软件系统即使上线使用，它的生命周期也非常短，为什么软件开发失败，大部分归纳起来以下几个方面：

1、项目预算不足（开发和维护成本太高）

2、需求不明确（无法满足业务需求）

3、没有整体架构设计（后续无法迭代改进）

4、开发人员能力不足（代码写得太烂，不好维护）

。。。

不可否认，以上的是项目开发失败的原因之一，作为一个IT领域从业人员，曾经历过无数个大小项目的失败，架构过多个大型项目，我认为软件系统开发失败最主要的原因是数据库设计问题，数据库设计不好项目注定会失败，而 数据库设计恰恰是最难的 。

1、项目预算不足（开发和维护成本太高）

一般我们在规划项目的时候会根据项目的需求评估开发周期，根据开发周期和人员角色及人员成本计算总的项目预算，如果做的比较规范的，一般预算是合理的，导致预算不足也是其他原因使开发成本增加，如需求不明确、人员技术差等。

2、需求不明确（无法满足业务需求）

可以说大部分的项目开始做的时候需求不是完全明确的，经过需求调研、需求分析、需求评审等这些环节，需求逐步清晰，但也不可能达到100%。根据不是完全明确的需求做的数据库设计一定只是满足现有需求的设计，如果最后用户改了需求，可能还需要修改数据库设计。既然需求不能完全确定，那如何避免以后出问题呢。

本人认为数据库设计一定要请高手设计，有多年项目开发经验及数据库知识的高级技术人员，首先仔细研究需求和客户探讨需求，把非常明确的需求设计好业务表，不明确的需求尽量设计灵活，有时一张表能满足设计，二张表也能满足设计，这个就需要仔细斟酌，预判未来可能的情况，尽量灵活甚至可以字段冗余（暂时不用的也可以设计），这样未来修改的风险和成本就非常低，系统上线后再修改数据库设计的代价是非常高的。表名和字段名一定要规范，设计人员要具备一些英文基础。尽量避免让实习生或刚开始工作的没有任何实践经验的人员设计。

3、没有整体架构设计（后续无法迭代改进）

本人认为架构设计是方便人员开发，提高开发效率的，架构设计也可以提高系统性能和方便维护，好的架构设计可以让整体系统层次清晰，但是架构设计即使不好，用老技术还是新技术并不影响业务的正常运行，有也是性能差一点，慢一点，不至于导致业务无法正常运营。最坏的打算就是几年以后系统重构一下采用新技术再开发。但是如果数据库没设计好，几年积累的大量业务数据你要整合和调整数据库那这个代价就是非常大了。

4、开发人员能力不足（代码写得太烂，不好维护）

开发人员能力不足这个我觉得最没有影响，某个开发人员能力差也只是影响其开发的某个模块而已（一般不会让一个技术差的写核心模块），只要他写的代码能测试通过运行，代码写的再乱都没问题，影响的只是一小部分，最坏就是以后把这部分代码重写一下就行。

另外数据库设计字段命名非常重要，不要写错的单词或毫无意义的字符，开发人员喜欢用数据库字段名在代码中命名属性，这样导致代码的可读性、维护性非常差 。

请大家一定要重视数据库设计，让你的软件系统生命周期更长久，数据库设计好了即使开始业务进行不下去，过一段时间还是可以重新把项目启动起来。数据库设计差以后在系统迭代更新，性能优化等方面都是问题。

一般IT项目管理中常见的风险有以下几类：

需求变更风险。需求变更是软件项目经常发生的事情。一个看似很有“钱途”的软件项目，往往由于无限度的需求变更而让项目承建方苦不堪言，甚至最终亏损。预防这种风险的办法是项目建设之初就和用户书面约定好需求变更控制流程、记录并归档用户的需求变更申请。

进度风险。有些项目对进度要求非常苛刻，但对于进度要求不高的项目，同样要考虑该风险。项目进度的延迟意味着违约或市场机会的错失，预防这种风险的办法一般是分阶段交付产品、增加项目监控的频度和力度、多运用可行的办法保证工作质量避免返工。

质量风险。有些项目和用户对软件质量有很高的要求，如果项目组成员同类型项目的开发经验不足，则需要密切关注项目的质量风险。一般需要经常和用户交流工作成果、采用符合要求的开发流程、认真组织对产出物的检查和评审、计划和组织严格的独立测试等。

技术风险。在软件项目开发和建设的过程中，技术因素是一个非常重要的因素。项目组一定要本着项目的实际要求，选用合适、成熟的技术，千万不要无视项目的实际情况而选用一些虽然先进但并非项目所必须且自己又不熟悉的技术。如果项目所要求的技术项目成员不具备或掌握不够，则需要重点关注该风险因素。

在应对IT项目的风险方面，可以借助信息化项目管理系统解决，比如8Manage PPM，能够对项目进行全程的风险跟踪，自动检测项目各种系统性风险及其影响，包括项目计划，成本，资源以及质量的风险，并且能根据现有影响自动推测最终的影响，做到自动监测超时和超支风险、自动监测使用不恰当资源与资源短缺的风险等工作，并提供集成的风险登记表和预警提示，使项目人员可清楚地知道若不及时恰当地管理这些风险的严重性。同时，8Manage支持记录用户自定义风险并跟踪风险从开始到结束的整个过程。系统会自动根据风险发生几率的高低和采取行动前后风险的的影响来分类和评估每个风险，以便项目人员更快速有效地确定行之有效的方案来避免风险，为IT项目的成功研发保驾护航。

IT项目管理的风险有哪些

项目风险是一种不确定事件或状况，一旦发生，会对至少一个项目目标，如进度、成本、范围或质量目标产生积极或消极影响。那么IT项目管理的风险有哪些呢？一起来了解下吧：

(1)技术风险。

核心系统升级引入了外包厂商的最新产品，使用了很多新技术，行内研发人员熟悉这些技术需要一定的时间，而在项目过程中却不可避免地会遇到一些技术问题。如何能快速解决这些棘手的技术问题我们的做法是：第一，指定行内外包厂商接头人，由接头人负责和外包厂商的技术人员进行沟通，同时该接头人也是行内对厂商产品最熟悉的人，一般性的小问题基本上此人就可以解决，比较复杂的问题才提交给厂商解决，这样比起全部问题都去找厂商解决，节省了时间。第二，购买厂商的人力进行技术支持，请厂商的研发人员来到开发现场和我们一块研发。第三，预约厂商在系统上线期间到现场待命，以应对紧急问题发生，对可能出现的问题进行第一时间的响应。

(2)沟通风险。

参与项目的外包厂商有多个，沟通渠道多，沟通成本大，而且容易出现理解不一致的情况。所以，项目组成立了专门的PMO，负责制定相应的沟通计划，为每个厂商指定行内的接头人，对内部人员实行分级管理，组织定期例会解决项目过程中出现的问题，防范由于对需求理解不一致造成的项目延误，充分利用已有的邮件、会议、电话和短信等沟通工具，并推广使用某即时通讯工具以作为主要的工作沟通工具。

(3)需求变更风险。

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

(4)进度风险。

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

(5)数据迁移风险。

项目涉及的系统多达上百个，系统集成环境复杂，需要迁移的数据量庞大，而且数据迁移对数据的准确性和完整性有着很高的要求。项目制定了分阶段集成和多次迁移演练的策略：将迁移工作进行提前预演，模拟真实上线迁移场景。经过多次演练以后，问题大大减少，减轻了系统上线的数据迁移风险。

(6)人力资源风险。

项目建设周期长，历时两年，大范围人员流动可能会造成项目延误。针对这一风险，应对的方法是：做两手准备，尽力挽留要走的人员，晓之以理，动之以情，请求公司人力资源部提升员工待遇;同时加紧社会招聘，在重要的岗位上安排备份，防止由于成员生病、离职等意外造成的减员。最终这个风险没有成为问题。

在项目升级项目中，我负责两个子系统的开放部分，由于高层对风险管理的重视，我在执行的时候也特别重视对风险的控制。项目组有四个人，沟通成本比较低，所以我们每隔一周进行一次代码评审，解决遇到的一些技术难题和编码规范问题，在实际开发中使用Checkstyle进行代码规范检视，及早扼杀了可能出现的Bug和不规范的代码;制定组员每周报告进度制度，防范进度偏差;面对前端最可能出现的需求变更——UI变更，我尝试在设计初期使用原型方法和业务进行有效沟通，大大减少了后期UAT阶段UI变更需求。回想刚进公司时我做过的某个项目，由于没有考虑到UI类需求变更风险，前期没有进行UI设计的交流，导致UAT阶段大量返工，使项目延误了一个多月，并且浪费了不少人力资源。设想如果当时识别了这类风险，在早期就把风险发生的概率降低，那么项目可能会顺利得多。

由于前期风险控制得当，一直到迁移演练前我负责的项目都很顺利，但是在迁移演练过程中出现了一些问题，其中一个问题是导库程序不能正常执行，并多次发生。我和同事花了很多时间研究问题，最后找到的原因是某个配置参数的问题，研发人员使用了错误的配置参数，ST、UAT期间导库的数据量比真实演练期间的数据量小太多，所以没有被发现，修改配置后再演练环境导库成功。还有一些问题是没有有效沟通导致的。例如，在演练的时候用户反映某个查询交易很慢，经排查，后台人员说前台调错了交易，前台人员提出异议：为什么ST环境查询很快原来后台人员写了多个查询交易，新交易确实能提升查询速度，但是没有在正式的文档上注明前台应使用新交易替换老交易，也没有通过别的途径告知前台，这样前台调用的还是老交易，导致了查询性能问题。由于ST、UAT环境和生产环境的差异性，上述两类问题很难暴露，试想如果没有进行迁移演练，这个问题恐怕要在生产上出现了。迁移演练提前暴露了ST、UAT所不能测出的系统缺陷，使得研发人员能有充分的时间去排查问题和修复缺陷，有效降低了系统上线风险。

经过这次核心升级项目的洗礼，我深深认识到风险管理在IT项目中的重要性，正因为对风险管理足够重视，提前制定了风险应对计划，我们才得以如庖丁解牛般化解项目中遇到的各种风险，并最终取得了上线的胜利。任何项目都不能回避风险问题，风险的存在导致几乎每个项目都不可能顺风顺水地完成项目目标，良好的风险管理技能将帮助项目经理处理好项目中的不确定因素，保证项目的顺利进行。

;

IT项目开发人员普遍认为，要高质量并按时完成项目是难以实现的，项目经理们并非不想要高质量的项目成果，他们只是想在质量的基础之上，能够按时完工和低于或等于预算的情况下，实现这个项目。有些项目管理技巧虽然确实可以成功地在降低成本和开发时间的同时不会对质量造成影响，然而，必需注意的是，过度地利用这些技巧就有造成灾难性后果的潜在可能。

1、时间盒(Time boxing)

在破坏项目质量的事件列表上，时间盒的应用排在第一位，当您告诉某人在任务必须移交之前，他拥有多长时间来完成这项工作，我说“移交”而不是“完成”，因为在极端情况下，这经常意味着代码并不完善，仅仅是抓紧时间去完成这项工作。

在大多数情况下，时间盒是有效的，因为它可以做到四件事：

1 它迫使开发者能够富有创造性地在他们的预算之内发现解决方案。

2 它排除了经常添加在软件中不必要的虚饰，而这些虚饰往往并不能增加软件的价值。

3 它防止开发者过度测试。

4 目的只是要得到这件产品，在完整的质量评价(QA)阶段将会有详细的测试，希望在此阶段中能够发现代码中存在的问题。

当存在未知问题，或技术没有经受检验，或没有正确的方法来检验结果的时候，时间盒就无能为力了;当时间盒很小，而且在分配的时间之内并没有可能的办法来实现目标时，这种方法也是无效的。换句话说，时间盒可以很好地解决一些问题，比如充分理解、谨慎评估和执行类的任务;然而，也确实存在时间盒方法不能很好解决的问题，比如研究和发展，还有解决问题等等。

如果时间盒是正确使用的，那么不应当导致测试到很糟糕的代码，这些糟糕的代码可能会导致数百个小时的诊断和返工。时间盒应当适度使用来确保最低的成本、最快和最高质量的软件。

2、误期

所有人都要有奋斗的目标，里程碑是一种受到尊敬的方法，它用来激发人们向同一个目标前进，这种动力可以在很短的时间内得到重大成果。然而，每个人都必须承认里程碑所界定的时间并不是每次都能实现，这时就必须要做出新的决定。

项目经理们必须要在团队中树立里程碑的目标，以此来激励他们前进，但是，当里程碑确立的日期并不现实，而且队员们一再出错，那就应该重新评估这个计划了。如果因为某种特殊情况可以使这个日期不再重要，那么当这个重要日期真正来临的时候，整个团队就只有很小的动力来实现这个里程碑日期。当整个团队连续错过了10个日期，那么第11个日期还重要么这就像喊着“狼来了”的孩子一样。

如果在设定的时间线之后并没有任何处罚，那么当错过这个时间的时候就应该强制执行或者移动整个时间线。

长远来看，不断创造持续的压力和令人迷惑的环境并不能创造出好的软件，开发人员需要能够专心工作的环境。完成项目的日期和关于里程碑日期是否真实的混乱，经常会导致开发人员在开发过程中跳过关键步骤或者造成难以发现的问题。

3、忽视相关性

在软件开发中，我们有很多技巧可以用来延迟相关性，我们可以停用一些函数、移动相连的基本架构，或者绕开众多的错误处理，在正确使用的情况下，所有这些技巧都可以帮助推进一个项目，然而，当为了完成项目，而这些技巧的成本因素又没有被考虑到整个计划当中时，就埋下了烦恼的种子。

很多时候，在项目中排列软件开发的顺序是非常具有挑战的事情，相关性并不容易被发现，因此也就不可避免地有很多相关性因素没有被安排到计划当中。为这些不可预见的相关性安排日程表可以让人变得疯狂，因此，压制相关性的方法是经常使用的，但是，如果过度使用了这些技巧，这些费用可能经常会占据项目总成本中很重要的一部分，而且直到项目的最后才会被发现。

所以要确信您现在所做的对于管理相关性是必需的，不会添加过多的成本，而且是整个软件开发项目中必不可少的一部分。当项目经理不能在成本与降低相关性的便利中取得平衡，那么他们草率地组装的代码将会展示出质量问题。

4、假装没有错误

在项目管理中，忽视并不是一种幸福。为了成功地完成项目，除了不可阻挡的政治压力，向公司其他的员工介绍项目的风险也是必需的。几乎每个软件开发项目都有延期或超出预算或同时出现这两种情况的风险。

问题在于，当最终某一时间，这些风险真正变为现实的时候将会引起恐慌，每个人都在混乱中将项目其余的部分组装在一起，整个项目的质量将因为最终轻率的装配而遭受损失。

当然，当整个项目还没有落后于计划之前，这一问题还不会充分暴露出来，然而，大多数项目都有办法只让项目的某些部分落后一点点，而几乎每个项目都有过于仓促的风险，这是因为管理层在很长一段时间之内都在项目没有任何问题之后得知项目的真实状态。

以上就是关于接手一个正在进行中的IT项目，如何进行全部的内容，包括:接手一个正在进行中的IT项目，如何进行、软件系统开发失败的最主要原因是数据库设计问题而非代码太烂、IT项目管理中有哪些常见的风险，如何规避等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！