你的软件项目为什么会失败，造成软件项目失败的多种原因
（一）软件开发项目失败大多是因为这三大原因
随着IT现在已然成为了公认的增长速度最快的产业之一，相关的各种需要进行完善和优化的项目也越来越多。与其他行业项目相比，软件行业很难确定项目失败的最终根源。不过，通过分析IT项目失败报告，一些常见的罪魁祸首可见一斑。
虽然导致每个项目失败的根本原因不尽相同，但是大多数我们可以归结为这三方面原因：可怜的预算、缺乏沟通和透明、不能适应变化和重新定向。
可怜的预算
俗话说，钱不是万能的，但是没有钱是万万不能的。钱在项目走向成功还是失败上面起着巨大的作用。即使是最精明的企业家和IT管理人员也都有因为资金的原因而导致项目失败的时候。
初创企业，大多资金有限，特别是在他们的发展早期。虽然一些初创企业可能会有一些财政援助，但是支持其整个开发过程所需要的资金还是很有限的，因为大多数风险投资者只有当你差不多能拿出成果——接近于成品的应用程序——的时候才会投给你大笔资金。
所以大多数初创企业只能选择怎么省钱怎么来。但是这可能不但会是最大的错误，也可能是最昂贵的。因为廉价所以很有可能会导致软件质量很差，而一个应用程序的根本在于能执行任务和操作，处理大量的请求，并且具备进一步扩展和开发的能力。
所以，如果代码的质量太差，很有可能前面所做的一切努力都会付之东流。即便是要将项目转移给另一个开发团队，用在修复代码库上面的时间也会大大影响预算。
另一个与预算有关的失败原因，与其说是因为缺乏资金，还不如说是因为没有正确地管理和使用资金。哪怕一家初创企业用于开发应用程序的资金远远超过所需要的资金额度，如果不能妥善管理，马上就会有捉襟见肘的困窘。
资金管理不善背后最普遍的原因是因为付款方式，通常被称为固定投标（Fixed Bid）。顺便说一句，在一个固定价格的基础上构建自己的应用程序，那你实际上就是自己将促成项目成功最关键的要素给抛弃了。
这种固定投标模式会破坏客户和开发人员之间透明和谐的沟通，原因是双方的目标是不一样的——开发人员想要尽快地做出产品，而客户想要以此收获更大的效益。
此外，这种固定投标模式也让人很难确切掌握这些钱到底是怎么用掉的，用到了哪里，因为它将项目直接看做一个整体，而没有了一个一个步骤。
缺乏沟通和透明
拥有一个开放的沟通渠道以便于全程规划、开发和部署的重要性，可谓是再怎么强调也不为过，原因是因为这是一个项目失败最直接也是最快的方式之一。众所周知，只有客户和开发人员紧密合作，才能保证客户的想法和要求可以明确地传达给开发团队。
缺少客户的参与可能会导致开发出来的应用程序与客户原本的初衷全然不同。这样一个不能满足客户需求的产品，又会怎么被认可是成功的呢？
不能适应变化和重构
事物总是在不断变化的，关于这一点，我想软件开发人员最是深有体会了。在软件开发过程中，出现变化和重构已经成为一种常态——无论是强迫的还是有意为之的。
在构建应用程序时，问题和障碍是其不可避免的组成部分，但是何尝不是发现新捷径的方式。变化和重构对于软件而言并不总是负面的。条条大道通罗马，构建软件也有很多方式，在我们解决问题的过程中，往往会突然灵机一动想出实现目标的新思路和新方法。
一个软件开发团队适应项目改变的能力主要依赖于项目管理方法。在软件开发中最常见的两种模式是敏捷开发和瀑布开发（较为传统）。敏捷开发方法在结构 上较为灵活，允许并鼓励软件变化和重定向。而瀑布开发方法则是线性的，并不允许项目在开发时发生任何变化——这个阶段完成后就进入下一个阶段，并且不允许 恢复到以前的任何阶段。
（二）软件项目最常见的失败原因分析
最佳实践建议在启动一个新的软件项目时，寻求一名在软件开发领域具有丰富经验并且可以在项目计划的早期阶段提供协助的主题专家的帮助。这一策略已经被证实可以极大提升项目的成果，然而在项目结束时你还是只能眼睁睁的看着失败发生。为什么会这样呢？
项目失败可分为成本超支、交付延期、质量不合格和/或产品未被应用等一种或几种情况。无论是否曾经参与到项目计划阶段，通常情况下，软件开发人员都会首当其冲承担失败的责任；无论怎样，他们是真正构建这个应用的人。然而，对项目更进一步的审查表明并非所有失败的项目都应归咎于开发人员能力不足。当对这些失败的项目进行评估时，其中一些项目与行业趋势相比完成的“还算不错”，然而却被其所在组织认定为失败项目。其原因在于绝大多数的问题都与项目之初有缺陷的评估或错误的商务决策联系紧密。为了避免这种情况发生，整个组织首先必须要使用标准的评估术语集合。我们经常会发现个人和组织大量地互换使用关键术语，而实际上他们各自都有独特的含义。
目标- 我们想要完成或达成的目标
约束- 在我们所能完成的工作上的一些内部或外部的限制
估算- 在范围、成本、日程、人员和可能性确定的情况下，对我们所能完成的工作的技术性计算。
承诺–通过选择一个评估场景并分配合适的资源，在一系列的限制条件下达成目标的商务决策。
计划–一系列项目任务和活动的集合，让我们可以在确定的范围、预算、日程以及人员的情况下，有一定的概率可以履行某一承诺。
这些概念的清晰定义可以确保项目拥有一个良好的开端——实际的目标和对项目所受限制的理解。若非如此，下面这些因素很有可能导致项目在一开始就踏上死亡的征程。
1. 在没有实质的数据和分析的情况下，就接受一个强制的日程安排或完成日期/里程碑日期。 组织中的某个人公开推测项目将在某一特定日期完成，这样在无意中整个团队都会致力于这一期限。也许你的预算周期显示分配给这一项目的资金必须花费到今年年底或者下一个版本不会得到资金支持。也许项目的利益相干人希望项目能在圣诞节前完成，知道项目已经结束他/她就可以安静地享受假期。或者干脆就是因为利益相干人特别喜欢整数，希望项目能够在该月一号发布。为什么一个开发团队会被设定一个主观的项目完成日期的原因五花八门。过于狂热的计划经常导致项目人员配备过度的不幸现实是为什么软件项目失败的另一原因。
2. 添加过多的人员以实现不切实际的日程压缩。 项目经理如何处理过度乐观的项目计划？一个常见的反应就是增加项目组成员，增加的成员经常会比完成项目所需的成员更多。这样不仅会大幅增加项目的成本，还会降低项目质量。让更多的人参与到项目中会增加错误传达的可能性，也会让不同部分的代码整合更具挑战。此外，Frederick Brooks (1975) 的主张“在延期项目中增加人手只会让项目更加滞后”是有一些道理的。这些人员通常是从其他项目中调派而来。这会让其他项目的项目计划更加滞后并且还要求新的成员能够赶上资深成员，这样整体来说生产力是下降的。
3. 未能考虑和调整需求的增长或变化并据此对计划和预算预期进行必要的调整。 “如果……不是更好么？”这种话有时候是最可怕的，特别是在项目组建的过程中道听途说而来时。当然，确实需要时间和场所进行头脑风暴，这些活动应该在第一阶段和第二阶段开展。实际上，这两个阶段的目的就是要决定一个项目是否可行，以及应用应该具备哪些功能特性。你可以如此考虑这个问题，第二阶段帮助你确定所要构建的内容，第三阶段则开始构建在第二阶段所确定的内容。在这两个高级阶段之间存在一定的重叠，当处于阶段三时，对于一个产品发布版本来说，应该已经有了一个清晰的必要功能列表。如果在没有增加开发时间和预算的前提下就增加功能，需求的增长就会成为问题。实际上，这是在要求在更短的时间内完成更多的工作，这种手段早已被证明无效。取决于其特性和时点，已有需求的变更也有可能成为问题。只要变更发生在某一特定迭代的构建之前，使用敏捷开发方法的项目就可以处理这些明细需求的变更。不过，对于任何会导致代码返工的软件架构方面的需求变更几乎必然会对项目的计划和预算产生影响。
4. 忽略事实和统计数据的情绪化或”全凭直觉的“利益干系人谈判。 或早或晚，我们都会与某个我们参与的具体项目紧密联系并在该项目的产出之上投入情感。对于许多人来说，该项目可能关乎自己的声望；项目太大经不起失败，而这经常会让我们被我们的情感所控制。当软件项目的成功或失败悬而未决导致个人的事业处于危险之中时，任何相关的业务决策很有可能都会受到影响。压力可以让人思维混乱，特别是在赌注巨大之时。为了给客户留下深刻的印象，某个利益相干人可能会要求一个12个月的项目计划安排，而完全不顾之前类似规模的项目报告均显示了15个月的生命周期。利益相干人很可能会忽略项目成员的建议，并声称他“感觉”项目团队可以渡过难关。在这种情况下，凭直觉可能是相当不利的并且有可能直接导致项目的失败。
5. 错误，但普遍认为众所周知的银弹可以独自解决项目吞吐量或过程问题。 当其他尝试都已失败时，一个常见的方法就是改变策略。这时比较常见的想法就是“我们现在的所作所为一定是错误的”以及“我们的竞争对手在做些什么？”也就在这时，“IT银弹”的思虑可能就会开始在办公室中蔓延。例如，某人可能会建议组织，需要采用最新的流行开发方法。虽然这可能会将组织引领至一个伟大的方向，但像这样的决策决不应该草草定论。无论你的组织决定采用哪种开发方法，这也只是实现层面的变化。仅仅是开发方法的转变并不足以完成开发操作的转换。无论做出什么决策，为了能够成功实施，就需要各方均能接受并支持这一决策，并且需要为项目成员提供培训，而且所有人都需要为同样的标准负责。否则，每次启动新的项目时，你的开发策略就基本相当于等待天空的星辰排列整齐，期盼奇迹发生一样。如果没有经过深思熟虑，实现这种策略不仅存在令人难以置信的风险，同时也会减少团队成员在项目中期提供反馈的机会。简而言之，造成软件项目失败的原因林林总总。花点时间认真反思一下上述原因是否曾经也是导致你的组织中项目失败的元凶。那么现在是否有了应对它的措施？作为一个执行领导人，可以做的工作有很多，不过对开发操作提供支持仍需很大的勇气。他们需要在合理的预期内运行。显然，他们仍需要对自己的行为负责，因此就需要历史绩效数据作为证明他们能力的证据。你需要从多个不同的维度搜集数据，包括项目的计划持续时间、所花费的精力、工作的范围、项目的整体质量以及所达到的生产力水平。这种情况下，生产率指数（PI）以指数点数作为计量单位，这是一个有专利的QSM计算单位，范围从0.1到40。它让项目之间的比较更有实际意义并且对软件开发因子作出了解释，其中包括如下变量：管理影响、开发方法、工具、经验水平和应用程序类型的复杂度。一旦某个组织建立了已完成项目的仓库，就可以计算定制化趋势线，用于基线创建。这些趋势线作为参考点可用于组织内的项目比较。项目相对于趋势线所处的位置表明了项目与平均水平的相比孰优孰劣。这会让你对组织的当前能力有清晰的洞察。
公司项目组合与基线生产力趋势对比图通过查看我们的项目与基线的相对关系，可以了解到许多关于我们在哪些方面做的很好，哪些方面仍需提高的信息。检测项目与各种趋势的偏离度有助于杜绝最好或最差的绩效。项目的极端值也可以为此提供有力的洞察。图1展示了公司项目组合与他们的基线平均生产率的对比。有两个项目由于落在两个标准偏差之外而显得尤为突出，其中一个在平均线之上而另一个则在平均线之下。对影响这些项目的因子的进一步检查（如，新技术、工具和方法、人员或项目复杂度）可以帮助了解为什么这些项目的执行如此成功或失败。效仿一流项目中最好的经验，避免失败项目中的教训可以帮助提升未来项目的绩效。通过展示过去已经完成的成果，了解当前开发操作的基线，可以帮助你合理地设立将来的项目的预期。如果所需的项目参数将评估置于一个未知的领域，就可以使用历史基线协商出一个更加合理的方案。这个基线还可以用于合约谈判、报价及供应商绩效评估以及引导客户约束，从而达到缩减成本和改进过程的目标。这一工作会让你在与客户和业务干系人的谈判中占据更加有利的位置。理想的结果是达到共赢。很有可能这会需要一些妥协和折衷，但这个过程中你会播下成功的种子。
（三）软件项目是这样失败的
谁也不知道城西银泰豪华的大楼是什么时候出现的。即使像我这样天天上下班都经过那里。
记忆里似乎巨大的塔吊和漫天的扬尘在那里飞舞了大半年，也许是一年有余。几个月前突然某一天经过时，看到了颇具规模的大厦似乎正在慢慢形成。直到最后几天，当最后一个丑陋的脚手架被拆掉，才发现这里竟凭空出现了如此巨大的庞然大物。
不禁感慨人类的才华和创造力。
相比之下软件行业似乎显得很渺小，通常很难向一个行外人介绍一款“伟大的软件”，因为他们很难理解一堆.dll和.exe的伟大之处。在他们眼里，只有一堆看不明白干什么用的奇奇怪怪文件和一个不见得多漂亮的图标，双击进入之后有功能A,B,C,D,E,F,G。
不幸的是，在多数人坚信“项目经理不需要懂技术”的巨大背景下，连项目经理本人也理解不了程序员们那些自称屌炸天的设计架构。
于是有了各种银弹，各种管理方法。其中之一有一个大家都耳熟能详甚至耳朵磨出茧的名字——敏捷。
快速迭代，快速发布可用版本。在看得见的功能一个接一个被“制造”出来，管理者比任何时候都心中有谱。于是他们在此之上又发明了以功能点来计算工作量等等诸如此类的时间管理方法。并对所有人说自己的项目用这管理方法进行的十分顺利。
某天一个管理者理所当然地听说并坚信了敏捷管理的出类拔萃所向披靡。他的团队正要建造一个像银泰城一样伟大的项目。
他理所当然地不想看到一堆开发者貌似很努力的敲打键盘然后产生一个个莫名其妙的带着各自后缀名却无一可以双击点开的文件。这种感觉加上一些基因带给他的莫名的不安全感让他觉得可怕，这些埋头敲键盘的家伙到底在干些甚么？他们拿走了不菲的薪水却很可能在搞一些跟工作压根没关系的东西。项目进度怎么样了？是不是该让他们加加班？是不是他们中有人技术不达标导致整体进度有问题却瞒着我好多领几个月薪水然后走人？这种无力感让他坐立不安。看着这群自称程序员的家伙天天上班下班就像看着工地里漫天的扬尘和出入其中的满载的黄沙车，工地上看上去一直是一片混乱，工队负责人告诉他在打地桩，可是，天知道发生着什么？
这次他决定采用更先进的管理方法，而这一方法已经被无数人证明科学且百分之百成功。敏捷，或是叫别的什么名字，管它呢。快速发布可用版本，快速迭代，基于功能点的计划，棒极了。
于是他把大楼图纸大致看了一遍，决定在第一个月完成第一层的最北边商铺，接下来两个月继续完成剩下的三个方向的。一开始总是会比较慢，因为那群程序员告诉他有许多设计什么的额外工作。计划是再接下来每两个月完成一层楼，这样完成整栋6层大楼需要13个月。加上测试和发布，15个月足矣。何况，第五层和第六层面积要小很多，应该会快不少。
他把所有人召集到一起开了一次长达一天的会，解释敏捷开发的成功案例和他的计划。所有开发人员都同意敏捷是时下最先进的管理模式，其中有两个似乎还看了不少相关的书籍教程觉得计划非常科学，在会议上盛赞了半天经理的英明神武，经理决定下次有机会提拔他们。项目红红火火的开始了。
在经理强大的个人魅力感召下，敏捷进行的比想象得还要顺利。一开始几个员工自愿加班加点，后来更多的人加入了他们。几乎每天都能看到他们在会议上为新完成的功能欢呼雀跃。不出所料，一开始的工程在20天内就完成了。经理给了项目中每一个人一笔不菲的奖金并在部门会议上表扬了每一个人。开发人员充满干劲，能够拥有如此优秀的团队，简直是上天的恩赐，经理睡得比任何时候都踏实。白天有人向他提到项目架构的风险，也许该给他加点薪水了，明天也有必要向全员强调下保证质量。
项目进度一路高歌猛进，团队里的每一个人都坚信自己所在的团队是首屈一指的，没有别的团队能在如此短的时间里发布如此多的功能。在前6个月他们已经完成了相当于3层大楼的所有商铺，唯一的问题是有比较多的零散BUG，大概是士气高昂之下大家都没有把项目质量的要求太放在眼里，以往的经验来看这些不会成为风险，经理自己也觉得这没什么可担心的。
第一次问题出现在第7个月中旬，有两个开发在例会上告诉大家ORM模块线程不安全。经理对此一头雾水，但似乎所有的开发人员都认为形势很严峻。有人提出在保证进度不拖慢太多的情况下进行一定程度的返工。有时候这在所难免，技术负责人说这就像是给大楼的第一层较小的柱子加一个支撑结构，应该很快就会完成。很快项目回到了正轨，只是更多的人偶尔提出设计架构的缺陷，但我们拥有如此优秀的团队，大家总会有办法做好它。项目进行到中旬，这往往是最考验项目经理能力的时候。经理表现出他在软件项目上的强大经验适时的激励组员，强调这个项目完成后公司能获得的巨大收益，所有人倍受鼓舞。
顺境只持续了两周，在第8个月初，计划中要进行的5个功能点开发有2个停摆，问题还是在ORM上。组里最年轻的程序员提出项目架构有巨大缺陷，需要大规模重构。其他所有人都认为这样做风险巨大，而我们目前面临的问题并没有想象中那么严重。只是需要在更大的层面上返工一下，然后在某些不能工作的地方做点特殊处理。经理这时候隐约感觉到似乎有点不对劲，好在项目进度已经足足提前了两个月，就算有问题也还有的是时间慢慢解决。他在例会上允诺了正在想公司为每一个组员争取利益，大家站在同一阵线上努力前进。例会非常成功，员工们又开始自愿加班。
此后又有若干次功能开发上的问题，在大家集思广益下都一一得到解决，虽然进度的领先已经几乎不复存在，但大部分功能也已经可以工作了。
真正的问题出现在第11个月中旬，在所有人测试服务器负载时发现并行处理能力不足以支撑整个系统业务需求。开发人员分析后告诉经理这主要还是因为ORM多线程处理有问题，而目前模块间耦合十分严重又导致不可能单独替换掉ORM模块。这就像是大楼的承重结构有问题，不把整个楼拆除根本不可能换掉哪怕其中的一根柱子。而底层的数据结构设计也有很大的缺陷。产品经理开始妥协砍掉上层一些不太重要的功能以期待系统能满足大多数需求，可技术负责人说还是不行。时间仅剩4个月，这时候已经没有人说要从头搭建架构了，因为所有人都知道时间不够。经理也清楚，在没有把握的情况下自己跳进这坑里极有可能被坑死在里面，未来也没可能再在这个公司混下去了。大家开始质疑需求的合理性，推脱责任，和有问题的模块划清界限。越来越多的BUG被证明与架构缺陷有关，不大规模重构就无法修复。项目陷入了一片混乱，所有技术人员每天开会思考风险较小的办法处理，但似乎每个方案都被推翻。知道12月初，一些人开始提出除了大规模重写别无他法。经理为此每天无法入眠，他每天陪员工加班到深夜，恨不得自己也上去写两行代码，如果能帮上忙的话。他开始询问每一个技术细节，希望自己能为大家或多或少提供点意见。但这除了增加了更多的会议之外似乎没有什么效果，甚至有人抱怨他占用太多时间。
噩梦一般的日子又持续了两周，眼看离交付只剩3个月，经理感到前所未有的无力和沮丧。自家小区边又开始建造房子，灰蒙蒙看上去一片混乱，看不出来工地里在干什么。这种工程居然能够成功，果然造房子比造软件容易多了。
部门领导每周都会询问这一重要项目的情况，以往经理总是会给出超出预期的答案。可最近连续几周项目没有任何进展，经理在周会上根本不敢面对大家。领导还在安慰他说努力努力，大家都在同一战线上。激励下属，作为这个民族管理学的最核心精髓，经理对此再熟悉不过。只是，假如一开始大家没有被热情冲昏头脑，是不是就会发现问题？会不会有人其实一开始就已经发现问题而没有说出来，只因为说出来会大家耻笑太悲观？
看着窗外远处建筑工地一片混乱的情景。也许房子只有这一种造法，前八个月注定尘土漫天，不会有一家商铺靓丽地出现在世界上，只有打桩机的轰鸣和巨大的钢筋混凝土柱子，商铺只在最后6个月以惊人的速度完成。
第二天，经理找来了所有的开发，询问了每一个人的意见后宣布，所有底层设计架构重做。
我们一起回到那一片漫天的尘土中去。
（四）造成IT项目失败的五个原因
摘要：造成IT项目失败的原因有很多，从前期准备到人力资源安排都可以看出端倪。虽然每个项目环境不尽相同，但是站在模式角度来看，失败项目的背后或多或少都有着相似的地方。本文列出了五个常见的原因和该如何防范的建议。
1. 技术与商业需求相悖
酷炫前沿技术不一定就是最适合，虽然新技术看上去很美。但是时刻紧记的一点应是如何以最小的代价获取最大的商业收益。因此，要先想明白“为什么”和“是什么”，然后才是“如何做”。
2. 急于求成
在明确项目范围前，人们往往会更倾向于尝试先做。这份自信或许来自过去成功的经验和认为技术能够摆平任何困难。这不但是个代价高昂的举措，而且会影响需求分析和造成80/20问题的出现（当80%的需求满足时，20%“有就更好”的需求往往会成为决定成败与否的关键因素）。
3. 没有划定明确的项目边界
没完没了的需求很容易会造成项目的拖沓冗长。任何时候我们都应该先回顾做这个项目的根本目的，然后再去谈额外需求。否则，我们面临的会是一再拖延的验收日期，更多付出，没用的繁杂功能等困境。
4. 没有果断地终止错误的项目
要终止正在运作的项目需要不少勇气，特别是如果发现这是个错误项目。错误的项目有可能是弄错了技术方向，有可能是超出项目预算，所有的这些都有可能造成更严重的支出问题。
5. 没有检查ROI（投资回报率）和估算项目周期
很多项目都把ROI作为可选项，特别是当认为该项目成本较低或有非常好的收益时。因此，不应该低估廉价策略对项目造成的影响。
同样地，很多项目没有设定正确的结束时间和估算后续的维护成本，导致项目迟迟没有上线，取而代之的是没完没了的调试和修正。
领导一个IT项目需要有前瞻性思维、良好的计划能力、沟通说服能力，以及果断英明的执行力。能及时在问题发生前识别出状况，才能对此做出正确安排。