La semana pasada estuve impartiendo un curso de Gestión de Proyectos y tuve la feliz coincidencia de tener a todos los estudiantes involucrados en la Gestión del Servicio con ITIL, tanto que dos de ellos tienen la certificación de Service Manager de ITIL v2.
Así que usamos ITIL para muchas de las referencias durante las conversaciones que mantuvimos en el aula. El marco de referencia de ITIL recomienda la Gestión de Proyectos en dos escenarios muy específicos, que al final son el mismo: Gestionar los Cambios haciendo uso de la Gestión de Proyectos y como proyectos, y en segundo lugar enfocar la creación de un nuevo servicio como un proyecto. Al final es el mismo consejo, ya que un nuevo producto debería ir por la Gestión de Cambios, pero como se predica la independencia de procesos, quizá el proceso no esté implantado, así que el consejo se mantiene por separado.
La Gestión de Cambios como todos los demás procesos requiere de un Gestor de la Gestión. En este caso la habilidad que buscamos con mayor interés es la capacidad y habilidad para gestionar proyectos.
Un cambio en sí mismo puede configurar un proyecto. Idealmente cuando juntamos la Gestión de Cambios y la Gestión de la Entrega intentaremos configurar un proyecto por cada Entrega o Versión, con lo cual el proyecto por lo general va a contener más de un cambio para la entrega.
En una metodología como PRINCE2 es bastante fácil configurar los distintos cambios como productos dentro del proyecto, y la nueva versión como el Producto del Proyecto.
Probablemente en una organización que no haya alcanzado un nivel de madurez en la Gestión de Entregas, le convendría trabajar con los métodos Ágiles de proyectos, métodos que permiten ir cubriendo etapas y sin necesidad de haber completado todo el ámbito ir haciendo entregables y planificando los siguientes productos.
La principal lección de esto no es el uso de la gestión de proyectos para la gestión de cambios de ITIL, sino que conseguirlo requiere de que la organización adopte una cultura de gestión de proyectos, ya que los proyectos no inician con un Gestor de Proyectos, sino con una organización que se prepara con sus interesados principales (stakeholders) involucrados en que el cambio se mantenga controlado, tenga un objetivo de negocio claro, y que sus beneficios estén bien definidos.
Así que usamos ITIL para muchas de las referencias durante las conversaciones que mantuvimos en el aula. El marco de referencia de ITIL recomienda la Gestión de Proyectos en dos escenarios muy específicos, que al final son el mismo: Gestionar los Cambios haciendo uso de la Gestión de Proyectos y como proyectos, y en segundo lugar enfocar la creación de un nuevo servicio como un proyecto. Al final es el mismo consejo, ya que un nuevo producto debería ir por la Gestión de Cambios, pero como se predica la independencia de procesos, quizá el proceso no esté implantado, así que el consejo se mantiene por separado.
La Gestión de Cambios como todos los demás procesos requiere de un Gestor de la Gestión. En este caso la habilidad que buscamos con mayor interés es la capacidad y habilidad para gestionar proyectos.
Un cambio en sí mismo puede configurar un proyecto. Idealmente cuando juntamos la Gestión de Cambios y la Gestión de la Entrega intentaremos configurar un proyecto por cada Entrega o Versión, con lo cual el proyecto por lo general va a contener más de un cambio para la entrega.
En una metodología como PRINCE2 es bastante fácil configurar los distintos cambios como productos dentro del proyecto, y la nueva versión como el Producto del Proyecto.
Probablemente en una organización que no haya alcanzado un nivel de madurez en la Gestión de Entregas, le convendría trabajar con los métodos Ágiles de proyectos, métodos que permiten ir cubriendo etapas y sin necesidad de haber completado todo el ámbito ir haciendo entregables y planificando los siguientes productos.
La principal lección de esto no es el uso de la gestión de proyectos para la gestión de cambios de ITIL, sino que conseguirlo requiere de que la organización adopte una cultura de gestión de proyectos, ya que los proyectos no inician con un Gestor de Proyectos, sino con una organización que se prepara con sus interesados principales (stakeholders) involucrados en que el cambio se mantenga controlado, tenga un objetivo de negocio claro, y que sus beneficios estén bien definidos.
Muy interesante el punto de vista, definitivamente una organizacion con un nivel de madurez que permita iniciar un proyecto con una gestion de cambio es dificl de encontrar en nuestra region, incluso las organizaciones u oficinas en nuestra region, que pertenecen a transnacionales, no estan aun en esos niveles de madurez. Sin embargo a pesar de no estar en esos niveles, se debe considerar ese punto de vista como el, o al menos, uno de los escenarios objetivos de las organizaciones que se encuentran en ese proceso de madurez.
ResponderEliminar