La pregunta que nadie puede responder
En la evaluación de un proyecto municipal de servicios, tres años y dos reorganizaciones después de su inicio, alguien plantea en la mesa la pregunta más simple que existe: ¿cuál era el objetivo, otra vez? Silencio. El jefe de proyecto original trabaja ahora en otro ayuntamiento. El business case estaba en un entorno SharePoint que se dio de baja en la última reorganización. Hay un informe final, hay actualizaciones trimestrales, hay un concejal satisfecho — pero ya no queda nada contra lo que evaluar.
Cuatro marcos, una suposición tácita
El CAD de la OCDE, la revisión británica Gate 5, la práctica PRINCE2 y el modelo CIPP de Stufflebeam se desarrollaron de forma independiente entre sí, para sectores muy distintos. Aun así, llegan a los mismos elementos: evaluar los beneficios frente a la promesa, validación independiente, criterios fijados de antemano, lecciones orientadas a la acción. Ese primer punto — evaluar frente a la promesa — presupone algo que rara vez se hace explícito: que esa promesa siga siendo, en el momento de la evaluación, localizable, legible e inalterada. Ninguno de los cuatro marcos describe qué hacer si no es así. Todos asumen, tácitamente, que sí lo es.
Por qué esa suposición casi nunca se cumple
La comisión parlamentaria neerlandesa Elias concluyó que, antes de los proyectos de TI, se piensa demasiado poco en el cómo y el porqué; las reglas básicas que surgieron de ahí se refieren únicamente al inicio de un proyecto: un business case, una decisión de seguir adelante o no, una justificación previa. En ninguna parte se establece que esos mismos documentos deban seguir existiendo al cierre, y mucho menos en la misma forma. Un proyecto de tres años sobrevive, de media, a varios cambios de personal, al menos un ajuste intermedio del alcance y, a veces, a una reorganización que reordena todo el archivo. Para cuando llega la evaluación, la promesa original a menudo ya se ha reescrito varias veces — o simplemente ha desaparecido.
El resultado es una evaluación que no comprueba, sino que conversa. En lugar de "¿se han realizado los beneficios acordados?", la pregunta pasa a ser "¿cómo lo vemos ahora?" — una conversación perfectamente válida, pero no una evaluación en el sentido que le dan la OCDE, Gate 5, PRINCE2 y CIPP. El Tribunal de Cuentas neerlandés ya señaló en 2013 que el aprendizaje organizativo mutuo se encontraba todavía en una fase inicial; una línea base perdida es una de las razones silenciosas por las que eso sigue siendo así. No se puede aprender de una comparación que ya no se puede hacer.
Lo que esto no resuelve
Una línea base conservada no garantiza el aprendizaje — quién recoge después las recomendaciones es otra pregunta, con otra respuesta. Pero sin una promesa conservada, ni siquiera esa pregunta se puede responder: no se sabría de dónde debería venir la lección.
Qué hacer al respecto en la práctica
La solución no está en la evaluación, sino en el arranque. Registre los objetivos, supuestos y criterios de éxito originales en un documento separado de la administración del proyecto, que va cambiando sobre la marcha — no una página viva que se mueve con cada ajuste, sino una versión fechada que nunca se sobrescribe. Designe a alguien que custodie ese documento, con independencia de quién dirija el proyecto en cada momento. Y al cerrar el proyecto, recupérelo literalmente antes de que empiece la conversación, para que la evaluación se mida frente a lo que se prometió — no frente a lo que mientras tanto se ha convertido en el relato cómodo.
Ahí es exactamente donde un instrumento como EvaluatieScore demuestra su utilidad: no decidiendo si un proyecto tuvo éxito, sino haciendo inevitable la pregunta "contra qué promesa evaluamos esto" antes de emitir cualquier juicio.