为什么大型IT项目往往会失败或成本/进度超支大？[关闭]

我总是读到完全或几乎完全是灾难的大规模改造或集成项目。即使他们以某种方式成功地取得了成功，成本和进度也非常巨大。大型项目更容易失败的真正原因是什么。可以在此类项目中使用敏捷还是传统方法仍然是最好的。

澳大利亚的一个例子是昆士兰薪资项目，他们改变了测试成功标准来交付该项目。
在此SO问题中查看更多失败的项目（在Wayback Machine上）

您有什么个人经验要分享吗？

主要原因是范围的扩大，《实用程序员》一书将其描述为：

• 功能膨胀
• 爬行的特征主义
• 需求蠕变

这是水煮青蛙综合症的一个方面。

各种“敏捷”方法的想法是加速反馈，并希望及时纠正项目的发展。

但是另一个原因是发布管理：如果您不打算发布项目（尽管它可能不完善），那么它很可能会失败（因为发布太晚了，功能太多，而且更难修复/更新/升级）。

这并不意味着您必须有一个固定的发布日期，而是意味着您必须始终能够构建程序的运行版本，以便对其进行测试/评估/发布。

博客文章“ 后期项目一次迟到一天 ”包含更多示例：

我知道要做的事情是“扩大范围”并保持启动日期固定，但是如果无法及时完成商定的功能，那将行不通。

这就是为什么我们不提倡使用规范或“不赞成功能”的原因。这就是问题的根源-您甚至在绘制第一个像素或编写代码行之前就了解所需的一切以及如何实现。 。

当您预测灵活的礼物会带来死板的未来时，您就会遇到麻烦。刚性期货是最危险的事情。他们不会为发现，出现和错误打开新的大门而留有余地。

通常，项目的复杂性被低估了。

史蒂夫·麦康奈尔（“ Code Complete”声名of起）列出了经典的错误。

许多人经常选择一些无效的开发实践，其结果可预测，不良，因此应将它们称为“经典错误”。

本节列举了三打经典错误。我个人至少看到了这些错误中的每一个，而且我自己也犯了很多错误。

此列表中的共同点是，如果避免错误，您不一定会得到快速发展，但是如果您避免错误，则肯定会得到缓慢的发展...

为了便于参考，该列表按照人员，过程，产品和技术的发展速度维度进行了划分。

人

＃1：动机受到破坏...

＃2：人员薄弱...

＃3：问题员工不受控制...

＃4：英雄...

＃5：增加人员到后期项目中...

＃6：嘈杂，拥挤的办公室...

＃7：开发人员与客户之间的摩擦...

＃8：不切实际的期望...

＃9：缺乏有效的项目赞助...

＃10：缺乏利益相关者的支持...

＃11：缺乏用户输入...

＃12：政治重在实质...

＃13：如意算盘...

处理

＃14：过于乐观的时间表...

＃15：风险管理不足...

＃16：承包商失败...

＃17：规划不足...

＃18：在压力下放弃计划...

＃19：在模糊前端浪费时间。“模糊前端”是项目开始之前的时间，通常是在批准和预算过程中花费的时间...

＃20：上游活动变短...也称为“跳入编码” ...

＃21：设计不足...

＃22：质量保证不足...

＃23：管理控制不力...

＃24：过早或过于频繁的收敛。计划在发布产品之前不久，就推动了产品的发布准备工作-提高产品的性能，打印最终文档，合并最终帮助系统挂钩，完善安装程序，取消不必要的功能按时准备好，依此类推...

＃25：忽略估算中的必要任务...

＃26：计划稍后再赶上...

＃27：类似代码的地狱编程。一些组织认为快速，宽松，随心所欲的编码是快速发展的途径...

产品

＃28：要求镀金。从一开始，有些项目的需求就超过了他们的需求。

＃29：功能蠕变...

＃30：开发人员镀金。开发人员对新技术着迷，有时会急于尝试新功能...-无论产品中是否需要...

＃31：推我，拉我谈判...

＃32：研究型开发。Cray超级计算机的设计师Seymour Cray说，他不会一次在两个以上的区域中超过工程极限，因为失败的风险过高（Gilb 1988）。许多软件项目都可以从Cray中吸取教训。

技术

＃33：银子弹综合症...

＃34：新工具或方法高估的节省...当项目重用以前项目中的代码时，会出现一种高估节省的特殊情况...

＃35：在项目中间切换工具...

＃36：缺乏自动化的源代码控制...

项目
越大= 复杂程度越高=不确定性
更多=不确定性更多=难以估计
难以估计=差的估计差的
估计=成本超支

我责怪招标过程。它奖励可以使交易看起来最便宜/最快的团队。

如果人们没有机会获胜，那么他们将不愿浪费时间，因此他们的正常估计被搁置了。我知道指定普通交换机而不是POE交换机的人可以节省80美元。但是该项目需要POE，因为它具有IP摄像机。这80美元需要花掉，但现在超出了规格。

我坚信，无论您获得多少投标，一个为期2个月的$ 2,000,000项目仍将花费2个月的$ 2,000,000。如果您认为做对了是很昂贵的，请静观其变，这是多么昂贵。

一个可能的原因是，估算是基于较小的项目进行的，假设成本随项目规模呈线性增长，而实际上由于复杂性的增加，项目持续时间较长（需求变更的时间更长）等原因，成本增长为二次方。难度越大，项目越大，就越难正确估计。

另一个原因是最优估计有偏差：为了赢得竞标，使用最佳情况估计来计算价格。项目规模越大，最佳方案的可能性就越小。投标规则使最乐观的要约人有可能被接受，因此，即使5个供应商做出了现实的估计而第6个供应商也过于乐观，但乐观的人中标了，后来失败了。因此，这是一种否定选择。

在“管理”的眼中，成本并不排除进度，这是一个重要的区别。众所周知，“有九个女人一个月内无法生孩子”，但是您会惊讶于有多少人认为问题的深度与扔给他们的钱有关而减少了。不良的项目管理（通常以微观管理的形式表现出来）是导致大多数项目失败的主要原因（以我的经验）。当“管理”意识到某些事情已经失控并且他们对原因一无所知时，微观管理就开始了。

如果不是这个原因，那么该项目的预期结果可能一开始就站不住脚。以我的经验，如果一个项目的时间框架太短，人们将非常害怕犯下导致“双重工作”的错误，以至于他们什么都做不了。

这就是为什么管理人员应该由经验丰富的程序员组成的，这些程序员具有领导团队的成功历史，这些团队曾开发过成功的项目。这样的人可能会说，尽管有可能获得收入，但“我们无法负责任地做到这一点”，而且不会长期任职于管理层，这就是为什么我们许多人（最终）回答MBA而不是PHD的原因。

我记不清我曾经在非程序员负责雇用程序员的公司工作过的公司数量。我曾经接受一次采访，招聘经理除了讨论最近的体育赛事（我认为那是一场足球比赛）外，什么也不想做。如果您的负责人从NFL教练那里比Knuth受到更多的启发，那么该项目将会失败。

偶尔，您会遇到一些计划周全，易于理解，切合实际且看似直截了当的事情。无论出于什么原因，经过六个月的开发，一切都发生了逆转。它发生了。然而，很少有项目导致成为光荣的猪肉桶的根本原因。

不过，我必须承认..如果您观看新闻，则可能会偶尔遇到摩托车事故或火车残骸。您从来没有听说过每天准时到达的无数摩托车或火车。项目也是如此。当然，很有趣的是，对某件确实非常糟糕的事情进行了公开验尸，但是您几乎从未听说过一件非常非常好的事情。我认为，糟糕的项目仍然是例外，不是常规。

大多数情况下，以下两个或多个组合：

• 部门之间的协作问题
• 政治...太多政治...
• 错队
• 不切实际的调度
• 没有适当的方法来改变范围
• 缺少信息

关于这个主题的好书：《死亡进行曲》。

人们倾向于认为软件开发是一个可预测的过程，试图在一年前进行度量和估计。这是不可能的！建筑软件不是螺栓制造。

遵循相同的“趋势”，他们试图做一个大型analisys（一年后），以为他们将涵盖所有可能性，后来将程序员变成纯粹的打字员。怎么会认为这可行呢？这种行为只会导致错误的估计和大量的官僚作风。

项目越大，您为大型组织工作的可能性就越大。组织越大，管理层就越多。管理的层次越多，坏消息（“我们无法拥有我们想要的，但我们无法负担得起的东西”）就越难将其组成指挥链。坏消息越不可能组成命令链，幻想计划就越有可能被接受，然后被认为是站不住脚的。

各种规模的软件项目都“倾向于失败”或“存在成本超支”。您没有听说过拐角处企业的成本超支，但确实听说过FBI虚拟案例系统或丹佛机场行李处理系统。因此，我将宣称并非所有大型系统都将发生故障，也不是所有大型系统都存在成本/进度超支。

我遇到了按时投入的大型系统（时间表在项目期间仅移动了一次，并且仅在规范上移动了一次）和规范（由于我们只是众多供应商之一，所以我无法访问预算信息）。仍然给我留下深刻印象的一个（并且我已经在此站点上写了些关于它的信息）是针对大型（《财富》 500强中的前100个）金融客户的大型集成客户管理系统。我估计他们在电话会议中每天要花掉大约10万美元（一年多）的薪水。

对于行李处理系统，软件经理说：“基于如此规模和复杂性的项目，构建和调试该系统将需要4年的时间。” 销售和执行经理说：“机场在2年内开放，我们告诉客户这将需要2年，所以您有2年的时间来做。” 检验您是否是程序员或管理不善的测试是对以下问题的简单回答：“行李处理系统是晚还是准时？”

如果客户确切知道他们想要什么（很少知道），他们将在控制成本和时间的道路上走得很远（这些人往往会做得很好的离岸外包）。如果您的项目必须满足客户可能梦dream以求的所有可能功能，并且每个部门都拥有将其宠物金砖添加到项目中的否决权，那么您注定要从一开始就遭受失败（例如FBI的失败） VCF项目）。

现实感

这是我所发现的对该问题的最佳描述。从businessballs.com的树摇摆

在我的编程职业生涯初期，我就被引入了“感知现实”的概念。为此，我表示衷心的感谢。我相信，这是任何项目失败的最大原因，而不仅仅是IT项目。

失败的原因之一是，一个大项目通常是一个引人注目的，对业务很重要的项目。当项目和任务备受瞩目时，它会鼓励人们说谎。

您的老板希望您从高方面评估完成状态。他想估算低端的超车和延误。当您遇到问题时，他不想听到这将使任务增加三周的时间。他想听到您可以将其工作到今晚几个小时。

等等等等。

几年前，我正在为一个客户进行一个项目。投标和项目计划完成后，我被带进来。不断有越来越大的压力要做出更快，更荒谬的成本削减决策，大量的工作人员超负荷工作，没有资源供他们使用；没有书桌，电脑，任何东西。

最终，我发现该项目的竞标价格为7个月和1600万美元。我估计信封的背面应该是24个月，50到1亿个。我与经理和他的经理开会，介绍了我的案情，以及我们如何无法按时交付预算或预算；他们轻描淡写了所有问题。在会议结束时，CIO基本上打电话给了我两个人，并告诉了我这两个经理人的内容，但原始竞标中的缺陷除外。

当他们将技术更改为我不熟练的技术时，我就有机会启动该项目。我后来跟某人说话。这个项目最终在大约一半的时间内被取消了……在12个月内耗资3500万美元。

备受瞩目的大型项目使人们不敢说“这是一个错误”。错误是不能容忍的。

详细阐述VonC的答案：

这个大项目倾向于具有“全有或全无”的心态。所定义的项目必须一次性发布-通常是从现有系统进行的转换。

这意味着功能/需求爬升的问题很难解决，因此当项目实现时，它通常被视为不再满足要求。如果现有系统已更新或技术同时发展，则可能会加剧这种情况。

有什么解决方案？

我真的不知道，没有人希望让两个系统并行运行，并且在这两个函数之间分配一组不断变化的功能。

外部政治压力会大大加剧大型项目的复杂性。一个部门可能对他们在新系统中的需求有一个非常清晰，集中的想法，但是随后相关部门会按照“嗯，只要您正在这样做，为什么不这样做？对我们来说这是一件小事吗？” 您可能首先说“不，那超出了范围。”，但随后各部门之间的政治斗争开始了，该项目的预算受到了威胁，除非每个人都能分得一杯pie。

多年以来，我们的当地警察一直无法通过汽车系统搜索部分车牌，这一功能似乎非常简单。我问一个朋友，到底增加这个功能有何困难，他们说，每当他们提议切换到现代数据库时，该州与机动车系统有任何交互作用的其他部门都希望获得此功能。系统也修复了。结果是完全实现了IT现代化的束缚。最终，国家集结了足够的资金来进行全系统的现代化工作，但由于它是如此可怕的复杂，之所以陷入困境。

一个已经涉及但尚未解决的因素：

几乎所有的重大失败都是被招标的合同。在这种情况下，有能力的公司会怎样？他们做出了现实的估计，因此几乎可以肯定有人做出了错误的估计。

如果公司不能正确估计，他们也不能正确构建系统是否令人惊讶？

ZDNet上的Michael Krigsman拥有一个专门讨论“ IT项目失败 ” 的博客，在这里可能会引起关注。

另一个要点是，对于跨越多年的长期项目，通常将需要进行升级或考虑其他解决方案，例如，现在是否可以在云中而不是在现场完成某个项目，从而开始出现越来越多的事情？这些在项目启动时不是给定的。例如，虽然人们可能会在6.0左右开始，但是到第一阶段完成时，很可能会出现6.3或6.4的问题，并提出了何时升级的问题。范围和所需功能的更改（由于未正确收集需求或某人改变了主意）是另外两个要点。

可以在此类项目中使用敏捷还是传统方法仍然是最好的。

应用良好的敏捷过程似乎并没有遭受这个问题的困扰，原因很简单。您不能以敏捷的方式启动大型项目。您可以选择其中一个。

有了敏捷的过程，您再也不会真正在项目的未来中经过一两次迭代了。接下来的两年没有“计划”，只有接下来的两个星期。当您的观点这么短时，您必须做出一些妥协。对于要设计的任何类型的小部件，您都无法从制定“小部件中的最后一句话”的计划开始。至多，您可以从“一个可以滚动的小部件”开始，因为多数民众赞成在一个或两个迭代中可以完成的大部分工作。

这样做的好处是，经过几次迭代，您已经拥有了一个完整的，可以正常工作的产品，并且有人可以找到有用的产品，尤其是那个急切需要一个可以摇动和整理的小部件的客户。

本质上，大型项目可能会失败，因为它们旨在解决所有潜在客户的所有问题。敏捷项目从来没有这个目标，而是在每个版本中仅解决单个客户可能遇到的一个关键问题。但是，经过很长一段时间，一个敏捷项目可能正在为很多客户解决很多关键问题。

• 无法运送给实际用户

大型项目多年来一直陷入“基础架构”模式的讨厌趋势，而忘记构建真正的最终用户功能并将其交付。到其交付时，更改的成本非常高昂，通常，最大的概念更改最终会在首次进行真正的Beta测试后被要求进行。

• 无法准确估算成本

如果项目看起来像他们将超过其投资回报，他们将被取消。

• 质量失控

如果有足够的缺陷，则前进动量有可能降至零或更低。根本没有任何进展，很难为继续存在而争论。

他们忘记了霍夫施塔特定律：即使您考虑霍夫施塔特定律，它总是比您期望的更长。

我在Web开发中看到的内容：

• 厨师过多-B＆M大型零售商那里的重点突然转移到了网上。突然，有20个部门的负责人开始不遗余力地打动新的起司奶酪。我曾经不得不实施新图标，因为法律不喜欢旧图标的外观。

• 过多地关注与实现目标相匹配的规范-“与IE7相比，IE6的图标略有褪色。请放弃正在执行的关键发布日期工作，并吸引0.05％的客户群来完成可能需要几天的糟糕工作进一步实施和减慢IE体验。”

• 非开发人员选择的错误工具，他们甚至不愿意去向内部开发人员寻求建议。

• 工具会挑坏的开发人员-“当我们可以外包200个几乎不懂版本控制的几乎没有代码知识的人时，为什么要向20名合格的Java开发人员支付可观的薪水？” 由于他们同时与不同国家/地区的人们同时使用，因此主要在3种大型应用程序的后端工作。

• 糟糕/残破的体系结构-那些被解雇或现在是经理的人在恐慌的，成千上万的昨天代码中层层叠叠。