Línea base de un proyecto: alcance, cronograma y costo

Una línea base es la versión congelada del plan aprobado: los entregables acordados, las fechas comprometidas y el presupuesto autorizado, guardados como referencia inmutable. Su única función es responder una pregunta con datos: ¿vamos según lo acordado o no? Sin esa foto congelada, «vamos bien» siempre será la opinión de quien hable más fuerte en la reunión.

Lo que no es: no es el plan de trabajo editable que el equipo actualiza a diario, ni el Gantt decorativo que se imprime para el kickoff, ni la carpeta de versiones «plan-FINAL-v3-este-sí». La línea base no se toca para reflejar la realidad: la realidad se compara contra ella. Esa distinción es la que separa un proyecto gobernado de uno que improvisa con hojas de cálculo y buena voluntad.

La línea base no es una sola: son tres referencias congeladas el mismo día, porque un cambio en una casi siempre arrastra a las otras dos:

La de costo merece una mención: no basta con el total aprobado, importa cómo se distribuye en el tiempo, porque el desvío solo es visible si sabes cuánto deberías haber gastado a la altura del mes 2. Cómo armar esa distribución y vigilarla está en presupuesto de un proyecto.

Fijar la línea base suena a trámite de oficina de proyectos, pero son cuatro decisiones:

1. Aprueba el plan antes de congelarlo. La base se fija cuando alcance, cronograma y presupuesto tienen acuerdo explícito de quien financia el proyecto. Congelar un borrador solo garantiza un re-baseline inmediato.
2. Guárdala como versión fechada e inmutable. Una copia que nadie edita, con fecha y responsable. Tres documentos, no treinta.
3. Declara que los cambios solo entran vía control de cambios. La base se ajusta cuando un cambio se aprueba, nunca para «actualizarla» porque el plan se quedó corto. El mecanismo completo está en control de cambios en un proyecto.
4. Deja una sola versión vigente y visible. Todo el equipo debe poder ver cuál es la referencia sin preguntar; dos versiones circulando equivalen a ninguna.

Con la base congelada, el seguimiento es aritmética simple. Ejemplo de cronograma: el hito «módulo de facturación terminado» estaba planificado al día 30 y se cerró al día 36. Desvío: +6 días. Si el proyecto dura 90, hablas de un 20 % de desvío en ese hito y puedes hacer la única pregunta relevante: ¿se recupera en la cadena o se arrastra hasta la entrega final?

Ejemplo de costo: a la altura del mes 2, la base decía 100.000 y el proyecto lleva comprometidos 112.000. Desvío: +12 %. La pregunta no es «¿por qué gastamos más?» sino «¿los 12.000 extra compraron alcance aprobado o alcance filtrado?»: la primera respuesta es gestión; la segunda, una fuga que hay que tapar. Para un proyecto chico, con esos dos números por semana —días y dinero contra la base— tienes el 80 % del control, sin métricas exóticas ni software especializado.

El de alcance se mide distinto, y casi todos lo ignoran: no se trata de porcentaje completado sino de lista cerrada. Si la base congelaba 12 entregables y hoy hay 14 sobre la mesa, el desvío no es de avance, es de frontera: dos entregables entraron y nadie los pagó en tiempo ni en dinero. Ese conteo —cuántos de los congelados están hechos y cuántos extras se colaron— es la conversación más incómoda y más rentable que una línea base te permite tener.

Re-baselinear es reemplazar la base vigente por una nueva versión oficial. Se hace pocas veces y con dos motivos legítimos: un cambio mayor aprobado formalmente que mueve el plan de punta a punta, o el cierre de una fase que cambia la escala de lo que queda. Cada re-baseline se documenta con fecha, motivo y la versión anterior archivada: el valor histórico de la base es justamente poder explicar el desvío acumulado.

Lo que no se hace es re-baselinear cada semana «para que el plan refleje la realidad». Una base que se actualiza al ritmo del desvío no mide nada: borra la evidencia y convierte cualquier proyecto en puntual. Si la tentación es alta, el problema no es la base sino que el plan nunca fue viable, y eso se corrige con un re-baseline único, argumentado y comunicado, no con ajustes silenciosos.

Una regla práctica para saber si el re-baseline es legítimo: solo procede cuando el desvío viene de una decisión, no de una acumulación. «El cliente aprobó mover la entrega por su reorganización interna» es un motivo; «nos atrasamos tres semanas así que actualizo las fechas» es un borrón. La prueba inversa también sirve: si los proyectos de tu portafolio nunca registran desvíos pero siempre llegan tarde, lo que está fallando no es el planificar, es el medir contra algo estable.

Si tu proyecto ya corre sin base, no intentes reconstruir las tres componentes de golpe: empieza por la más barata. Congela hoy las fechas de los hitos que quedan y el presupuesto total restante. Son dos números, caben en media página, y desde mañana ya puedes decir «el hito va 4 días tarde» en vez de «va algo justo». El alcance congelado puede esperar una semana; la disciplina de comparar, no.

Dos ayudas inmediatas. Para armar el cronograma que vas a congelar, parte de una plantilla con hitos y dependencias: la tienes en plantilla de cronograma de proyecto. Y si trabajas por iteraciones, la línea base viva son los objetivos de sprint: cada iteración compromete un alcance pequeño y se mide contra él; ese modelo de cadencia y flujo está desarrollado en scrumban.

Y si quieres congelar la base y seguir el avance en la misma herramienta —dashboard de portafolio para ver todos tus proyectos, sincronización con GitHub 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 — tu línea base y tu avance, local-first, sin nube.