En los siguientes apartados te explico en más detalle lo qué es la línea base de un proyecto y cómo usarla, pero si quieres profundizar más en las técnicas de gestión de proyectos, te recomiendo que eches un vistazo al libro que acompaña a esta página. Si lo descargas nos ayudas a seguir creando contenido de calidad para ti. 😉 Gracias!
La línea base de un proyecto es la última versión de la planificación 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 la planificación 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:
De forma práctica la línea base de un proyecto es una foto 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 o marco referencial, y la superior (azul o rojo) el plan de trabajo.
Ahora que sabes lo qué es la línea base de un proyecto toca conocer cómo se usa durante el seguimiento y control del proyecto. Durante la ejecución de un proyecto pueden darse diferentes situaciones, las cuales pueden requerir ajustar las tareas y la línea base. Vamos a ver las más significativas y cómo se debe actuar en cada caso:
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 plan para mostrar la nueva situación, y este queda de la siguiente forma:
Como la finalización de la tarea 1 se ha retrasado en un día, el resto de tareas se han 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. ¿Qué hacemos?
Creamos una nueva versión del planning 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 su 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:
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 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:
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.
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:
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.
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.
Antes de mostrar la línea de base, debes establecerla. Aquí te explico cómo:
Una vez que has establecido la línea de base del cronograma, puedes mostrarla de la siguiente manera:
MS Project también te permite comparar fácilmente las diferencias:
Siguiendo estos pasos, podrás visualizar y comparar tu cronograma actual con la línea de base en MS Project, lo que te ayudará a gestionar mejor el progreso de tu proyecto y a identificar desviaciones a tiempo.
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.
