En la reunión de cierre del nuevo sistema de gestión de expedientes de un ayuntamiento de tamaño medio se aplaude: entregado en la fecha acordada, dentro del presupuesto de algo más de un millón de euros, toda la funcionalidad acordada construida. El jefe de proyecto recibe una palmada en la espalda y el siguiente encargo. Nadie plantea la pregunta que todavía importa un año después: ¿se materializaron realmente los plazos de tramitación un treinta por ciento más cortos que prometía el business case?
No es una excepción. Es el patrón con el que suele tropezar la evaluación posterior: los proyectos se cierran en función de si entregaron lo acordado, no en función de si entregaron lo prometido.
Dos promesas distintas
Un plan de proyecto promete algo distinto de un business case. El plan promete alcance, tiempo y dinero: este sistema, en esa fecha, por ese presupuesto. El business case promete un beneficio: plazos más cortos, costes más bajos, mayor satisfacción del cliente. Un proyecto puede tener éxito en la primera promesa y guardar silencio total sobre la segunda, y eso ocurre de forma estructural, porque tras la entrega ya nadie tiene el mandato de medir el beneficio.
El Tribunal de Cuentas neerlandés (Algemene Rekenkamer) ya lo constató en 2013 para los proyectos de TI del Estado: la realización de beneficios se vigila demasiado poco. No porque a nadie le parezca importante, sino porque después de la puesta en marcha ya no queda un momento designado en el que alguien siga planteando la pregunta. El proyecto ha terminado, el equipo se ha disuelto, la siguiente licitación espera.
Lo que tienen en común cuatro marcos
La OCDE-CAD, un marco de evaluación ampliamente aplicado y transferible, desarrollado dentro de la cooperación al desarrollo, antepone la prueba de beneficios frente a la promesa: no «¿se entregó?», sino «¿hizo lo que debía hacer?». El Gate 5 británico, la práctica PRINCE2 y el modelo CIPP de Stufflebeam, desarrollados de forma independiente entre sí, llegan al mismo núcleo. Cuatro tradiciones distintas, una sola conclusión: una evaluación que solo mira la entrega está evaluando lo que no corresponde.
La pregunta que falta al cierre
El problema práctico no es que las organizaciones carezcan de criterios. El plan de proyecto está lleno de ellos, solo que son del tipo equivocado. El alcance, el tiempo y el dinero son fáciles de comprobar en la entrega: el sistema funciona o no funciona, la factura está o no está. Un beneficio como «un treinta por ciento menos de plazo de tramitación» solo es medible tras un período de uso real, un momento en el que la puesta en marcha ya se celebró hace tiempo y la atención ya se ha trasladado al siguiente proyecto.
Eso explica por qué la revisión ex ante, obligatoria para la TI del Estado desde la comisión Elias, es la práctica habitual, mientras que la revisión ex post de los beneficios no lo es: la primera corresponde al momento en que todos siguen mirando, la segunda al momento en que ya nadie mira.
Para un jefe de proyecto que quiera romper este patrón, el primer paso no es un proceso de evaluación más elaborado, sino una pregunta distinta en el momento de la entrega: no «¿construimos lo acordado?», sino «¿qué beneficio del business case seguiremos comprobando dentro de seis meses, y quién lo hará?». Sin esa segunda pregunta, «a tiempo y dentro del presupuesto» sigue siendo la única respuesta que se da jamás.