Los grandes proyectos de software siguen fracasando incluso después de invertir billones de dólares
(spectrum.ieee.org)- Aunque el gasto mundial en TI se ha más que triplicado desde 2005, la tasa de éxito de los grandes proyectos de software casi no ha mejorado
- En casos como el sistema de nómina Phoenix de Canadá, Post Office Horizon en el Reino Unido y sistemas de bienestar y administración en EE. UU. y Australia, se repiten fallas de gestión, organizacionales y éticas
- Las herramientas de IA o copilots no pueden resolver estos problemas; la falta de imaginación humana, los objetivos poco realistas y la mala gestión de riesgos siguen siendo las causas principales
- El costo de mantener sistemas legacy representa entre el 70% y el 75% del presupuesto de TI, y la adopción de Agile y DevOps también tiene altas tasas de fracaso sin liderazgo organizacional ni cambios culturales
- Los repetidos errores de gestión y la evasión de responsabilidades elevan el costo social, y se plantea como tarea esencial la transparencia, la ética y el diseño de sistemas centrado en las personas
El problema persistente del fracaso del software
- En los últimos 20 años, el gasto en TI aumentó de 1.7 billones de dólares a 5.6 billones, pero la tasa de éxito del software sigue estancada
- Los fracasos ocurren sin importar el país, la industria o el tipo de organización
- El costo social y económico de estos fracasos sigue aumentando
- Se señala explícitamente la limitación de la IA para resolver problemas de gestión
- A la IA le resulta difícil controlar los intereses complejos y los factores políticos de los grandes proyectos
- En los proyectos de TI ya abundan las decisiones irracionales, por lo que hay pocos casos adecuados para que la IA aprenda
- Las causas del fracaso incluyen falta de imaginación humana, objetivos poco claros, mala gestión de la complejidad y ausencia de control de riesgos
- Durante décadas se han repetido los mismos factores, manteniendo un fenómeno de “déjà vu del fracaso”
El sistema de nómina Phoenix de Canadá
- El sistema Phoenix, puesto en marcha en 2016 con un costo de CA$310 millones, fracasó al intentar integrar 80,000 reglas salariales y 105 convenios sindicales
- Para ahorrar presupuesto, se aplicaron procedimientos forzados como reducir pruebas y pilotos y eliminar funciones clave
- Como resultado, durante 9 años, el 70% de 430,000 empleados sufrió errores de pago
- A marzo de 2025, 349,000 errores seguían sin resolverse, y más de la mitad llevaba más de un año de retraso
- Incluso se han reportado casos de suicidio de empleados
- El costo total supera los CA$5,100 millones, y la auditoría lo calificó como “un fracaso incomprensible de gestión y supervisión del proyecto”
El sistema Post Office Horizon del Reino Unido
- El sistema POS Horizon de Fujitsu, introducido en 1999, ocultó errores internos y llevó a procesar a 3,500 encargados de sucursal por contabilidad falsa y fraude
- 900 fueron condenados, 236 encarcelados y más de 13 se suicidaron
- Aquí se combinaron fallas técnicas, de gestión, legales y éticas
- Middleware con muchos bugs, expansión del alcance sin control, falta de pruebas y personal insuficiente
- La dirección adoptó una actitud hostil hacia quienes señalaban problemas, ocultó evidencia e intentó un encubrimiento organizacional
- Los intentos de reemplazo en 2016 y 2021 también fracasaron, y Horizon sigue en uso
- El nuevo sistema tiene un presupuesto de £410 millones, con decisión prevista para julio de 2026
Otros grandes casos de fracaso
- Minnesota MNLARS: iniciado en 2016, cancelado en 2019, costo de $100 millones
- Modernising Business Registers de Australia: el presupuesto pasó de AU$480 millones a AU$2,800 millones, y se canceló en 2022
- Sistema de registro vehicular de Luisiana: fallas repetidas en un mainframe de 50 años llevaron a declarar emergencia en 2025
- Jaguar Land Rover: un ciberataque en 2025 detuvo operaciones globales por más de un mes, con pérdidas de entre $1,200 y $1,900 millones
- ERP de Lidl: tras fracasar el ERP basado en SAP por €500 millones, la empresa volvió a su sistema propio (2017)
- Boeing 737 Max: un defecto de diseño en MCAS causó 346 muertes; el costo total se estima en $74,000 millones
- Actualización F-35 Block 4: el cronograma lleva 5 años de retraso y el costo subió de $10,500 millones a $16,500 millones
El costo económico del fracaso
- En EE. UU., el costo de los fracasos de software en 2022 fue de $1.81 billones, con $260,000 millones por desarrollos fallidos
- El total es mayor que el presupuesto de defensa ($778,000 millones)
- El mantenimiento anual de sistemas legacy cuesta $520,000 millones y representa entre el 70% y el 75% del presupuesto de TI
- Como el reemplazo es caro y riesgoso, suele postergarse
- Informe 2024 de NTT DATA: el 80% de las organizaciones respondió que la tecnología obsoleta frena la innovación
- La mayoría de los ejecutivos reconoce que la infraestructura legacy dificulta responder al mercado
Los límites de Agile y DevOps
- A pesar de la expansión del desarrollo iterativo e incremental, la tasa de fracaso sigue ahí
- Algunos reportes mencionan tasas de fracaso de hasta 65% en proyectos Agile y 90% en DevOps
- Para una implementación exitosa se requieren liderazgo, disciplina organizacional, capacitación y cambio cultural
- Sin embargo, la mayoría de las organizaciones no logra sostener esto
Errores de gestión que se repiten y falta de aprendizaje
- Los gerentes de proyectos de TI suelen ignorar las lecciones de fracasos anteriores diciendo: “nuestro proyecto es diferente”
- El gobierno canadiense repitió en Phoenix las lecciones ignoradas del primer fracaso de su sistema de nómina en 1995
- La mayoría de los fracasos proviene de errores de gestión comunes, más que de intentos verdaderamente innovadores
- Se parece menos a una “destrucción creativa” y más a una “destrucción financiera”
- Casos de fracaso en sistemas administrativos basados en IA
- El sistema de subsidios por desempleo MiDAS en EE. UU. y Centrelink Robodebt en Australia procesaron injustamente a cientos de miles de personas por algoritmos erróneos
- Los gobiernos mostraron poca disposición a reconocer errores y compensar a las víctimas
La necesidad de responsabilidad, ética y transparencia
- La toma de decisiones opaca en sistemas con IA incorporada genera preocupación por posibles vulneraciones a los derechos de la ciudadanía
- La UE garantiza legalmente el “derecho a una explicación sobre decisiones algorítmicas”
- A nivel global, se plantea la necesidad de establecer la transparencia y la rendición de cuentas de los sistemas automatizados como un derecho humano
- Existen debates sobre leyes de responsabilidad del software y licencias profesionales, pero su viabilidad es baja
- La alternativa más realista es reforzar la honestidad de la dirección, el pensamiento escéptico y el juicio ético
- Es necesario reconocer claramente los riesgos y desconfiar de las promesas exageradas de los proveedores
- Se enfatiza aplicar principios de diseño centrado en las personas a todos los sistemas de TI, incluida la IA
Conclusión: detener los mismos errores repetidos
- El desarrollo de software es inherentemente complejo y frágil, y pequeños errores pueden producir grandes consecuencias
- Para que un proyecto tenga éxito, son indispensables recursos suficientes, liderazgo y rendición de cuentas
- Es necesario calcular los costos considerando también el daño emocional y económico que sufren los usuarios
- Han pasado más de 50 años desde la “crisis del software” de 1968, y seguimos repitiendo los mismos errores
- “Cometan errores nuevos”
“Cualquiera puede equivocarse, pero solo un necio persiste en su error” - el orador romano Cicerón
5 comentarios
Opinión de Hacker News
Sentí que la solución propuesta al final del texto se quedaba corta
Para mí, la verdadera solución es empezar en pequeño y validar en un entorno operativo real
Por ejemplo, si vas a construir un sistema nacional de nómina, primero deberías probarlo en un pueblo pequeño de 50 personas, corregir los errores y luego expandirlo gradualmente a ciudades más grandes
No existe un proceso de desarrollo de software en el que se resuelvan los problemas a escala nacional de una sola vez sin haberlos resuelto antes en una escala pequeña
El volumen de transacciones era bajo, así que si surgían problemas se podían ajustar manualmente, y además podíamos evitar las regulaciones PCI
Gracias a que probamos de esa manera antes del despliegue en tiendas reales, llegamos a la fecha límite sin incidentes graves
Si lo hubiéramos desplegado desde el inicio en tiendas con clientes, errores en el cálculo de impuestos o problemas de rendimiento habrían causado un caos enorme
La expansión gradual termina acumulando deuda técnica y, con el tiempo, nadie confía realmente en el núcleo del codebase, así que aparece el miedo a reescribirlo
Incluso en un producto simple como WhatsApp, hace falta un diseño de ingeniería pensado desde el inicio para la escalabilidad a gran escala
En los sistemas pequeños y exitosos es más fácil que aparezca alguien así, y eso permite crecer gradualmente ganando la confianza tanto de usuarios como de desarrolladores
Como los proyectos grandes tienen una alta probabilidad de fracasar, hay que empezar en pequeño siguiendo el Principio de Precaución (Precautionary Principle)
Ese ciclo iterativo es la base de cualquier proyecto
Hay que empezar en pequeño y modularizar antes de escalar. El caso de la megafábrica de Tesla me pareció impresionante
Estudiando la historia de la tecnología, lo que he notado es que la industria del hardware aprende de sus éxitos y fracasos pasados, pero la industria del software no
La mayoría de los desarrolladores no aprende desarmando sistemas antiguos, y cada generación vuelve a pasar por los mismos problemas
En las retrospectivas siempre preguntan “qué deberían hacer distinto los desarrolladores la próxima vez”, y los gerentes nunca asumen responsabilidad alguna
Al final se repiten los mismos problemas y la carga recae sobre los desarrolladores
Las generaciones pasadas resolvían problemas en la parte baja del stack, pero ahora se intenta resolver todo desde arriba
Como resultado, se acumula una torre de abstracciones, se consumen más recursos y aun así se obtiene una funcionalidad similar
Ahora además estamos entrando en una era donde se añade otra capa de software encima de los modelos de IA
Importan tanto la experiencia como la personalidad, y es indispensable tener bajo ego y una mentalidad centrada en resolver problemas
La mayoría subestima la complejidad de los proyectos
En la maestría pasé una semana leyendo el código fuente de TinyOS para entender su estructura, y esa experiencia me ayudó muchísimo
La capacidad de entender rápido un codebase desconocido es muy valiosa
Si periódicamente aparecen nuevos lenguajes o frameworks, las empresas pueden seguir contratando personal junior de bajo salario
Creo que esa es una de las razones por las que el software no se trata como otras ramas de la ingeniería
En el fondo, esto no es un problema de programación sino de incompetencia gerencial
En la mayoría de los proyectos, los requisitos de negocio no están claramente definidos y todo avanza a partir de suposiciones
El fracaso de los grandes proyectos públicos de TI se entiende al mirar la estructura contractual y los incentivos
El problema es una estructura que depende más de consultoría facturada por horas que de capacidad real
En los proyectos exitosos, más que la tecnología importan la alineación (alignment) entre organizaciones y la competencia (competence)
Creo que la discriminación por edad en Silicon Valley es un problema real
Se ignora la experiencia y no se incorporan en absoluto las lecciones del pasado
La industria del hardware buscó innovar sin dejar de respetar su legado
También existe la idea de que quien aprendió de los fracasos del pasado ya no puede intentar cosas nuevas
Los proyectos de software al final fracasan por fallas humanas
Más importante que un proceso o herramienta perfecta es contar con personas motivadas y con sentido de responsabilidad
Debe haber consecuencias (Consequences) legales para que la gente haga bien su trabajo
Igual que en la construcción física, cada etapa debería tener verificación independiente y responsables claros
Por eso, en la práctica, lo razonable es avanzar aceptando cierto nivel de riesgo
Los proyectos exitosos salieron adelante gracias a unas cuantas personas con inteligencia emocional y liderazgo
En última instancia, la ingeniería de software es un problema humano
Pero la industria sigue atrapada en evadir responsabilidades y perseguir modas
Este problema no es exclusivo del software
Grandes proyectos de obra civil como Auburn Dam, Columbia River Crossing y Big Dig también son tristemente famosos por sus sobrecostos
Si el presupuesto inicial era irreal, entonces tal vez solo se ajustó al costo real
Por eso es importante el enfoque de empezar con proyectos pequeños y escalar gradualmente
No soy desarrollador ni PM, pero me daban curiosidad los casos de éxito a gran escala
Como trabajo en un hospital, mejor aún si fueran casos exitosos relacionados con salud
Leí The Phoenix Project y entendí un poco la mentalidad de Agile y DevOps, pero me cuesta aplicarla en la práctica
Quiero sembrar las semillas del éxito en proyectos pequeños
Surgieron como una reflexión frente a la complejidad de Multics, y empezaron cuando Ken Thompson escribió Unix él mismo en tres semanas
Ver este texto relacionado
La ley de Conway, el riesgo de depender de personas clave, la propiedad clara y una cultura de pruebas también son fundamentales
Sobre todo, hace falta el valor de decir “no”
También hay casos como healthcare.gov, que mejoró después del fracaso inicial
Antes de culpar a la comunidad de TI, hay que mirar la cultura empresarial centrada en ganancias de corto plazo
La seguridad y la estabilidad siempre son las primeras en sufrir recortes presupuestales
Los ejecutivos fracasan y aun así se van con paracaídas de oro, mientras que la responsabilidad se queda con los desarrolladores
El gobierno tampoco castiga adecuadamente los incidentes de seguridad por negligencia corporativa
Al final se repite la realidad cínica de querer resolver todo con IA, consultores y outsourcing
Aunque se inviertan billones en IA, la situación no va a mejorar; más bien va a empeorar
Las sociedades occidentales ya están inestables y girando hacia la extrema derecha
La próxima crisis podría no ser solo un colapso financiero, sino un colapso social
La humanidad debería avanzar hacia el progreso mediante la comprensión, no mediante crisis
Si tienes buenos procesos, amplifica los resultados; si tienes malos procesos, acelera los problemas
Al final, la dirección es la misma: solo cambia la velocidad
Si después de tanto tiempo esto no se ha corregido, ¿no será que más que un problema de las técnicas o principios de desarrollo, es un problema del lado de operaciones que lo tiene que adoptar...?
El escándalo de la oficina postal británica también tiene una serie dramática.
Hasta ahora, las víctimas todavía no han sido indemnizadas, así que el caso sigue en curso.
Un caso reciente en Corea que se me viene a la mente es el fracaso en la implementación del sistema informático de próxima generación de Gyeonggi Credit Guarantee Foundation.
https://v.daum.net/v/20251111165048155
¿En otros países también llevan a cabo proyectos de SI enormes?