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.
Este artículo viene a cuento por una historia que compartiré.
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.
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.
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.
Acá hay unos momentos de análisis. Sin imponer un orden serían los siguientes.
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.
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.
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.
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»).
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.
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.
Lo que muestra la evidencia y la práctica es que Agile es una decisión, no un deseo ni una imposición. Y aunque algunos dicen que Agile implica amabilidad por sobre servicio, y diligencia en lugar de resiliencia, la verdad que todo proyecto son personas interactuando y conversando.
¿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?
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.
Proudly powered by WordPress