Cómo elegir el ciclo de vida de un proyecto

«¿Ustedes trabajan en cascada o son ágiles?» Es la pregunta que abre casi toda reunión de arranque, y está mal planteada. Los ciclos de vida no son dos bandos ni cinco escuelas rivales: son puntos de una misma escala, y lo único que decide dónde te paras es qué tan claros están tus requisitos y cuándo necesita el negocio recibir valor.

Elegir bien no es un asunto de moda metodológica. El ciclo de vida define cómo vas a manejar los cambios, cada cuánto vas a ver a los interesados y cómo vas a controlar el riesgo durante meses. Equivocarse ahí es caro.

Los cinco, en una frase cada uno

• Predictivo (cascada). Alcance, tiempo y costo se fijan al inicio. Un solo entregable al cierre y control estricto de cambios.
• Iterativo. Repite ciclos sobre el mismo producto para entender mejor qué hay que construir. Su pregunta es qué.
• Incremental. Entrega partes funcionales sucesivas, cada una utilizable. Su pregunta es cuándo.
• Adaptativo (ágil). Los requisitos se elaboran de forma continua en ciclos breves, con interesados metidos todo el tiempo.
• Híbrido. Frentes distintos del mismo proyecto, cada uno con su propio enfoque.

La distinción que más se confunde es la del medio. Iterativo e incremental no son sinónimos. El iterativo pule la solución: hace prototipos, prueba, ajusta, y recién entonces construye. El incremental ya sabe qué construir y lo entrega por pedazos que sirven desde el primer día. Uno busca acertar; el otro busca llegar temprano.

Dos preguntas, y ya estás decidiendo

El árbol completo cabe en tres preguntas, pero las dos primeras hacen casi todo el trabajo:

1. ¿Los requisitos están definidos y se van a sostener? Si la respuesta honesta es sí —normalmente porque una norma o un contrato los impone—, estás del lado predictivo.
2. ¿El negocio recibe algo utilizable antes del final? Si no, predictivo. Si sí, incremental.

Cuando la primera respuesta es no, la pregunta pasa a ser si los interesados están disponibles de verdad para dar retroalimentación continua. Si lo están, adaptativo. Si no lo están y lo que falta es entender el producto, iterativo.

Puedes recorrer ese árbol en el selector de ciclo de vida que acompaña este módulo: tres preguntas y te devuelve el resultado con la justificación escrita, lista para pegar en un acta.

Por qué la respuesta real suele ser «híbrido»

Un caso que se repite en la banca colombiana. Un proyecto de modernización del canal digital de empresas tiene dos frentes bajo el mismo presupuesto:

• La malla regulatoria. Reportes fiscales, auditoría, depuración de registros. La norma exige que la lógica esté cien por ciento definida, documentada y validada jurídicamente antes de cualquier despliegue. Aquí un backlog abierto no es innovación: es un hallazgo del regulador esperando a pasar.
• La experiencia de usuario. Portal y app para aprobar nóminas corporativas. Nadie sabe todavía cómo debe verse la pantalla; se descubre con prototipos, y los requisitos que importan son de desempeño y seguridad. Aquí congelar el alcance seis meses antes garantiza entregar algo que ya nadie quiere.

Mismo proyecto, dos naturalezas. Forzar un solo enfoque rompe uno de los dos lados siempre. Por eso la respuesta correcta es híbrido: predictivo en el frente regulatorio, adaptativo en el de producto.

Y ahí está el punto fino: el híbrido no falla en los extremos, falla en la costura. Lo que hay que escribir desde el primer día es dónde termina un frente y empieza el otro, y cómo se integran. Esa frontera es el verdadero entregable de la decisión.

Antes del ciclo de vida está la autorización

Ninguna de estas discusiones importa si el proyecto no existe formalmente. El acta de constitución —el project charter— es lo que autoriza el proyecto y le da al director la facultad de usar recursos de la organización. Es el punto de no retorno: aprobada el acta, la empresa compromete plata y gente.

Sus once elementos se resumen en cuatro preguntas que alguien va a hacer tarde o temprano: qué vamos a lograr y cómo se mide, hasta dónde llega el proyecto, quién decide que está bien hecho, y con qué autoridad cuenta el director. Si el acta es ambigua en cualquiera de esas, el proyecto va a discutir lo mismo durante toda su vida.

Al lado del acta va la gestión de interesados, que no es una lista de correos: identificar, involucrar y monitorear son tres actividades distintas y continuas. Un interesado que no fue identificado a tiempo no desaparece; aparece al final, cuando el cambio ya es caro.

Los requisitos son la materia prima del alcance

El PMBOK los clasifica en cinco categorías, y usar la correcta evita la mitad de las peleas de aceptación:

Los no funcionales son los que más se olvidan y los que más caro cobran: seguridad, desempeño, disponibilidad, retención. Nadie reclama por una pantalla fea tanto como por un sistema lento o por un dato que no se pudo auditar.

Antes de entrar a la línea base, cada requisito debe ser inequívoco, medible, trazable, coherente y aceptado. «El sistema debe ser rápido» no cumple ninguno de los cinco.

La EDT: entregables, no tareas

La estructura de desglose del trabajo descompone el alcance total en pedazos cada vez más pequeños hasta llegar al paquete de trabajo, el nivel donde el trabajo ya se puede estimar, programar y controlar.

Hay un malentendido que vale la pena matar: en la EDT, «trabajo» significa los entregables, no las actividades. La EDT no es un cronograma ni una lista de tareas: es el mapa de lo que va a existir cuando el proyecto termine. Las tareas vienen después, y salen de ahí.

Y la regla que ordena todo el alcance: el proyecto incluye todo el trabajo requerido y únicamente el trabajo requerido. La primera mitad evita que falten cosas; la segunda, que el proyecto crezca solo.

Una nota sobre la edición

Esta guía usa la clasificación de ciclos de vida de la sexta edición del PMBOK, que sigue siendo la referencia más clara para procesos y grupos de procesos. La séptima edición, publicada en 2021, cambió el enfoque: pasó de procesos a principios y dominios de desempeño, y el detalle de los enfoques de desarrollo se trasladó en buena parte a la guía de prácticas ágiles. Los cinco ciclos siguen siendo los mismos; lo que cambió es dónde están explicados. Si vas a citar el estándar en un documento formal, verifica en cuál de las dos ediciones está el texto que citas.

PMBOK es una marca registrada del Project Management Institute, Inc. Este material es educativo y no está patrocinado ni avalado por el PMI.

Para llevar

Si te queda una sola idea: el ciclo de vida no se escoge por convicción, se deduce de tus requisitos y de tus entregas. Y cuando el proyecto tiene un frente que la norma obliga a fijar y otro que el usuario tiene que descubrir, la respuesta madura no es elegir un bando, es dibujar la frontera entre los dos.

El módulo anterior, sobre cómo nace un proyecto y qué lleva un business case que sí aprueban, está en Cómo nace un proyecto: de la idea al presupuesto aprobado.