Los gerentes de TI fallan estrepitosamente en proyectos de software: dos décadas cometiendo los mismos errores

La pregunta del presidente de la KGB Charkov al químico inorgánico Valery Legasov en la miniserie «Chernobyl» de HBO —»¿Por qué preocuparse por algo que no va a pasar?»— sirve como epitafio perfecto para los cientos de fallos en desarrollo de software, modernización y operaciones que se han documentado desde 2005. Como se señaló entonces, y sigue siendo cierto dos décadas después: los fallos del software son universalmente imparciales. Ocurren en todos los países, a empresas grandes y pequeñas. Suceden en organizaciones comerciales, sin fines de lucro y gubernamentales, independientemente de su estatus o reputación.

El gasto global se triplicó, pero los fracasos persisten

El gasto mundial en TI se ha más que triplicado en dólares constantes de 2025 desde 2005, pasando de $1.7 billones a $5.6 billones, y continúa aumentando. A pesar del gasto adicional, las tasas de éxito del software no han mejorado notablemente en las últimas dos décadas. El resultado es que los costos comerciales y sociales del fracaso continúan creciendo a medida que el software prolifera, permeando e interconectando todos los aspectos de nuestras vidas.

Para aquellos que esperan que las herramientas de software de IA y los copilots de codificación hagan que los proyectos de software de TI a gran escala sean exitosos rápidamente: olvídenlo. En el futuro previsible, existen límites duros sobre lo que la IA puede aportar para controlar y gestionar las miles de intersecciones e intercambios entre ingeniería de sistemas, gestión de proyectos, financiera y comercial, y especialmente la política organizacional involucrada en cualquier proyecto de software a gran escala. Como saben los profesionales del software, los proyectos de TI ya sufren suficientes alucinaciones y delirios gerenciales sin que la IA agregue más.

Los mismos errores una y otra vez

Los conductores de fallas de software frecuentemente son fallas de la imaginación humana, objetivos de proyecto poco realistas o no articulados, la incapacidad de manejar la complejidad del proyecto, o riesgos no gestionados. Numerosos otros factores se remontan a décadas atrás, como los identificados por Stephen Andriole, director de tecnología empresarial en la Escuela de Negocios de la Universidad de Villanova, en un diagrama publicado inicialmente en Forbes en 2021. Descubrir una falla del sistema de software que se haya salido de control de una manera única y previamente no documentada sería sorprendente, porque la abrumadora mayoría de fallas relacionadas con software involucran factores evitables e inductores de fallas conocidos documentados durante décadas en cientos de informes post-mortem, estudios académicos y libros técnicos y de gestión. El déjà vu del fracaso domina la literatura.

La pregunta es: ¿por qué no hemos aplicado lo que repetidamente nos hemos visto obligados a aprender?

El caso Phoenix: cuando el software se vuelve radiactivo

Muchos de los desarrollos de TI y fallas operacionales analizados en los últimos 20 años han tenido cada uno sus propias fusiones tipo Chernobyl, esparciendo radiación reputacional por todas partes y contaminando las vidas de los afectados durante años. Cada uno tiene típicamente una historia que desafía la credulidad.

Un ejemplo principal es el sistema de nóminas Phoenix del gobierno canadiense de CA $310 millones, que se puso en línea en abril de 2016 y poco después se volvió supercrítico. Los ejecutivos del proyecto Phoenix creían que podían entregar un sistema de pago modernizado, personalizando el paquete de nóminas estándar PeopleSoft para seguir 80,000 reglas de pago que abarcaban 105 acuerdos colectivos con sindicatos del servicio público federal. También intentaban implementar 34 interfaces de sistemas de recursos humanos a través de 101 agencias y departamentos gubernamentales requeridos para compartir datos de empleados. Además, el equipo de desarrollo del gobierno pensó que podían lograr esto por menos del 60 por ciento del presupuesto propuesto por el proveedor. Ahorrarían eliminando o aplazando funciones críticas de nómina, reduciendo las pruebas del sistema y de integración, disminuyendo el número de contratistas y personal gubernamental trabajando en el proyecto, y prescindiendo de pruebas piloto vitales, junto con una serie de otras propuestas excesivamente optimistas.

El colapso de nómina de Phoenix estaba predestinado. Como resultado, durante los últimos nueve años, alrededor del 70 por ciento de los 430,000 empleados actuales y anteriores del gobierno federal canadiense pagados a través de Phoenix han soportado errores en sus cheques de pago. Incluso tan recientemente como en el año fiscal 2023-2024, un tercio de todos los empleados experimentaron errores en sus cheques. El estrés financiero continuo y las ansiedades para miles de empleados y sus familias han sido inconmensurables. Los problemas recurrentes de cheques de pago no solo están minando la moral de los trabajadores, sino que en al menos un caso documentado, un forense culpó al suicidio de una empleada a la insoportable tensión financiera y emocional que sufrió.

Para finales de marzo de 2025, cuando el gobierno canadiense había prometido que el atraso de errores de Phoenix finalmente se resolvería, más de 349,000 casos seguían sin resolver, con el 53 por ciento pendientes por más de un año. En junio, el gobierno canadiense se comprometió una vez más a reducir significativamente el atraso, esta vez para junio de 2026. Dadas las promesas anteriores, el escepticismo está justificado.

Los costos financieros para los contribuyentes canadienses relacionados con los problemas de Phoenix han ascendido hasta ahora a más de CA $5.1 mil millones (US $3.6 mil millones). Tomará años calcular el costo final del fiasco. El gobierno gastó al menos CA $100 millones (US $71 millones) antes de decidirse por un reemplazo de Phoenix, que el gobierno reconoce costará varios cientos de millones de dólares más y tomará años implementar. Los informes de auditoría del fallecido Auditor General canadiense Michael Ferguson para el fiasco de Phoenix describieron el esfuerzo como un «fracaso incomprensible de gestión de proyectos y supervisión».

Si bien puede ser un desastre de gestión de proyectos y supervisión, Phoenix ciertamente no es un fracaso inconcebible. La comunidad de TI se ha esforzado enormemente durante décadas para hacer rutinario lo incomprensible.

El peor fracaso de TI de la historia

El fallo de Phoenix palidece en comparación con el peor fallo operacional de sistema de TI hasta la fecha: el sistema Horizon de punto de venta electrónico (EPOS) de la Oficina Postal del Reino Unido, proporcionado por Fujitsu. Lanzado en 1999, Horizon estaba plagado de errores internos de software que fueron deliberadamente ocultados, llevando a la Oficina Postal a acusar injustamente a 3,500 gerentes de sucursales postales locales de contabilidad falsa, fraude y robo.

Aproximadamente 900 de estos gerentes fueron condenados, con 236 encarcelados entre 1999 y 2015. Para entonces, el público en general y los propios gerentes de sucursales finalmente se unieron a los reporteros de Computer Weekly (quienes habían informado tenazmente sobre los problemas de Horizon desde 2008) en el conocimiento de que había algo seriamente mal con el software de Horizon. Luego tomó otra década de casos judiciales, una investigación pública estatutaria independiente, y una miniserie de ITV «Mr. Bates vs. The Post Office» para desentrañar cómo surgió el escándalo.

Como Phoenix, Horizon estuvo plagado de problemas que involucraron fallas técnicas, de gestión, organizacionales, legales y éticas. Por ejemplo, el software del sistema central de punto de venta se construyó sobre middleware de comunicación y transferencia de datos que en sí mismo tenía errores. Además, la funcionalidad de Horizon se descontroló bajo una expansión de alcance incesante y mal disciplinada. Hubo procesos de desarrollo y gestión de proyectos ineficaces o inexistentes, pruebas inadecuadas y falta de personal profesional, técnico y gerencial calificado.

El liderazgo superior de la Oficina Postal declaró repetidamente que el software Horizon era completamente confiable, volviéndose hostil hacia los administradores de correos que lo cuestionaban, lo que solo añadió al ambiente tóxico. Como resultado, el liderazgo invocó todos los medios legales a su disposición y elaboró un encubrimiento de clase mundial, incluyendo la supresión activa de información exculpatoria, para que la Oficina Postal pudiera procesar agresivamente a los administradores de correos e intentar aplastar cualquier disidencia que cuestionara la integridad de Horizon.

Escandalosamente, los acusados falsamente aún tienen que continuar luchando para recibir compensación justa por sus vidas arruinadas. Casi 350 de los acusados murieron, al menos 13 de los cuales se cree que fueron por suicidio, antes de recibir cualquier pago por las injusticias experimentadas. Desafortunadamente, como los intentos de reemplazar Horizon en 2016 y 2021 fracasaron, la Oficina Postal continúa usándolo, al menos por ahora. El gobierno quiere gastar £410 millones en un nuevo sistema, pero es una apuesta segura que implementarlo costará mucho, mucho más. La Oficina Postal aceptó ofertas para un nuevo sistema de software de punto de venta en el verano de 2025, con una decisión esperada para el 1 de julio de 2026.

Los costos de oportunidad siguen acumulándose

Al sur de la frontera canadiense, Estados Unidos también ha visto que el costo general de fallas de desarrollo y operacionales relacionadas con TI desde 2005 ha aumentado al rango de múltiples billones de dólares, potencialmente superando los $10 billones. Un informe del Consorcio para la Calidad de Información y Software (CISQ) estimó que el costo anual de fallas operacionales de software solo en Estados Unidos en 2022 fue de $1.81 billones, con otros $260 mil millones gastados en fallas de desarrollo de software. Es más grande que el presupuesto total de defensa de Estados Unidos para ese año, que fue de $778 mil millones.

La pregunta es: ¿por qué no hemos aplicado lo que repetidamente nos hemos visto obligados a aprender?

Qué porcentaje de proyectos de software fracasan, y qué significa el fracaso, ha sido un debate continuo dentro de la comunidad de TI que se remonta a décadas. Sin profundizar en el debate, está claro que el desarrollo de software sigue siendo uno de los emprendimientos tecnológicos más riesgosos a realizar. De hecho, según Bent Flyvbjerg, profesor emérito de la Escuela de Negocios Saїd de la Universidad de Oxford, los datos exhaustivos muestran que no solo los proyectos de TI son riesgosos, sino que son los más riesgosos desde una perspectiva de costos.

El informe del CISQ estima que las organizaciones en Estados Unidos gastan más de $520 mil millones anualmente manteniendo sistemas de software heredados, con el 70 al 75 por ciento de los presupuestos de TI organizacionales dedicados al mantenimiento heredado. Un informe de 2024 de la empresa de servicios NTT DATA encontró que el 80 por ciento de las organizaciones conceden que «la tecnología inadecuada u obsoleta está frenando el progreso organizacional y los esfuerzos de innovación». Además, el informe indica que prácticamente todos los ejecutivos de nivel C creen que la infraestructura heredada frustra su capacidad de responder al mercado. Aun así, dado que el costo de reemplazar los sistemas heredados es típicamente muchos múltiplos del costo de mantenerlos, los ejecutivos de negocios dudan en reemplazarlos hasta que ya no sea operacionalmente factible o rentable. La otra razón es un temor bien fundado de que reemplazarlos se convertirá en un desastre como Phoenix u otros.

Ejemplos recientes de fracasos costosos

Sistema de Registro y Licencias de Minnesota (MNLARS, 2019): El esfuerzo planificado de $41 millones se lanzó en 2016 y luego se canceló en 2019 después de un costo total de $100 millones. Se consideró demasiado difícil de arreglar.

Programa de Modernización de Registros Comerciales de Australia (2022): El programa planificado de AU $480.5 millones para modernizar los sistemas de registro comercial se canceló. Después de gastar AU $530 millones, una revisión encontró que el costo proyectado había aumentado a AU $2.8 mil millones, y el proyecto tomaría cinco años más para completarse.

Sistema de Vehículos Motorizados de Louisiana (2025): El gobernador de Louisiana ordenó un estado de emergencia por fallas repetidas del sistema de computadora mainframe de la Oficina de Vehículos Motorizados de 50 años de antigüedad. El estado promete una adquisición expedita de un nuevo sistema de TI, que podría estar disponible para principios de 2028.

Jaguar Land Rover (2025): Un ciberataque obligó a Jaguar Land Rover, el mayor fabricante de automóviles de Gran Bretaña, a cerrar sus operaciones globales por más de un mes. Una evaluación inicial FAIR-MAM, un modelo de costos de ciberseguridad, estima la pérdida para Jaguar Land Rover entre $1.2 mil millones y $1.9 mil millones (£911 millones y £1.4 mil millones), lo que ha afectado a sus 33,000 empleados y a unos 200,000 empleados de sus proveedores.

Cadena de supermercados Lidl ERP (2017): La cadena de supermercados internacional Lidl decidió revertir a su sistema heredado de gestión de mercancías desarrollado internamente después de tres años de intentar hacer funcionar correctamente el sistema de planificación de recursos empresariales (ERP) de SAP de €500 millones.

Boeing 737 Max (2018): Boeing agregó un Sistema de Aumento de Características de Maniobra (MCAS) mal diseñado y descrito al nuevo modelo 737 Max, creando problemas de seguridad que llevaron a dos accidentes aéreos fatales que mataron a 346 pasajeros y tripulantes y el aterrizaje forzoso de la flota durante unos 20 meses. El costo total para Boeing se estima en $14 mil millones en costos directos y $60 mil millones en costos indirectos.

Cazas F-35 (2025): Los problemas de software y hardware con la actualización Block 4 del F-35 continúan sin cesar. El programa de actualización Block 4 que comenzó en 2018, y está destinado a aumentar la letalidad de los aviones JSF, se ha retrasado hasta 2031 como mínimo desde 2026, con costos aumentando de $10.5 mil millones a un mínimo de $16.5 mil millones. Tomará años más desplegar la capacidad a la flota F-35.

Por qué persisten las fallas

La frustante y perpetua pregunta es por qué los errores básicos de gestión de proyectos de TI y gobernanza durante el desarrollo y operaciones de software continúan ocurriendo tan frecuentemente, dada la dependencia social casi total en software confiable y una historia extensamente documentada de fallas. Junto a la infraestructura eléctrica, con la cual TI se está fusionando cada vez más en una relación mutuamente codependiente, el fallo de nuestros sistemas informáticos es una amenaza existencial para la sociedad moderna.

Frustrantemente, la comunidad de TI obstinadamente falla en aprender de fracasos anteriores. Los gerentes de proyectos de TI rutinariamente afirman que su proyecto es de alguna manera diferente o único y, por lo tanto, las lecciones de fallas anteriores son irrelevantes. Esa es la excusa de los arrogantes, aunque generalmente no de los ignorantes. En el caso de Phoenix, por ejemplo, fue el segundo intento de reemplazo del sistema de nómina del gobierno, el primer esfuerzo terminó en fracaso en 1995. Los gerentes del proyecto Phoenix ignoraron las razones bien documentadas del primer fracaso porque afirmaron que sus lecciones no eran aplicables, lo que no impidió que los gerentes las repitieran. Como se ha dicho, aprendemos más del fracaso que del éxito, pero los fracasos repetidos son terriblemente caros.

No todas las fallas de desarrollo de software son malas; algunos fracasos incluso son deseados. Al empujar los límites del desarrollo de nuevos tipos de productos, tecnologías o prácticas de software, como está sucediendo con los esfuerzos relacionados con la IA, el fracaso potencial es una posibilidad aceptada. Con el fracaso, la experiencia aumenta, se obtienen nuevas percepciones, se hacen correcciones, las limitaciones se comprenden mejor, y la innovación tecnológica y el progreso continúan. Sin embargo, la mayoría de los fracasos de TI hoy no están relacionados con empujar las fronteras innovadoras del arte de la computación, sino los bordes de lo mundano. No representan las «ventiscas de destrucción creativa» del economista austriaco Joseph Schumpeter. Son más como ventiscas de destrucción financiera. ¿Cuántos fracasos más de proyectos de planificación de recursos empresariales (ERP) se necesitan antes de que el éxito se vuelva rutinario? Tales fracasos deberían llamarse desatinos de TI, ya que aprender algo nuevo de ellos es dudoso en el mejor de los casos.

¿Fue Phoenix un fracaso o un desatino? Se argumenta fuertemente por lo último, pero como mínimo, Phoenix sirve como una clase magistral en mala gestión de proyectos de TI. La pregunta es si el gobierno canadiense aprendió de esta experiencia más de lo que aprendió del fiasco del proyecto de nómina de 1995. El gobierno mantiene que aprenderá, lo cual podría ser cierto, dado el alto perfil político del fracaso de Phoenix. ¿Pero se extenderán las lecciones de Phoenix a los miles de sistemas de TI obsoletos del gobierno canadiense que necesitan reemplazo o modernización? Con suerte, pero la esperanza no es una metodología, y será necesaria una acción decidida.

Repetir los mismos errores y esperar un resultado diferente no es aprender. Es una absurdidad farsesca. Parafraseando a Henry Petroski en su libro «To Engineer Is Human: The Role of Failure in Successful Design» (Vintage, 1992), podemos haber aprendido cómo calcular el fallo del software debido al riesgo, pero no hemos aprendido cómo calcular para eliminar el fallo de la mente. Hay una plétora de ejemplos de proyectos como Phoenix que fracasaron en parte debido a la gestión torpe, sin embargo, es extremadamente difícil encontrar proyectos de software gestionados profesionalmente que aún así fracasaron. Encontrar ejemplos de lo que podrían denominarse «fracasos heroicos de TI» es como Diógenes buscando un hombre honesto.

El futuro con IA: más de lo mismo

Las consecuencias de no aprender de los desatinos serán mucho mayores y más insidiosas a medida que la sociedad lidie con los efectos crecientes de la inteligencia artificial, o más exactamente, algoritmos «inteligentes» integrados en sistemas de software. Las pistas de lo que podría suceder si las lecciones pasadas no se tienen en cuenta se encuentran en los espectaculares fracasos tempranos de toma de decisiones automatizada del sistema de desempleo MiDAS de Michigan y el sistema de bienestar «Robodebt» de Centrelink de Australia. Ambos usaron algoritmos cuestionables para identificar reclamos de pago engañosos sin supervisión humana. Los funcionarios estatales usaron MiDAS para acusar a decenas de miles de habitantes de Michigan de fraude de desempleo, mientras que los funcionarios de Centrelink acusaron falsamente a cientos de miles de australianos de ser tramposos del bienestar. Innumerables vidas nunca volverán a ser las mismas debido a lo que ocurrió. Los funcionarios del gobierno en Michigan y Australia depositaron demasiada confianza en esos algoritmos. Tuvieron que ser arrastrados, pateando y gritando, a reconocer que algo andaba mal, incluso después de que se demostró claramente que el software no era confiable. Incluso entonces, los funcionarios intentaron minimizar el impacto de los errores en las personas, luego lucharon contra el pago de compensación a los afectados adversamente por los errores. Si bien tal comportamiento se denomina legalmente «mala administración», el mal administrativo está más cerca de la realidad.

Si este comportamiento ocurre en organizaciones gubernamentales, ¿alguien piensa que las empresas impulsadas por ganancias cuyos sistemas impulsados por IA van mal actuarán mejor? A medida que la IA se incrusta en más sistemas de TI, especialmente sistemas gubernamentales y la creciente infraestructura pública digital que como individuos no tenemos más remedio que usar, la opacidad de cómo estos sistemas toman decisiones hará más difícil desafiarlos. La Unión Europea ha otorgado a los individuos un «derecho a la explicación» legal cuando una decisión puramente algorítmica va en su contra. Es hora de que la transparencia y la rendición de cuentas con respecto a todos los sistemas automatizados se conviertan en un derecho humano fundamental y global.

Qué se necesita para reducir los errores

¿Qué se necesitará para reducir los desatinos de TI? No mucho ha funcionado con consistencia en los últimos 20 años. Los incentivos financieros para construir software defectuoso, la adicción de la industria de TI a la pornografía del fracaso, y la falta de responsabilidad por decisiones gerenciales imprudentes están profundamente arraigadas en la comunidad de TI. Algunos argumentan que es hora de leyes de responsabilidad de software, mientras que otros sostienen que es hora de que los profesionales de TI tengan licencia como todos los demás profesionales. Ninguno de los dos es probable que suceda pronto.

Entonces, solo nos queda una obligación profesional y personal de reenfatizar lo obvio: pregunta qué sabes, qué deberías saber, y cuán grande es la brecha entre ellos antes de embarcarse en la creación de un sistema de TI. Si nadie más ha construido exitosamente tu sistema con el cronograma, presupuesto y funcionalidad que pediste, por favor explica por qué tu organización piensa que puede. El software es inherentemente frágil; construir sistemas de software complejos, seguros y resilientes es difícil, detallado y consume tiempo. Los pequeños errores tienen efectos desproporcionados, cada uno con un número casi infinito de formas en que pueden manifestarse, desde causar un error funcional menor hasta una interrupción del sistema o permitir que una amenaza de ciberseguridad penetre el sistema. Cuanto más complejo e interconectado es el sistema, más oportunidades hay para errores y su explotación.

Un buen comienzo sería que la alta dirección que controla los recursos financieros finalmente trate los esfuerzos de desarrollo, operaciones y mantenimiento de software y sistemas con el respeto que merecen. Esto no solo significa proporcionar el personal, los recursos financieros, el apoyo y el compromiso del liderazgo, sino también la responsabilidad profesional y personal que demandan.

Es bien sabido que la honestidad, el escepticismo y la ética son esenciales para lograr el éxito del proyecto, sin embargo, a menudo están ausentes. Solo la alta dirección puede exigir que existan. Por ejemplo, la honestidad comienza con la contabilidad franca de la miríada de riesgos involucrados en cualquier emprendimiento de TI, no su racionalización. Es un «secreto» común que es mucho más fácil obtener financiamiento para arreglar un esfuerzo de desarrollo de software problemático que pedir lo que se requiere por adelantado para abordar los riesgos involucrados. La exageración de los proveedores también puede ser legal, pero eso significa que el cliente de TI necesita un escepticismo saludable de las promesas típicamente demasiado buenas para ser verdad que hacen los proveedores. Una vez que se firma el contrato, es demasiado tarde. Además, la maleabilidad, complejidad, velocidad, bajo costo y capacidad de reproducir y almacenar información de la computación se combinan para crear situaciones éticas que requieren una reflexión profunda sobre las consecuencias de la computación en individuos y la sociedad. Lamentablemente, las consideraciones éticas han retrasado rutinariamente cuando se trata de progreso tecnológico y ganancias. Esta práctica debe cambiar, especialmente a medida que la IA se inyecta rutinariamente en sistemas automatizados.

En la comunidad de IA, ha habido un movimiento hacia la idea de IA centrada en el ser humano, lo que significa sistemas de IA que priorizan las necesidades, valores y bienestar humanos. Esto significa intentar anticipar dónde y cuándo la IA puede salir mal, moverse para eliminar estas situaciones y construir formas de mitigar los efectos si suceden. Este concepto requiere aplicación a todos los esfuerzos de sistemas de TI, no solo a la IA.

Dado la falta histórica de determinación organizacional para inculcar prácticas probadas, los enfoques novedosos para desarrollar y mantener sistemas de software cada vez más complejos también frecuentemente se quedarán cortos.

Finalmente, las justificaciones de costo-beneficio de los desarrollos de software rara vez consideran la angustia financiera y emocional que se impone a los usuarios finales de los sistemas de TI cuando algo sale mal. Estos incluyen los efectos posteriores del fracaso a largo plazo. Si estos costos tuvieran que tenerse completamente en cuenta, como en los casos de Phoenix, MiDAS y Centrelink, quizás podría haber más realismo en lo que se requiere gerencialmente, financieramente, tecnológicamente y experiencialmente para crear un sistema de software exitoso.

Puede ser una solicitud desesperada, pero seguramente es hora de que la comunidad de TI deje de cometer repetidamente los mismos errores ridículos que ha cometido desde al menos 1968, cuando se acuñó el término «crisis del software». Comete nuevos, maldita sea. Como dijo el orador romano Cicerón en Filípica 12: «Cualquiera puede cometer un error, pero solo un idiota persiste en su error».