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 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. ¿Quizá el código estaba terminado al 90% pero las pruebas no habían comenzado? ¿Quizá se había comprobado el funcionamiento de los “tele-carritos” pero se descubrieron fallos en los dispositivos para escanear los códigos de barras? Cualquier auditor podía verificar el avance de las obras, pero no podían determinar el avance del proyecto software porque el producto no es aparente, no se ve…
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 el estado de salud de un proyecto simplemente por una foto tomada en un momento, 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.
El estado de salud de un negocio puede inferirse a partir de los informes contables, principalmente por dos razones:
- Existe un convenio (cuadro de cuentas del plan general contable) que permite juzgar de manera objetiva los estados contables, evitando interpretaciones subjetivas.
- La evolución dinámica de los indicadores (los flujos de caja, evolución de inventarios, ventas, compras, crecimiento de la plantilla, expansión a otros países, etc.) obedece a leyes predecibles causa-efecto, aplicables a los negocios en general, que permiten realizar pronósticos más o menos precisos.
El problema que tenemos cuando tratamos de juzgar el estado de los proyectos a partir de informes operativos es que la casuística es mucho más variante, y es casi imposible generalizar leyes causa-efecto en gestión de proyectos.
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, ante problemas reales en un proyecto, los directivos se ven obligados a preguntar al project manager.
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 pone 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. Los interesados se involucran y ofrecen retroalimentación. Los informes de proyectos deberían ser fuente de interacción con los interesados.
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.
Más interesante, no obstante, es la capacidad que tiene cualquier interesado en PMPeople para acceder al informe de situación en una fecha determinada, descargar el informe y cargarlo en su zona privada. El equipo de gestión 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.
La información incluida en estos informes puede ser igual de imprecisa, o inútil, que en el caso del aeropuerto de Denver, pero si puede haber decenas, o cientos de “ojos vigilantes”, ¿de verdad merece la pena el esfuerzo?
Comience a usar PMPeople gratis, sin límite de tiempo, sin límite de usuarios. En las organizaciones premium solo pagan los gestores, 20 euros al mes. Algunos roles (interesados, team members, patrocinadores y gestores de recursos) son siempre gratis. Podrá añadir o reducir usuarios premium según las necesidades reales de su organización. En todo momento, tendrá acceso a nuestro soporte interactivo por Slack. Nuestros servidores se encuentran dentro de la UE. Si lo prefiere, el software puede quedar alojado en sus instalaciones.