Programar una obra es un proceso complejo. Más de lo que nos imaginamos. Exige modelizar la ejecución de nuestras previsiones orientada a unos objetivos determinados y expresarlo mediante relaciones que demandan una lógica muy parecida a la que empleamos para la programación informática.
Sin embargo, ningún técnico duda de su capacidad para hacer un cronograma de una obra. Malo será, pensamos todos, que no seamos capaces de expresar en un diagrama nuestra idea acerca del desarrollo de la obra. Por ello, si alguien cuestiona el método empleado y sus resultados, nos sentimos muy agraviados.
Ahora bien, nadie tiene problemas en reconocer que no sabe plantear y desarrollar un pequeño programa informático, por ejemplo, una macro en Excel para hacer tareas que repite sistemáticamente. Casi ningún técnico piensa que esta falta de capacidad supone un menoscabo de su valía. Y es que pensamos que no somos programadores: nos dedicamos a hacer o dirigir obras, y para eso no se necesita saber de programación.
Pues resulta que elaborar un cronograma tiene mucho de programación informática y es bastante más difícil de lo que parece. Además, no es una habilidad que se desarrolle espontáneamente con el ejercicio de la profesión.
EL CRONOGRAMA COMO CONTENEDOR DE DATOS ESTRUCTURADOS Y NO ESTRUCTURADOS
Para controlar el plazo de una obra es muy común dar por bueno un pdf del diagrama de Gantt, más menos legible, acompañado quizá con una distribución mensual de los costes obtenida del propio cronograma. La información que se puede obtener así es muy limitada: las fechas previstas de comienzo y fin de las actividades, las tareas críticas… y poco más.
Sin embargo, cuando un cronograma responde a un modelo de obra adecuadamente definido y expresado con unas determinadas reglas de programación, la cantidad de información que podemos extraer es mucho mayor y más interesante. Con razón en BIM se habla de contenedores de información, más que de archivos. Y es que un editable de MS Project contiene mucha más información de la que nos imaginamos.
El pdf de una vista del cronograma es una información no estructurada, puesto que no es susceptible de ser compartida y tratada con otros programas. Por el contrario, un cronograma adecuadamente desarrollado puede aportar información elaborada por el mismo programa de creación, o permitir su exportación a otros, por ejemplo, a Excel o a Word. También puede ser objeto de programación para hacer informes empleando Visual Basic.
Tratar de gestionar el plazo de un cronograma de una obra con la información que ofrece un pdf del diagrama de Gantt es como intentar diseñar una estructura empleando solo los diagramas de esfuerzos. En ambos casos, la información gráfica ayuda a detectar errores y a realizar aproximaciones, pero el trabajo real se lleva a cabo con la información estructurada que contiene el programa aplicado.
EL CONTROL DEL CRONOGRAMA CON INFORMACIÓN NO ESTRUCTURADA
¿Cómo controlamos el plazo en una obra al cabo del tiempo? Pues en la mayoría de los casos nos limitamos a pedir un nuevo cronograma que indique las fechas de comienzo y fin de las tareas completadas, y la programación de las restantes.
Puede parecer suficiente, pero es realmente una información escasa y muy poco sistematizada. Mediante este planteamiento, el cronograma no es mucho más que una imagen de apoyo para explicar lo que sucedió en la obra, interpretando subjetivamente los retrasos que se hubieran producido hasta esa fecha y relatando la obra futura comparando visualmente los pdf de los cronogramas.
Sin embargo, la explicación del avance de una obra, lo que ha sucedido con las tareas completadas, las variaciones respecto a las previsiones anteriores, y la organización futura de la obra debiéramos de poder deducirlo directamente con la información contenida en el programa, y no con un relato. Ese es el auténtico reto.
LOS CAMPOS DE MS PROJECT: LA BASE DE LA INFORMACIÓN ESTRUCTURADA
Para poder utilizar los datos que alberga un contenedor de información debemos saber dónde se encuentran y conocer sus características. En el caso de MS Project, la información se guarda en lo que se denominan “campos”, que son las columnas que podemos incorporar u ocultar en las diferentes vistas.
Los campos están preparados para contener información de distinta naturaleza: textos, fechas, duraciones, costes, números, y marcas. Por otra parte, los campos pueden ser generados automáticamente por el programa o bien ser cumplimentados por los usuarios. A éstos últimos se les denomina “campos personalizados”.
Campos de texto
Un ejemplo de campo tipo Texto es el “Nombre de tarea” o el “Nombre de los recursos”. Estos y otros similares los genera el programa cuando introducimos los datos. Pero MS Project nos ofrece treinta campos adicionales tipo texto que podemos utilizar para hacer anotaciones. Los nombres de estos campos también los podremos cambiar a nuestro gusto.
Campos de fecha
Los campos tipo Fecha son fundamentales cuando hablamos de cronogramas. Al cubrir los datos de un cronograma, aunque sea muy básico, estamos aportando información que se guarda en un campo de este tipo. Por ejemplo, la fecha de comienzo de una tarea. Ahora bien, debiéramos saber que Project tiene, para éste y otros datos empleados en el control, tres subtipos de datos: el planificado, el real y el de línea base.
Los dos primeros no necesitan mucha explicación: el planificado es el que corresponde a la previsión actual de una tarea que no comenzó y el real, al de una tarea finalizada. El de línea base hace referencia al dato comprometido en el programa aprobado.
Los datos de línea base son como una fotografía, una imagen instantánea de toda la información asociada a un cronograma aprobado. Manejar la información de la línea base es fundamental para el adecuado control del cronograma. Dicho de otra forma: no emplear las líneas base denota una técnica de control muy poco desarrollada.
Campos de duración
Los campos tipo Duración se refieren, por ejemplo, a los días, semanas o meses que estimamos que va a durar una tarea (duración planificada), que duró, una vez finalizada, (duración real) o la que se aprobó (duración de línea base de las tareas). Pero Project aporta otros campos con duraciones de interés, como la “Variación de fin” de una tarea o del proyecto, que representa la diferencia entre la aprobada (la de línea base) y la planificada o la real. Este y otros valores de interés los calcula el programa directamente, pero además nos permite utilizar nueve campos personalizados de este tipo.
Campos de número y de coste
Los campos tipo Número o tipo Costo permiten guardar y gestionar información de esta naturaleza. En el caso del tipo costo también es posible diferenciar el costo planificado, el real y el de línea base.
Campos de marca
Por último, los campos tipo Marca admiten dos valores, a modo de casilla de verificación. Ejemplos de campos de este tipo aportados directamente por MS Project es del de Tarea de resumen o el de Tarea crítica. Podemos generar un campo tipo Marca para señalar, por ejemplo, las tareas críticas previstas en un periodo de interés, las que excedan un determinado importe, retraso, etc.
EJEMPLOS DE INFORMACIÓN INTERESANTE PARA EL CONTROL
Incremento del retraso o adelanto de la obra durante último período de control
Esta información se obtiene a partir del campo integrado “Variación de fin“, que muestra la diferencia entre la fecha actual (la planificada) y la prevista en la línea base (la contractual). El incremento de variación lo obtenemos al comparar el valor actual con el del anterior control, que habremos copiado en un campo personalizado tipo Duración al que le habremos denominado con la fecha correspondiente. Esto es de aplicación para la obra completa y para cada una de las tareas.
Causas de la variación de fin durante el último período de control
Si antes de la introducir la información de la situación actual marcamos las tareas críticas de ese período previo (el mes anterior, por ejemplo), podremos emplear filtros para que solo aparezcan esas tareas, y analizar las variaciones de fin, como mencionamos antes. Esto es, los retrasos o adelantos sobre las fechas contractuales del mes pasado y de éste. Además, el resultado de este análisis de variaciones lo podemos dejar por escrito en un campo personalizado tipo texto.
Justificación de la desviación de plazo en cualquier momento de la obra
Si repetimos el proceso anterior cada vez que actualicemos la obra, en el momento que deseemos, podemos establecer la suma de causas que cada mes han introducido variaciones en el plazo final de la obra. Para ello, solo necesitamos que nuestros campos de texto personalizados tengan el nombre de cada mes de control, por ejemplo.
Aplicación del método del valor ganado
Esta metodología, que he presentado en la entrada #12 del blog, tiene por objeto sintetizar el grado de avance de una obra y el control de los costes de un modo integrado. Su aplicación es impensable sin una adecuada estructuración de los datos del cronograma.
CONCLUSIONES
El desarrollo convencional de cronogramas ofrece poco más que una representación gráfica de las previsiones de ejecución de las obras. Su utilidad para el control del plazo y del avance de la obra es muy limitada.
Para obtener un cronograma útil para un control efectivo de las obras es necesario modelizar adecuadamente el alcance de la obra, su desarrollo, y emplear un enfoque muy similar a la programación informática.
Los cronogramas así obtenidos tienen el carácter dinámico imprescindible. Esto, unido al empleo de la información estructurada generada, nos permitirá multiplicar la información de interés obtenida.
