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

13 de febrero de 2014

Landscaping - drawing by Hand a Sketch of a modern small City GardenEl 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?

Este artículo de www.cio.com enumera quince cuestiones clave que pueden hacer fracasar un proyecto. Un repaso sobre cada una de ellas nos permitirá ver las similitudes entre Gestión de Cambios y Gestión de Proyectos.

1.- Alcance mal definido o inexistente.

Un cambio debería tener un objetivo concreto. Para ello deberíamos ser capaces de enunciar qué se debe hacer y cómo se comprueba que el resultado es exitoso. Por ejemplo, si el objetivo de un cambio está enunciado como “aumentar la capacidad de almacenamiento de los buzones de e-mail de los empleados” deberíamos tener un método para validar si el aumento es el adecuado.

Este método recibe el nombre de criterio de aceptación y debería ser algo cuantificable, por ejemplo “que cada empleado disponga de 2 GB”. Así, cuando se haya completado la ejecución del cambio y se quiera realizar la PIR para validar el cierre, podremos saber fácilmente si el cambio está bien realizado o por el contrario el resultado no es satisfactorio.

2.- No gestionar las expectativas.

Cada stakeholder se ve afectado por el cambio de una manera distinta. Además de comunicar correctamente a cada stakeholder qué se espera que haga y cuando, no debemos olvidar que hay stakeholders que no participan activamente en la ejecución del cambio pero sí se verán afectados por la modificación. Estas personas o grupos tienen expectativas y debemos gestionarlas.

Por ejemplo, si estamos realizando un cambio para poner en producción un nuevo servicio ¿hemos tenido en cuenta las expectativas de los futuros usuarios? Por ejemplo, si el nuevo servicio es soporte on-line, ¿se prestará en el horario/idioma/formato que los usuarios esperan? Es más, ¿hemos hecho el esfuerzo de identificar a todos los stakeholders? Cada stakeholder ignorado se convertirá en un elemento reactivo al cambio.

3.- No disponer de respaldo adecuado.

Un cambio puede afectar a muchas personas y partes distintas de la organización y quizás no todas estén igual de receptivas. Si debemos convencer o incluso imponer la realización del cambio, ¿disponemos del respaldo adecuado? Todo cambio debe disponer de un sponsor.

Por ejemplo, si el cambio implica la sustitución de tecnología Microsoft por tecnología Oracle, ¿tenemos un sponsor que nos ayude a conseguir presupuesto y a convencer de la idoneidad del cambio?

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

José Luis Fernández 

Suscríbete a nuestro Blog
Loading
“La combinación perfecta entre agilidad y potencia”
CMDB

¡Resolvemos tus dudas sobre la CMDB!

Gestionar todos los componentes que forman parte de la infraestructura tecnológica...
Proactivanet sigue cuidando las mejores prácticas ITIL

Proactivanet permanece a la vanguardia con los nuevos esquemas de certificación ITIL

En medio de la evolución de las mejores prácticas ITIL para...
Reforzamos nuestro compromiso con ITIL4 ¡Ya contamos con 18 prácticas certificadas!

Reforzamos nuestro compromiso con ITIL4 ¡Ya contamos con 18 prácticas certificadas!

Llegamos a final de año 2022 cumpliendo la mayoría de edad...