Diagrama de flujo del proceso de solicitud de cambios en proyectos

¿Qué es diagrama de flujo del proceso de solicitud de cambios en proyectos?

Una solicitud de cambio en un proyecto pide modificar algo que ya estaba acordado: el alcance, el coste o las fechas de la línea base aprobada. Eso es lo que la separa de una replanificación normal. Reordenar tareas, mover a una persona entre líneas de trabajo o absorber un retraso de dos días dentro de la holgura es trabajo del jefe de proyecto y no necesita solicitud. Este proceso empieza cuando alguien pide algo que la línea base no promete hoy, y termina o bien con una línea base que dice otra cosa, o bien con la solicitud cerrada y el motivo registrado.

Esto es control de cambios de proyecto, no gestión de cambios de servicios de TI. Si tu decisión es si liberar un cambio a un servicio en producción, con un CAB, un calendario de cambios, una ventana de parada y un plan de rollback, ese terreno lo cubren el diagrama de flujo del proceso de gestión de cambios en /es/templates/proceso-de-gestion-de-cambios-itil y el proceso general de control de cambios en /es/templates/proceso-de-control-de-cambios. Aquí las preguntas son de otra naturaleza: cuánto cuesta el cambio, qué mueve, quién lo financia y si el caso de negocio sigue en pie. Tampoco es gestión del cambio organizativo, la disciplina del lado humano que hay detrás de modelos como ADKAR, ni es una puerta de fase. Si lo que estás decidiendo es si continuar al final de una fase en lugar de si modificar la línea base, usa el proceso de decisión go/no-go en /es/templates/proceso-de-decision-go-no-go.

Dos decisiones sostienen el diagrama. La primera es la tolerancia: si el cambio es lo bastante pequeño para que el jefe de proyecto lo apruebe por autoridad delegada, o lo bastante grande para requerir al comité de dirección. Sin límites escritos, o todo llega al comité y este se convierte en una cola, o no llega nada y los cambios se hacen de manera informal. La segunda es qué puede responder la autoridad de cambio. Aprobar y rechazar son sencillos; aplazar es lo que peor gestionan casi todos los registros, porque un cambio aparcado sin fecha de revisión es indistinguible de uno que se ignoró. Aquí el aplazamiento tiene su propia ruta de vuelta a una revisión posterior, y el rechazo tiene un estado cerrado explícito en lugar de silencio.

Qué cubre este diagrama de flujo

En esta plantilla

• Cinco calles (Solicitante, Jefe de proyecto, Equipo de proyecto, Finanzas y Autoridad de cambio / comité de dirección) a lo largo de cinco etapas: Solicitud, Evaluación de impacto, Autorización, Actualización de la línea base, e Implementación y cierre.
• La entrada repartida entre las calles Solicitante y Jefe de proyecto: presentar una solicitud de cambio con su descripción y justificación, registrar el cambio en el registro y después una puerta, «¿La solicitud es suficientemente clara?», que devuelve las solicitudes pobres al solicitante para añadir detalle y justificación antes de volver a pasar por la misma comprobación.
• La evaluación de impacto en las calles Equipo de proyecto y Finanzas: evaluar el impacto en alcance, plazos y calidad, estimar coste y evaluar riesgos, validar el coste y la fuente de financiación, y registrar una única evaluación de impacto (con opciones, recomendación y la opción de no hacer nada incluida) en lugar de un hilo de comentarios.
• La decisión de tolerancia, «¿Dentro de la tolerancia del jefe de proyecto?», que enruta Dentro hacia la aprobación por autoridad delegada y La supera hacia el escalado al comité de dirección.
• La decisión de la autoridad de cambio, «¿Aprobar, rechazar o aplazar?», con tres ramas etiquetadas: Aprobar hacia la actualización de la línea base, Rechazar hacia un terminador cerrado en la calle del solicitante, y Aplazar hacia un paso de espera que vuelve a llevar el cambio a una revisión posterior del comité.
• De la actualización de la línea base al cierre: actualizar la línea base del proyecto, Finanzas actualiza el presupuesto y la previsión de costes, se comunica el cambio a los interesados, el equipo de proyecto lo implementa en el plan y se confirma la entrega antes de cerrar el registro del cambio.

Cuándo usar esta plantilla

• Estás escribiendo el apartado de control de cambios de un plan de dirección de proyecto o de un manual de la PMO y quieres la ruta de la solicitud a la línea base actualizada en una sola página.
• Los cambios se acuerdan en reuniones y en hilos de chat, así que nadie puede decir después qué se aprobó, quién lo aprobó ni qué añadió al coste y a la fecha de fin.
• Necesitas cerrar la autoridad delegada antes de que empiece el próximo proyecto: qué puede absorber el jefe de proyecto y qué tiene que ir al comité de dirección.
• Estás traspasando un proyecto a un nuevo jefe o presentando un comité de dirección nuevo, y necesitas mostrar cómo se autorizan los cambios de alcance, coste y plazos.
• Una PMO o un programa está estandarizando el control de cambios en proyectos que hoy lo hacen de forma distinta, antes de configurar un registro de cambios en una herramienta de gestión.

Cómo funciona

1. Renombra las calles según vuestros roles reales

   Sustituye Solicitante, Jefe de proyecto, Equipo de proyecto, Finanzas y Autoridad de cambio / comité de dirección por los roles que realmente tenéis. En un proyecto pequeño la autoridad de cambio puede ser un único patrocinador, y Finanzas puede ser un socio de negocio que revisa las cifras por correo. Fusiona calles en lugar de dibujar órganos de gobierno que no existen, y mantén el número de calles en cinco o menos para que el diagrama siga siendo legible.

2. Escribe vuestras tolerancias junto a la decisión

   «¿Dentro de la tolerancia del jefe de proyecto?» solo es útil con cifras detrás. Registra la desviación de coste y de plazo que el jefe de proyecto puede autorizar, más una regla de alcance del tipo ningún cambio en entregables acordados, beneficios o compromisos contractuales. Si trabajáis con PRINCE2, esta es la tolerancia que delega el comité de proyecto, y puede venir con un presupuesto de cambios para que los cambios rutinarios nunca lleguen al comité. Acordad los límites en el inicio, no la primera vez que se ponen a prueba.

3. Define qué debe contener la evaluación de impacto

   Convierte «Registrar la evaluación de impacto» en una plantilla real: efecto sobre alcance, plazos, coste, calidad y riesgo, la fuente de financiación, las opciones consideradas, una recomendación y la opción de no hacer nada. Nombra a quien evalúa cada dimensión y cuánto tiempo tiene, porque una evaluación que tarda tres semanas acaba convertida en una decisión tomada sin ella.

4. Nombra la autoridad de cambio y su cadencia

   En la revisión del comité de dirección, registra quiénes son los aprobadores, si hace falta quórum, cada cuánto se reúnen y el plazo de corte para entrar en el orden del día. Decide explícitamente qué pasa entre reuniones: o una persona con nombre puede autorizar de urgencia e informar en la siguiente revisión, o el cambio espera. Dejar eso sin definir es lo que produce cambios aprobados en los pasillos.

5. Haz que el aplazamiento tenga fecha

   Un cambio aplazado necesita fecha de revisión, responsable y un estado vivo en el registro, y por eso la rama Aplazar vuelve aquí a una revisión posterior del comité y no a un terminador. Revisa los aplazados en cada reunión y cierra los que hayan quedado superados, con el motivo registrado, para que el registro refleje decisiones en lugar de acumularlas.

6. Fija la regla de nueva línea base y luego publica y versiona el diagrama

   Indica qué cambios aprobados obligan a una nueva línea base formal y cuáles se absorben en la previsión, y exige que la referencia del cambio quede registrada contra la nueva versión de la línea base. Conserva las líneas base anteriores para poder explicar una desviación meses después. Después comparte el diagrama donde se trabaja (junto al formulario de solicitud de cambio y en el manual del proyecto) y mantén su propio historial de versiones para poder mostrar cuándo cambió el procedimiento y por qué.

Preguntas frecuentes

¿Qué diferencia hay entre una solicitud de cambio de proyecto y la gestión de cambios de TI?

Responden a preguntas distintas. Una solicitud de cambio de proyecto pregunta si debe modificarse una línea base acordada (alcance, coste, fechas y a menudo beneficios), y la decisión es comercial: cuánto cuesta, qué retrasa, quién lo financia y si el caso de negocio sigue en pie. La gestión de cambios de TI pregunta si debe liberarse un cambio a un servicio en producción, y la decisión es operativa: riesgo para los usuarios, pruebas, ventana de parada y rollback. Si la conversación incluye un CAB, un calendario de cambios y un plan de rollback, usa el diagrama de flujo del proceso de gestión de cambios. Si incluye un comité de dirección, una fecha de fin revisada y una partida presupuestaria, este es el diagrama correcto.

¿Qué debe incluir una solicitud de cambio de proyecto?

Lo suficiente para que otra persona pueda evaluarla sin una reunión: qué cambia y por qué, quién lo plantea y cuándo, el disparador (un requisito nuevo, un defecto, una dependencia externa, una decisión revertida), la urgencia, a quién afecta y qué pasa si nada cambia. La evaluación aporta el resto: efecto sobre alcance, plazos, coste, calidad y riesgo, la fuente de financiación, las opciones consideradas y una recomendación. Mantén los dos como registros separados. La solicitud son las palabras del solicitante y la evaluación es la respuesta del proyecto; fusionarlas hace imposible ver después qué se pidió realmente.

¿Quién aprueba una solicitud de cambio de proyecto?

Depende del tamaño, que es justo para lo que sirve la decisión de tolerancia de este diagrama. Los cambios que caben dentro de la desviación delegada al jefe de proyecto en el inicio se aprueban en la calle Jefe de proyecto y se registran. Todo lo que la supere va a la autoridad de cambio, normalmente el comité de dirección, el comité de proyecto o el patrocinador. PRINCE2 define la autoridad de cambio como un rol que el comité de proyecto puede delegar, a veces con un presupuesto de cambios asociado para que los cambios rutinarios no necesiten una decisión completa del comité, y el control integrado de cambios del PMI usa un comité de control de cambios con el mismo propósito. Lo llames como lo llames, escribe los límites: una tolerancia sin definir significa que o se escala todo o no se escala nada.

¿Qué significa realmente aplazar un cambio?

Que la decisión se pospone, no que se rechaza; normalmente porque el impacto aún no está claro, porque el cambio depende de otra decisión o porque pertenece a una fase o versión posterior. Solo funciona si el aplazamiento tiene fecha. En este diagrama la rama Aplazar lleva a un paso de espera que vuelve a llevar el cambio a una revisión posterior del comité de dirección, y no a un terminador, porque un cambio aplazado sin ruta de vuelta es un rechazo que nadie ha tenido que justificar. Da a cada aplazado una fecha de revisión, un responsable y un estado visible en el registro.

¿Hay que rebasar la línea base después de cada cambio aprobado?

Rebasa todo lo que cambie lo que el proyecto se ha comprometido a entregar, para cuándo o por cuánto. Si no, el informe de desviaciones mide contra un plan que ya has aceptado abandonar, y cada informe de estado necesita una explicación verbal. Conserva las líneas base anteriores en lugar de sobrescribirlas, registra la referencia del cambio contra la nueva versión y anota la fecha de aprobación. Los cambios pequeños aprobados dentro de tolerancia suelen absorberse en la previsión en lugar de provocar una nueva línea base formal: indica en vuestro plan cuál es cuál, para que dos personas leyendo el mismo informe lleguen a la misma cifra.

¿Cómo frena este proceso el scope creep?

Haciendo visible el coste de un cambio antes de acordarlo y no después de entregarlo. El scope creep rara vez es una única decisión grande; es una serie de pequeñas adiciones absorbidas por un equipo que nunca las mandó a evaluar. Los controles que importan aquí son el registro, para que toda solicitud deje rastro; la evaluación de impacto, para que nadie apruebe una adición sin ver qué le hace a las fechas y al presupuesto; y los límites de tolerancia, para que el jefe de proyecto sepa exactamente dónde acaba su autoridad. El proceso no puede impedir los cambios, ni debería: los hace deliberados y atribuibles.