Si algo es seguro, es que todo cambia, y un proyecto no es diferente.
De hecho en ambientes militares, se dice que lo difícil para un plan es que aguante el contacto. Es decir, podemos haber planificado muy bien, pero es muy factible que la realidad nos fuerce a adaptarlo y ajustarlo para conseguir sus objetivos.
En cualquier caso, y pese a este hecho, hay que mantener el control del proyecto y dominar el cambio. Es necesario disponer de un proceso, más o menos desarrollado dependiendo del proyecto y de la organización ejecutante, que garantice que cada cambio es analizado, valorado, aceptado y comunicado. Y desde luego, el proyecto debe mantenerse siempre actualizado.
Búsqueda de la eficiencia
Por mi experiencia profesional sé que cuando se está gestionando un proyecto, el Project manager, no quiere hacer trabajo burocrático y que no tenga un retorno positivo. Así, hay que pensar muy bien cómo debe ser el proceso del cambio y qué formatos se utilizan.
Si hacemos caso de la metodología PMI© descrita en el PMBOK©, vemos que se define en el área de conocimiento de integración, como un proceso fundamental, la implantación de un sistema integrado de gestión del cambio.
¿Cómo hacerlo de forma sencilla?
Se genera el cambio a partir de una solicitud que puede venir por cualquier agente, y que el Project manager debe analizar; determinando si el cambio es factible, valorando su impacto –desde todos los punto de vista del proyecto-, y buscando posibles alternativas. Ya que si se va a cambiar algo, tenemos que asegurarnos que es el mejor posible.
Os voy a exponer cuál es el formato base con el que gestiono el cambio en los proyectos. El proceso más o menos sería así:
Como podréis ver, es un documento muy sencillo en la forma, pero en el que se incluyen las dimensiones clave para dominar el cambio.
1.- Identificación del responsable del cambio: o en su defecto del Project manager. Este dato es muy importante, ya que no es suficiente con proponer un cambio y que este se acepte, sino, si éste se decide implementar, hay que garantizar que se actualicen todos los datos y planes subsidiarios del proyecto. Y comunicarlo!.
2.- Explicación del cambio propuesto: El Project manager debe asegurarse que el cambio es posible y que mejora lo existente. Así, se expondrá qué se incluye en el alcance del proyecto y cómo es el cambio solicitado, es decir, cómo queda el proyecto si se aplicase. También se puede incluir información sobre quién lo ha solicitado y su motivación, así como la mejora que produce en el proyecto.
3.- Detalle del presupuesto: Si el primer componente de la triple restricción es el alcance, analizado en el punto anterior, el siguiente es el costo o presupuesto. Se trataría en este momento, y en mi opinión se debe detallar tanto a nivel paquete de trabajo, como por actividad más detallada. Aunque para cada caso se deberá analizar la descomposición y nivel de detalle adecuado.
4.- Gestión de las reservas: este es uno de los puntos más interesantes, ya que una vez analizado el impacto económico (y de tiempo, como veremos en puntos anteriores), tenemos que ver los posibles ajustes que podemos hacer en el presupuesto para minimizar el impacto. Así, tendremos que valorar el importe actual de las reservas, tanto de gestión (para los riesgos detectados) como las de contingencia (para cubrir los posibles eventos no planificados). Teniendo en cuenta, tanto el nivel de incertidumbre y riesgo del proyecto, como el momento temporal del mismo. De forma que podamos ir dimensionándolas adecuadamente.
Es muy importante, implicar en esta decisión al patrocinador o promotor del proyecto, ya que dependerá de su nivel de aceptación del riesgo (risk tolerance), que las reservas sean más o menos voluminosas.
5.- El proceso final del cambio es la determinación de si se hace o no. Así, el Comité del Cambio (en definitiva, la figura que tenga la autorización para aceptar o denegarlo), tomará una decisión (en el plazo que se indique como máximo). En este punto, también hay que reflexionar sobre el nivel de toma de decisiones, ya que no todos los cambios tienen el mismo impacto, y es muy útil, el determinar unos criterios para ellos. Así, pequeños cambios podrían no necesitar autorización superior, sino que el Project manager podría hacerlo, y otros de mayor calado sí deberían tener la aprobación superior.
Faltan más cosas!,… ¿Y los riesgos?
Pero no es suficiente. Con este primer documento, tenemos mucha información y en muchos casos suficiente. Pero, no hay que olvidar que un cambio genera riesgos, y hay que analizarlo desde un punto de vista global.
No podemos obviar aspectos más concretos del cambio, como pueden ser las implicaciones legales, comerciales, etc. Y como no, los riesgos que se generan en el cambio. Aspecto este fundamental en la gestión de un proyecto.
