Selección del Ciclo de Vida de un proyecto (Predictivo o Ágil). Al comienzo de un proyecto, en primer lugar, el equipo (o la PMO – Oficina de Gestión de Proyectos, si existe) tiene que determinar el ciclo de vida más apropiado, es decir, el que proporciona mayor probabilidad de éxito. El artículo proporciona algunas guías para aclarar la toma de decisiones.

1. 1
Enero 2019
Selección del Ciclo de Vida de un proyecto (Predictivo o Ágil)
Al comienzo de un proyecto, en primer lugar, el equipo (o la PMO – Oficina de Gestión de Proyectos, si
existe) tiene que determinar el ciclo de vida más apropiado, es decir, el que proporciona mayor
probabilidad de éxito.
Podemos distinguir varios ciclos de vida:
Predictivo:
Es el clásico enfoque en cascada. Cuando se conocen los requisitos desde el comienzo, la mayor parte
de la planificación se puede realizar por adelantado, luego se ejecuta de forma secuencial, y se entrega
los resultados. Puesto que el recorrido es conocido y predecible, permite planificar y ejecutar las
actividades optimizando recursos y tiempos. Se aplica por ejemplo de muchos de los proyectos de
ingenierías y proyectos “llave en mano”.
Iterativo:
Se trata de obtener una retroalimentación temprana a partir de un trabajo aun sin terminar. Por ejemplo,
la elaboración de prototipos que ayudan a validar la viabilidad de un nuevo producto, permite obtener un
feedback del cliente, o detectar como lo percibe el mercado. Mas que definir unos requisitos detallados,
se trata de detectar las soluciones más apropiadas a problemas existentes, y para ello presentar algo
rápido al mercado que lo valida o rechaza. Normalmente implica cambios frecuentes a los requisitos.
Por ejemplo, la metodología Design Thinking aplica este enfoque. Cuando existe un problema o una
oportunidad establece una serie de pasos para descubrir/diseñar la mejor solución o productos
innovadores. Así plantea una primera fase de para entender el problema (empatizar y definirlos), una
segunda fase de explorar/diseñar soluciones (creatividad, idear, prototipar, probar), para validar el
producto al menor coste, y en caso de aceptación, una tercera fase de Implementación. Puesto que el
producto/solución a desarrollar no está claramente definido, se prioriza la creatividad y el aprendizaje
en el proceso antes que la velocidad de entrega.
Dentro de Lean Start Up, el desarrollo del Producto Mínimo Viable (PMV) es otro ejemplo. Se trata de
lanzar un nuevo producto con el mínimo esfuerzo (centrándose en las características relevantes del
producto), para evaluar las posibilidades de aceptación frente a los consumidores. El objetivo es evaluar
las hipótesis fundamentales de un negocio, aprender rápidamente y sin arriesgar demasiado.
Incremental:
Se trata de proporcionar cuanto antes las funciones que aportan mas valor al cliente de forma que las
pueda utilizar de inmediato. En algunos casos, el esperar hasta tener una solución completa a un
problema, o un producto nuevo para el mercado, puede retrasar su utilización e impedir aprovechar
oportunidades de negocio, o por ejemplo llegar al mercado más tarde que la competencia.
En alguno de nuestros proyectos de mejora en la gestión, con el objeto añadido de conseguir una
certificación ISO 9001, desarrollamos inicialmente aquellos aspectos que consideramos más valiosos
(Planificación Estratégica, Riesgos, Procesos Clave) y los entregamos rápidamente. El objetivo era
aportar valor y facilitar el feedback del cliente sobre la forma en que la organización estaba asimilando los

2. 2
Enero 2019
cambios. Este tipo de entregas incrementales, además nos permitió detectar dónde el cliente percibía
más valor, y por lo tanto dónde había que dedicar más esfuerzo.
Como en el caso del Producto Mínimo Viable, el equipo puede optar por entregar una versión parcial del
producto a algunos clientes más tolerantes, a sabiendas de que no está completo, pero que cubra los
requisitos más importantes. La retroalimentación del cliente ayuda a entender mejor las necesidades del
cliente para las siguientes versiones del producto.
En el caso de desarrollo de software, por su propia naturaleza es posible que cada parte (módulos de
valor) se pueda desarrollar, probar y validar, e ir integrando con el resto de módulos en etapas sucesivas.
No todos los productos tienen esas características modulares y permiten entregas incrementales.
Fuente: Guía del PMBOK: Diferencias en función del tipo de ciclo de vida
Híbridos:
En algunos proyectos se mezclar diferentes enfoques en los mismos proyectos. Se puede combinar
enfoque iterativo por ejemplo en la fase de desarrollo de requisitos, o búsqueda de un diseño, y predictivo
una vez que la solución se ha encontrado y se trata de fabricarla e implantarla.
En realidad, la mayoría de los proyectos aplican una combinación de todos ellos.

3. 3
Enero 2019
La conclusión es que es necesario conocer bien las características de los proyectos en tu negocio
(proyectos de ingeniería, de desarrollo de software, proyectos de innovación, etc.) y su grado de
incertidumbre y predictibilidad, para elegir el ciclo de vida más apropiado.
Recomendaciones para aplicar el enfoque Ágil
Desde luego, no tengo una receta perfecta, pero existen buenas Ideas de expertos que pueden ser útiles:
 Entender la cultura de la organización, y su posición ante el cambio. Conocer las prioridades de los
diferentes grupos de Interés (Dirección, Equipos de Proyecto, Departamentos, Entorno del negocio, tipos
de proyectos, etc.), para evaluar la oportunidad y establecer las técnicas y la velocidad de aplicación.
 Educar a gerentes y líderes en mentalidad ágil. Hay que asegurar el posicionamiento a favor del cambio
y que este este posicionamiento sea activo.
 Prepararse para el cambio. Patrocinio de la Dirección. Prácticas de gestión del cambio. Los enfoques
ágiles encajan bastante bien con empresas formadas en metodologías Lean.
 Definir los criterios de aplicación. En qué tipo de proyectos podemos aplicarlo en nuestras
organizaciones. El equipo de soporte (o la PMO) debería tener dichos criterios y orientar en la decisión.
Identificar en que proyectos predominan algunas características como la velocidad y la flexibilidad,
sobre las típicas de alta calidad o coste.
 Formar a los equipos en el enfoque ágil y en las técnicas y buenas prácticas asociadas. Hay que
preparar a los equipos en nuevas dinámicas de trabajo y preparar el entorno/contexto. Empoderar a los
equipos. Solo en entornos de autogestión pueden los equipos sentirse seguros, reflexionar y aprender.
En organizaciones muy funcionales/departamentales puede ser más complicado establecer equipos
multifuncionales y autogestionados. Sin la formación adecuada, el desafío y cambio de mentalidad que
supone, puede provocar una potente resistencia al cambio.
 La adopción de la agilidad debe estar basada en el conocimiento, en las experiencias y buenas prácticas
que han funcionado bien en otras organizaciones, y no en el mero instinto.
 La tecnología puede ser un buen facilitador (Herramientas Kanban, etc.) pero nunca el conductor o
determinante del cambio.
 El cambio es disruptivo y nada fácil de llevar adelante, muchas organizaciones han fracasado. Llevar
adelante un Proyectos piloto para preparar y foguear a los equipos de proyecto y aprender. Introducción
gradual de prácticas ágiles donde sea posible. Esto puede ayudar en el cambio cultural y seguramente
facilitar los cambios organizativos.
 Aprender y mejorar durante el propio proyecto, y de los proyectos fallidos.
 Definir una hoja de ruta: Definir cómo hacer la transición (método completo, o gradual, ejemplo tableros
Kanban)
 El Mentoring o apoyo externo puede ser de gran ayuda en la implantación (mejoras de hasta un 35% de
los éxitos del proyecto).
 Hay que ser consciente que la adopción de metodologías ágiles por si mismo no garantiza el éxito de los
proyectos.
Fuentes
Guía PMBOK® (Guía de los Fundamentos para la Dirección de Proyectos), PMI®
Guía Práctica de Ágil, PMI®
The Agile Enterprise, Dan S. Roman
AUTOR: Fernando García
LinkedIn: es.linkedin.com/in/fernandogarciafgg
Twitter: @fer_gargar