Cómo agilizar cualquier proyecto: 10 estrategias clave

¿Estás trabajando en un proyecto tradicional? ¿Te preocupa la efectividad de los resultados? ¿Ves riesgos de no cumplir con los plazos y alcance comprometido? ¡Sigue leyendo! En este artículo te comparto diez estrategias para hacer tu proyecto más ágil.

La agilidad de proyectos es la capacidad de adaptarlo a los nuevos aprendizajes y a los cambios de contexto, para lograr mejor los objetivos.

Estoy convencido de que todos los proyectos se pueden “agilizar” independientemente de su naturaleza, de la industria y de la metodología que se adopte. No me refiero particularmente el marco de trabajo que se esté utilizando, sino a mejorar la capacidad de adaptación para lograr mayor efectividad.

Voy a listar las estrategias que me han sido de utilidad para este propósito. La intención es que puedas tomar estas ideas y busques la forma de aplicarlas en el proyecto donde estés trabajando.

Incluso aunque no estés ocupando un rol de liderazgo o gerente de proyecto, siempre puedes mejorar las condiciones con propuestas de mejoras. Los actos de liderazgo están en todos lados, no siempre requieren autoridad formal.

¿Necesita tu proyecto utilizar una metodología ágil? Cynefin es un framework para la toma de decisiones que te permite responder esta pregunta.

El primer paso es identificar el dominio de complejidad del problema que intentas resolver, esto también está relacionado al nivel de incertidumbre. Los dominios de cynefin son: obvio, complicado, complejo y caótico.

Si el dominio es “obvio” (también conocido como “simple” o “claro”), entonces el proyecto puede ser resuelto de la forma habitual y conocida. No será crítico agilizar el proyecto. Un ejemplo, es implementar una solución de software que ya está desarrollada, pero requiere instalarla y configurarla siguiendo los pasos ya conocidos.

Si el dominio es “complicado”, también puedes aplicar una metodología tradicional, aunque un marco ágil podría ser de mayor efectividad.

Un ejemplo es la implementación de una solución de software ya desarrollada, pero donde se requiere a un experto que analice las causas raíces de los problemas que vayan surgiendo.

Si el dominio es “complejo”, una metodología tradicional de gestión de proyectos no será efectiva. En estos tipos de proyectos es difícil prever con anticipación todas las actividades y tiempos. La mayoría de los desarrollos de software entran dentro de esta categoría.

Algunas preguntas que pueden ayudar son ¿Puedes identificar todas las tareas requeridas para completar el proyecto? ¿Consideras que no habrá nuevas tareas no previstas? ¿Sabes cuánto tiempo demora cada tarea? ¿Consideras que no habrán cambios de contexto que afecten a la planificación? ¿Qué tanto sabemos sobre este proyecto y qué tanto tenemos por aprender en el camino?

Si identificas el domino “complicado” o “complejo”, utiliza este framework para apoyar tu recomendación de emplear un marco de trabajo ágil o al menos algunas de las otras estrategias.

Si el proyecto fue concebido con una fecha de entrega ya definida, un alcance ya determinado y un costo fijo es posible que estés en peligro! Esta situación no suele tener buenos resultados en un contexto complejo y de incertidumbre.

Salvo en los casos donde las variables fijas no presentan una restricción (por ej: fechas muy holgadas y alcances pequeños), la mayoría de los proyectos de este tipo en entornos complejos fracasan, de acuerdo al estudio realizado por The Standish Group, The Chaos Report.

Si estás en esta situación, lo mejor es no engañarse desde el comienzo del proyecto y exponer los riesgos, generar las conversaciones necesarias para entender por qué se encuentran en esta situación y qué pueden hacer para permitir alguna de las variables libre.

En los proyectos ágiles, lo habitual es mantener como variable libre el alcance, es decir que pueden estimar, pero no comprometer los resultados que se entregarán en cada fecha determinada de entrega. Sin embargo, las fechas de entrega son fijas, tempranas y frecuentes y el costo puede estar ya determinado para cada ciclo.

El modelo del triángulo invertido ilustra esta diferencia clave entre los proyectos tradicionales y los proyectos ágiles.

Para escapar de la trampa del triángulo de hierro podrías tomar estos pasos:

• Remitirse a experiencias pasadas ¿Cuál es la experiencia previa del equipo y de los clientes con proyectos de estas características? Si no ha sido exitoso, ¿Qué se puede aprender de aquella experiencia para aplicar en este proyecto?
• La situación puede tener origen en falta de confianza y por lo tanto caer en la tendencia de ejercer mayor control. Si es así analiza el origen de esta situación y la experiencia previa en cuanto a los acuerdos y compromisos.
• Evita comprometerte a resultados que no crees poder cumplir y generar falsas expectativas. Esto refuerza más aún la falta de confianza.
• Comenzar el proyecto con una Incepción Ágil. Se trata de una reunión colaborativa para definir aspectos clave del proyecto. Es un evento ideal para identificar los riesgos del Triángulo de Hierro y proponer formas alternativas que aseguren mejores resultados. 
• Utiliza la siguiente estrategia #3

Un ejemplo interesante es la construcción del edificio más alto del mundo en la actualidad: Burj Khalifa (829.8 metros) en el 2004. En general, la construcción civil sigue un proceso tradicional. Sin embargo, el desafío de hacer la torre de estas características requiere innovación de procesos, de técnicas y de materiales, con lo cual no se trata de un proyecto “Simple”, sino más bien ”Complicado”.

En este proyecto, se decidió que el alcance fuera variable. Esto significa que mientras construían la torre, no sabían cuántos pisos tendría una vez terminada. La decisión se tomó lo más tarde posible, en función de ver hasta dónde podían llegar. Los planos tampoco estaban terminados mientras se estaba construyendo la torre.

Si construir la torre más alta del mundo pudo hacer su proyecto más ágil, ¿Aún sigues pensando que en tu proyecto no es posible? No te preocupes y sigue leyendo más estrategias.

Los proyectos ágiles realizan entregas parciales, frecuentes y tempranas del producto funcionando. El resultado más obvio de esta práctica es que permite incorporar el feedback para ajustar el plan de la siguiente entrega.

Además, mostrar resultados concretos de manera frecuente y pedir feedback aumentará la transparencia y la confianza de todos los involucrados, generando así un contexto más apropiado para el éxito del proyecto.

Si no es el caso de tu proyecto, comienza particionando en etapas o fases. Es una gran mejora hacerlo en dos etapas, que de una sola vez. A mayor cantidad de particiones, estarás agilizando más el proyecto. 

El primer objetivo en todo proyecto en donde se desarrolla un producto o servicio en un contexto complejo, debe ser obtener un “Producto Mínimo Viable” (MVP, por sus siglas en inglés). El concepto consiste en que lo más temprano posible exista alguna versión del producto que se pueda probar. Si se requiere validar la idea, antes de la construcción del producto real, es conveniente que el MVP sea un prototipo. Sino, puede ser una versión básica que tenga solamente lo esencial. Para esto la priorización y la mirada “User Journey” es fundamental. Una técnica muy útil para lograrlo es el User Story Mapping. 

Los proyectos tradicionales asumen que se completará todo el proyecto, dentro de los plazos estipulados y el cliente espera ver el producto completo al final. Con lo cual da igual el orden en el que se realicen las tareas. En ocasiones, se comienza por donde es más fácil, quedando las tareas más riesgosas y con mayor incertidumbre para más tarde.

Sin embargo, en la práctica los proyectos se interrumpen por cambios en el contexto, porque lo que era riesgoso termina siendo muy costoso de implementar, porque se agota el presupuesto o tiempos estipulados se extienden demasiado.

Independientemente que el cliente espere todo el producto al final del proyecto, esta estrategia consiste en implementar primero lo que aporta más valor y lo que tiene más incertidumbre y riesgo. De esta manera mitigaremos los riesgos más temprano y si el proyecto se interrumpe podremos entregar lo que más valor tiene.

Un ejemplo: cuando realicé mi proyecto de tesis para mi carrera de Ingeniero en Sistemas, la cátedra exigía las entregas acordes a un proceso secuencial. En los primeros seis meses las entregas consistían en documentación funcional y de diseño del sistema. La construcción comenzaba en el segundo semestre, una vez aprobados los documentos.

Conociendo los riesgos asociados, comencé con la construcción desde el comienzo, resolviendo primero los aspectos más riesgosos del proyecto. De esta manera logré terminar con el proyecto completo con anticipación, con buena calidad y mucho más tranquilo, mientras otros equipos estuvieron en problemas y lidiando con el estrés del último momento.

Esta estrategia es uno de los principios de Lean y consiste en no cerrarse a las posibilidades con más anticipación de la necesaria.

En todo proyecto hay ciertas decisiones que se pueden dejar pendientes para tomarlas más adelante, cuando haya más información y estemos en mejores condiciones de decidir.

Identifica qué decisiones, una vez tomadas pueden condicionar el futuro del proyecto, generan un punto de inflexión, generan compromisos o gastos que luego serían costosos de revertir.

Busca formas alternativas de dejar las opciones abiertas hasta el último momento responsable, para permitir que el proyecto sea más adaptable. Responsable significa no correr con costos por no haber tomado decisiones. El siguiente gráfico ilustra este concepto.

Un ejemplo simple: en lugar de comprar un servidor web, utiliza un servicio de outsourcing en la nube hasta que estén completamente seguros que es la decisión correcta. Contratar el servicio es una decisión más fácil de revertir que comprar un equipamiento.

Otro ejemplo de decidir lo más tarde posible, es el antes mencionado en el caso de Burj Khalifa.

Si queremos lograr que el proyecto tenga mayores posibilidades de éxito y efectividad en resolver un problema, desafío u objetivo, el mismo debe estar claramente identificado, definido y comunicado. El problema debe estar desacoplado de una solución en particular.

En este sentido debemos plantear el proyecto en términos del objetivo y no en términos de implementar una solución ya determinada.

Si el objetivo no está claro, es posible que se implemente la solución y no se resuelva el problema o no se cumpla el objetivo, por lo que la efectividad puede ser menor.

Cuánto más cerrado sea la definición del proyecto en cuanto a la solución a implementar, más difícil será adaptarlo luego. Si en cambio el proyecto está definido más cercano a la necesidad, el problema, la oportunidad, el desafío o el objetivo, la solución puede ir tomando forma a medida que se implementa y se aprende más sobre el contexto y así lograr mayor efectividad.

Si logramos particionar el proyecto en etapas o fases, cada una de ellas puede tener un objetivo específico a resolver.

Si estamos en una situación, donde el cliente solicita implementar una solución particular, podemos indagar sobre el “para qué”. ¿Qué problema resuelve esta solución, que es más importante que la solución en sí? ¿Es posible que hayan otras soluciones que también puedan resolver este problema? ¿Podemos sugerir otras soluciones que sean más efectivas, con menor riesgo, con menos costo o en menos tiempo

Los proyectos más tradicionales penalizan el cambio. Si el cliente tiene un nuevo requerimiento, se genera un sobrecosto. Si se identifica que es necesario realizar una nueva tarea imprevista, el equipo corre con la penalidad de llevarla cabo como horas extras para no afectar la planificación inicial y no generar demoras en la fecha comprometida.

Esto se debe a que el avance del proyecto se mide con el cumplimento de las tareas estipuladas dentro de los tiempos establecidos. En ocasiones a pesar de que las tareas planificadas no lleven al éxito.

Si te encuentras en esta situación, indaga la utilidad que tienen estas métricas para el cliente, y si existen otros indicadores que tengan más sentido que sólo el cumplimiento del plan.

Busca métricas que no penalicen en cambio, y que estén en línea con entregar valor al cliente. Por ejemplo, el cumplimiento de un objetivo relevante para el cliente, una métrica de negocio, o incluso el feedback subjetivo del cliente del valor percibido al obtener las entregas parciales.

En los proyectos ágiles, los equipos se autogestionan para realizar el trabajo y organizar la forma de llevarlo a cabo. Esto implica que el equipo tiene autonomía para tomar decisiones y realizar cambios en la forma de trabajo.

Si te encuentras en un proyecto, donde hay un jefe de proyecto que asigna tareas, puedes generar conversaciones para lograr mayor delegación y sobre la posibilidad de que el equipo proponga otras soluciones y formas de trabajo.

Es altamente importante otorgar responsabilidad al equipo por la calidad de los resultados. De poco sirve que cada integrante del equipo se ocupe solamente de sus tareas asignadas. Todos deben ser igualmente responsables por el éxito del proyecto. Esta condición favorece el trabajo colaborativo y en equipo.

Los proyectos suelen terminar con una conversación de “lecciones aprendidas” o “post-mortem”. La limitante es que las lecciones aprendidas llegan tarde, cuando ya terminó el proyecto y no sirven para ajustar el curso del mismo.

La estrategia consiste en contemplar dentro del proyecto, instancias pautadas periódicamente para reflexionar sobre cómo está funcionando el equipo y los resultados que genera. El objetivo es tomar decisiones que permitan hacer ajustes durante el curso del proyecto. Estos momentos son especialmente útiles luego de cada entrega parcial del proyecto. Obtiene aprendizajes que puedas aplicar en la siguiente fase.

En los equipos ágiles esta instancia lleva el nombre de retrospectiva: mirar hacia atrás, lo que venimos haciendo y los resultados logrados para ajustar hacia adelante. Existen muchas dinámicas que facilitan este proceso, como las que puedes encontrar en el sitio: https://retromat.org/es.

Algunas preguntas útiles son: ¿Cómo está siendo la satisfacción del cliente? ¿Cómo podemos mejorarlo? ¿Cómo podemos ser más efectivos en nuestra colaboración como equipo? ¿Cómo es nuestra capacidad de aportar al proyecto con nuestras habilidades y conocimientos? ¿Cómo está nuestro nivel de estrés y satisfacción en este proyecto? ¿Qué estamos aprendiendo y que nos falta aprender? ¿Qué impedimentos tenemos y cómo podemos removerlos? ¿Qué podemos hacer distinto? ¿Qué estamos haciendo bien y queremos conservar? ¿Cuáles son nuestra fortalezas y debilidades?

Los proyectos no son solamente ágiles por adaptar el curso del proyecto, sino también por adaptar la forma de trabajo.

¿Consideras que no puedes aprovechar ninguna de las nueve estrategias anteriores? No desesperes, aun tienes una estrategia más: generar flujo significa que el proyecto debe estar continuamente avanzando sin detenerse a través de la cadena de generación de valor.

Las dependencias entre tareas, personas y otros proyectos generan bloqueos y tiempos muertos de espera que retrasan los proyectos. Es habitual ver que las tareas pasen mucho más tiempo esperando su turno a ser atendidas, que realmente siendo trabajadas.

Presta atención en detectar dónde pueden estar los bloqueos o tiempos de espera y asegúrate de tener una estrategia para eliminarlos o reducirlos a su mínima expresión. La coordinación previa puede ser un factor clave. Imagina una carrera de postas, el foco no debe estar en el corredor, sino en que la posta llegue a la meta sin tiempos de espera.

Aún mejor que la coordinación es formar equipos autónomos que puedan ejecutar todas la tareas el proyecto con la mayor dedicación posible al proyecto y con las menor dependencia posible en otras personas o áreas de la organización.

Generar flujo en la cadena de valor es un concepto de Lean. Puedes emplear la técnica de Value Stream Map para mapear la cadena de flujo de valor e identificar los desperdicios.

¿Un ejemplo de flujo en un proyecto tradicional? En el año 1920 se construyó la torre más alta del mundo hasta el momento: el Empire State. El proyecto siguió un enfoque puramente tradicional, con un diagrama GANTT, presupuesto y fechas fijas. El objetivo se logró con éxito, en un tiempo admirable de 18 meses por debajo de los tiempos y costos pautados.

La clave del éxito estuvo en la estrategia de flujo. La coordinación se diseñó de manera tal de que los trabajadores tengan dependencias reducidas y no tengan tiempos de espera.