Control de cambios en un proyecto: el proceso, no el drama

Nadie abandona un proyecto por un solo cambio gigante: lo pierden por veinte cambios chicos que nadie discutió. La pantalla extra que «es una línea de código», el reporte que «solo falta agregarle una columna», el plazo que «se estira una semanita nada más». Cada uno parece gratis en el momento; acumulados, son el desvío que nadie autorizó. Ese fenómeno tiene nombre y mecánica propias: el scope creep.

El control de cambios es el antídoto, y conviene entender bien qué es: no una valla para decir que no, sino un mostrador donde cada cambio se registra, se le pone precio en alcance, plazo y costo, y alguien con autoridad decide con la información en la mano. Los proyectos que dicen que no a todo funcionan tan mal como los que dicen que sí a todo: lo que protege el proyecto no es la negativa, es la decisión consciente.

El proceso completo cabe en una tabla. Ningún paso es opcional, pero todos pueden ser ligeros:

El paso que los equipos se saltan casi siempre es el cuarto, y es el que guarda la coherencia: si el alcance cambia y la línea base no, en tres semanas el plan oficial y la realidad son documentos distintos y nadie puede decir si vas bien o mal.

Un recorrido completo, para aterrizarlo: el cliente pide el jueves que el reporte también salga en PDF. Se registra con folio el mismo día. El impacto tarda una hora: son 4 horas de trabajo, no toca la fecha de entrega, cabe en la reserva. El líder aprueba el viernes, la base no cambia (el plazo no se movió) y el lunes el equipo ya lo ve en el tablero. Total: tres días, cero drama, cero trabajo invisible. El mismo cambio sin proceso viaja por chat, lo toma quien estaba libre, lo hace en su fin de semana y nadie lo vuelve a mencionar —ni para agradecer ni para cobrarlo—.

El formulario es la parte que decide si el proceso vive o muere: si pide más de lo necesario, la gente deja de llenarlo y los cambios vuelven a viajar por el pasillo. Seis campos bastan:

1. Identificación: folio, fecha y quién pide el cambio.
2. Descripción: qué cambia, en una o dos frases sin adjetivos.
3. Motivo: por qué se pide —qué problema resuelve o qué riesgo evita—.
4. Impacto: efecto estimado en alcance, plazo y costo, con números.
5. Recomendación: opciones del responsable del proyecto con su sugerencia.
6. Decisión: aprobado, rechazado o aplazado; quién, cuándo y a quién se comunicó.

Copia esos seis campos a un documento o a una plantilla de tarjeta y tienes el proceso funcionando. El campo de recomendación es el que más se subestima: presentar opciones con precio —«lo hacemos este mes y movemos X», «lo hacemos el mes que viene», «no lo hacemos»— convierte la reunión de decisión en una elección y no en una discusión.

El error clásico es enviar todo al cliente o dejar decidir todo al equipo. La regla que funciona es un umbral escrito antes del primer cambio:

• Dentro del margen del líder. Cambios que caben en la reserva del propio proyecto —unas horas de trabajo, sin tocar fechas comprometidas—. Aprueba el responsable del proyecto y se informa, no se consulta.
• Fuera del margen. Todo lo que toca precio, fecha de entrega o alcance acordado. Aprueba el cliente o la dirección según el contrato interno, con la nota de impacto delante.
• Recurrentes. Si el mismo tipo de cambio se aprueba tres veces, deja de ser un cambio y pasa a ser alcance: se incorpora y se ajusta la base una sola vez.

Lo importante del umbral no es el número sino la existencia: cuando todo el mundo sabe de antemano quién decide qué, el proceso no depende de ánimos ni de jerarquías del día. Y el solicitante gana algo valioso: saber antes de pedir si su cambio es de mostrarador chico o de mesa grande.

Los equipos malos con el control de cambios suelen tener la misma idea de fondo: que decir «ese cambio va por el proceso» es una forma elegante de decir que no. Es al revés. Un proceso sano es el que permite decir que sí —con su precio en fecha o en presupuesto— sin castigar al equipo con trabajo invisible. Lo contrario es el sí barato: se acepta todo, se descuenta de los fines de semana y del alcance real, y el agotamiento hace el control de calidad.

Piénsalo desde el otro lado de la mesa: el cliente que pide un cambio no está atacando el proyecto, está ajustando lo que necesita. Lo que destruye la relación no es un «sí, con este costo», ni un «no, porque rompería X», sino el «sí, claro» silencioso que después llega como retraso sorpresa. El proceso da un tercer camino que el improviso no tiene: negociar opciones. Y cada cambio aprobado y cobrado correctamente deja de ser una amenaza y pasa a ser parte legítima del negocio.

Si trabajas por iteraciones, además, el proceso se simplifica solo: los cambios que no urgen pueden esperar al próximo sprint, y el tablero con límites WIP te impide meterlos empujando lo que ya estaba en curso. Ese modelo de cadencia con flujo está desarrollado en scrumban: mezclar Scrum y Kanban.

Y si quieres manejar los cambios como tarjetas con dueño —tablero con límites WIP, checklists para el análisis de impacto y todo en un JSON local de tu carpeta, sin cuenta ni asientos— Hito está pensado para equipos de 1 a 15 personas.

👉 Prueba Hito gratis — cada cambio, registrado y decidido donde el equipo trabaja.