Línea base del cronograma

Share Button

En este artículo vamos a describir lo que es la línea base del cronograma, como se utiliza durante el proceso de seguimiento y control, y cuál es el comportamiento que se espera del director del proyecto frente a ella.

¿Qué es la línea base del cronograma?

La línea base del cronograma se puede definir como la última versión del cronograma que ha sido aprobada formalmente por el sponsor el proyecto, o el comité de dirección del proyecto, y que define los objetivos de este en relación a los plazos. Esto no implica que cada vez que modifiquemos el cronograma se genere una nueva línea base, de hecho la mayoría de las veces no ocurrirá así (idealmente nunca debería).

Dos puntos importantes que se desprenden del párrafo anterior son:

  • La línea base del proyecto la crea el director del proyecto, ya que sale directamente del cronograma, pero la aprueba y oficializa el sponsor. Por tanto, un director de proyectos no puede utilizar o distribuir una nueva línea base hasta que el sponsor la haya aprobado.
  • Un director de proyectos puede modificar el cronograma siempre que sea necesario, mientras se mantengan los objetivos del proyecto. Cuando esto deje de ser cierto será necesario modificar la línea base. Por tanto, una modificación del cronograma que implique modificar la fecha de entrega del proyecto (o de cualquier objetivo) solo puede oficializarse por parte del sponsor, ya que implica una modificación en la línea base.


De forma práctica la línea base del cronograma es una foto de este en un momento concreto, y se suele representar como un segundo cronograma junto al de trabajo. En la siguiente imagen podemos ver que cada tarea tiene dos líneas, la línea negra inferior es la línea base del cronograma, y la superior (azul o rojo) el cronograma de trabajo.

Uso de la línea base del cronograma

Durante el proceso de seguimiento y control del proyecto, el director del proyecto debe ajustar el cronograma de acuerdo al avance y modificaciones previstas, pudiéndose generar diferentes situaciones. Vamos a ver las más significativas (asumiendo que se ha realizado una correcta planificación), y como debe actuar el director de proyecto en cada caso:

Atraso de una tarea con efecto sobre los objetivos del proyecto

Imaginemos que acabamos de empezar un proyecto de 21 días de duración. Al comienzo del tercer día vemos que la tarea 1 solo ha conseguido completar el trabajo de un día y no podemos incrementar sus recursos, lo que implica que nos hará falta un día adicional para completarla. La tarea 5 está en el avance previsto. Modificamos el cronograma para mostrar la nueva situación, y este queda de la siguiente forma:

linea base del cronograma, ejemplo de atraso

Como la finalización de la tarea 1 se ha retrasado en un día, el resto del cronograma se ha retrasado en un día, lo que implica que sabemos que la fecha de entrega del hito y de fin del proyecto no se van a cumplir. Que hacemos?
Creamos una nueva versión del cronograma e informamos de la nueva situación al equipo del proyecto? Por todos es sabido que una buena comunicación es una pieza clave en la gestión del proyecto, y cuando antes se informe de los problemas mejor. Que lastima que el proyecto se vaya a atrasar y que esto implique tener que modificar la línea base, pero que podemos hacer? A esto es lo que me refería cuando publique en otro artículo la siguiente frase sarcástica “Hay directores de proyecto que son grandes periodistas, ya que como estos, cuentan la realidad sin interferir en ella ni tomar partido”

La función de un director de proyectos no es hacer seguimiento del proyecto, es dirigir el proyecto, y garantizar que este cumpla los objetivos. Si vemos que estos no se van a cumplir, lo que debemos hacer es analizar la situación, y definir los planes de contingencia necesarios (junto con los miembros del equipo de proyecto que haga falta). Después informaremos de estos planes, y distribuiremos el cronograma con las modificaciones oportunas.

En el ejemplo anterior vemos que el proyecto se atrasará porque las tareas 2 y 4 (dentro de la cadena crítica) se van a atrasar, por tanto debemos actuar sobre ellas. Una posible opción sería mover recursos de la tarea 3 a la tarea 2, lo que reduciría la duración de la tarea 2 pero incrementaría la duración de la tarea 3. Supongamos que hemos analizado esta propuesta y es factible, vamos a ver cómo queda el cronograma:

linea base del cronograma - retraso corregido

Como vemos, el cronograma se ha visto modificado tanto en fechas de realización de las tareas, como en la duración de estas, pero estos cambios no afectan a la fecha de entrega final. Seguimos cumpliendo con los objetivos. Por tanto el nuevo cronograma sigue siendo válido y puede distribuirse al equipo sin aprobación del sponsor, ya que no implica un cambio en la línea base

Atraso en una tarea sin efecto sobre los objetivos del proyecto

Tercer día del mismo proyecto. Durante la ejecución de la tarea 1 vemos que la tarea 3 no era tan simple como pensábamos en la fase de planificación, y va a requerir más tiempo del previsto. Adicionalmente la persona que tiene que realizar la tarea 5 ha cogido una baja laboral hasta la siguiente semana (nadie más en la empresa sabe cómo hacer la tarea 5). El director del proyecto actualiza el cronograma y sale lo siguiente:

linea base del cronograma en proyecto sin atraso

Qué hacemos? Miramos que el nuevo cronograma sea factible, y si lo es, simplemente lo distribuimos y nos dedicamos a otra cosa. Como vemos los cambios no tienen ningún efecto sobre los objetivos del proyecto, por lo que no hay ningún problema.

Inclusión de nuevas tareas o hitos

Tercer día del mismo proyecto. El cliente nos llama para pedirnos una nueva funcionalidad al producto, para la cual nos dará en dos semanas los datos a considerar.

Qué hacemos? Aquí lo importante es darse cuenta que estamos gestionando un cambio (el alcance se ha incrementado), por lo que el director de proyecto debe analizar la solicitud y ver como esta afecta al proyecto (en todos los puntos). Volviendo al ejemplo, imaginemos que implica una nueva tarea de 6 días de duración que empezará después de recibir la información del cliente. El proyecto queda de la siguiente forma:

Como se trata de un cambio, el proyecto ha cambiado, ya no es el que se aprobó con el project charter, por lo que el sponsor debe de aprobar la nueva situación antes de poder continuar. Por tanto, este nuevo proyecto se adjuntará al documento de gestión de cambios, y esperaremos la respuesta del sponsor o del comité de dirección de proyecto. Supongamos que el cambio es aceptado, en este caso el cronograma pasa a ser:

cambio en el proyecto y efecto sobre la línea base del cronograma

Te has fijado que se ha modificado la línea base y que la fecha de fin se ha atrasado? Cuando se acepta una modificación, implícitamente se aceptan todas las consecuencias en el proyecto originadas por esta modificación, por lo que nunca podremos hablar de retrasos por cambios, sobre costes por cambios, etc. Por el contrario deberíamos decir retrasos por mala gestión de cambios, sobre costes por mala gestión de cambios, etc

El proceso de gestión de cambios se explicará en otros artículos, y a nivel teórico lo dicho en el punto anterior es coherente con este proceso. En la realidad hay aspectos “políticos”, “de posición”, o “comerciales” que pueden llevar a tratar este asunto de otra forma, y forzarnos a tratar este asunto como el primer punto. Si algún lector va a certificarse en breve, que olvide este comentario.

Efecto de riesgos no esperables

Lo primero a clarificar es que no me estoy refiriendo a riesgos no considerados por una mala identificación de riesgos, sino a los riesgos que correctamente no consideramos. Por ejemplo, un terremoto durante la ejecución de un proyecto en Tokio es un riego esperable, mientras que en Madrid no lo sería.

Si estamos haciendo un proyecto en Madrid y se produce un terremoto de grado 5, puede que tengamos que rehacer parte del trabajo ya realizado, lo que afectará sin duda al cronograma (y otros puntos). Como estamos hablando de un riesgo no esperable, se debería tratar como el punto 3.

Pero qué ocurriría en el proyecto de Tokio? En Tokio los terremotos de grado 5 son esperables, por lo que si estos pueden afectar al proyecto, debemos considerarlo en la fase de planificación. Si no se ha hecho, los atrasos producidos serían considerados como un error de planificación del director del proyecto, por lo que inicialmente se trataría como en el punto 1, solicitando una revisión de las líneas base si no se consigue ningún plan de contingencia adecuado.

Por motivos de simplificación del artículo, se ha obviado en los ejemplos la existencia de márgenes de seguridad antes de las entregas y entrega final, aunque en un cronograma correcto este margen debería existir. Esto implica que a veces los atrasos se compensan con este margen en lugar de aplicar un plan de contingencia. Como calcular y gestionar este margen se explicará en otros artículos.

Licencia de Creative Commons
Línea base del cronograma by Albert Garriga is licensed under a Creative Commons Reconocimiento-NoComercial-SinObraDerivada 4.0 Internacional License.

Visita más secciones de esta página

Publicado en Gestión del cronograma Etiquetado con: , ,

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies

ACEPTAR