Gestión de Cambios y Gestión de Proyectos (3 de 5)

El proceso de Gestión de Cambios indica y sugiere cómo liderar los cambios que se realizan en los activos participantes para la prestación de servicios. Sin embargo, muchos cambios son complejos y merecen ser considerados como un proyecto. ¿Qué puede aprender Gestión de Cambios de prácticas y metodologías sobre Gestión de Proyectos?

Continuamos repasando las cuestiones clave que pueden hacer fracasar un proyecto para ver las similitudes con Gestión de Cambios a partir de este artículo de www.cio.com.

6.- Falta de visibilidad o de información.

Si los resultados del cambio son invisibles hasta prácticamente la finalización (lo que se denomina modelo de la cascada de agua) seguramente no podamos reaccionar ante situaciones adversas. Por ejemplo, ¿qué pasa si el cambio consiste en sustituir los routers de marcas heterogéneas por un modelo concreto de router CISCO para así simplificar la gestión y descubrimos que hay alguna incompatibilidad importante con la necesidad de alguna sede de la empresa? En Gestión de Proyectos suelen recomendarse metodologías iterativas o ágiles que ofrecen entregables intermedios, en Gestión de Cambios podríamos hablar de una Gestión de Entregas que haga despliegues progresivos de manera que se vaya testeando y consolidando el cambio.

7.- Falta de definición de quién toma las decisiones.

Un cambio puede requerir muchas decisiones, pero al menos una es clave y fundamental y es su aprobación para ser realizado. ¿Tenemos un procedimiento claro que establezca a qué comité de autorización le corresponde autorizar (o rechazar) al cambio en función de sus características?

8.- No utilizar software de apoyo.

Cualquier actividad puede realizarse con lápiz y papel, pero eso no significa que sea la manera más eficaz de hacerla. Del mismo modo que hace operaciones matemáticas con una calculadora y no con un ábaco, ¿por qué no utiliza la herramienta adecuada para gestionar cambios?

9.- Permitir modificaciones en el alcance u otros parámetros del cambio.

Como ya comentamos en el primer artículo de esta serie, cada cambio debería tener unos objetivos y unos criterios de aceptación claros y definidos. Partiendo de ellos se ha realizado el análisis de impacto, la identificación de stakeholders e incluso se ha obtenido la aprobación. Si permitimos modificaciones, en el alcance u otros aspectos, o rehacemos los pasos previos o corremos el riesgo de enfrentarnos a situaciones imprevistas que pongan en riesgo el éxito del cambio.

Por ejemplo, si hemos obtenido aprobación para realizar la sustitución de un servidor MS SQL Server por Oracle pero en el último momento instalamos MySQL, ¿estamos seguros de que el software que se iba a migrar de MS SQL Server a Oracle se puede migrar a MySQL sin incurrir en sobrecostes o limitaciones técnicas?

En posteriores artículos seguiremos revisando más cuestiones claves que pueden hacer fracasar la ejecución de un cambio. Ir al artículo 4 de 5. 

 José Luis Fernández