Una copa de despedida, tres promesas, ninguna cita en la agenda
En la copa de cierre de un proyecto de TI en un municipio mediano, el cliente lo dice en voz alta: "Dentro de unos meses lo evaluaremos en serio." Es junio, el proyecto acaba de entregarse, y el equipo del proyecto ya está repartido en otros tres encargos. Nadie pone una fecha en la agenda, nadie queda designado para llevarlo. Seis meses después, la promesa es una línea en una lista de acciones que ya nadie abre.
Este patrón no es la excepción. Es la vía por defecto por la que se evaporan las evaluaciones — no porque nadie quiera aprender, sino porque nunca se fijó un momento para hacerlo.
Lo que es obligatorio, y lo que no
Tras los grandes fracasos de TI del Estado neerlandés, la comisión de investigación Elias constató que, antes de los proyectos, se pensaba demasiado poco en el cómo y el porqué. Las reglas básicas que de ahí resultaron — un business case fundamentado, un documento de inicio, un momento de aprobación (go/no-go) — son todas ex ante. Un instrumento obligatorio comparable para lo que ocurre después de la entrega no existe. La fecha en que un proyecto empieza está fijada en todo plan de proyecto. La fecha en que alguien lo revisa con ojo crítico casi nunca lo está en ninguna parte.
Documentar sin un proceso no es aprender
Williams ya lo describió con precisión en 2007: sin un esfuerzo deliberado y un proceso designado, las lecciones rara vez se incorporan a una política organizativa más amplia. Ese "proceso designado" es donde normalmente falla — no en la voluntad de aprender, sino en la ausencia de un momento que realmente esté en una agenda, con un nombre al lado. Un registro de lecciones aprendidas guardado en una carpeta del proyecto no es un proceso. Es un archivo que espera a que alguien lo abra algún día.
El Tribunal de Cuentas neerlandés (Algemene Rekenkamer) constató en 2013 que el aprendizaje organizativo mutuo en los proyectos de TI del Estado todavía se encontraba en una etapa inicial. Parte de la explicación es evidente: si nadie ha acordado de antemano cuándo y quién hará la revisión, el aprendizaje depende de la iniciativa individual. Y la iniciativa individual pierde, cada vez, frente al siguiente plazo que sí tiene una fecha.
Lo que sí funciona: fijar la fecha antes de que empiece el proyecto
Cuatro marcos desarrollados de forma independiente entre sí — la OCDE-CAD, el Gate 5 británico, la práctica PRINCE2 y el modelo CIPP de Stufflebeam — llegan, sin coordinarse entre ellos, a los mismos elementos: contrastar los beneficios con la promesa original, una validación independiente, y criterios establecidos de antemano. Ese último elemento suele leerse como "acordad de antemano contra qué vais a medir." Debajo hay una capa más práctica: acordad también de antemano cuándo vais a medir, y quién lo hace.
Esa es la diferencia entre un proyecto que realmente se evalúa y uno cuya evaluación se disuelve en el ajetreo de la semana siguiente. El problema entonces no es la calidad de los criterios, sino la ausencia de un momento planificado para usarlos.
En concreto: fijarlo al inicio, no en la despedida
Quien pone en marcha un proyecto planifica un kick-off, una revisión de avance intermedia y una fecha de entrega. Un momento de evaluación pertenece a ese mismo plan, con el mismo estatus: una fecha, un responsable, una cita en la agenda — no una buena intención pronunciada cuando el proyecto ya casi ha terminado. Fijad esa fecha cuando el proyecto se aprueba, no cuando se cierra. Entonces ya no es una promesa de sobremesa, sino una cita.