Por qué fallan los proyectos de software: 5 razones que se repiten

En 2005, el mundo gastaba US$1,7 billones al año en tecnologías de la información. En 2025, ya en dólares ajustados, la cifra llegó a US$5,6 billones. Según un reportaje de Robert N. Charette en IEEE Spectrum, publicado el 23 de noviembre de 2025, la tasa de éxito de los proyectos de software no mejoró de forma visible en ese período.

Charette sigue los fracasos de software desde hace dos décadas. Su conclusión es incómoda: los proyectos no fracasan por culpa de tecnología nueva o difícil. Fracasan por los mismos motivos de siempre. En sus palabras, “la esperanza no es una metodología”.

El tamaño del problema

Los ejemplos del reportaje son de organismos públicos y grandes empresas, pero la lógica sirve para cualquier fundador.

• El sistema de nóminas Phoenix, del gobierno de Canadá, se presupuestó en CA$310 millones y entró en funcionamiento en 2016. Ya ha costado más de CA$5.100 millones. Cerca del 70% de los 430 mil funcionarios tuvo errores en su nómina en nueve años.
• El sistema de matriculación de vehículos de Minnesota se planificó en US$41 millones y se canceló en 2019, tras costar US$100 millones.
• Lidl abandonó un ERP de €500 millones después de tres años y volvió al sistema antiguo.
• En Estados Unidos, el CISQ estimó en US$260.000 millones el costo de los fallos de desarrollo de software solo en 2022.

Ninguno de estos proyectos empezó con la intención de fracasar. Todos tenían presupuesto, equipo y cronograma.

Las 5 razones por las que tu producto nunca salió en línea

IEEE Spectrum enumera más de diez causas. Agrupamos en cinco las que más aparecen en los productos digitales de fundadores.

1. La meta nunca se escribió

Charette señala las “metas irreales o no articuladas” como causa recurrente. En producto digital, se ve así: todos coinciden en que la app tiene que “resolver el problema del cliente”, pero nadie escribió qué problema, para quién ni cómo medirlo. Sin una meta escrita, cada reunión cambia el rumbo.

2. El alcance crece sin dueño

El scope creep es el punto más conocido de la lista. Cada funcionalidad nueva parece pequeña. Sumadas, empujan el lanzamiento meses. La señal es simple: si nadie tiene autoridad para decir “esto queda para la versión 2”, el alcance va a crecer hasta que se acabe el dinero. Por eso vale aprender a recortar el alcance para caber en la fecha.

3. Plazo y costo se estimaron a la baja

El reportaje cita “supuestos de costo y plazo demasiado optimistas”, como recortar pruebas y saltarse el piloto. En el caso Phoenix, el proyecto se presupuestó en menos del 60% del valor de la propuesta del proveedor. Cuando el número encaja con el deseo y no con el trabajo, la diferencia aparece después, con intereses.

4. Las pruebas quedaron para el final

Las “pruebas inadecuadas” están en la lista. En un producto pequeño, las pruebas suelen ser lo primero que se sacrifica cuando aprieta el plazo. El resultado es un lanzamiento que se traba el primer día de uso real y quema la confianza de los primeros clientes, que son los más difíciles de conseguir.

5. Nadie responde por las decisiones

Charette habla de falta de responsabilidad en las decisiones de gestión y de política interna que esconde problemas. Para un fundador con proveedor externo, eso tiene una cara conocida: el estudio dice que el retraso es culpa del cambio de alcance, el fundador dice que es culpa del estudio, y el producto sigue fuera de línea. Es el retrato del proyecto de software retrasado.

La trampa de creer que tu caso es distinto

Un punto del reportaje merece destacarse: la “trampa de la singularidad”, cuando los gestores descartan lecciones de fracasos pasados porque creen que su proyecto es único. Charette lo resume: repetir los mismos errores esperando otro resultado no es aprender.

Todo fundador cree que su producto es distinto. El producto puede serlo. La forma de hacerlo fracasar casi nunca lo es.

Qué cambia esto para ti

Antes de empezar o retomar un proyecto, responde por escrito:

1. ¿Cuál es la meta de la primera versión, en una frase y con un número?
2. ¿Qué queda fuera, de forma explícita?
3. ¿Cuál es la fecha, y quién puede cambiarla?
4. ¿Cuándo y cómo se probará el producto con gente de verdad?
5. ¿Quién responde por el resultado, de tu lado y del lado del proveedor?

Si alguna respuesta es “ya lo veremos”, ya sabes dónde se va a atascar el proyecto.

Cómo lo hacemos en el Studio

Empezamos por un diagnóstico. Solo después damos precio, y el precio es cerrado. El plazo queda por escrito en el contrato, y el alcance se recorta para cumplir esa fecha, no al revés. Así LCX, empresa de turismo que opera en más de 10 países de Sudamérica, pasó de un sistema por país a uno solo, en línea en 29 días.

Tras el lanzamiento, cada sistema sale con un agente de IA que se ejecuta a diario, señala fallos, sugiere mejoras y comprueba que los datos tengan sentido. Es la prueba que no termina cuando termina el proyecto.

Si quieres sacar un sistema o SaaS del papel sin repetir estas cinco razones, ese es exactamente el trabajo de nuestro servicio de desarrollo de sistemas a medida y SaaS.