La importancia de gestionar el CAMBIO

A ver si os suena…
Día 29 de Octubre, llueve, pero eso no viene al caso… El director de mi área me está metiendo un paquete porque mi último proyecto lleva un retraso en la entrega, y con un avance del 80%, ya hemos consumido todo el presupuesto del proyecto… tierra trágame!!
Pero esto no ha pasado de la noche a la mañana, así que hagamos un flashback al más puro estilo de “perdidos”…

1 de Marzo (curiosamente hace sol), he tomado los requisitos del cliente, están por escrito en un documento que él mismo ha validado y construyo mi Project plan… me han asignado un equipo estupendo y tengo una línea base que me garantiza una rentabilidad alta y una fecha de entrega acorde a las necesidades del cliente… preparados, listos, ya!! Arrancamos el proyecto…

Los días pasan, el proyecto avanza, y de repente, suena el teléfono! Es el cliente, tras nuestro primer prototipo de la aplicación, ha decidido que el titulo de ésta debe estar más a la izquierda y en un color más “atractivo”… fácil, no? Tú traduces “atractivo=rojo”, lo haces y lo presentas… vaya, parece que el rojo no es atractivo para el cliente, seguimos buscando hasta que finalmente, acepta un verde azabache que tú ni si quiera conocías. Bien!! Ya lo tengo, seguimos con el proyecto…

Bueno, como ya habréis adivinado, el cliente hizo alguna que otra llamada más, el proyecto inicial poco tuvo que ver con el final y como consecuencia, pérdidas. El proyecto cambió en varias ocasiones, pero esos cambios no estuvieron gestionados. Por favor, no nos sorprendamos, como dice un gran sabio, “lo único que no cambia, es que todo cambia”. Simplemente asumamos que esto pasará y aprendamos a gestionarlo adecuadamente.

Como Jefes de proyecto, debemos gestionar el cambio. Una vez que se nos presenta un cambio, que puede venir no sólo del cliente, sino también de un usuario, de un técnico, de otros responsables… Lo primero que debe hacerse, es un análisis de la solicitud, estudiando cómo va a impactar dicho cambio en nuestro proyecto, no sólo en la triple restricción (alcance, tiempo y coste), sino también en la calidad del proyecto y un factor muy importante que solemos olvidar, el impacto en otras áreas: cambiar de azul a rojo puede que no haya mucho problema, pero si eliminas un campo de la BD, asegúrate que no estás rompiendo nada que otras aplicaciones o áreas estén utilizando. Una vez analizado el cambio, se lo presentamos al patrocinador. El PMI (Project Management Institute), distingue entre el patrocinador, que sería la figura que financia el proyecto (pone la pasta) y el cliente, que es la figura que usará el producto o proyecto (lo que nosotros solemos denominar “usuario final”). Esta distinción es importante, ya que presentar el cambio al patrocinador, nos ayudará a que nuestro cambio se gestione correctamente, puesto que es él y no el usuario (fuente de la mayoría de cambios), quien lo va a pagar. Una vez presentado el cambio al patrocinador, solicitamos aprobación. Si el patrocinador rechaza el cambio, seguimos con la línea base inicial, si se aprueba, debemos actualizar la línea base y si lo tenemos, actualizar también el cuaderno de bitácoras del proyecto, para tener así todo un registro de los cambios producidos. Es vital actualizar la línea base!!! El proyecto está vivo y ya no es el proyecto inicial. Tras esto, sólo queda desarrollar el cambio e informar del mismo a otras áreas que puedan estar afectadas de alguna forma.
Al final es un sencillo flujograma que hace la vida más fácil al JP:





















El no gestionar los cambios, es una de las principales causas de desvíos en el proyecto, gestionemos el cambio y tendremos mucho ganado!!

Un saludo!!