Cuanto más grande es el proyecto de software, más probable es que fracase. No es una opinión ni una boutade: es uno de los hallazgos mejor documentados de la gestión de proyectos tecnológicos, y va de frente contra el instinto de cualquiera que asocie tamaño con seguridad.
El estudio de referencia lo hicieron McKinsey y la Universidad de Oxford analizando más de 5.400 proyectos de IT con presupuestos superiores a 15 millones de dólares. De media, esos grandes proyectos terminaron un 45% por encima del presupuesto y un 7% por encima del plazo, entregando un 56% menos de valor del previsto. Y un dato que debería estar en la primera diapositiva de cualquier comité que vaya a aprobar uno: el 17% salen tan mal que llegan a amenazar la existencia misma de la compañía.
6% es la tasa de éxito de los grandes proyectos de software; los pequeños llegan al 62%: Standish Group CHAOS Report.
El tamaño como factor de riesgo, no de seguridad
El Standish Group, que mantiene una base de decenas de miles de proyectos, lo enseña con crudeza al cruzar el éxito con el tamaño. Los proyectos pequeños tienen éxito en torno al 62% de las veces. Los grandes, solo el 6%. Los más grandes de todos, apenas el 2%. La probabilidad de éxito no es plana: se desploma con el tamaño.
La razón es estructural, no de talento. Un proyecto grande tiene más partes que pueden fallar, más personas que coordinar y más tiempo durante el cual el negocio cambia bajo sus pies. Hay además una trampa conocida desde hace medio siglo: añadir gente a un proyecto que va tarde lo hace ir más tarde, porque el coste de coordinación crece más rápido que la capacidad que aportan las nuevas manos. Y cada año adicional de duración incrementa el sobrecoste medio un 15%, según McKinsey/Oxford. El proyecto largo no es solo más caro: se encarece cuanto más dura.
Un proyecto de dos años no es dos proyectos de un año. Es una apuesta a que el negocio, el equipo y la tecnología no cambiarán en 24 meses. Esa apuesta casi siempre se pierde.
La paradoja de los recursos
La empresa grande tiene más presupuesto, más gente y más proveedores. Eso, lejos de protegerla, suele ser parte del problema. Más presupuesto habilita alcances más ambiciosos, que tardan más y cambian más por el camino. Más gente significa más coordinación y más puntos donde lo que se construye se desalinea de lo que el negocio necesita. El resultado tiene nombre: el macroproyecto. Dos años, un alcance enorme cerrado al principio ( cuando menos se sabe ) y una entrega final que aterriza cuando el problema que iba a resolver ya cambió de forma.
Hay un detalle técnico que lo agrava en los proyectos de software frente a otros tipos de obra: el riesgo de integración. Cuanto más grande el sistema, más piezas tienen que encajar entre sí y con los sistemas existentes, y la integración es justo donde aparecen los problemas que ninguna especificación previa anticipó. Por eso el software es, según el propio estudio, la categoría con mayor riesgo de sobrecoste de todas.
La alternativa: rebanar el valor, no acumular el riesgo
La respuesta a este riesgo no es gestionar mejor los proyectos enormes, es no hacerlos enormes. La forma más fiable de construir software valioso en una empresa grande se parece poco a un gran proyecto y mucho a una sucesión de entregas pequeñas:
- Trocear por valor, no por fases. Cada pieza debe ser útil por sí misma al entregarse, no un módulo que solo sirve cuando llegue el siguiente dentro de seis meses.
- Poner en producción pronto. El contacto con la realidad ( datos sucios, casos límite, usuarios reales ) revela en dos semanas lo que ninguna especificación revela en seis meses de análisis.
- Cerrar el alcance por ciclo, no de una vez. Un alcance pequeño cerrado cada pocas semanas, en lugar de un alcance gigante cerrado una sola vez al inicio, cuando la información es mínima.
Esto tiene una consecuencia incómoda para quien vende grandes proyectos cerrados: lo más seguro es justo lo contrario de lo más grande. Y tiene una ventaja para quien paga: si algo va a salir mal, se descubre en la semana cuatro con una pieza pequeña, no en el mes dieciocho con el presupuesto entero comprometido.