Project brief ágil: el sitio más barato para frenar un mal proyecto

Hay un momento incómodo en casi toda organización: el del proyecto que todo el mundo sabe que va mal pero que nadie consigue parar. Lleva meses comiéndose presupuesto, el sponsor lo defiende en cada comité y la pregunta de si conviene seguir invirtiendo no está en ninguna agenda. Cuando por fin se cancela, ya ha costado el triple.

Solemos contarlo como un problema de gestión. Casi nunca lo es. El lugar donde ese proyecto debería haberse podido frenar barato es un documento de una página que probablemente se escribió mal, o ni se escribió: el project brief. No es la pistola de salida que casi todos creen, sino el freno más barato que vas a tener.

¿Por qué la mayoría de project briefs no sirven para decidir?

Porque se escriben para conseguir un sí. El brief típico es un documento de venta interna: justifica la inversión y enumera beneficios. Eso vale para arrancar, pero no para lo más caro: saber pronto y sin drama cuándo conviene cortar.

Y cortar a tiempo importa más de lo que parece. El estudio de mayor alcance sobre proyectos de IT grandes (Flyvbjerg y Budzier, de Oxford, en Harvard Business Review, hace más de una década, sobre 1.471 proyectos) encontró un sobrecoste medio del 27%. Suena asumible. El problema es lo que esconde esa media: uno de cada seis proyectos se disparaba un 200% de media, con casi un 70% de retraso.

La amenaza no es el proyecto que se pasa un poco, sino el que se convierte en un agujero.

Un project brief que sirve para decidir contesta cinco preguntas:

1. ¿Qué apuesta estamos haciendo, dicha en una frase que pueda resultar falsa?
2. ¿Con qué señal sabríamos pronto que nos hemos equivocado?
3. ¿Qué NO vamos a hacer?
4. ¿Quién decide y quién tiene que estar, aunque no dependa de nosotros?
5. ¿Cuál es el primer trozo de valor que podemos liberar y medir?

Un brief en seis líneas. Pongamos un portal de autoservicio para reducir soporte. La apuesta: cubrir las dudas más repetidas bajará los tickets de nivel uno lo justo para absorber el crecimiento sin ampliar el equipo. La señal de error: si en tres meses no bajan con claridad sobre la línea base, paramos. No haremos: migrar el histórico ni tocar los casos complejos. Decide soporte; tiene que estar quien sepa por qué entran esos tickets. Primer entregable: el portal para las tres consultas más frecuentes, el que pone a prueba la apuesta.

¿El propósito se escribe como hipótesis o como justificación?

El brief debería plantear su propósito como una hipótesis. El estándar hace lo contrario: lo redacta de forma que no pueda ser falso, «mejorar la relación con el cliente», «modernizar la operativa». Nadie discute eso, y precisamente porque nadie lo discute, nunca te dirá que pares.

La alternativa es escribirlo como una apuesta: no «implantar un CRM para mejorar el servicio», sino «creemos que centralizar los datos de cliente subirá la retención, y si en seis meses no se mueve, nos equivocamos». Una frase así conecta con la estrategia y deja la puerta abierta a que la respuesta sea no.

Entregable: una frase de apuesta que un escéptico de la sala podría discutir. Si nadie es capaz de imaginar que salga mal, no tienes una hipótesis, tienes un deseo.

¿Cuántas métricas necesita un brief para no engañarte?

Las justas: una o dos, y al menos una con un umbral de parada acordado. Aquí vive un autoengaño común. Coges un brief de CRM y te encuentras una docena de porcentajes (un 20% aquí, un 30% allá) que dan sensación de rigor. El problema es doble: casi ninguno se va a medir, y con doce objetivos siempre se moverá alguno, así que el proyecto nunca «falla» del todo. Precisión no es rigor; un «20,0%» inventado no es más serio que un «esperamos que baje de forma clara».

El contraargumento es real: hay investigación reciente con muestras de proyectos que sí cumplen presupuesto, y la idea de que «todo proyecto fracasa» está exagerada. Pero eso no te salva: por adelantado no sabes si el tuyo es el del 27% aburrido o el del 200%, y esa incertidumbre es la razón para acordar un umbral barato de parada antes de empezar.

Lo que cuesta: un brief con doce métricas precisas y ningún umbral te da la sensación de control sin el control. La corrección: una o dos métricas que vas a instrumentar, cada una con su línea roja acordada de antemano, y, junto a ellas, un techo de gasto o de plazo. Porque a veces un proyecto no se para porque una métrica cruce su umbral, sino porque el dinero gastado ya supera lo que la apuesta valía, y eso se pacta al principio, no se descubre tarde. (La diferencia entre la métrica que decide y la que solo reporta la desarrollamos en OKR vs KPI).

¿Qué parte del alcance es la que de verdad importa?

La parte que casi nadie cuida: lo que el proyecto NO va a hacer. Todo brief enumera lo que sí hará; la lista explícita de lo que queda fuera es la decisiva. No es buena educación documental: cada cosa que metes en la columna del «no» hace la apuesta más pequeña, y una apuesta pequeña es más fácil de evaluar y de frenar. Además obliga a tener la conversación incómoda antes de gastar, en lugar de descubrir a medio camino que tres áreas suponían cosas distintas.

Pregunta para tu comité: ¿qué tres cosas que alguien espera de este proyecto vamos a dejar fuera, y lo hemos dicho explícitamente, o lo estamos evitando para que nadie se enfade?

¿A quién pones en el brief: a un jefe de proyecto o a quien rompe el silo?

A quien rompe el silo. El apartado de personas parece el más burocrático y es donde más se decide. Si escribes «un jefe de proyecto y el departamento de Operaciones», ya has perdido: has anclado el proyecto a un organigrama que casi nunca coincide con el problema que vas a tocar. Los proyectos que importan cruzan áreas; el brief debería nombrar a quien tiene autoridad para pararlo y a quien tiene que estar aunque su jefe no se lo pida, porque será quien levante el riesgo que nadie más ve.

Hay una objeción razonable: «no infles el equipo». Cierto, pero pequeño no es lo mismo que aislado: quieres pocas personas que abarquen los silos que el proyecto va a atravesar, no pocas de una misma caja del organigrama.

Bien hecho si: puedes señalar con el dedo a la persona que tiene autoridad para cancelar el proyecto, y al menos a una que está en la sala aunque su área no sea la «dueña».

¿El roadmap va con fechas o con trozos de valor?

Con trozos de valor que puedas soltar y medir, no con un calendario de fechas. Un Gantt detallado da una falsa sensación de control: aparenta saber qué pasará en el mes nueve cuando aún no sabes si la apuesta del mes uno es correcta. Un roadmap por entregables de valor hace lo contrario: cada trozo que liberas te da una señal real, y esa señal es justo lo que alimenta la decisión de seguir o parar. Por eso el primer entregable no debería ser el más fácil de construir ni el que mejor luce en la demo. El consejo ágil de manual, suelta antes el trozo de valor más pequeño, no siempre apunta ahí: si ese trozo coincide con tu suposición más frágil, perfecto; si no, en un brief que existe para decidir gana atacar primero lo que podría tumbarlo todo.

¿Y si el proyecto es grande, regulado o con muchas dependencias? Entonces necesitarás más planificación. Pero eso ya es un project plan, y viene después: el brief sigue siendo donde decides si ese plan merece la pena.

Empieza por: el entregable que valida (o tumba) tu hipótesis más frágil.

¿Cuál es el error de fondo que arruina casi todos los briefs?

Que se escriben desde el optimismo del arranque. Quien redacta el brief quiere que el proyecto salga adelante, así que, sin mala fe, infla los beneficios y deja los riesgos en letra pequeña.

La corrección es un giro pequeño: escribe el brief, o somételo, desde el futuro en el que ya ha fracasado. Es la lógica del pre-mortem. Ponte a un año vista, da el proyecto por muerto y pregunta «¿qué salió mal?». Las respuestas son, directamente, tu lista de riesgos, tus métricas de parada y tu columna de «no». Así el documento deja de venderte el proyecto y empieza a ayudarte a decidir sobre él.

Test rápido: ¿tu brief decide o solo vende?

Coge el último brief que aprobaste y marca cada frase con la que estés de acuerdo. Cada «sí» es una bandera roja.

1. No recuerdas la hipótesis del proyecto sin abrir el documento.
2. Hay métricas, pero ninguna lleva un umbral de «si baja de aquí, paramos».
3. No aparece en ningún sitio qué cosas el proyecto NO va a hacer.
4. Sabes quién es el jefe de proyecto, pero no quién tiene autoridad para cancelarlo.
5. El sponsor lo defiende como algo personal, no como una apuesta que podría salir mal.
6. Nadie discrepó mientras se escribía.

Cómo leerlo: cero o una marca, tu brief decide. Dos o tres, arranca proyectos pero te costará pararlos: acuerda umbrales antes de seguir invirtiendo. Cuatro o más, no es un brief, es una carta de presentación; reescríbelo desde el pre-mortem.

En resumen: escríbelo desde el futuro en el que salió mal

Los apartados de un project brief (propósito, métricas, alcance, personas, roadmap) son la parte fácil que casi todo el mundo conoce. Lo que separa un brief que sirve de uno que no es si te deja decidir, sobre todo decidir que no. Y la forma más barata de conseguirlo es dejar de escribirlo desde el día del lanzamiento para escribirlo desde el día en que el proyecto fracasó.

¿Cuál fue el último proyecto que seguiste financiando solo porque ya habíais empezado? Si te ha venido uno a la cabeza, el problema no estaba en cómo se gestionó, sino en lo que nunca se acordó al principio. Escribir bien esos criterios no garantiza que alguien los respete cuando ya hay dinero invertido; pero un umbral pactado por adelantado convierte esa decisión en algo que ya habías firmado, no en una pelea nueva.

En SmartWay ayudamos a equipos y comités a arrancar y decidir proyectos sin frenar la organización, con nuestra consultoría Agile y la alineación estratégica que conecta cada proyecto con el resultado que persigue. Si quieres que tus próximos briefs decidan en vez de solo vender, hablemos. 🙂