Cómo gestionar una solicitud de cambio en un proyecto (proceso + plantilla)

November 5, 2026

GanttMaster

Plan Smarter. Execute Faster.

Interactive Project Management Tool, real-time collaboration.

⭐ 4.8 Rating • Trusted by modern teams worldwide

Un "¿puedes añadir esto también?" dicho de palabra en una obra con mucho movimiento, en el pasillo de una clínica o durante una llamada rápida puede parecer inofensivo. Días después el cronograma se ha retrasado, el presupuesto va justo y nadie recuerda quién aceptó qué. Los cambios informales arruinan proyectos no porque las ideas sean malas, sino porque nadie registró la solicitud, revisó el impacto ni actualizó el plan.

Esta guía te lleva paso a paso por un proceso práctico de solicitud de cambio que puedes usar en obras y trabajo de campo, operaciones sanitarias, proyectos de pequeñas empresas y entregas con varios equipos. Encontrarás pasos claros, un formulario listo para copiar, un breve ejemplo práctico y consejos para evitar los errores más comunes.

¿Qué es una solicitud de cambio en un proyecto?

Una solicitud de cambio es una propuesta por escrito para modificar algo que ya se había acordado: el alcance, el cronograma, el presupuesto, las expectativas de calidad, los entregables o la forma de hacer el trabajo. Puede venir de un cliente, un patrocinador, un jefe de cuadrilla, un proveedor o alguien del equipo del proyecto.

No es lo mismo que las actualizaciones diarias de tareas. Mover una subtarea un día porque los materiales llegaron tarde es gestión normal del cronograma. Añadir una nueva sala, cambiar un proveedor importante o aplazar la fecha de puesta en marcha por un nuevo requisito es un cambio que debe pasar por una solicitud formal.

La solicitud en sí no aprueba el cambio. Solo inicia una revisión para que las personas adecuadas decidan con el impacto delante.

Por qué importa un proceso formal de solicitud de cambio

  • Protege la línea base. El alcance, el cronograma y el coste solo siguen teniendo sentido si los cambios se registran frente a ellos.
  • Hace visible el impacto. Una petición "pequeña" suele afectar a las dependencias, al riesgo, a la calidad y a quienes esperan ese trabajo.
  • Crea un rastro claro de decisiones. Puedes mostrar quién pidió el cambio, quién lo evaluó y quién lo aprobó o rechazó.
  • Mantiene conversaciones justas. Decir "sí" o "no" depende del impacto documentado, no de quién lo pidió más alto.
  • Reduce el retrabajo. Los equipos dejan de perseguir instrucciones medio recordadas y trabajan con un plan actualizado.

El proceso de solicitud de cambio en 7 pasos

1. Registra la solicitud

Anota cada solicitud de cambio en un único lugar en cuanto aparezca. Apunta la fecha, quién la envió y un título breve. No esperes a que alguien "lo haya pensado". Si no está registrada, es fácil tratarla como si ya estuviera aprobada.

2. Describe y justifica el cambio

Pide al solicitante que explique qué debe cambiar y por qué. Las buenas descripciones son concretas: "Añadir un segundo punto de inspección antes de la entrega" sirve; "mejorarlo" no. La justificación debe decir qué problema resuelve el cambio o qué oportunidad crea.

3. Evalúa el impacto en alcance, cronograma, coste, calidad y riesgo

Revisa la solicitud frente al plan actual:

  • Alcance: ¿Qué entregables o trabajos se añaden, eliminan o modifican?
  • Cronograma: ¿Qué tareas se mueven, qué dependencias se rompen y cambia la fecha de fin?
  • Coste: ¿Qué mano de obra, materiales o tarifas de proveedores adicionales aparecen y, en su caso, qué ahorros?
  • Calidad: ¿El cambio eleva, rebaja o redefine los criterios de aceptación?
  • Riesgo: ¿Qué riesgos nuevos aparecen y cuáles de los existentes crecen o disminuyen?

Implica a las personas que harán el trabajo. Los jefes de campo, los supervisores de departamento y los proveedores suelen detectar efectos en cadena que una revisión solo desde la oficina pasa por alto.

4. Enumera las opciones, incluida no hacer nada

Antes de decidir, detalla opciones realistas. Las habituales son: aprobar tal como se pidió, aprobar una versión más pequeña, aplazar a una fase posterior o rechazar. Incluye siempre "no hacer nada" para que el coste de quedarse quieto también quede explícito.

5. Decide: aprobar, modificar o rechazar

Usa un circuito de decisión acordado. En proyectos pequeños pueden ser el propietario y el responsable del proyecto juntos. En los grandes, un breve comité de cambios. Registra la decisión, la fecha y cualquier condición (por ejemplo, "aprobado si el cliente acepta una ampliación de dos semanas").

6. Actualiza la línea base y el plan de trabajo

Un cambio aprobado no está completo hasta que el plan se pone al día. Actualiza la declaración de alcance o las exclusiones si hace falta, revisa las tareas y fechas afectadas, ajusta las partidas del presupuesto y renueva los riesgos. Avisa a las personas cuyo trabajo ha cambiado.

7. Cierra la solicitud

Marca la solicitud como cerrada con el resultado final. Guarda el formulario donde el equipo pueda encontrarlo más tarde. Cerrar el ciclo evita que solicitudes antiguas sigan circulando como si estuvieran abiertas.

Formulario de solicitud de cambio listo para copiar

Usa estos campos como formulario de una página. Cópialos en un documento, una hoja de cálculo o una plantilla de notas y rellénalos para cada solicitud.

  • ID de solicitud / fecha:
  • Solicitado por (nombre, cargo, organización):
  • Nombre del proyecto:
  • Título breve del cambio:
  • Descripción detallada del cambio propuesto:
  • Motivo / justificación de negocio:
  • Prioridad (baja / media / alta / urgente):
  • Fecha de efecto deseada:
  • Impacto en el alcance:
  • Impacto en el cronograma (tareas, fechas, fecha de fin):
  • Impacto en el coste / presupuesto:
  • Impacto en la calidad / criterios de aceptación:
  • Impacto en el riesgo:
  • Opciones consideradas (incluida no hacer nada):
  • Recomendación:
  • Decisión (aprobar / aprobar con cambios / rechazar / aplazar):
  • Responsable(s) de la decisión y fecha:
  • Condiciones o acciones de seguimiento:
  • ¿Plan actualizado? (alcance / cronograma / presupuesto / riesgos / comunicaciones):
  • Fecha de cierre:

Ejemplo práctico: instalación de equipos en una clínica

El siguiente ejemplo es una ilustración inventada para un pequeño proyecto de operaciones sanitarias. Adapta el nivel de detalle a tu propio trabajo.

  • Proyecto: Instalar dos monitores nuevos y sus soportes en salas de consulta de la Clínica B.
  • Plan original: Cableado y soportes en la semana 1, instalación de equipos y recorrido con el personal en la semana 2, reapertura de las salas el viernes.
  • Solicitud de cambio: Operaciones pide añadir un tercer monitor en una sala auxiliar que estaba fuera del alcance.
  • Impacto: Soporte y tendido de cable adicionales; el electricista necesita medio día; el recorrido con el personal se alarga; el presupuesto sube por el coste del equipo y la mano de obra; la reapertura se retrasa dos días laborables salvo que se aprueben horas extra.
  • Opciones: (1) aprobar ya la tercera sala con una ampliación de dos días; (2) aprobar solo si las horas extra mantienen la reapertura del viernes; (3) aplazar la tercera sala a un miniproyecto posterior; (4) no hacer nada.
  • Decisión: Aplazar. El patrocinador mantiene la reapertura del viernes y registra un nuevo proyecto de seguimiento para la sala auxiliar.
  • Actualización del plan: Se aclaran las exclusiones de alcance; el cronograma no cambia; se añade una nota en el proyecto para que el equipo no se vea arrastrado a trabajos informales de "ya que estás aquí".

Lo útil no es qué opción ganó, sino que el equipo comparó el impacto antes de decir que sí.

Consejos para distintos equipos

Equipos de obra y de campo

Canaliza las instrucciones de obra a través del mismo registro de cambios que se usa en la oficina. Adjunta fotos o croquis a la solicitud cuando el cambio sea físico. Revisa los relevos entre oficios y las fechas de inspección antes de aprobar algo que parezca "rápido".

Operaciones sanitarias

Detalla qué unidades, turnos y servicios de atención al paciente se ven afectados. Indica si el cambio puede hacerse sin interrumpir la atención y quién puede aprobar cambios operativos frente a cambios de instalaciones o de TI.

Pequeñas empresas

Mantén el formulario en una página. El propietario y el responsable del proyecto pueden ser todo el circuito de decisión. El objetivo sigue siendo el mismo: poner la petición por escrito, revisar plazos y coste y después actualizar el plan.

Jefes de proyecto

Acuerda el circuito de decisión en la reunión de arranque, antes de que llegue la primera sorpresa. Vincula cada cambio aprobado a responsables del cronograma para que los comentarios y los enlaces a archivos estén en las tareas que realmente se movieron.

Errores comunes en las solicitudes de cambio

  • Tratar un acuerdo verbal como aprobación. Si no está escrito y decidido, no es un cambio controlado.
  • Saltarse el impacto en las dependencias. Una sola tarea añadida puede empujar varias sucesoras Fin a Comienzo y la fecha de fin.
  • Aprobar el trabajo sin actualizar el presupuesto. El impacto en el coste forma parte de la misma decisión que el impacto en el cronograma.
  • Ignorar la opción de no hacer nada. A veces lo mejor es aplazar o rechazar.
  • Dejar la solicitud abierta para siempre. Ciérrala con un resultado para que el registro siga siendo fiable.
  • Actualizar el plan solo en la cabeza de alguien. El equipo necesita las tareas, fechas, responsables y riesgos revisados en el plan compartido.

Tras la aprobación: actualizar el plan con GanttMaster

Una vez aprobado un cambio, el plan tiene que reflejar la nueva realidad. GanttMaster es nuestra app de gestión de proyectos para iPhone y iPad, y encaja de forma natural en esta etapa:

  • Añade o reorganiza tareas y subtareas. Crea tareas para el trabajo nuevo, divídelas en subtareas y define fechas de inicio y vencimiento, prioridades y un usuario o equipo asignado.
  • Repara la secuencia del Gantt. Vuelve a enlazar el trabajo con dependencias Fin a Comienzo, Comienzo a Comienzo y Fin a Fin para que las tareas sucesoras se muevan con el cambio.
  • Marca tareas de control cortas. Si el cambio añade una revisión o un punto de inspección, añádelo como una tarea normal corta y enlázalo con Add Dependency para que siga ligado al trabajo que lo rodea.
  • Actualiza riesgo y presupuesto cuando se vean afectados. Registra los riesgos nuevos o modificados con probabilidad, impacto, responsable y mitigación. Ajusta el presupuesto del proyecto y registra los gastos relacionados por categoría.
  • Deja el rastro en el propio trabajo. Usa comentarios y enlaces a archivos en las tareas afectadas para el formulario de cambio firmado, los planos o las notas de decisión.
  • Mantén claro el foco diario. La vista Today y los recordatorios ayudan al equipo a ver qué vence ahora después de que se muevan las fechas.
  • Mantén alineados los roles y todo el equipo. El acceso por roles (Project Manager, Team Manager, User) y las notificaciones en tiempo real ayudan a que las personas adecuadas vean asignaciones y novedades, sin coste extra por miembro del equipo.

Reflexiones finales

Un proceso de solicitud de cambio no tiene por qué ser pesado. Si cada cambio relevante se registra, se evalúa en alcance, cronograma, coste, calidad y riesgo, lo deciden las personas adecuadas y después se refleja en el plan vivo, evitarás la mayor parte de la deriva silenciosa que convierte proyectos sanos en simulacros de incendio. Empieza con un formulario de una página, acuerda quién decide y cierra cada solicitud con un resultado claro.

GanttMaster logo

Planifica desde tu iPhone o iPad

Transparencia total: desarrollamos GanttMaster, una app para iPhone y iPad con dependencias FS/SS/FF, tareas y subtareas, tareas de control, una vista Today con recordatorios, asignación de equipo, seguimiento de riesgos y presupuesto, y sin precio por usuario. Se descarga gratis con una semana de prueba y después cuesta 5,99 $/mes o 34,99 $/año.

Download on the App Store