Proceso para realizar cambios

He aquí uno de los pilares de la gestión de proyectos como tal y del día a día de los proyectos y del trabajo de un jefe de proyecto.

Los @Cambios por normal general son una fuente ilimitada ya no de problemas, sino de discordia pues es una conversación en la que el proveedor suele limitar al cliente. Lo romántico e ideal es que el alcance sea en su definición siempre algo claro y sencillo, especialmente en los requisitos, y de hecho este debe ser este el objetivo, cuanto más claro y sencillo, mejor vamos a vivir el día a día del proyecto.

La realidad es que, aunque nuestro esfuerzo sea máximo a la hora de definir el alcance siempre faltará algo, o incluso cambiará algo (por avances tecnológicos, por necesidad cambiante del cliente…).

También es importante recordar y es especialmente cierto en los proyectos de IT, que el alcance a veces no está del todo claro, es decir, que el cliente no sabe exactamente lo que quiere sobre este escenario la metodología PMP sufre si no hay herramientas bien definidas, y por el contrario las metodologías ágiles lo llevan mejor.

Lo que hay que tener presente siempre, es basarnos en el alcance que se ha definido en el plan de proyecto, los entregables que esto implica y que cubren los requisitos detallados acordados.

Cuando el cliente solicita cambios, nuestro equipo detecta cambios, otros proveedores detectan cambios, o se dispara un riesgo, se traduce en:

  • Solicitud de cambio, cuando todavía estamos por ejemplo desarrollando o elaborando un entregable.
  • Cuando un entregable ya se ha desplegado implica un CR (siglas que vienen de Change Request) con los detalles resumen, costos económicos y tiempo, que generalmente va de la mano de un SOW (Statement of Work) con las especificaciones técnicas del cambio o necesidad.
    Un CR tiene siempre una dimensión acordada, por ejemplo, será necesario un CR cuando un cambio supere los XXXX euros o tenga unas ciertas características.
  • Nueva Fase o Evolutivo del proyecto, cuando se han detectado varios cambios o necesidades durante el proyecto no esenciales pero deseables en el futuro se puede agrupar en un nuevo proyecto (evolución del anterior o fase II) que amplíe la funcionalidad. Este será un nuevo proyecto independiente.
  • A veces los proyectos una vez desplegados van de la mano de un contrato de Servicio de Soporte (en proyectos IT debería intentarse siempre) que dé cobertura a la operación del cliente, y que suele incluir distintos tipos de peticiones, entre los que hay un tipo que es @petición tipo evolutivo, no confundir con la anterior, pero el alcance se limita a una funcionalidad concreta (mostrar nueva información, modificar una interfaz…)

 

Respecto al examen tener claro esta síntesis:

Es responsabilidad del Jefe de proyecto y del Sponsor/Patrocinador, velar por cumplir dichos requisitos, si empiezan a surgir cambios hay que canalizarlos mediante las herramientas establecidas.

El proceso de gestión de cambios resumido es:

  1. Prevenir la Causa Raíz de los cambios.
  2. Identificar el cambio
  3. Revisar el impacto en el área de conocimiento
  4. Realizar el control integrado de cambios
    1. Evaluar el cambio
    2. Buscar Opciones
    3. Aprobar o Rechazar el Cambio
    4. Actualizar el estado de cambio en el Registro de Cambios
    5. Ajustar el plan para la dirección de proyecto, los documentos del proyecto y las líneas base según sea necesario.
  5. Gestionar las expectativas de los interesados comunicando los cambios a los afectados
  6. Gestionar el proyecto de acuerdo con el plan de dirección y los documentos modificad

 

El director puede aprobar muchos de los cambios que surjan, pero, los que afecten al plan de dirección, líneas base, acta de constitución deben ser aprobados por el comité de control de cambios.

Anuncios

Grupos de Procesos de Gestión

Grupos de Procesos


Siempre que alguien piensa en el PMbook y en la visión de gestión a través de la metodología tradicional, la primera imagen que tenemos (o deberíamos tener en la cabeza con mayor o menor detalle) es la del famoso cuadro de PMI qué es ni más ni menos que el resumen y guía general de todo el proceso.

Probablemente la imagen no se vea muy bien pero si las flechas que es lo que interesa remarcar en este post.

grupos de procesos de gestión

Lo importante que tenemos que saber es que PMI dos distinciones muy claras en gestión de proyectos, por un lado los Grupos de Procesos, las columnas por lo que nos enfocaríamos en visualizar el cuadro en vertical y por otro las Áreas de conocimiento (próximo post).

Cuidado con confundirlo con las fases o ciclos de desarrollo de software que por norma solemos definir como:

  • Inicio,
  • Diseño,
  • Desarrollo o Implementación,
  • Despliegue,
  • Cierre o Transferencia.

El ciclo de vida del proyecto y los grupos de procesos son cosas diferentes y hay que marcar bien esa diferencia, estos grupos de procesos se pueden repetir en las distintas fases de un proyecto que dependiendo del sector (arquitectura, Ingeniería del Software, Medicina…) los proyectos pueden tener un ciclo de vida concreto.

Por ejemplo:

“Supongamos que tenemos un proyecto en el que se va a diseñar y construir una gran fábrica de manufactura y supongamos que el ciclo de vida del proyecto se divide en las siguientes fases”

esquema concepto ciclo y grupos de proceso

“Como se aprecia claramente dentro de cada fase y debido a la dimensión de cada una se realizan y llevan a cabo todos los procesos de dirección, incluidos los procesos de inicio y los procesos de cierre en cada fase.”

Hay que tener claro que PMI identifica 47 Procesos de gestión agrupados en 5 Grupos de Procesos

  • Grupo de Proceso: Inicio (2 procesos)
  • Grupo de Proceso: Planificación (24 procesos)
  • Grupo de Proceso: Ejecución (8 procesos)
  • Grupo de Proceso: Seguimiento y Control (11 procesos)
  • Grupo de Proceso: Cierre (2 procesos)

Otro aspecto muy importante es que estos procesos, no son secuenciales a excepción de los procesos de planificación que si son secuenciales e iterativos. Es decir en general todos los procesos pueden producirse y se llevan a cabo en cualquier momento durante el ciclo de vida del proyecto.

El caso más claro que nos ayuda a recordar esto es por ejemplo el proceso, Identificar Interesados, del grupo de procesos de inicio que se puede producir a mitad del proyecto, porque o bien no lo habíamos identificado al principio o ha surgido un interesado o stakeholder nuevo durante el proyecto.