Gestión de Proyectos: Ágil o Predictivo, ¿es una o la otra?

Desde hace un tiempo a la fecha hemos sido partícipes de una batalla en lo que respecta a las metodologías en gestión de proyectos: por un lado tenemos las predictivas y, por el otro, las llamadas ágiles.

Compartir entrada

Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on facebook
Facebook
(Last Updated On: 25 octubre 2017)

Sobre el Autor

Gastón Martirena

LinkedIn

Foto de perfil de gaston martirena

Es parte del equipo de Gestión de Proyectos de Xn desde 2015, brindando apoyo en la implementación de Oficinas de Gestión de Proyectos Estratégicos (PMO) y la gestión de proyectos para clientes en distintas industrias. Cuenta con más diez años de experiencia Dirección de Proyectos y Gestión del Cambio Organizacional, dirigiendo e integrando el trabajo de equipos de trabajo multidisciplinarios. Ingeniero en Informática, MBA con especialización en Dirección y Estrategia y Professional Scrum Master certificado. Tutor de Planes de Negocios en la Facultad de Administración y Ciencias Sociales de la ORT.

Gestión De Proyectos: Ágil O Predictivo, ¿Es Una O La Otra?

Desde hace un tiempo a la fecha hemos sido partícipes de una batalla en lo que respecta a las metodologías en gestión de proyectos: por un lado tenemos las predictivas y, por el otro, las llamadas ágiles.

Las primeras hacen referencia a prácticas que tienen un ciclo de vida predictivo, también llamado en cascada, en el cual hay un trabajo intenso de planificación al inicio de un proyecto y luego la ejecución y el cierre.

Por otro lado, están los proyectos que tienen un ciclo de vida iterativo o incremental. El primero de los dos incorpora instancias de feedback en el cual se evalúa el trabajo no terminado, mientras que en el incremental se van entregando sucesivas funcionalidades al producto. Cuando estamos ante un ciclo de vida que es tanto incremental como iterativo, decimos que el proyecto tiene un ciclo de vida ágil.

Leer más: ¿Cuál es el valor de la gestión de proyectos y la instalación de una PMO?

¿De dónde viene el empuje actual de las metodologías Ágiles?

La industria de las tecnologías de la información es el lugar propicio para la creación e innovación, también en lo que respecta a metodologías o frameworks, que con el tiempo son volcadas en otras industrias. Es por esto que cuando vemos que una metodología tiene una gran aceptación en esta industria, tenemos que evaluar cuáles son las razones del surgimiento de la misma, para entender cómo será utilizada en las demás industrias.

De esta industria surgió el manifiesto ágil:

Individuos e interacciones sobre procesos y herramientas, Software funcionando sobre documentación extensiva, Colaboración con el cliente sobre negociación contractual, Respuesta ante el cambio sobre seguir un plan.”

La razón del surgimiento se dio por la dificultad en definir con antelación lo que un sistema debe hacer, el tiempo que va a tomar desarrollarlo y cuánto va a costar. Enfoques que fomentan entregas incrementales y un mayor diálogo con el cliente mitigan este problema, lo cual ha propiciado un fuerte crecimiento.

Hoy las metodologías más ampliamente utilizadas en IT son las ágiles, dentro de las más importantes están Scrum, XP y Kanban.

¿Es la respuesta a nuestros problemas?

Una de las primeras preguntas que tenemos que hacernos al elegir el marco metodológico o framework es cuáles son los problemas que tenemos y a dónde queremos apuntar. Luego de esto se debe de elegir la metodología.

Usar Scrum, Lean, Kanban, como cualquier otra metodología simplemente porque están en boga, no nos va a ayudar a cumplir con nuestros objetivos estratégicos, por lo menos no de una forma intencionada.

gestion de proyectos agil o predictivo cascada

Entonces, ¿vamos por ágil o cascada?

Un nuevo aporte a la gestión de proyectos es la herramienta presentada en el Agile Practice Guide de PMI (publicado en septiembre 2016), llamada Agile Suitability Filters Tools.

En la misma se presentan un conjunto de filtros que nos pueden ayudar para definir en qué casos la cultura, el proyecto y la gente con la que estamos trabajando hacen que sea mejor trabajar con un enfoque ágil o predictivo.

Cultura

  • Ante cualquier iniciativa es importante tener la aceptación de un sponsor que entienda y apoye la utilización de un enfoque u otro, como también un liderazgo que pueda impulsarlo.
  • Cuando los stakeholders del proyecto no tienen la confianza de que el equipo puede transformar las necesidades que tienen en productos y servicios exitosos, se pueden incorporar procesos y procedimientos, fomentando enfoques predictivos.
  • Cuando el grupo tiene autonomía en la toma de decisiones, se pueden utilizar enfoques como el ágil.

Equipo

  • Si el tamaño del equipo es grande, posiblemente las metodologías en cascada se adapten mejor.
  • Los equipos ágiles deben de tener todo el conocimiento para poder transformar los requerimientos en funcionalidades, es por esto que requieren mayor experiencia en todos los roles.
  • Para que los enfoques ágiles sean exitosos, es necesario contar con acceso al cliente a diario.

Proyecto

  • Cuanto mayor es la probabilidad de cambio de requerimientos, más adecuado es ágil.
  • Si tenemos una baja tolerancia a fallas del producto o servicio, posiblemente las metodologías en cascada se adapten mejor.
  • Si se pueden realizar entregas incrementales del producto y los clientes van a poder evaluar estas entregas parciales y dar su feedback, se puede considerar ágil como primera opción.

¿Cómo seguimos?

Nuestra experiencia nos marca que no hay una única solución a todos los problemas y oportunidades que hay en las organizaciones. De la misma forma, no hay una metodología o enfoque que sea el mejor para todos los casos.

Hay veces en que la mezcla de los enfoques ágiles y predictivos es la mejor solución. En uno de nuestros clientes, que realiza proyectos arquitectónicos, hemos descubierto que los mismos pasan por etapas tan distintas que pueden requieren diferentes enfoques. En la etapa de anteproyecto se requiere mucho dinamismo y hay mucho cambio, para lo cual se usan enfoques ágiles.

En etapas posteriores, con todos los planos ya disponibles, se usan metodologías en cascada, dado que está claro lo que hay que hacer. A nuestro juicio, sea cual sea el enfoque, las personas están antes que las metodologías, procesos y herramientas.

Por esto, el factor clave de éxito es poder involucrar a las personas para que sean ellas las que definan cuál es el enfoque que se adapta más a su realidad.

Leer más: Desafíos de Implementación de una PMO

Artículos relacionados:

Diseño de un Programa OKRs — una herramienta para ejecutar la estrategia ágilmente

Claves de la Comunicación en Proyectos

Contenidos de la Entrada

¿Te gustó esta entrada? ¡Compártela!

Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on facebook
Facebook

Respuestas

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

  1. Hola.
    Entiendo que es sumamente complejo el elaborar una comparación entre ambos tipos de metodologías en un espacio tan reducido; hay un inevitable riesgo de simplificar elementos o definiciones. Partiendo de esa base, creo importante de todas formas puntualizar algunos conceptos aquí vertidos.
    Creo que colocar Lean y Scrum en el mismo punto, como metodologías comparables no es lo mejor. Lean es una metodología, Scrum es un instrumento/herramienta, con sus artefactos, etc. para llevar adelante un proceso iterativo o «ágil». Podrían utilizarse también otros. Y podrían utilizarse además con o sin el objetivo de procurar aplicar Lean.
    Una precisión adicional que creo aplica es que Lean no surge de la industria IT; surge en particular en Toyota, en su área de fabricación de vehículos, el «Just in Time». Al igual que los Kanban Cards.
    Dado su éxito luego hubieron múltiples actores que procuraron su adaptación no solamente a otras industrias (como IT) sino también a la cultura occidental.
    Scrum surge como una forma de aplicación de conceptos que también son centrales en Lean y como una forma -entre otras- de facilitar el alineamiento con los conceptos que sustentan Lean.
    Coincido totalmente en la necesidad de evaluar en cada caso cuál es el mejor conjunto de herramientas y metodologías a aplicar.
    Creo sin embargo que -cada vez más-, la realidad es muy cambiante y desde etapas más tempranas. Las metodologías del tipo «en cascada», cada vez requieren mayores y más permanentes adaptaciones en etapas muy iniciales. Y esas permanentes adaptaciones… no solamente son muy desmotivantes para quienes las deben realizar, sino que son -fundamentalmente- muy costosas y van minando la credibilidad de quienes las utilizan para su trabajo. Y ese comportamiento es consecuencia que la propia realidad impone e impacta en ese tipo de metodologías. Sin embargo, en las metodologías ágiles es la esencia en la que se sustentan.
    La realidad actual, prácticamente en cualquier área, cambia muy rápido y constantemente, el empoderamiento de las tareas por parte de quienes las realizan es cada vez más necesario, los estándares de calidad también, la transparencia de la información que fluye y se genera en todos los sectores y el compromiso de todos los actores son elementos cada vez más necesarios; en algunos casos, imprescindibles. Todos estos componentes son la esencia de Lean, por sobre los instrumentos que se decida utilizar.
    La mayor dificultad que en mi opinión existe para su aplicación más masiva es el fuerte cambio que supone la aplicación de metodologías ágiles en la forma de hacer las cosas y de pensar las cosas. En lo mental. En el cambio de formas de pensamiento y hasta en las formas de cómo se concibe y organiza el rol de todos los niveles de la organización y su gente.
    Quedó muy extenso esto, espero haya sido un aporte.
    Saludos

    1. Daniel, cómo andas? Muchas gracias por el comentario y el tiempo que te tomaste.

      Lo que pretendía transmitir el artículo es que antes de ir por una metodología, un framework o una herramienta tenemos que evaluar ciertos aspectos referentes a la cultura, el equipo de trabajo y el proyecto, podremos evaluar más, pero por lo menos deberíamos evaluar estos, luego de esto decidir por el enfoque que se adecue más a nuestras necesidades.

      En varios proyectos pasa lo que vos mencionas y se menciona en el artículo, la probabilidad de cambios de los requerimientos es muy alta y hace muy complejo la utilización de un enfoque tipo cascada. Si bien esto se da cada vez más, no tenemos que dar por sentado que va a pasar siembre. Un ejemplo de lo último podría ser un proyecto arquitectónico, una vez que está definido que es lo que vamos a construir la probabilidad de cambios no es tan alta como ante la mayoría de los proyectos de software, y esto hace que un enfoque ágil no sea a priori la mejor solución.

      Por último, me parece muy importante lo que mencionas de la cultura y la gestión de cambio que hay que realizar ante cualquier aplicación masiva de una nueva forma de trabajar. En el artículo de Pilares de Cambio Organizacional podes se plantean las bases para que este tipo de cambios sea exitosa https://xnpartners.com/cambio-organizacional-change-management/pilares-de-cambio-organizacional-change-management/.

      Nuevamente, mil gracias por el comentario.

      Saludos,

Suscríbete al Newsletter de Xn

Mantente al tanto de próximos eventos, capacitaciones, y recibe artículos sobre liderazgo y gestión diréctamente a tu inbox. Jamás compartiremos tu información.