Archivo de la etiqueta: Gestión de proyectos

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

plan_blog_ProactivaNETEl 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.

13.- Reuniones excesivas o muy largas.

Si bien la comunicación es necesaria, el exceso de reuniones es contraproducente ya que, por lo pronto, supone un sobrecoste importante en la realización del cambio. Por ejemplo, una reunión de una hora en la que participen ocho personas cuesta tanto como una jornada de trabajo.

Para mejorar la comunicación intente proporcionar canales alternativos a las reuniones, por ejemplo un foro web o un tablero kanban.

No obstante, algunas reuniones seguirán siendo necesarias. En esos casos asegúrese de que todas tienen un orden del día, una duración concreta, unos objetivos y que los participantes la preparan antes de asistir. Por ejemplo, si una reunión debe servir para decidir a qué proveedor se compra cierto material, asegúrese de que los asistentes disponen de información sobre los distintos proveedores antes de la reunión y de que la reunión termina con una decisión firme.

14.- Descuidar la calidad.

La calidad en la realización de un cambio empieza por una buena definición de los criterios de aceptación que ayuden a garantizar que se entrega lo que se esperaba. Sin embargo, el punto de control clave para impedir que descuidemos la calidad son las revisiones post-implementación (PIR) de los cambios. Concédales el valor y la importancia que tienen un realícelas dedicándoles el tiempo que merecen.

Para que sean más ágiles y estandarizadas quizás las PIR podrían ser una lista de comprobación (checklist) que permitan análisis agregados más rápidos.

15.- No aprender de los errores del pasado.

La calidad está siempre relacionada con la mejora continua. Cada cambio debe realizarse mejor que el anterior y, para ello, debemos hacer uso de dos herramientas fundamentales que nos sugiere ITIL: las revisiones post-implementación (PIR) de los cambios, que son el mecanismo fundamental de reflexión sobre la calidad de lo realizado, así como el proceso de Gestión de Problemas, que permite identificar oportunidades de mejora a partir de distintos inputs, como por ejemplo las PIR de los cambios. En este artículo hay más sugerencias al respecto.

Con este artículo termina, por fin, esta larga serie donde repasamos los puntos más importantes que tienen en común la Gestión de Cambios y la Gestión de Proyectos.

José Luis Fernández

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

plan_blog_ProactivaNET2El 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.

10.- Miedo a decir “no”.

No todos los cambios son apropiados. Quizás la parte más importante del proceso de Gestión de Cambios sea rechazar los inadecuados. Para saber cuándo decir “no” debemos tener claro que hay más criterios que un cambio debe cumplir que ser técnicamente viable. Es más, el personal de TI suele centrarse en cuestiones de viabilidad técnica olvidando otros aspectos como el coste, la rentabilidad o limitaciones no técnicas (como por ejemplo las restricciones legales).

11.- No saber trabajar en equipo.

La realización de un cambio es una actividad compleja que es mejor realizar en equipo. Cuando se trabaja en equipo pueden surgir dificultades de comunicación y coordinación, pero también aparecen ventajas como el reparto de tareas para evitar la sobrecarga de trabajo o el uso de personal especializado que garantice los mejores resultados para cada actividad. Es más, no debemos olvidar que suele ser mal criterio ser juez y parte, por lo que separar tareas de manera que quien concede la aprobación no es el mismo que quien solicita el cambio y que tampoco es el mismo que quien hace el análisis de impacto suele producir resultados mejores al basarse en juicios más objetivos y certeros.

12.- Comunicación deficiente.

Si bien el trabajo en equipo es positivo, la comunicación y la coordinación entre los miembros es fundamental. Por este motivo aunque las tareas se deleguen en distintas personas siempre debe existir una única persona responsable del cambio en su conjunto y que debe actuar de líder y coordinador entre los miembros del equipo. El responsable del cambio deberá favorecer la comunicación entre los participantes (interna) sin olvidar la comunicación con los stakeholders (externa).

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

 José Luis Fernández

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

plan_blog_ProactivaNETEl 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

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

plan_blog_ProactivaNET2El 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

4.- Utilizar siempre la misma metodología.

Hay un dicho que dice que quien tiene un martillo todo lo que ve son clavos. Debemos comprender que no se puede aplicar la misma metodología a todos los cambios porque un cambio muy complejo gestionado con una metodología muy simple será propenso a errores mientras que un cambio muy simple gestionado con una metodología muy compleja será muy caro por los costes de la gestión.

Por lo tanto, debemos diferenciar los cambios segmentándolos en varias clasificaciones y gestionándolos con metodologías acordes. Empecemos cuestionando si hace falta usar Gestión de Cambios para realizar la modificación que queremos hacer o si podríamos usar Gestión de Peticiones. Si hace falta Gestión de Cambios, ¿el cambio requiere autorización o podemos evitar esta etapa? Si el cambio requiere autorización, ¿el comité que concederá la autorización está formado por las personas oportunas o hay demasiadas personas en el comité? Si el cambio es urgente, ¿estamos usando un procedimiento más ágil? Seguro que se le ocurren más cuestiones que podríamos plantear para encontrar aspectos de la Gestión de Cambios que pueden hacerse de manera diferente en función de la entidad del cambio.

5.- Sobrecargar a los miembros del equipo.

Recuerde que proceso no es sinónimo de departamento. Por lo tanto lo más probable es que Gestión de Cambios no sea un departamento de personas que se dediquen sólo a las tareas relacionadas con los cambios. Así que cuando planifique los cambios tenga en cuenta el impacto de la carga de trabajo derivada de los cambios en otros procesos. Por ejemplo, ¿qué pasa si uno de los miembros del equipo que realiza un cambio es a su vez técnico de tercera línea de Gestión de Incidencias? ¿Dispone el técnico de tiempo suficiente o podemos estar poniendo en riesgo el cumplimiento de algún Acuerdo de Nivel de Servicio?

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

 José Luis Fernández

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

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