En la gestión de proyectos, un cambio no aprobado formalmente no es un cambio gestionado: es un riesgo. Cuando una modificación del alcance, el cronograma o el presupuesto se ejecuta sin un proceso formal de aprobación, el proyecto queda expuesto a conflictos sobre quién autorizó el cambio, quién asume el coste adicional y qué impacto tiene sobre los compromisos del proyecto con el cliente.
La plantilla de solicitud de cambios es el documento que inicia el proceso formal de gestión de cambios. Recoge la descripción del cambio solicitado, su justificación y el análisis de su impacto en coste, plazo y alcance, y obtiene las firmas de aprobación necesarias antes de que el cambio sea implementado. Sin este documento, no hay cambio gestionado — solo improvisación.
En el PMBOK, el Control Integrado de Cambios es el proceso que garantiza que todos los cambios del proyecto se gestionan de forma coordinada y coherente. La solicitud de cambios es el punto de entrada de ese proceso: el documento que formaliza que alguien está proponiendo una modificación y que desencadena el análisis, la evaluación y la decisión de aprobación o rechazo.
El proceso sigue siempre la misma secuencia:
Sin este proceso formal, los cambios se acumulan sin control, el presupuesto y el cronograma se desvían sin que nadie tenga una imagen clara de cuánto y por qué, y los conflictos con el cliente son inevitables.
Es habitual confundir estos dos documentos. Son complementarios y se usan en secuencia, pero tienen funciones distintas:
La solicitud de cambios es el documento individual que formaliza un cambio concreto. Recoge todos los detalles de ese cambio específico: descripción, justificación, impacto, análisis y firmas. Se emite una solicitud por cada cambio.
La lista de control de cambios es el registro global de todos los cambios del proyecto. Recoge un resumen de cada solicitud — su estado, su impacto en coste y plazo y si ha sido aprobada o rechazada — en una única tabla que da la visión de conjunto del proyecto.
El flujo correcto es: se emite una solicitud de cambios por cada modificación → cuando se resuelve (aprobada o rechazada), se registra en la lista de control de cambios. Ambos documentos son necesarios: la solicitud gestiona el detalle; la lista gestiona la visión global.
La solicitud de cambios tiene varios apartados, pero el análisis de impacto es el que determina si el cambio puede aprobarse o no. Sin un análisis de impacto riguroso, la aprobación es a ciegas: se acepta una modificación sin saber realmente cuánto va a costar ni cuánto va a retrasar el proyecto.
Impacto en el cronograma
El análisis debe identificar qué tareas del proyecto se ven afectadas por el cambio y cómo varía su duración o sus dependencias. Si el cambio afecta a tareas del camino crítico, el impacto en la fecha de fin del proyecto puede ser significativo aunque el cambio en sí parezca menor. Si afecta solo a tareas con holgura, el impacto en el cronograma puede ser nulo o limitado.
Impacto en el coste
El análisis de coste debe cuantificar el trabajo adicional — o reducido, en el caso de cambios que eliminan alcance — que implica la modificación. Esto incluye las horas de trabajo del equipo, los materiales adicionales, los costes de terceros y cualquier otro gasto directo o indirecto asociado al cambio.
Impacto en el alcance
No todos los cambios son de alcance — algunos afectan solo al cronograma o al coste — pero cuando el cambio implica añadir o eliminar entregables o paquetes de trabajo, la modificación del alcance debe quedar documentada con precisión. En estos casos, conviene referenciar el elemento de la WBS afectado para facilitar la trazabilidad.
Quién debe realizar el análisis
El análisis de impacto no siempre lo realiza el director del proyecto. En cambios técnicos complejos, puede ser necesario que lo realice el responsable técnico del área afectada o incluso un proveedor externo. La plantilla incluye un campo específico para identificar quién ha realizado el análisis, con su firma, lo que garantiza que el resultado del análisis es responsabilidad de alguien concreto.
Identificación del proyecto y referencia de la solicitud
Cada solicitud debe tener una referencia única que permita identificarla y localizarla dentro del sistema documental del proyecto y en la lista de control de cambios. El sistema de referencias lo define el director del proyecto al inicio del proyecto — puede ser tan simple como una numeración correlativa (SC-001, SC-002...).
Datos del solicitante
La solicitud puede ser emitida por el director del proyecto, por el cliente o por cualquier otro interesado. Identificar al solicitante es importante para tener un punto de contacto claro en caso de dudas durante el análisis, y para entender el contexto y la motivación del cambio.
Descripción y justificación del cambio
La descripción debe ser suficientemente concreta para entender sin ambigüedades qué se está modificando. La justificación explica por qué el cambio es necesario o conveniente — cuál es el problema que resuelve o el beneficio que aporta. Sin una buena justificación, la solicitud difícilmente será aprobada.
Si el cambio afecta a un paquete de trabajo concreto de la WBS, conviene referenciar su código en este apartado. Esto facilita enormemente el análisis de impacto y la trazabilidad posterior.
Análisis de impacto en coste y plazo
Los campos de impacto recogen el resultado del análisis: cuántos días de retraso implica el cambio y cuánto coste adicional (o reducción) supone. También incluye la firma de la persona responsable del análisis, que avala el resultado.
Firmas de aprobación
La plantilla requiere tres firmas: el director del proyecto, el representante del cliente y el sponsor. Las tres deben aprobar el cambio para que pueda implementarse. Si cualquiera de los tres rechaza, el cambio no se implementa — o se renegocia hasta alcanzar un acuerdo.
Esta triple firma tiene un propósito claro: garantizar que el cambio ha sido evaluado desde tres perspectivas distintas — técnica (director del proyecto), de negocio (cliente) y organizativa (sponsor) — antes de ser aprobado.
El momento correcto para emitir una solicitud de cambios es en cuanto se identifica la necesidad de cambio, antes de que se tome ninguna decisión de implementación. Emitir la solicitud después de que el cambio ya se ha ejecutado — para regularizar una situación de hecho — es una práctica que debe evitarse: invierte el proceso, elimina la posibilidad de rechazar el cambio y debilita la posición del director del proyecto frente al cliente.
En proyectos con muchos cambios, es recomendable establecer un umbral de impacto por debajo del cual los cambios menores pueden gestionarse de forma simplificada, sin necesidad de la solicitud completa. Este umbral debe acordarse con el cliente al inicio del proyecto y quedar documentado en el plan de gestión de cambios.
Esta plantilla forma parte del Pack de Plantillas Profesionales, que incluye 46 plantillas editables alineadas con los procesos del PMBOK. Se integra directamente con otras herramientas del pack:
ASI DE FACIL Y SEGURO. Para cualquier duda puedes ponerte en contacto con nosotros en el pie de página.