Cuando desarrollamos un nuevo proyecto hay muchas incertidumbres y dudas. En innumerables ocasiones, el resultado final será diferente a lo que en un principio podría haberse pensado. Esto, no necesariamente es un problema.
El paradigma sobre el que se basa la gestión de proyectos, es que el entorno puede cambiar. Y no solo el entorno del proyecto, sino que incluso la necesidad que originó el proyecto, también puede sufrir modificaciones e incluso desaparecer. Es por eso que los enfoques ágiles como SCRUM están de moda.
Este hecho, obliga a los directores de proyecto, y en general, a todos los implicados su desarrollo, a tener un doble foco: el primero es orientarse hacia la consecución de los objetivos más “técnicos” del proyecto y el segundo debe centrarse en asegurarse que el producto que se está desarrollando, cubra realmente las necesidades principales y que, realmente sirva al cliente/usario.
Así, un aspecto clave para el éxito del proyecto, es asegurarnos de que el cliente realmente obtenga un producto –o servicio- que se ajuste a sus necesidades, que, por otra parte, pueden ser cambiantes conforme el proyecto se desarrolla. La cuestión, la encontramos en el “cómo” se debe gestionar un proyecto.
Podemos encontrarnos con el problema de que los requisitos del proyecto, no estén muy claros y/o que el entorno sea muy variable (acción de competidores introduciendo productos novedosos que pudiesen afectar al nuestro, avances tecnológicos, evolución del gusto de los usuarios, etc), lo que obligaría a todo el equipo a hacer un esfuerzo extra en la gestión del proyecto, ya que en algunos casos, incluso habiendo definido todo muy bien, y con trabajo ya hecho, es necesario volver atrás y reorientar el proyecto. De ahí que cuando Nonaka y Takeuchi (The New New Product Development Game, 1986) empezaron a hablar de desarrollos ágiles e iterativos de proyectos, pensaron que el concepto de Scrum (melé) del rugby era realmente interesante y descriptivo de cómo se debería funcionar en un proyecto.
De nuevo, podemos pensar que esto es negativo. Pero, desde el punto de vista del usuario, no tiene porqué serlo. El objetivo no es producir un producto, sino generar una solución que realmente funcione. En este tipo de situaciones podemos pensar que, centrarnos en la generación de un plan que nos sirva como referencia (base line), no parece demasiado interesante, ya que podríamos estar dedicando un tiempo excesivo a trabajos de carácter burocrático y no a los que realmente aporten valor.
Efectivamente. ¿ Y si el entorno es muy incierto? El esfuerzo de planificación debe realizarse con un horizonte muy corto; lo que denominamos Sprints. Así, una de las bases de la gestión de proyectos con SCRUM, es la identificación de cada cuanto hay que planificar, ejecutar, y, por tanto, obtener productos, o mejor dicho, trozos de productos, que permitan presentar al cliente “cosas” que pueda tocar y usar. De modo que pueda percibir, de una manera práctica, si el producto va en la buena dirección para cubrir sus necesidades. Así mismo, se puede presentar al mercado, para comprobar su respuesta y re-orientar el proyecto, si fuese necesario. Lo que, sin duda, reduce el riesgo del mismo.
Así, la adaptación al entorno y a las necesidades, es una de las claves del éxito de los proyectos ágiles. Y de hecho, es uno de sus principios a tener en cuenta. Y para ser un buen Project Manager, una de las habilidades más demandadas; ¡hay que ser ágil! y no ver los cambios como «problemas», sino como oportunidades de adaptar el proyecto y aumentar las posibilidades de éxito.
Seguimos la metodología del SBOK, si quieres poder integrarte en equipos de gestión de proyectos ágiles, te recomendamos nuestro curso de SCRUM MASTER, en el que tratamos todos los aspectos, herramientas -artefactos- y roles que hay que dominar.
