Gestión de proyectos: definir bien el proyecto antes de empezar

Esta serie parte de ideas de la Guía de Harvard Business Review sobre gestión de proyectos. Son notas con mi propia lectura y experiencia, no un resumen del libro.

«Todo con orden.» — Susana Siller

Es una frase que me acompaña en cada proyecto. Para mí, el orden empieza antes de escribir una línea de código o de agendar un evento: empieza por definir bien qué se va a hacer. Hay una escena que se repite: arranca un proyecto con entusiasmo, el equipo empieza a construir y tres meses después descubren que cada quien entendía algo distinto. El retraso no se debe a que trabajaran lento, sino a que nunca se puso de acuerdo, por escrito y de forma clara, qué se iba a lograr. Esa fase previa, a veces incómoda, es donde se ganan o se pierden la mayoría de los proyectos.

El problema: empezar por la solución

Casi todos los proyectos nacen como una solución: "necesitamos un portal", "hay que migrar a la nube", "vamos a usar IA". Pero una solución no es un objetivo. Detrás debería haber una pregunta: ¿qué problema cambia si esto sale bien? Un ejemplo:

• Solución: "Construir una app móvil para clientes."
• Problema real: "El 40 % de las llamadas a soporte son consultas de estado de pedido que el cliente podría resolver solo."

Con el segundo planteamiento, quizá la app es la mejor opción, o quizá bastaba un correo automático. Si no defines el problema, no puedes comparar opciones ni saber si funcionó.

Los elementos de una buena definición

1. Objetivo claro y medible

Una frase que cualquier persona del proyecto pueda repetir. Si hace falta una diapositiva para explicarlo, aún no está claro. Mejor si incluye un número y una fecha: "Reducir un 30 % las consultas de estado de pedido en soporte antes de junio."

2. Alcance: lo que entra y lo que no

Definir lo que no se hará es tan importante como lo que sí. El alcance sin límites crece solo, pedido tras pedido. Una lista explícita de "fuera de alcance" te da con qué responder cuando alguien dice "ya que estamos, ¿podrías también…?".

3. Criterios de éxito

Responde: ¿cómo sabremos que terminamos y que valió la pena? Distingue entre:

• Entregables: lo que se produce (un sistema, un informe).
• Resultados: el cambio que provoca (menos llamadas, menos errores).

Un proyecto puede entregar todo lo prometido y fracasar en resultados.

4. Quiénes están involucrados

Identifica al patrocinador (quien pone el respaldo y los recursos), a las personas que usarán el resultado, al equipo y a quienes pueden bloquearlo. Cada grupo necesita algo distinto de ti.

5. Restricciones y supuestos

Las restricciones son límites conocidos: presupuesto, fecha, personal disponible. Los supuestos son cosas que das por ciertas sin haberlas confirmado: "el proveedor entregará la API en marzo". Los supuestos no escritos son los riesgos más peligrosos, porque nadie los vigila.

El triángulo y sus incómodas decisiones

Alcance, tiempo y costo se afectan entre sí. Si alguien exige más alcance en menos tiempo con el mismo presupuesto, algo tiene que ceder, y casi siempre lo que cede es la calidad, sin que nadie lo haya decidido. Pregunta desde el inicio: ¿cuál de los tres es el menos flexible? Si la fecha es fija (un evento, una normativa), entonces el alcance es lo que se negocia. Tener esa conversación pronto evita sorpresas.

Una plantilla breve

Antes de arrancar, intenta llenar una página con:

| Pregunta | Tu respuesta | |---|---| | ¿Qué problema resolvemos y para quién? | | | ¿Cómo medimos el éxito? | | | ¿Qué incluye y qué no? | | | ¿Quién es el patrocinador y quién decide? | | | ¿Qué supuestos estamos haciendo? | | | ¿Cuál es la restricción más rígida? | | | ¿Cuáles son los 3 riesgos principales? | |

Si no puedes responder alguna, ya encontraste dónde se va a torcer el proyecto, y encontrarlo hoy es barato.

Errores comunes

• Aprobar sin leer. El patrocinador firma una definición que nunca revisó con cuidado, y después discute el alcance.
• Definición enorme que nadie lee. Una página clara vale más que cuarenta ambiguas.
• Tratar la definición como inamovible. Debe poder cambiar, pero a través de un acuerdo explícito, no por deslizamiento.
• Saltarse a los usuarios. Si nunca hablas con quien usará el resultado, estás adivinando.

Cuando no alcancé a mapearlo todo

Me pasó en un proyecto con una fecha que no se podía mover. Para cumplir los tiempos no alcanzamos a mapear todos los procesos con el cuidado que merecían ni a identificar a todas las áreas involucradas. Entregamos en tiempo, que era justo lo que el cliente quería, y quedó contento con el resultado. Yo, sin embargo, sentí que lo que entregué estaba incompleto: no cumplía con mis estándares personales. Lo que faltaba y lo que había que mejorar se fue trabajando en funcionalidades posteriores. Aprendí que el alcance se puede recortar de forma consciente, pero lo que no conviene recortar es entender el problema: quién está involucrado, qué procesos toca y qué significa "terminado". Eso es lo que permite decidir qué se queda para después sin que se vuelva una deuda escondida.

También por eso valoro tanto la trazabilidad: poder ir de la necesidad al entregable (de atrás hacia adelante) y del entregable a la necesidad que lo originó (de adelante hacia atrás). Cuando hay trazabilidad, recortar o priorizar es una decisión con información; cuando no la hay, es una apuesta.

Para finalizar

Definir el proyecto no es burocracia: es el momento más barato para equivocarte. Una página honesta con objetivo, alcance, éxito, supuestos y riesgos hace que todos jalen hacia el mismo lado. En el siguiente artículo de la serie veo cómo armar el equipo y repartir responsabilidades una vez que el rumbo está claro.