Técnicas para Análisis de Retrasos de proyectos
A lo largo de la vida de un proyecto, desde que se crea la línea base de proyecto hasta que obtenemos un cronograma que recoge cómo se han ejecutado cada una de las actividades (as-built), ocurren una gran cantidad de acontecimientos que eran desconocidos al principio. Estos acontecimientos pudieron causar retrasos en la consecución de los diferentes paquetes de trabajo, así como en los diferentes hitos contractuales del proyecto. Estos retrasos pueden ser responsabilidad del cliente, del contratista o de terceras partes. En este artículo vamos a hablar sobre las 6 técnicas para el análisis de retrasos de proyectos. Éstas servirán como herramienta para mejorar la relación con nuestros clientes, para preparar reclamaciones de tiempo y/o coste, y para poder tener bien documentados todos los eventos sucedidos durante la vida del proyecto.
6 técnicas para el Análisis de Retrasos de proyectos
1. Análisis de impacto sobre lo planificado o «Impacted As-planned Analysis»
Este método se basa en añadir un Evento de Retraso o Delay Event dentro del cronograma Línea Base del Proyecto, vinculándolo de manera lógica. Una vez se haya vinculado correctamente con las actividades de la Líne Base que correspondan, se realizarán de nuevo el cálculo del cronograma gracias a la herramienta de planificación que se esté utilizando. En nuestro caso, esta herramienta es Primavera P6 de Oracle. De este modo, se determinará el impacto prospectivo o a tiempo futuro que el Evento de Retraso ha tenido en el hito contractual de finalización del proyecto. En planificación, a este hito contractual se le suele denominar en terminología anglosajona como «Contract Completion Date».
Es importante contar con una sólida Línea Base del proyecto, donde se haya confirmado que la secuencia y duraciones de los trabajos a realizar son razonables, realistas y alcanzables. Del mismo modo, es necesario asegurar que todas las actividades se han vinculado de manera correcta.
Normalmente, éste es el más simple y menos caro de todos los análisis que se describen en este artículo sobre las técnicas para el análisis de retrasos de proyectos. Sin embargo, tiene algunas limitaciones como son el no considerar el progreso real del proyecto o los cambios sobre lo planificado originalmente. En determinados contratos, y dependiendo de los términos que hayan sido acordados con nuestro cliente, esta técnica de Análisis de Retrasos sería suficiente para valorar la extensión del tiempo que tenemos derecho a solicitar.
2. Análisis de impacto del tiempo o «Time Impact Analysis»
Del mismo modo que en el método de Análisis de Retrasos denominado «Impacted As-planned Analysis», debemos introducir y vincular los Eventos de Retraso dentro de la Línea Base de proyecto y calcular este programa actualizado con la herramienta de planificación con la que se esté trabajando. Como en el caso anterior, quedará determinado el impacto a futuro del Evento de Retraso sobre la fecha de finalización del proyecto.
El cronograma usado como Línea Base para cada análisis puede ser un cronograma contemporáneo o la Línea Base actualizada que refleje los cambios que haya habido en la lógica, progreso real de los trabajos, o nuevos paquetes de trabajo o actividades. Dicho de otro modo, la Línea Base a analizar deberá reflejar el progreso real de los trabajos y una secuencia realista, alcanzable y razonable de los trabajos pendientes. Cualquier mitigación y/o plan de aceleración se incorporará y tendrá en cuenta en la Línea Base actualizada.
El número de Eventos de Retraso que se modelen tiene un impacto considerable en la complejidad y coste en el uso de este método.
3. Análisis de retrasos de proyectos basados en una franja de tiempo o «Time Slice Analysis»
Éste es el primero de los dos métodos de Análisis de Retraso por ventanas que existen. Este método require que la persona que analice los retrasos verifique o desarrolle una serie de cronogramas actualizados a considerar como Líneas Base, a modo de instantáneas durante el curso de los trabajos. Mediante este proceso el progreso de los trabajos se divide en intervalos de tiempo, típicamente mensuales, que reflejan la ruta crítica real de cada periodo. Ésto permite a la persona que analice los retrasos conlcuir la extensión de tiempo de cada retraso crítico dentro de cada «ventana».
Dicho ésto, el analista investiga los informes del proyecto para determinar qué eventos podrían haber causado el retraso crítico identificado en cada intervalo de tiempo. Para el cronograma referente a cada «ventana», el analista necesita verificar que el histórico de sucesos ocurridos reflejan el progreso real de los trabajos y que la secuencia y duraciones de los trabajos pendientes son razonables, realistas y alcanzables, además de presentar una secuencia lógica. Éste método depende en gran medida del software de planificado.
4. Análisis de ventanas planeado contra ejecutado o «As-planned versus As-built Windows Analysis»
Éste es el segundo método de Análisis de Retraso por ventanas. Este método depende menos del software de planificación que usemos y suele aplicarse cuando existe cierta preocupación sobre la validez de la Línea Base del proyecto. La duración de los trabajos se divide en «ventanas», las cuales están enmarcadas por cronogramas revisados, cronogramas actualizados, hitos e importantes eventos que hayan sucedido. El analista determinala ruta crítica real para cada «ventana» mediante un análisis de sentido común y un análisis práctico de los hechos disponibles.
Como esta tarea no depende tanto de la herramienta de planificación que se use, es importante que el analista exponga las razones por las que se ha dterminado la criticidad.
La incidencia y el alcance del retraso crítico en cada «ventana» se determinan comparando fechas clave a lo largo de la ruta crítica contemporánea o real con las fechas planificadas correspondientes en el cronograma de Línea Base. Posteriormente, el analista investiga los registros del proyecto para determinar qué eventos de retraso podrían haber causado el retraso crítico identificado. El retraso crítico incurrido y la mitigación o aceleración lograda en cada ventana se acumulan para identificar el retraso crítico durante la duración de los trabajos.
5. Análisis de retrasos de proyectos retrospectivo de la ruta más larga o «Retrospective Longest Path Analysis»
El método de análisis retrospectivo de la ruta más larga implica la determinación de un modo retrospectivo de la ruta crítica como se construyó o as-built. Ésta no debe confundirse con la ruta crítica contemporánea o real identificada en los métodos anteriores basados en ventanas. En este método, el analista primero debe verificar o desarrollar un cronograma as-built detallado, tal como se han ejecutado los trabajos. Una vez completado, el analista traza la ruta más larga hacia atrás desde la fecha de finalización real para determinar el camino critico del proyecto ejecutado.
La incidencia y el alcance del retraso crítica se determina comparando las fechas clave a lo largo de la ruta crítica de los trabajos ejecutados (as-built) con las fechas planificadas correspondientes en el programa de Línea Base. Posteriormente, el analista investiga los registros del proyecto para determinar qué eventos podrían haber causado el retraso crítico identificado.
Una limitación de este método es su capacidad más limitada para reconocer y permitir interruptores en la ruta crítica durante el curso de los trabajos.
6. Análisis colapsado de lo ejecutado o «Collapsed As-built Analysis»
El método de análisis colapsado de lo ejecutado implica la extracción de los eventos de retraso del cronograma «as-built». Con ello se proporciona una hipótesis de lo que podría haber sucedido si los eventos de retraso no hubieran ocurrido. Este método no requiere un cronograma Línea Base. Sin embargo, se requiere un programa as-built detallado y con una lógica en la bien definida en la ejecución de las actividades. Es raro que dicho cronograma de actividades exista en el proyecto. Generalmente se requiere que el analista introduzca la lógica a un cronograma as-built verificado. Esto puede llevar mucho tiempo y es un esfuerzo bastante complejo. Una vez completada, se identifican los Eventos de Retraso dentro del cronograma as-built y se «colapsan» o se extraen para determinar el impacto neto de éstos.
Este método a veces se realiza en «ventanas», utilizando las herramientas de software adecuadas que contienen datos detallados y completos de los trabajos realizados realmente. Una limitación de este método es que solo mide el retraso incremental a la ruta crítica. La fecha de finalización no colapsará más que la ruta crítica más próxima.
EN PROJECT 2080 NOS GUSTARÍA QUE RECORDARAS
Existen diferentes métodos para analizar los retrasos de un proyecto. Todos ellos se basan en el uso de un cronograma de actividades del proyecto. La utilización de uno u otro dependerá de las circunstancias particulares y de los términos que se hayan fijado en el contrato con nuestro cliente. De cara a minimizar disputas futuras, es bueno que se acuerde el método más apropiado a utilizar para el Análisis de Retrasos de proyectos antes de que éste se ponga en marcha. En este artículo se han mostrado las 6 técnicas más comunes para el Análisis de Retrasos de proyectos. Pero existen otros métodos como son: el análisis del valor ganado, análisis de la línea de equilibrio o el análisis de la curva de recursos. ¿Cuál es el método que usas en tus proyectos?