La causa estructural del fracaso de los proyectos de TI: la ignorancia gerencial recurrente y su costo

baeba · 2025-11-26T09:56:15+09:00

Resumen general: Tema central: El fracaso de los proyectos de TI no se origina en desafíos técnicos, sino en la 'ignorancia deliberada' de la gerencia y en la arrogancia de negarse a aprender de fracasos anteriores. Cifras clave: En los últimos 20 años, el gasto global en TI se triplicó (5.6 billones de dólares), pero la tasa de éxito sigue estancada, y el 75% del presupuesto se consume solo en el mantenimiento de sistemas legacy. Casos clave: La mala gestión integral del sistema Phoenix de Canadá y el encubrimiento antiético del caso Horizon en el Reino Unido no son simples 'errores (Blunder)', sino 'maldad administrativa (Administrative Evil)'. 1. Introducción: una tasa de fracaso que no mejora pese a la enorme inversión Estancamiento de la eficiencia frente a la inversión: Desde 2005, el gasto mundial en TI se disparó de 1.7 billones de dólares a 5.6 billones en 2025, más de tres veces. Sin embargo, a pesar del enorme gasto, la tasa de éxito de los proyectos de software no ha mostrado una mejora clara en los últimos 20 años. Cuidado con la ilusión en torno a la IA: Muchos ejecutivos esperan que las herramientas de IA o los asistentes de programación (Copilot) hagan exitosos los proyectos a gran escala, pero el autor se muestra escéptico al respecto. La IA no puede resolver la complejidad de la ingeniería de sistemas, los trade-offs financieros y, sobre todo, la 'política organizacional (Organizational Politics)' dentro de los proyectos. Un fenómeno de fracaso universal: Los fracasos de software ocurren indiscriminadamente sin importar país, tamaño de la empresa o si la organización es con fines de lucro o no, y esto se debe no a simples errores técnicos, sino a la 'falta de imaginación humana' y a 'objetivos poco realistas'. 2. Desarrollo: análisis profundo de los tipos y causas del fracaso 2.1. Los 'errores (Blunder)' que se repiten y el rechazo a aprender Diferencia entre fracaso y error: El fracaso como 'destrucción creativa (Creative Destruction)', cuando surge de desafiar límites técnicos, debe ser bienvenido. Pero la mayoría de los fracasos en TI no son más que 'errores tontos (Blunder)' que repiten causas ya documentadas durante décadas (ausencia de gestión de riesgos, subestimación de la complejidad, etc.). La arrogancia de la gerencia: Los gerentes de proyecto suelen afirmar que su proyecto es "especial y único", y tienden a ignorar los casos de fracaso previos y los datos históricos. No se trata de simple ignorancia, sino de 'ignorancia deliberada (Willful Ignorance)', es decir, de apartar la vista intencionalmente de las señales de riesgo. La trampa de los sistemas legacy: Las organizaciones en Estados Unidos gastan más de 520 mil millones de dólares al año solo en mantener sistemas legacy, lo que representa entre el 70% y el 75% del presupuesto total de TI. Por miedo a fracasar en el reemplazo, posponen la modernización hasta que el sistema colapsa físicamente (por ejemplo, el mainframe de la oficina de vehículos de Luisiana) o deja por completo de ser costo-efectivo. 2.2. Detalles de los principales casos de fracaso y sus efectos El sistema de nómina Phoenix de Canadá: Error de juicio inicial: Al adoptar una solución comercial existente (PeopleSoft), se intentó personalizarla para 80,000 reglas salariales y 105 convenios colectivos. El costo de recortar el presupuesto: Para ejecutar el proyecto con menos del 60% del presupuesto propuesto por el proveedor, se forzó la eliminación de funciones clave de nómina, la reducción de pruebas y la omisión de pruebas piloto esenciales. Resultado: Colapsó poco después de entrar en operación en 2016. Provocó sufrimiento financiero por pagos incorrectos a empleados (incluso se le señaló como causa de algunos suicidios). Costo: El presupuesto inicial era de 310 millones de dólares canadienses, pero el costo de recuperación y resolución ya supera los 5.1 mil millones de dólares canadienses (aproximadamente 3.6 mil millones de dólares estadounidenses). El escándalo Horizon del servicio postal del Reino Unido: Falla técnica: Un bug de middleware en el sistema provisto por Fujitsu generó errores de discrepancia monetaria. Encubrimiento organizacional: La gerencia sabía de los defectos del software, pero los ocultó y, en cambio, acusó a 3,500 encargados de oficinas postales de malversación y robo. 900 fueron condenados y encarcelados. Costo social: Hubo quiebras, divorcios, encarcelamientos y suicidios entre las víctimas. Quedó registrado como el peor fracaso de TI y error judicial en la historia del Reino Unido. 2.3. La toma de decisiones automatizada y la 'maldad administrativa' La violencia de los algoritmos: Los sistemas MiDAS de Michigan, Estados Unidos (detección de fraude en seguro de desempleo), y Robodebt de Australia (detección de fraude en beneficios sociales) emitieron decisiones apoyándose solo en algoritmos, sin supervisión humana. Decenas de miles de ciudadanos inocentes fueron tratados como criminales, pero los burócratas se negaron a compensarlos o eludieron su responsabilidad incluso después de demostrarse los errores del sistema. Los riesgos de adoptar IA: Esta 'maldad administrativa (Administrative Evil)' se agravará a medida que la IA se involucre más profundamente en la infraestructura pública. La UE introdujo el 'derecho a exigir una explicación', pero a nivel global urge establecer transparencia y responsabilidad sobre los algoritmos. 3. Conclusión: soluciones y tareas pendientes para la comunidad de TI Las metodologías (Agile/DevOps) no son una llave maestra: Como muestran informes que sitúan la tasa de fracaso de proyectos Agile hasta en 65%, la metodología por sí sola no garantiza el éxito. Sin liderazgo consistente ni disciplina organizacional, cualquier metodología nueva también fracasa. Evaluación honesta del riesgo y responsabilidad ética: Antes de iniciar un proyecto, debe realizarse un análisis honesto de brechas (Gap Analysis) sobre "qué sabemos y qué no sabemos". El concepto de 'IA centrada en las personas (Human-centered AI)' debe ampliarse a todos los proyectos de TI, incorporando al análisis costo-beneficio el daño emocional y financiero que una falla del sistema puede causar a los usuarios finales. Llamado a cambiar la actitud de la gerencia: El software es, por naturaleza, frágil (Fragile) y complejo. La gerencia debe respetar y apoyar el desarrollo de software no solo como quien controla el presupuesto, sino como quien asume la responsabilidad cuando ocurre un fracaso. Detener la repetición de los mismos errores es el único camino para que la industria de TI salga de la 'crisis (Crisis)'.

(spectrum.ieee.org)

3 puntos por baeba 2025-11-26 | 1 comentarios | Compartir por WhatsApp

Resumen general:
- Tema central: El fracaso de los proyectos de TI no se origina en desafíos técnicos, sino en la 'ignorancia deliberada' de la gerencia y en la arrogancia de negarse a aprender de fracasos anteriores.
- Cifras clave: En los últimos 20 años, el gasto global en TI se triplicó (5.6 billones de dólares), pero la tasa de éxito sigue estancada, y el 75% del presupuesto se consume solo en el mantenimiento de sistemas legacy.
- Casos clave: La mala gestión integral del sistema Phoenix de Canadá y el encubrimiento antiético del caso Horizon en el Reino Unido no son simples 'errores (Blunder)', sino 'maldad administrativa (Administrative Evil)'.

1. Introducción: una tasa de fracaso que no mejora pese a la enorme inversión

Estancamiento de la eficiencia frente a la inversión:
- Desde 2005, el gasto mundial en TI se disparó de 1.7 billones de dólares a 5.6 billones en 2025, más de tres veces.
- Sin embargo, a pesar del enorme gasto, la tasa de éxito de los proyectos de software no ha mostrado una mejora clara en los últimos 20 años.
Cuidado con la ilusión en torno a la IA:
- Muchos ejecutivos esperan que las herramientas de IA o los asistentes de programación (Copilot) hagan exitosos los proyectos a gran escala, pero el autor se muestra escéptico al respecto.
- La IA no puede resolver la complejidad de la ingeniería de sistemas, los trade-offs financieros y, sobre todo, la 'política organizacional (Organizational Politics)' dentro de los proyectos.
Un fenómeno de fracaso universal:
- Los fracasos de software ocurren indiscriminadamente sin importar país, tamaño de la empresa o si la organización es con fines de lucro o no, y esto se debe no a simples errores técnicos, sino a la 'falta de imaginación humana' y a 'objetivos poco realistas'.

2. Desarrollo: análisis profundo de los tipos y causas del fracaso

2.1. Los 'errores (Blunder)' que se repiten y el rechazo a aprender

Diferencia entre fracaso y error:
- El fracaso como 'destrucción creativa (Creative Destruction)', cuando surge de desafiar límites técnicos, debe ser bienvenido.
- Pero la mayoría de los fracasos en TI no son más que 'errores tontos (Blunder)' que repiten causas ya documentadas durante décadas (ausencia de gestión de riesgos, subestimación de la complejidad, etc.).
La arrogancia de la gerencia:
- Los gerentes de proyecto suelen afirmar que su proyecto es "especial y único", y tienden a ignorar los casos de fracaso previos y los datos históricos.
- No se trata de simple ignorancia, sino de 'ignorancia deliberada (Willful Ignorance)', es decir, de apartar la vista intencionalmente de las señales de riesgo.
La trampa de los sistemas legacy:
- Las organizaciones en Estados Unidos gastan más de 520 mil millones de dólares al año solo en mantener sistemas legacy, lo que representa entre el 70% y el 75% del presupuesto total de TI.
- Por miedo a fracasar en el reemplazo, posponen la modernización hasta que el sistema colapsa físicamente (por ejemplo, el mainframe de la oficina de vehículos de Luisiana) o deja por completo de ser costo-efectivo.

2.2. Detalles de los principales casos de fracaso y sus efectos

El sistema de nómina Phoenix de Canadá:
- Error de juicio inicial: Al adoptar una solución comercial existente (PeopleSoft), se intentó personalizarla para 80,000 reglas salariales y 105 convenios colectivos.
- El costo de recortar el presupuesto: Para ejecutar el proyecto con menos del 60% del presupuesto propuesto por el proveedor, se forzó la eliminación de funciones clave de nómina, la reducción de pruebas y la omisión de pruebas piloto esenciales.
- Resultado: Colapsó poco después de entrar en operación en 2016. Provocó sufrimiento financiero por pagos incorrectos a empleados (incluso se le señaló como causa de algunos suicidios).
- Costo: El presupuesto inicial era de 310 millones de dólares canadienses, pero el costo de recuperación y resolución ya supera los 5.1 mil millones de dólares canadienses (aproximadamente 3.6 mil millones de dólares estadounidenses).
El escándalo Horizon del servicio postal del Reino Unido:
- Falla técnica: Un bug de middleware en el sistema provisto por Fujitsu generó errores de discrepancia monetaria.
- Encubrimiento organizacional: La gerencia sabía de los defectos del software, pero los ocultó y, en cambio, acusó a 3,500 encargados de oficinas postales de malversación y robo. 900 fueron condenados y encarcelados.
- Costo social: Hubo quiebras, divorcios, encarcelamientos y suicidios entre las víctimas. Quedó registrado como el peor fracaso de TI y error judicial en la historia del Reino Unido.

2.3. La toma de decisiones automatizada y la 'maldad administrativa'

La violencia de los algoritmos:
- Los sistemas MiDAS de Michigan, Estados Unidos (detección de fraude en seguro de desempleo), y Robodebt de Australia (detección de fraude en beneficios sociales) emitieron decisiones apoyándose solo en algoritmos, sin supervisión humana.
- Decenas de miles de ciudadanos inocentes fueron tratados como criminales, pero los burócratas se negaron a compensarlos o eludieron su responsabilidad incluso después de demostrarse los errores del sistema.
Los riesgos de adoptar IA:
- Esta 'maldad administrativa (Administrative Evil)' se agravará a medida que la IA se involucre más profundamente en la infraestructura pública.
- La UE introdujo el 'derecho a exigir una explicación', pero a nivel global urge establecer transparencia y responsabilidad sobre los algoritmos.

3. Conclusión: soluciones y tareas pendientes para la comunidad de TI

Las metodologías (Agile/DevOps) no son una llave maestra:
- Como muestran informes que sitúan la tasa de fracaso de proyectos Agile hasta en 65%, la metodología por sí sola no garantiza el éxito. Sin liderazgo consistente ni disciplina organizacional, cualquier metodología nueva también fracasa.
Evaluación honesta del riesgo y responsabilidad ética:
- Antes de iniciar un proyecto, debe realizarse un análisis honesto de brechas (Gap Analysis) sobre "qué sabemos y qué no sabemos".
- El concepto de 'IA centrada en las personas (Human-centered AI)' debe ampliarse a todos los proyectos de TI, incorporando al análisis costo-beneficio el daño emocional y financiero que una falla del sistema puede causar a los usuarios finales.
Llamado a cambiar la actitud de la gerencia:
- El software es, por naturaleza, frágil (Fragile) y complejo. La gerencia debe respetar y apoyar el desarrollo de software no solo como quien controla el presupuesto, sino como quien asume la responsabilidad cuando ocurre un fracaso.
- Detener la repetición de los mismos errores es el único camino para que la industria de TI salga de la 'crisis (Crisis)'.

1 comentarios

baeba 2025-11-26

Resumen de reacciones en los comentarios de Hacker News

1. Falta de despliegue gradual y de estrategia de escalamiento (Start Small)

Fracaso inevitable del enfoque "big bang": desplegar un proyecto a escala nacional de una sola vez es un acto suicida. Es indispensable una estrategia de expansión con validación secuencial en unidades pequeñas (pueblo → ciudad → país).
Diferencia entre producto y sistema: a diferencia de un producto único como WhatsApp, los sistemas empresariales complejos deben soportar una escala enorme desde el inicio, por lo que el enfoque tiene que ser distinto.
Solución clave: se sigue ignorando el principio de "construir algo pequeño y agregar funciones después de validarlo".

2. Incapacidad de la gerencia y evasión de responsabilidades (Management Issues)

Estructura de poder sin responsabilidad: se critica la contradicción de que, cuando un proyecto fracasa, los desarrolladores lo intentan rescatar con horas extra, mientras que la gerencia, que tomó las decisiones, no asume responsabilidades o incluso recibe bonos.
Falta de comprensión técnica: imponer cronogramas irreales ignorando la dificultad técnica y una cultura jerárquica que se niega a escuchar "malas noticias" impiden resolver los problemas.
Decisiones políticas: existe una tendencia a elegir soluciones no por su adecuación técnica, sino por la política interna o por relaciones con proveedores externos (por ejemplo, rebates).

3. Requisitos fuera de control y complejidad (Complexity & Scope Creep)

Ausencia de simplificación previa de procesos: como en el caso de The Phoenix Project, intentar informatizar tal cual 80 mil reglas de nómina sin ordenarlas primero es una causa de fondo. Un proceso offline caótico solo produce un sistema digital caótico.
Cambios frecuentes de requisitos: la ampliación del alcance del proyecto (scope creep) por caprichos de la gerencia o del cliente durante la ejecución termina hundiendo el proyecto.

4. Cultura de desarrolladores e incentivos equivocados (Developer Culture)

Desarrollo guiado por el currículum (RDD): se introducen a la fuerza tecnologías de moda recientes (frameworks) que favorecen un futuro cambio de empleo personal más que el éxito del proyecto, aumentando la deuda técnica.
Ruptura del aprendizaje: la cultura de cambios frecuentes de trabajo (job hopping) cada 2 o 3 años impide que los desarrolladores vean el fracaso a largo plazo del código que hicieron y aprendan de ello.
Obsesión por reinventar: una práctica ineficiente de volver a escribir código desde cero para la realización personal, en lugar de aprovechar soluciones existentes y ya probadas.

5. Naturaleza particular de la ingeniería de software (Engineering Nature)

Ausencia de restricciones físicas: a diferencia de la construcción o el hardware, el software no tiene restricciones físicas y eso permite una complejidad infinita, lo que termina provocando situaciones fuera de control.
Falta de aprendizaje del pasado: otras ramas de la ingeniería analizan a fondo los fracasos (por ejemplo, el colapso de puentes) y extraen lecciones, pero la industria del software repite errores del pasado con una mentalidad tipo "YOLO" de que "esta vez es diferente".