Diagrama de flujo del proceso de solicitud de cambios en proyectos

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.