尽管采用了新的方法和管理技术来阻止惊人的失败，但关键的技术措施仍然以惊人的速度失败。下面来谈谈IT可以从错误中学到学到什么教训。
在敏捷开发、devops(开发运维)和相关的管理技术的时代，IT项目失败甚至不是个事儿了吗?可悲的是，答案是肯定的。
在过去，IT失败往往意味着代价高昂的失败之作，大规模的软件实施时间过长，超出预算。那些失败可能而且仍然会发生。例如：IBM未曾完成的1.1亿美元的升级到宾夕法尼亚州的失业补偿制度。
但是今天的IT失败往往与过去的不同，因为敏捷、devops(开发运维)、持续交付和快速失败的运动已经改变了IT处理项目的本质。这些迭代的管理方法和理念旨在最大限度地减少项目出岔子的可能性，但事实是IT项目仍然失败，只是以新的，有时甚至是更阴险的方式失败。
以下是七位IT领导者和分析师对如今的IT项目失败状况的看法。
警世寓言
目前，加利福尼亚州科罗纳市的首席信息官Chris McMasters引用了几年前在前雇主进行的为期18个月的SaaS客户关系管理系统的实施情况，在那里IT部门与销售部门的领导层一起了解业务需求并定义要求。
他说：“我们以为我们有了所有必要的决策支持并知道结果应该是什么，但我们到达项目尽头，而销售人员不想要。阻力极大。高层管理人员是支持的，但是用户之间有不信任。”
基于云的CRM被宣布为破产和报废——这表明即使项目按时按预算完成，它们依然可能失败。
McMasters说：“失败可能以很多不同的形状和形式出现，无关乎产品有多闪亮，或者它能做一千件事情。对我来说，如果我们没有提供终端用户期望的结果，那就是失败。”
McMasters说如果IT更多地关注营销新系统的好处而不是项目执行，那么它更有可能获得成功。他说：“我们没有达到本该有的参与度。我们本该与业务更好地合作。”
CRM作为一个失败的项目，它的实施并非绝无仅有。项目管理研究所(Project Management Institute)2017年的职业脉搏(Pulse of the Profession)报告发现，受调查对象所监督的战略举措中有28个被认为是彻底失败。 3000多名项目管理专业人员中有37%的人回答引证说缺乏明确的定义和/或可实现的里程碑和目标以评估作为失败原因的进展，其次是沟通不畅(19%)、高级管理层缺乏沟通(18%)、员工抵制(14%)和资金不足(9%)。
说到钱，同一份报告发现，由于项目绩效不佳，组织每投资10亿美元就平均浪费9700万美元。这比2016年的1.22亿美元的浪费要好些，但仍然有大量的现金损失。
失败的因素
专家说，尽管采用新的方法论和管理技术意味着阻止壮观的失败，但传统上使IT项目处于失败风险的很多因素仍然存在于企业中。资源不足、咄咄逼人的时间表、成本低估、被忽视的需求、意料之外的并发症、治理不善以及错误代码等人为错误都可能导致项目失败。
普华永道(PwC)的2017年全球数字智商调查调对来自53个国家的2216名业务和IT领导人进行了民调并询问他们是什么阻碍了数字化转型。约64%的受访者表示IT与业务之间缺乏合作是元凶，58%的人表示是因为不灵活或缓慢的流程，41%的受访者表示缺乏新技术和现有技术的整合，38%称是过时的技术，37%b把矛头指向熟练队伍的缺乏。
专家说，同时，用于判断项目是否成功还是失败的标准已经扩大，以反映今天的技术举措的重要性。PMI的2017职业脉动报告指出，“成功的定义正在发展。范围、时间和成本的传统措施在当今竞争环境下已经显得不足了。项目提供它们着手做的工作的能力——即预期的收益——同样重要。”
研究确认了他们的项目中有80%或以上是按时按预算完成的，同时满足原始目标和业务意图;它将这个组别归类为“冠军”。报告还强调，这些冠军投资于几个共同领域，其中包括项目专业人员的领导技能、福利实现管理、项目管理办公室、积极参与的高管以及敏捷项目管理实践。
研究公司IDC的分析师Stephen Elliot估计，IT项目中有30%至35%可能被视为失败。 Elliot将很多这样的失败归因于业务优先级或目标的变化。他说，这意味着技术运作良好，但并没有提供业内目前所期望的结果。在这些情况下，由于缺乏有效的沟通和协作——“在这里决定是制订了而但没有得到传递”——而这恰恰在IT项目失败方面罪责难逃。
他说：“在这个以客户为中心的世界里，我将‘失败’定义为你公司的声誉或利润或收入已经受到负面影响。失败仍然是真实的，与其说它与技术故障有关，比如因为有人没有检查主路由器上的配置，不如说它与业务流程有关。”
其他人也表示认同。 IT认证提供商美国计算机行业协会(CompTIA)的产品高级总监James Stanger表示：“如果你按时按预算将事物整合起来，但它没有做到客户想要的或用户需求的，那么这无济于事。”
敏捷和自动化力挽狂澜?
有一些趋势，特别是敏捷和devops方法，有助于减轻现代IT商店中的大规模项目失败的可能性。
Elliott说：“从理论上说，这种编写代码的新方式，即以小块为单位进行自动化测试，并且迭代直到它清理然后移动到下一个块，提供了一个安全网。你更频繁地检查错误，因此输出的应该是更高的质量——所以处理恰当的话，它不应该中断这么多。你可以更快地推出更新的功能，同时还能够降低高故障点。”
自动化在开发和测试中的日益普及也有助于减轻故障发生的可能性。正如Elliott所说：“如今的大多数故障仍然与人为因素有关——错误代码，导致中断的网络配置，负载均衡不良。这个东西真的很复杂，而且错误在所难免。但是随着自动化的到来，应该减少人为的错误，特别是在脚本和应用程序部署和网络方面。”
组织层次的变化也有助于降低风险。各单位的高管有望携手合作、快速前进、迅速调整;事实上，根据分析师和顾问的说法，领先的组织能顾及更多的自主权来修正路线以实现这种文化。
Stanger说：“今天人们更愿意说，‘让我们随着进展重新定义它。’这是今天与20年前相比最大的变化之一。”
McMasters说，他试图通过更多地关注一个项目应该实现的目标来管理失败的风险。他采用devops原则将工作分解成更小的部分，在这里问题可以更快地浮出水面，并在思路可以安全地回火的地方运行试点项目(从而允许创新而不会对业务产生重大影响)。
他还认为“强大的项目管理运动已经通过IT”，以帮助减轻IT部门以及其它部门的失败风险。他表示，这项运动有助于技术领导者及其业务部门的同僚更好地阐明项目应该完成的工作——以及项目不该完成的工作。这将成功的定义从按时按预算标准转变为业务目标的实现。
作为工具快速失败
同时，关于企业失败的观念转移有助于重塑组织对风险的态度。Elliott说：“现在失败没关系，只要你从中汲取教训。有些公司真的很感激失败，只要事情越来越往好的方面发展，人们从失败中汲取教训并变得越来越聪明，他们知道什么该做什么不该做。”
当然，Elliott和其他人指出，那些更加不忌讳失败的组织也会努力减轻风险，使用沙盒环境和试点项目以及迭代开发，以限制因某些事情的发生可能导致的损失量。McMasters说：“他们正在减轻最终出大事的风险。”
韦斯特蒙特学院(Westmont College)的副校长和首席信息官Reed A. Sheard见证了这种文化转型是如何取得积极成果的。他说他和其他首席信息官都明白并不是所有的项目都是平等的; 每个人在成功时都会带来不同的潜力，如果失败，则带来不同程度的后果。考虑到这一点，他说：“我们要对可以失败和不可以失败的地方作出判断。”
他列举了最近的两个举措来说明他的观点。第一个举措突出了实施一个管理学校入学过程的新平台，这是一个关键任务，因为不符合用户要求和具体期限将是毁灭性的，因为入学是组织的核心职能之一。Sheard表示，他积极参与项目，评估进度和资源。它于2015年7月成功上线。
第二个举措集中在一个允许校友网络虚拟化的平台的提供。Sheard说，他的团队试图建立一个安全的、用户友好的平台，但最终无法实现这些目标。工作人员努力保护系统，验证用户和并用正确的信息填充用户资料。
他说他对该项目的失败很坦然，因为他们在尝试中学到很多东西。“我们因经历了一些失败而成为专家。所以我能很轻松地从为期两年的工作脱身，因为我们在平衡安全性和可用性方面超级精明。”他补充说，他的团队使用新发现的知识与供应商合作，最终提供一流的产品。
其他人将这种心态——愿意失败的心态——看作想要创新并保持竞争力的组织的关键组成部分。
宾夕法尼亚州拉德纳镇的WGroup是一家帮助企业优化业务绩效并创造价值的公司，他的负责人Terry Coull表示：“如果你不断学习并不断改进，那么你可能会不断失败。对于那些在这个连续体中的事物，这意味着你正在调整、适应、你是灵活的——所以你在小团队工作和交付。所以你的项目失败并不像以前那么大。在旧的瀑布式世界里，你可能会失去一年，然后才发现失败。”
失败的风险依然存在
这些最新的企业文化趋势和IT方法当然不能保证成功，也不能完全防范项目失败。其实有些人说现代IT商店里有些元素甚至会加剧可能导致项目被取消的问题的可能性。
有一位专家指出了敏捷和devops方法的潜在问题。波士顿大学凯斯特罗姆商学院商学院(Questrom School of Business)的信息系统教授兼校长Marshall Van Alstyne说：“你解决了较小的问题，但是随后你[建立]这些大型的综合系统，其中大规模的问题在你达到规模之前是不可见的。。
他说，例如使用这些迭代方法的IT团队可能会发现，他们的新的软件特性和功能在每一个步骤中都可以工作，但是随后发现应用程序在完全部署后整体运行不正常。他补充说：“在某种意义上说，你所做的是将系统升级到一个程度，在这里系统将在更高一层出故障”，他补充说，将这个情景与医生“治愈”一个病人的个别症状进行比较，不能治疗较大的病症将引发所有的症状。
同时，业务部门和IT部门之间的筒仓可能会增加项目失败的风险，因为业务部门主管接受了技术并试图将最新和最牛的技术资本化，无论他们是否充分了解或彻底审查了他们的选择。
美国普华永道的首席技术官兼首席技术专家Chris Curran说：考虑到越来越多的技术支出来自业务部门的预算，而不是IT的资金。他指出普华永道的2015年全球数字智商调查显示，技术支出的68%超出IT预算。
他指出：“这鼓励了领导人尽快做出重要的事情并尽可能专注，他们会外出并参与SaaS和第三方供应商和云端。云端和SaaS既增加了速度，又获得了新技术，同时也为项目失败做出了贡献。[业务领导者]直接外出参与这些产品，但后来意识到他们需要访问企业数据或企业IT基础设施的其它部分，他们不知道他们需要这些，所以项目被停滞或委派或取消或重新定义范围。”
他指出，普华永道在过去三年的其它调查中也发现，引发项目失败的第一个原因是“僵化或缓慢的过程”。其他主要原因是缺乏技术型团队和第三方的问题。
此外，虽然IT基础架构，特别是硬件上的基础架构的改进有助于降低灾难性故障的风险，但仍然存在老旧的工具、技术债务和手动流程，在这里当项目上线时，小而大的错误可能会导致大规模的故障。
Elliott说：“风险依然存在。”他解释说即使一个新的应用程序运行正常，其被引进大环境时其新老技术形成的复杂网络可能会导致问题。“应用程序在网络上运行，并且它们是全球性的，它们往往运行在其他人的设备上。如果故障可以发生的话会有很多层次。”
最后，重要的是要记住，无论涉及技术的项目失败的原因是什么，如果IT无法实现，IT可能会受到责备——无论是否公平。
Stanger说：“到最后关头背黑锅的往往是IT，这就是为什么IT必须非常小心。”
