Un equipo de proyecto de un ayuntamiento de tamaño medio dedica su primera reunión sobre un nuevo sistema de gestión de expedientes a decidir si el proyecto seguirá Prince2 o una variante ligera de Scrum. Se vota; al final de la reunión, el método ya figura en la primera diapositiva de la presentación. En ese momento, la lista de requisitos del propio sistema consiste en tres puntos en media hoja: sin criterios de aceptación, sin responsable por requisito, sin distinción entre requisitos imprescindibles y deseables. Tres semanas después, cuando arranca el primer sprint, resulta que nadie se pone de acuerdo sobre qué significa exactamente 'un resumen de expediente funcional'.
Ese orden, primero el método y después los requisitos, se da más a menudo de lo que parece. Y la investigación muestra que es el orden equivocado.
Lo que muestra la investigación
Dvir, Raz y Shenhar estudiaron en 2003 con qué se correlaciona realmente el éxito de un proyecto. Su hallazgo: el éxito se correlaciona con la calidad de la definición de requisitos, con la precisión con la que se documenta qué debe entregar el proyecto, y no con el grado en que se ha implantado un proceso formal de gestión de proyectos. Con la elección del método en sí, por muy minuciosamente que esté desarrollada en un manual o una plantilla, apenas se correlaciona. Con los requisitos, sí.
Es una conclusión incómoda para quien dedica mucho tiempo a elegir y documentar una forma de trabajar. Un plan de proyecto con una estructura Prince2 rigurosa, roles, transiciones de fase, un PID, todo según el manual, parece profesional. Pero si la lista de requisitos que hay debajo sigue siendo vaga, el cliente compra una falsa seguridad: la forma está en orden, el contenido no.
El matiz que lo acompaña
Esto no es un alegato para abandonar la gobernanza y los acuerdos de proceso. Otra investigación, de Serrador y Turner de 2015, sí encuentra vínculos positivos entre la madurez de los procesos y el éxito de los proyectos. 'El contenido antes que el proceso' no es, por tanto, una ley universal; las dos líneas de investigación se contradicen en este punto. Lo que se mantiene: la definición de requisitos no puede desaparecer detrás de una discusión metodológica, ni siquiera cuando esa discusión es en sí misma útil.
Qué significa esto para el inicio de un proyecto
En concreto: si un plan de proyecto dedica sus primeras semanas sobre todo a qué método se seguirá, qué marco de trabajo, qué plantillas, qué estructura de reuniones, mientras la lista de requisitos sigue siendo un marcador de posición, el orden está invertido. La elección del método puede muy bien producirse pronto, pero no en lugar de documentar los requisitos. Un requisito que cuenta tiene un responsable, es verificable (se puede comprobar después si se cumplió) y es independiente de cómo se dirige el proyecto.
Para quien evalúa un plan de proyecto antes del arranque, esta es una pregunta concreta junto a la de la gobernanza y la fasificación: ¿están los requisitos ahí, con independencia de la forma de trabajo elegida? Un plan que puntúa de forma excelente en el diseño de procesos pero cuyos requisitos no pasan de una declaración de intenciones merece en ese punto una mirada crítica. No porque el proceso no importe, sino porque un proceso riguroso puede enmascarar la ausencia de requisitos precisos, y eso es exactamente lo que falló con el sistema de gestión de expedientes.
Un paso concreto
En la próxima sesión sobre el plan de proyecto, coloque la lista de requisitos al principio del orden del día, antes de la conversación sobre el método a seguir. Haga que cada requisito tenga un responsable y un criterio de aceptación antes de que el equipo pase a la pregunta de qué marco de trabajo se construirá alrededor. Eso cuesta una hora en un momento en que la discusión todavía trata sobre la forma, y evita que un método bien documentado acabe asentado sobre unos cimientos vacíos.