El aspecto visual de los cronogramas limita su utilidad. Al igual que sucede con BIM, la visualidad de las herramientas oculta el verdadero sentido y potencial de los procesos a los que dan soporte. Por ello, es bastante frecuente que una vez finalizado el cronograma, se imprima y pase a formar parte de la decoración del despacho o de la sala de reuniones de la obra.
Para muchos gestores de proyectos y de obras un cronograma no es mucho más que la expresión gráfica del orden de ejecución de los trabajos; una representación esquemática de cómo se espera la evolución de la obra, y que sirve de apoyo para el relato de sus intenciones.
En consecuencia, la metodología de control suele reducirse a la comparación visual de las sucesivas planificaciones. Pero comparar planificaciones no es controlar… y es que un cronograma no es un poster: es una base de datos con una visualización gráfica de apoyo.
El cronograma como contenedor de información estructurada
MS Project se creó a finales de los años ochenta. El desarrollo de la informática en esas fechas era muy limitado, y aún no flotaba en el ambiente el fenómeno de la digitalización. Sin embargo, con total seguridad, la organización de la información necesaria permitía ya una explotación automatizada, aunque las herramientas no estaban muy extendidas.
Una fotografía o una imagen, por el contrario, es un ejemplo de contendor de información no estructurada. Poco podemos hacer para obtener más información de una imagen que comentarla o incorporarla como elemento de apoyo para un informe.
Por ello, si nos quedamos con la idea simple de que un cronograma es una imagen, un poster, estamos olvidándonos de que debería ser una fuente de información estructurada muy relevante para la gestión de la obra.
El “precio” de la información estructurada
Para que alguien distinto al autor de una información pueda comprenderla y utilizarla es necesario haberla creado de acuerdo con una serie de pautas y normas conocidas y compartidas. Esto aún es más necesario si pretendemos utilizar programas informáticos auxiliares para obtener nueva información. Por ello, debemos emplear una metodología basada en normas o estándares de gestión.
En el sector de la construcción somos poco dados a la estandarización. Es más, mi impresión es que nos incomoda mucho que nos obliguen a trabajar de una cierta manera, de acuerdo con una norma o procedimiento, en especial a las direcciones de obra. Nos consideramos espíritus libres, capaces de realizar cualquier actividad desde cero.
No dudo de la capacidad técnica del sector, sin embargo pienso que no se puede estar definiendo todo desde la nada, al menos por dos motivos: porque resulta ineficiente dedicarle atención a lo que ya está pensado, y porque el producto obtenido así no es predecible ni controlable.
Por ejemplo, si como directores de obra nos limitamos a pedir “el cronograma” al contratista, ya cometemos dos errores de partida. El primero es que no hay “el” cronograma, si no tantos cronogramas como dicte la pericia de cada encargado de desarrollarlo y, sobre todo, por los usos previstos. El segundo error es que es muy probable que el cronograma no sea apto para aplicar metodologías para su control. Solo lo lograremos si estandarizamos su contenido.
La estandarización es imprescindible para el trabajo colaborativo, pero es compleja y exige un trabajo previo muy intenso que no siempre estamos dispuestos a acometer. Lo más lógico es que, al igual que existen bases de precios de colegios profesionales o instituciones, también existiesen publicaciones de buenas prácticas para el disponer de metodologías para el desarrollo y control de cronogramas. El RIBA Plan of work del Royal Institute of British Architects, es un ejemplo.
En la entrada #9 del blog podréis leer en más detalle sobre la visión de MS como contendor de información.
¿Qué podemos esperar de un cronograma-poster?
Hace bastantes años dirigí unas cuantas obras en las que casi nunca teníamos un cronograma actualizado. ¡Claro que es posible trabajar así!, pero con un elevado nivel de riesgos y preocupaciones que no siempre es admisible.
El grado de satisfacción depende en gran medida de las expectativas que tengamos. Por ello, cuando el nivel de planificación era tan bajo, disponer de una imagen de la evolución prevista de la obra ya se percibía como un éxito.
Es necesario saber qué podríamos hacer si dispusiésemos de un cronograma adecuadamente desarrollado. De ese modo podremos valorar lo que nos perdemos por desconocer las posibles utilidades. En la anterior entrada del blog planteo un total de veintiún posibles usos de un cronograma.
Podemos comparar la información que nos aporta un cronograma tipo poster con la obtenida de una hoja Excel en la que dibujamos las tareas y con un cronograma bien configurado y gestionado acorde a metodologías correctas.
Para cuantificar la diferencia, he asignado puntuación de 0 a 3 en función de que el grado de respuesta sea malo, regular, buena o muy bueno. Los resultados se muestran en la siguiente figura. Se aprecia como emplear el programa MS Project como herramienta de dibujo aporta poco más que una Excel en la que marquemos las actividades de un modo muy primario.
Por el contrario, se corrobora que un cronograma adecuadamente desarrollado multiplica exponencialmente las posibilidades de mejorar nuestro desempeño, por ejemplo, aplicando la técnica del valor ganado, que explico en otras entradas.
Resumen
Disponer exclusivamente de una imagen del cronograma, sin explotar la información estructurada que contiene, es una aproximación muy limitada a la gestión del tiempo, que introduce muchos riesgos.
Emplear la vista del cronograma como un poster decorativo para nuestro ámbito de trabajo tiene un efecto placebo importante, ya que nos puede hacer creer que la obra está controlada, cuando no es cierto.
Los mejores resultados se obtienen cuando se considera al cronograma como una base de datos de la información relevante para su gestión. En términos de BIM, se trata de un contendor con información estructurada. Esto nos permite compartirlo con otros usuarios y emplear otros medios informáticos. En esas condiciones, la representación gráfica es meramente una ayuda para comprobaciones concretas y para evitar errores de configuración.
Este salto cualitativo exige emplear normas y metodologías conocidas para poder obtener y compartir eficazmente la información empleando el trabajo colaborativo.
