Informes de Proyecto sencillos y frecuentes

En 1988, la ciudad de Denver decidió reemplazar su antiguo aeropuerto, el Stapleton International Airport (SIA), por el nuevo Denver International Airport (DIA). La fecha estimada para inaugurar el DIA era el 31 de octubre de 1993. Finalmente, el DIA solo pudo abrir parcialmente y comenzar a operar en marzo de 1995, después de unas pérdidas estimadas en unos 500 millones de dólares de entonces. ¿Qué ocurrió?

En la fecha fin prevista, todo estaba terminado, menos un sistema software llamado Sistema Automático de Gestión de Equipajes (Automatic Baggage Handling System -ABHS). Al parecer, el resto de los trabajos, construcciones y servicios ya estaban terminados, salvo ese invisible software sin el cual no se podían trasladar las maletas desde las mesas de facturación hasta las puertas de embarque. Como el sistema ABHS formaba parte del camino crítico, el aeropuerto tuvo que permanecer cerrado hasta que el software fue entregado, verificado y validado.

Durante todo el año 1994, cuando ya era evidente el retraso, los principales interesados de aquel proyecto, es decir, los ciudadanos de Denver, usaban el acrónimo DIA para referirse al aeropuerto, no como Denver International Airport, sino como Delayed International Airport.

El proyecto DIA fue un grave fracaso, pero antes de octubre de 1993, todos los informes indicaban que el proyecto sí estaba bajo control. Obviamente, aquellos informes no mostraban fielmente la situación.

En cualquier caso, lo importante aquí es que, al contrario que en gestión de operaciones, los proyectos no pueden controlarse con informes estáticos, sobre la situación en un momento dado. Juzgar un proyecto con una foto es todavía más impreciso en el caso de un proyecto ágil, donde tiene mucha importancia a la opinión cambiante de los interesados. Haciendo analogía con las artes visuales, una simple fotografía puede servir para juzgar el estado de un servicio operativo, pero necesitaríamos muchas fotos, o una película entera, para juzgar el estado de salud de un proyecto.

Los informes de proyecto que quedan en un dossier para cubrir el expediente, o para buscar culpables cuando el proyecto fracase, no sirven para controlar y monitorizar el proyecto. En el momento en que se realizan, no aportan valor, son sencillamente “desperdicio”.

Muchas herramientas PPM han diseñado sus informes tratando de emular las funcionalidades de los paquetes ERP o Business Intelligence, para ofrecer a los directivos la capacidad de controlar los proyectos resumiendo ciertos indicadores clave de desempeño. La falsa sensación de control se evidencia cuando se descubren problemas reales en un proyecto, y el project manager se ve obligado a revelar la triste realidad, todo pasa de verde a rojo, pero ya no hay tiempo de recuperar el control. Esto se parece mucho a lo que ocurrió en el proyecto del aeropuerto de Denver.

Los informes automatizados muchas veces no revelan la información clave del desempeño del proyecto. La información clave vive en la cabeza del project manager, pero no como tienen mucho trabajo que hacer, solo informan por excepción: cuando algo malo ocurre.

Realizar informes de proyecto debería ser algo rutinario, no dramático.

Si los informes son complejos y costosos de producir, los project managers informarán raras veces, con lo que los informes se harán más complejos y costosos. Esto es un círculo vicioso. Por otro lado, si el reporte es fácil, los project managers informarán a menudo, y cada informe será más fácil. Las herramientas PPM deberían facilitar a los project managers la producción de informes de proyecto ligeros y frecuentes.

Un informe de proyecto que muestra que “todo está verde” aporta información, pero sobre todo da un mensaje tranquilizador. En gestión de proyectos, más importante que leer informes, es el hábito de redactarlos. Si la situación del proyecto se deja por escrito, de forma regular, sabiendo que hay un público de lectores interesados, es muy probable que el equipo de gestión también describa las acciones preventivas o correctoras, además de los problemas actuales o potenciales. Si los project managers saben que hay muchos ojos vigilantes esperando leer informes de seguimiento, seguro que gestionarán mejor:

• Los interesados deberían poder acceder fácilmente a un informe de situación de una fecha determinada, descargar el informe y conservarlo. Es probable que los interesados se involucren y ofrezcan retroalimentación oportuna sobre el desempeño del proyecto.
• El project manager se ve motivado a publicar informes habitualmente, comunicando escuetamente por qué el proyecto en general, o un determinado paquete de trabajo en particular, “está en verde” en cuanto a los plazos, pero “en rojo” en cuanto a los costes, por ejemplo. El informe de ese momento puede resumir las medidas correctoras y preventivas, en caso de ser necesarias, especialmente tranquilizadoras cuando son medidas que se toman como respuesta a solicitudes de cambio, o respondiendo a los comentarios de un grupo de interesados.

Los informes de proyectos ligeros y frecuentes deberían ser fuente de interacción con los interesados. Imagine una serie de informes de este tipo en el proyecto del aeropuerto de Denver. Es muy probable que algunos riesgos importantes se hubieran mitigado. En cualquier caso, si el proyecto hubiera fracasado igualmente, nadie se habría sorprendido.

PMPeople ofrece informes operativos para ahorrar tiempo a los usuarios que deben consumir información sobre horas y gastos incurridas, análisis de volumetría de proyectos, asignaciones, tareas pendientes, etc. Los proyectos contienen mucha información y hay que optimizar el acceso.

Resúmenes del estado global de cada uno de los paquetes de trabajo:

Resumen del desempeño de la financiación para el proyecto:

Resumen del desempeño del cronograma del proyecto:

Resumen del desempeño del coste del proyecto:

Resumen del desempeño del equipo del proyecto:

PMPeople facilita adquirir el hábito de producir y consumir informes de seguimiento.