Los patrones de fracaso de los proyectos de software se repiten de un proyecto a otro, y tienen muy poco que ver con la elección del lenguaje o del framework. La mayoría de las veces, un proyecto fracasa porque la necesidad se entendió mal, porque el alcance creció sin que nadie lo presupuestara o porque nadie asumía la responsabilidad técnica del resultado. Vivo en Vietnam desde 2014 y allí dirijo un equipo de desarrolladores senior: veo estos mismos escenarios en clientes muy distintos. Esto es lo que dicen las cifras, y después, los cuatro patrones que intento detectar lo antes posible.
- 📊 Cifras históricas, solo el 16,2 % de los proyectos cumple presupuesto y plazos, según el Chaos Report.
- ⚠️ Definición difusa, una necesidad mal entendida arruina más proyectos que la tecnología.
- 🏗️ Código sin responsable, la IA produce rápido, pero nadie responde de la arquitectura.
- 🎯 Veredicto claro, un equipo senior con un seguimiento cercano reduce el riesgo, también en offshore.
Lo que dicen las cifras sobre el fracaso de los proyectos de software
El Chaos Report es el estudio anual del Standish Group, publicado desde 1994 y basado en más de 50 000 proyectos según bestofbusinessanalyst.fr. Clasifica los proyectos en tres categorías: exitosos, problemáticos (entregados con retraso o por encima del presupuesto) y fallidos (cancelados antes del despliegue). En las cifras históricas que recoge, el 16,2 % de los proyectos cumple presupuesto y plazos, el 52,7 % se desvía y el 31,1 % se cancela por el camino.
¿Qué porcentaje de los proyectos de software fracasa realmente?
Los proyectos problemáticos cuestan de media el 189 % de su estimación inicial, según orgatypik.com, que se basa en el mismo informe. Una actualización de 2015 del Standish Group, citada por bestofbusinessanalyst.fr y por reussirsesprojets.com, sitúa la tasa de fracaso global en el 71 %, en parte gracias al uso más extendido de los enfoques ágiles. En el ámbito de las grandes empresas, la consultora McKinsey ya advertía en 2020 que el 17 % de los grandes proyectos informáticos se desvía hasta el punto de amenazar la propia existencia de la empresa, siempre según orgatypik.com.
Son cifras antiguas y su definición de fracaso es estricta: un software entregado con un 20 % de retraso pero que se usa a diario cuenta como «problemático». Yo las leo como un orden de magnitud, no como una probabilidad aplicable a tu proyecto.
El problema no es que los proyectos fracasen, sino que siempre fracasan de la misma manera.
| Indicador | Resultado | Qué significa | Fuente citada |
|---|---|---|---|
| Proyectos exitosos | 16,2 % | Presupuesto y plazos cumplidos | Chaos Report (vía bestofbusinessanalyst.fr) |
| Proyectos problemáticos | 52,7 % | Sobrecoste medio del 189 % | Chaos Report (vía orgatypik.com) |
| Proyectos fallidos | 31,1 % | Cancelados antes del despliegue | Chaos Report (vía bestofbusinessanalyst.fr) |
| Tasa de fracaso global, edición 2015 | 71 % | Mejora atribuida al agile | Standish Group (vía reussirsesprojets.com) |
| Grandes proyectos TI en peligro crítico | 17 % | Amenaza para la existencia de la empresa | McKinsey, 2020 (vía orgatypik.com) |
FUENTE: Standish Group Chaos Report, McKinsey, a través de las páginas citadas · ACT. 11/2026
¿Hay que creerse el estudio que culpa al agile?
Un estudio difundido por agile.developpez.com en junio de 2024, realizado con 600 ingenieros británicos y estadounidenses, afirma que los proyectos que adoptan prácticas ágiles de ingeniería de requisitos tienen un 268 % más de probabilidades de fracasar. Según el estudio, el 65 % de esos proyectos no se entrega a tiempo, dentro del presupuesto y con la calidad esperada, frente al 10 % de los que siguen un método llamado «ingeniería de impacto».
Yo no saco en absoluto la misma conclusión. El estudio se hizo para un libro, Impact Engineering, que vende precisamente el método ganador: el conflicto de intereses está en la propia fuente. Y, sobre todo, lo que mide se parece más a un problema de requisitos mal definidos que a un defecto del agile en sí, lo que nos lleva al siguiente patrón.
Patrones 1 y 2: la necesidad mal entendida y el alcance que se infla
El primer patrón de fracaso de un proyecto de software es una necesidad mal interpretada; el segundo, un alcance que se amplía sin que el presupuesto acompañe. Ambos están relacionados: un pliego de condiciones difuso permite que cada parte entienda una cosa distinta y luego reclame o facture la diferencia.
¿Por qué sale tan cara una necesidad poco clara?
La guía de reussirsesprojets.com sitúa la «mala interpretación de las necesidades» a la cabeza de sus 33 causas de fracaso. Su ejemplo es deliberadamente caricaturesco: te piden que vayas a París, tú pones rumbo a Francia, y el cliente estaba pensando en París, Texas. Cada semana de desarrollo se construye entonces sobre una hipótesis que nadie ha comprobado.
Un desarrollador senior no adivina: pregunta en cuanto algo es ambiguo, en lugar de interpretar. Es lo que espero de cada perfil que coloco, y es también lo que separa un presupuesto útil de una partida optimista. Mi artículo sobre un presupuesto de aplicación móvil comentado línea por línea muestra cómo es un alcance lo bastante preciso como para poder discutirlo antes del primer commit.
¿Cómo detectar la deriva del alcance antes de que cueste un 189 %?
La deriva se ve en los entregables, no en las reuniones. Hay tres señales recurrentes: ninguna demo visible en dos semanas, peticiones de nuevas funciones aceptadas «porque son pequeñas» sin presupuestarlas, y un backlog en el que nadie sabe decir qué es prioritario.
Mi antídoto se resume en un hábito: empezar con un lote de 5 días, medir la velocidad y la calidad reales, y proyectar el resto a partir de datos y no de promesas. El cliente sigue mandando sobre las prioridades y el equipo presupuesta cada añadido en el momento en que llega.
Patrón 3: código entregado rápido, pero sin responsable técnico
El tercer patrón es reciente: un producto generado deprisa con IA, sin ningún ingeniero que responda de él. El vibe coding es la práctica de generar código con un asistente de IA validando el resultado a ojo en lugar de revisarlo. Es útil para prototipar y peligroso para construir un producto serio sin supervisión técnica.
¿Por qué el vibe coding hace fracasar proyectos serios?
Alguien que no es ingeniero puede conseguir fragmentos de código que funcionan. Pero no necesariamente sabe gestionar la arquitectura, la seguridad, el mantenimiento, los bugs y los casos límite, y son justo esos puntos los que matan un producto en la tercera versión. Un producto generado sin control técnico cuesta mucho más reparar que construir bien desde el principio.
Creo que muchas empresas van a perder dinero pensando que la IA basta. Seguirán necesitando una verdadera responsabilidad técnica, es decir, una persona capaz de decir «no, esta decisión de arquitectura no va a aguantar». He desarrollado esta frontera en vibe coding y desarrolladores offshore.
¿Cuándo reduce la IA de verdad el riesgo de fracaso?
Cuando está en manos de un ingeniero. Un desarrollador que trabaja con Claude Code o Cursor sigue siendo un ingeniero, no un operador de prompts: mantiene los tests, la revisión y las decisiones de arquitectura, y la IA multiplica su capacidad de producción. Un buen desarrollador se vuelve más productivo, uno malo se vuelve más arriesgado, y la brecha se agranda.
Por eso el número de desarrolladores importa menos que antes. Lo que cambia el desenlace de un proyecto es la capacidad del equipo para usar la IA con inteligencia y bajo responsabilidad técnica. Para ver en detalle cómo funciona, consulta cómo usan los desarrolladores Claude Code.
Patrón 4: el offshore fracasa por los malentendidos, no por el nivel técnico
Un proyecto offshore rara vez fracasa porque los desarrolladores sean malos. Fracasa porque la necesidad se pierde entre el cliente francés y el equipo a distancia. El nivel técnico disponible en Vietnam basta de sobra para construir SaaS, aplicaciones móviles y plataformas de negocio serias, y creo que muchas empresas europeas siguen subestimando el país.
¿Cómo suele torcerse un proyecto offshore?
El guion es conocido: el cliente describe su necesidad en unas pocas líneas, el equipo entrega lo que ha entendido y la diferencia solo aparece en la fase de pruebas de aceptación. Nace de malentendidos técnicos, culturales y organizativos de los que nadie se ha hecho cargo. Sin un interlocutor que hable los dos idiomas del proyecto, cada ambigüedad queda abierta.
Ese es exactamente mi papel: tender el puente entre las exigencias de los clientes franceses y la capacidad de ejecución del equipo vietnamita. Si estás evaluando a un proveedor, la lista de lo que hay que comprobar en un proveedor informático en Vietnam y el artículo sobre el interlocutor francófono en offshore te dan las preguntas que hacer.
¿Cuándo no es el offshore la respuesta adecuada?
Si no tienes pliego de condiciones ni a nadie de tu lado capaz de decidir las prioridades, el offshore amplificará la falta de claridad en lugar de corregirla. Lo mismo ocurre si el proyecto exige presencia física diaria en tus oficinas. En esos casos, vale más una definición previa del proyecto, o un equipo local más pequeño, que arrancar deprisa.
Mi veredicto: lo que de verdad reduce el riesgo de fracaso
Los proyectos de software fracasan siguiendo cuatro patrones repetitivos, y todos se ven antes de que termine el primer mes: una necesidad difusa, un alcance sin presupuestar, un código sin responsable técnico y la ausencia de puente entre cliente y equipo. El riesgo se reduce con tres cosas: una necesidad escrita y cuestionada antes del primer commit, una entrega visible cada semana y un ingeniero senior que responda del resultado.
¿Qué señales comprobar antes de firmar?
Antes de lanzar un proyecto, compruebo cuatro puntos, tanto con el cliente como con el equipo:
- La necesidad está por escrito, la han revisado dos personas y cada zona de ambigüedad tiene una pregunta abierta.
- Un primer lote corto (5 días) permite medir la velocidad y la calidad antes de comprometer el resto.
- Una persona identificada responde de la arquitectura, los tests y la seguridad, incluso cuando la IA escribe parte del código.
- El código, los accesos y la documentación están en las cuentas del cliente desde el primer día, lo que le deja libertad para acelerar, frenar o retomarlo internamente.
No vendo solo tiempo de desarrollo: mis clientes pagan por la capacidad de convertir una idea en un software utilizable. Si quieres ver cómo funciona este modelo, puedes contratar a un desarrollador senior en Vietnam, con perfiles en 48 h y un arranque en menos de 7 días.
Preguntas frecuentes
¿Cuál es la tasa de fracaso de los proyectos de software?
Según el Chaos Report del Standish Group, recogido por bestofbusinessanalyst.fr, el 16,2 % de los proyectos cumple presupuesto y plazos, el 52,7 % se desvía y el 31,1 % se cancela. Una edición de 2015 sitúa el fracaso global en el 71 %. Estas cifras usan una definición estricta de fracaso y deben leerse como un orden de magnitud.
¿Por qué los proyectos informáticos superan su presupuesto?
Las causas más frecuentes son una necesidad mal interpretada desde el principio y un alcance que se amplía sin volver a presupuestarse. Según orgatypik.com, los proyectos problemáticos del Chaos Report cuestan de media el 189 % de su estimación. Presupuestar cada añadido y entregar una demo visible cada semana limita esa deriva.
¿El agile hace fracasar los proyectos de software?
No, al menos según los datos disponibles. Un estudio de 2024 con 600 ingenieros afirma que las prácticas ágiles multiplican el riesgo de fracaso, pero se realizó para un libro que promueve un método competidor. El problema de fondo suele ser unos requisitos mal definidos, sea cual sea el método de gestión.
¿Es arriesgado el vibe coding para un producto en producción?
Sí, si no hay un ingeniero que revise y estructure el código. El vibe coding sirve para prototipar, pero la arquitectura, la seguridad, el mantenimiento y los casos límite exigen supervisión técnica. Un producto generado sin control suele costar más reparar que construir bien.
¿El offshore aumenta el riesgo de fracaso de un proyecto?
No lo aumenta por el nivel técnico de los equipos, pero desplaza el riesgo hacia la comunicación. Sin un interlocutor que entienda la necesidad del cliente y la traslade al equipo, los malentendidos se acumulan hasta la fase de pruebas de aceptación. Con un pliego de condiciones claro y un primer lote corto para medir la calidad, el offshore en Vietnam sigue siendo una opción sólida.
