Hice clase a fines del 2021 de gestión de proyectos ágiles a técnicos de I+D. Me tocó enseñarles cómo se identifica un proyecto ágil lo cual es muy útil en profesionales que deben manejar grandes presupuestos y siempre en condiciones de alta incerteza y riesgo.
En el examen final (era una diplomatura), uno de ellos expuso su proyecto que a todas luces era ágil, pero su decisión fue hacerlo de forma predictiva. La verdad que acertó.
Y además aplicó bien lo que quiero explicar un poco: diseño del proyecto.
En suma, aquí termino explicando una metodología para identificar si un proyecto debe y puede ser ágil.
Ingeniería de Proyectos y Diseño Proyectual.
La ingeniería de proyectos se preocupa de muchas cosas que simplemente limitarse a la gestión del proyecto. Abarca el diseño y la dirección del proyecto.
En este artículo daré una mirada al proyecto ágil desde el diseño proyectual o el diseño del proyecto. O sea, es algo así como preguntarse ¿cómo puedo saber si mi proyecto debe ser ágil?
La verdad no hay receta. Otra cosa es que hay mucha emoción por decir que todo proyecto debe ser ágil o que los llamados proyectos predictivos son un desastre siempre. A veces siento que le llaman proyecto ágil a cualquier acción organizacional o de ingeniería que alguien lo ve difícil o para tapar que no puede hacerlo.
Para seguir con claridad hay que aclarar algo, el proyecto ágil no existe. Ágil o el marco Agile o el planteamiento Agile es para diseñar productos. No es para corporificar el producto final del proyecto que nace de una intención a la resolución de un conflicto.
Aquí ya nos pusimos difíciles.
Corporificar es una palabra de la cual se apropia la ingeniería de proyectos (de hecho la palabra no existe en castellano, se podría decir viene de to be bodyness -pero ni idea-). En palabras llanas es construir algo que sea útil y de valor, que luego veremos con los recursos a mano cómo queda y qué sale del proceso creativo propio de cada proyecto.
Y cómo construir algo no es tan claro al inicio de un proyecto cualquiera, siempre hay un paso importante que es intentar dilucidar ciertas características que influirán en la ejecución de la gestión de un proyecto que permitirán saber cómo organizarlo.
Y aquí entra el diseño proyectual o más bien una parte, pues ahora comentaré el diseño conducente a dilucidar la gestión, mientras existe también el diseño para dilucidar el producto final deseado.
El camino a un proyecto ágil.
Desde una perspectiva de la ingeniería de proyectos, la gestión de un proyecto no la define el gestor del proyecto, sino el proyectista. Por supuesto el gestor del proyecto puede influir pero será luego de que comience la ejecución de la gestión del proyecto.
Ojo, que diseñar un proyecto no es planificarlo. El proyectista diseña en base a un objetivo o meta del proyecto que debe dilucidar, el gestor del proyecto planifica en función de un objetivo que le han dado desde el diseño. Otra cosa es que luego el objetivo cambie, pero el fin probablemente no.
Dicho esto debemos tener presente que el proyecto ágil es el apelativo que se le da a un proyecto cuyo 100% -es lo ideal- actividades se rigen por el Manifiesto Agile.
Esto implica varias cosas. Un proyecto en general, cuando se gestiona, tiene una dimensión de ejecución de la gestión o el camino para lograr un objetivo y una dimensión de la ejecución técnica o el camino para corporificar el resultado.
Así se habla de que un proyecto ágil tiene la dimensión de gestión que puede denominarse gestión ágil del proyecto que en suma es hacer que la gestión del proyecto tenga agilidad. Y se habla de la gestión técnica del proyecto que ya es hablar simplemente de . que la consecución, concreción, materialización del resultado sigue un proceso ágil aplicando técnicas y herramientas consideradas ágiles (como Scrum, Kanban, Lean, entre otras).
Si se tiene presente lo anterior, queda claro el motivo por el cual hay confusión y solapamiento entre el project manager y los roles Scrum de Product Owner y Scrum Master.
Por tanto, al hablar del diseño proyectual de un proyecto ágil, no estamos hablando de que ya nació ágil, sino de que debemos ver si vale la pena que sea ágil. Y con esto aclarado ver si su gestión debe o no ser ágil, y ver qué herramientas ágiles emplear (que al final siempre son las mismas Scrum, Kanban y un poco de Lean -pero hay muchas más-).
Este camino de saber si se puede ser ágil viene a continuación.
El camino para saber si un proyecto debe ser ágil.
Acá hay unos momentos de análisis. Sin imponer un orden serían los siguientes.
Momento : Análisis de Conocimiento.
Acá es investigar qué se sabe del tema o intención a resolver. Lo ideal es investigar de productos, hacer un scan de tecnologías, investigar qué se sabe del problema o del tipo de problema (si es simple, complejo o wicked) o de cosas aparentemente relacionadas, y cualquier conocimiento existente.Este momento es importante pues muchas veces un proyecto se ejecuta como Ágil porque se piensa que es complejo o no hay conocimiento, cuando en realidad se obró por pereza y sí habían soluciones.
Momento : Análisis de Complejidad e Incerteza.
Acá se trata de imaginarse cómo se podría sería la vida en el proyecto. Es un análisis esencialmente multidimensional de muchas cosas. Lo mejor es aplicar las siguientes herramientas, cada una de las cuales busca responder ciertas preguntas.Modelo CYNEFIN.
¿Conozco las relaciones del trabajo de gestión a realizar, del producto a crear y de la forma de hacer el producto?
¿Conozco realmente que se tiene que hacer después de que haga algo?
¿Conozco realmente que se tiene que hacer después de construir algo?
Matriz de Complejidad de Stacey.
¿Cuál es la incerteza que se manejara/manejaría al tomar decisiones de gestión del proyecto y respecto de aspectos relativos a la consecución del resultado?
¿Cuán claros serán/serían los acuerdos a conseguirse durante la gestión del proyecto y respecto de aspectos relativos a la consecución?
Matriz de Incertidumbre de Wisocki.
¿Qué se necesita hacer?
¿Cómo hacerlo?
Matriz de Requerimientos.
¿Qué tanto sabemos de los requerimientos?
¿Cuál es mi nivel de incerteza?
Filtro de Idoneidad.
Cultura. ¿Existe un ambiente favorable con aceptación del enfoque y confianza en el equipo?
Equipo. ¿Es el equipo de un tamaño adecuado para tener éxito en la adopción de Ágil, sus miembros tienen la experiencia necesaria y el acceso a los representantes del negocio a fin de tener éxito?
Proyecto. ¿Existen altos índices de cambio? ¿Es posible la entrega incremental? ¿Qué tan crítico es el proyecto?
Todo este análisis permite saber si el responsable del proyecto podrá y tendrá los apoyos y elementos organizacionales, políticos y técnicos para acometer un proyecto de forma ágil.
Este momento es importante pues evitar iniciar un proyecto en modo ágil asumiendo que todas las personas y el contexto aplaudirán y recibirán bien el modo ágil.
Momento : Análisis de recursos, experticia y paciencia del cliente.
Acá se trata de afinar la información para saber que si el proyecto es ágil podrá ser ejecutado con enfoque iterativo o incremental. Algo que no es menor.Se busca claridad en saber si los recursos para uno u otro enfoque se podrán disponer. Asimismo la experticia en este tipo de enfoques especialmente si el equipo podrá soportar uno u otro enfoque. Y por último, si el cliente tendrá la paciencia para uno u otro enfoque, o ninguno.
Este momento es importante pues podrán haber muchas ganas de aplicar Agile, pero hay que ver si se sabe cómo ejecutar uno u otro enfoque y tener claro si el cliente aceptará en tiempo real ser ágil (una cosa es aceptar un enfoque ágil porque se lo dice el consultor o pues está de moda y ala, vamos para adelante, y otra es decir, no me vengas con tatas reuniones para que tu averigues lo que yo quiero).
Momento : Análisis de Mindset.
Acá se trata de averiguar en profudidad si el equipo ágil tiene claro esto de ser ágil. Una cosa es decirlo y otra serlo, vivirlo y difundirlo.Este momento es importante en muchos proyectos llamados ágiles, se descubre luego de unas semanas que el equipo pensaba que esto de ser ágil era un continuo de reuniones para ir mejorando ad-infinitum, o simplemente que no está apto para el momento real de resiliencia que surgen en los proyectos ágiles, o que vemos que el liderazgo servicial en realidad es un liderazgo ególatra.
Síntesis: Agile es una decisión.
La siguiente figura intenta sistematizar los momentos, pero en la práctica no hay un orden, pero si deben aplicarse todos. Si pueden variar las técnicas para cumplir con la meta de cada momento.
Además se ha visto que a nivel de Oficina de Proyectos, esta metodología o proceso ordena muchas cosas que en un proyecto ágil se consideran vacíos o temas conflictivos.
Además se aprecia que una cosa es creer que un proyecto ágil es aplicar Scrum, cuando en realidad esa es la parte técnica de la ejecución del proyecto y no tiene nada que ver con la gestión. Es decir, confundir reuniones Scrum en modo ágil, con que sean las reuniones de gestión del proyecto ágil. Se podrán solapar o aprovechar pero hay fines distintos.
Además se aprovecha mejor el potencial del planteamiento ágil y no se malgastan recursos siendo ágil cuando quizás no sea necesario ser ágil.
Además se aclara mejor la expresión Gestión del Proyecto Ágil que muestra que muchas veces se gestionan actividades técnicas ágiles de forma no-agil, versus la expresión Gestión Ágil del Proyecto que explicita que muchas veces cualquier proyecto se puede gestionar con agilidad sin que las actividades lo sean.
¿Aportarías otro momento?
¿Te atreves a dar un orden a los momentos?
¿Qué pasa en tu organización?
¿Habías pensado en esta mirada?
¿Conocías de la ingeniería de proyectos?
Resúmenes previos.
t=0: (Noviembre 21, 2010), donde formulé o más bien intenté exponer el concepto de proyecto necesario a trabajar, las escuelas de pensamiento, los niveles de investigación, y los elementos del objeto de estudio (el proyecto).
t=1: (Mayo 20, 2012), donde recopilé post relacionados con fundamentos proyectuales, elementos de la teoría sistémica de proyectos de Blasco y, diversas aplicaciones de su pensamiento en diversos campos y áreas de conocimiento.
t=2: (Abril 30, 2013), donde abordé y mostré el pensamiento más detallado de la epistemología de proyectos de Blasco analizando su visión del proyecto como la dualidad entre un proyectar y un proyectado.
t=3 (Enero 30, 2014), donde resumí varios post del tema relacionados con las bases fundacionales e históricas del pensamiento de Blasco.
t=4 (Abril 23, 2015), donde presenté cómo se sitúa la propuesta de ciencia proyectual sistémica con relación a un modelo de Éxito en los proyectos.
Una Agenda Forzada (Enero 24, 2016), donde resumo varias ideas clave en ingeniería de proyectos.
t=5 (Enero 16, 2017), donde comparto ideas sobre PMO u Oficinas de Proyectos.
t=6 (Septiembre 10. 2018), donde resumo distintas perspectivas sobre -o relativas a- los proyectos de innovación.
t=7 (Diciembre 31, 2021), donde relaciono los proyectos de innovación con el nuevo enfoque de la versión 7 del PMBOK y el modo Agile.
Proyectando innovaciones para personas, estrategia y sociedad
Espacio de reflexión personal dedicado a la investigación e innovación aplicada cuando se vinculan a la ciencia proyectual, y se aplican al desarrollo de las personas, la gestión estratégica y la sociedad.
Dirección de correo electrónico:
Suscribir a este blog
Proudly powered by WordPress
Fuente: este post proviene de Blog sobre diseño de proyectos, donde puedes consultar el contenido original.
¿Vulnera este post tus derechos? Pincha aquí.
Creado: