[…] los mayores fallos que solemos encontrar no son que los planes fallen sino que fallamos en apartarnos de los planes […] – Andy Grove, CEO de Intel

He tenido la oportunidad de leer un artículo de Simon Collyer, Clive Warren y otros en que se citan a ellos mismos (Collyer y Warren, 2009) en referencia a distintas colecciones de técnicas para afrontar proyectos en entornos dinámicos. Me ha parecido interesante y, por eso, os paso la lista propuesta por ellos. La traducción de los nombres puede ser algo libre.

Manipulación del entorno. Consiste en intentar mantener el entorno estático. Ni qué decir tiene que es la que querríamos los directores proyectos ya que ocasiona menos preocupaciones. Y también es obvio que funciona mejor si el entorno ya es de por si estático. Si el entorno no lo fuera, intentar mantenerlo es muchas veces una tarea imposible. Esta aproximación a la gestión de proyectos es la tradicional consistente en planificar mucho y, cuando estás seguro de todo, empezar a ejecutar. Conocemos sus limitaciones. Fundamentalmente, que nunca se llega a definir el proyecto correctamente al 100% (yo ya he sufrido alguna discusión al respecto en mis propias carnes) y cerrar la fase de planificación se alarga en el tiempo. Quiero decir que tener una primera definición al 80% puede llevar un tiempo razonable pero completar ese 20% restante, puede tardar tanto o más que el primer 80%. La ventaja de esta aproximación es que disminuyes el riesgo porque conoces el proyecto a la perfección: entregables, plazos, costes, recursos, etc… si no fuera porque el entorno no es manejable y siempre hay alguna situación que no era la planificada. Creo que todos sabemos lo que da de sí este método.

Planificación emergente informada con feedback. También conocida como iterativa o rolling wave. Se intenta comenzar con una definición de alto nivel y definir los detalles según nos acercamos al momento de ejecutarlos. Es como la planificación de la producción. Se comienza con unos planes a un año o año y medio vista en los que se especifican volúmenes sin mucho detalle. Al mismo tiempo, se van creando planes a más corto plazo con mayor definición de los recursos necesarios y de los elementos a suministrar. Permite acortar la duración total del proyecto y acertar mejor en los detalles. Por el contrario, el alcance no queda suficientemente precisado e implica un riesgo mayor.

Liberaciones por etapas. Consiste en crear productos entregables con funcionalidades básicas utilizables 100%. Esto es importante puesto que es lo que establece la diferencia con el caso anterior. Sobre estos entregables, una vez probados y recibiendo feedback de los clientes y usuarios, se añaden más funcionalidades y se ponen en producción versiones más completas y avanzadas. Esto permite salir, al principio, con un producto con coste relativamente bajo en el que hacer la prueba de concepto y no esperar a hacerla al final de todo el desarrollo. La primera etapa debe contener el menor alcance posible. Hay desarrollos muy interesantes actualmente en el campo del software. El método no es perfecto puesto que necesita clientes muy implicados durante el proyecto y puede ser menos competitivo en entornos en los que el éxito del proyecto se mide por conseguir el 100% de las funcionalidades independientemente de los hitos intermedios. A su favor tiene que la resolución de errores es mucho más eficaz y temprana y que el control de los plazos es mucho más sencillo y fiable.

Experimentos competidores. Se inician en paralelo diversas versiones para, una vez probadas, decidir cuál es la aproximación óptima. Esto es útil cuando realmente no se está seguro de si los entregables van a cubrir completamente los objetivos propuestos o cuando existen factores en su desarrollo demasiado desconocidos al inicio del proyecto y es imposible descartar unas aproximaciones frente a otras. Consume muchos recursos y no está, por tanto, al alcance de todos.

Controles alternativos. Esta aproximación requiere un mayor foco en controlar las entradas y salidas del proyecto como, por ejemplo, la selección del equipo, la selección de los objetivos y el sistema de recompensas. El objetivo es completar la visión de control del proceso ya considerada en los sistemas de gestión de proyectos e ir más allá con el fin de mejorar los resultados de los proyectos. Sobre este tema, hablaré algo más en otra ocasión. Yo no veo que esta aproximación, aunque los autores la traten aparte, sea incompatible con las anteriores sino más bien un complemento de las mismas.

Para próximas ocasiones, ya estáis en situación de considerar más formas de acometer proyectos además de la clásica.