Lo que nunca debería faltar en un informe de seguimiento de proyecto

El que más y el que menos ha pasado y pasa por unas cuantas, muchas, reuniones de seguimiento de proyecto. Salvo en proyectos pequeños, las reuniones de seguimiento son un clásico, un arte.
Como toda reunión, la de seguimiento, si se prepara adecuadamente puede ser altamente efectiva o, como muchas de las reuniones, puede ser una perdida de tiempo.
Durante mi vida profesional he asistido a reuniones de seguimiento de todo tipo, las eficientes, las inútiles, las engañosas (aquellas que se sale con la falsa sensación de que el proyecto va bien), las pierde tiempo, las altamente tensas, las de vamos a cargarle el muerto a alguien que no se lo espera, etc.
Añadido a las que me ha tocado participar, en estos últimos 5 años además me ha tocado revisar el estado de los proyectos de bastantes empresas y cómo hacen sus reuniones de seguimiento.
De todos los atinos y desatinos experimentados, vistos, sufridos y observados, he querido extraer lo que más suele faltar y que, al menos, debería estar en una reunión de seguimiento y que, sin embargo, falta en la mayoría de ellas:

1 – Riesgos y su estado.

Pero un buen estado de los riesgos, uno elaborado por alguien que se ha devanado los sesos pensando en aquello que entre mañana y hasta dentro de 12 meses nos puede tumbar el proyecto.
Y no quiero unos riesgos ahí genéricos, obsoletos, y puestos por cumplir, me refiero a unos riesgos de verdad, con su probabilidad de ocurrir y con cómo evitar que se produzcan.

2 – Avance del proyecto.

Esto puede parecer una obviedad, pero es que falla en la mayoría de los proyectos: el avance del proyecto con un mínimo grado de realismo, lo cual excluye, de manera no limitada, el uso de porcentajes a ojo en diagramas de Gantt (recuerda aquello de Diagramas Gantt cómo arma de destrucción masiva de proyectos), por favor, no los uses que es peor.
Hasta ahora la manera más fiable que ha descubierto la humanidad de calcular el avance del proyecto es por funcionalidad terminada (programada, probada y lista para pasar a producción).

3 – Estado de la calidad del software.

Rara vez está en un informe de seguimiento de proyecto. ¿Cómo está en calidad el desarrollo que se está llevando acabo? Un informe cuantitativo y extraído desde los fuentes, lo demás olvídalo (la verdadera calidad software la tienes que ver en los fuentes, en el código. No te fíes de nada más).
Bueno, y doy por hecho, y esto es mucho decir, que quien lleva el seguimiento del proyecto… accede frecuente a los fuentes, sabe dónde están y los ve con frecuencia (cosa que en ocasiones no ocurre), no sólo los ve al final de proyecto. Selecciona un conjunto pequeño par de métricas claves, y pon una gráfica simple con su evolución en el tiempo.

4 – Una demo de la funcionalidad real implementada.

Nada de powerpoints, no, demos reales en preproducción (o producción si aplica) en cada reunión de seguimiento de proyectos, cada viernes.
No me alargo más con otros tantos, pero si durante no más de una hora, cada viernes, revisas los anteriores, te aseguro que pocos sustos te vas a llevar, y pocas cosas no van a estar bajo tu control.

0 comentarios en “Lo que nunca debería faltar en un informe de seguimiento de proyecto”

  1. Yo también incluyo:
    – Problemas graves que estén afectando al proyecto y cómo se están gestionando.
    – Progreso de alcance, plazo y presupuesto
    Me ha gustado mucho tu artículo por resaltar la importancia de los aspectos que refieres, algunos de ellos grandes olvidados en los informes o tratados de forma superficial.

  2. Nosotros llevamos tiempo trabajando sobre diferentes aspectos del reporting de proyectos, y hemos llegado a conclusiones parecidas. Además de lo que habéis comentado, creemos que es importante para la organización mantener la información de progreso de forma que además del uso para seguimiento, se pueda procesar y obtener de ella un histórico para analizar y sacar conclusiones de cara a la mejora de procesos (por ejemplo aislando factores que se hayan dado en proyectos exitosos y fracasados). Hemos implementado este concepto para la Agencia Europea del Espacio, procesando métricas de gestión y de producto (calidad software) proporcionadas en los informes de progreso:
    http://www.immediait.com/birf.html
    En los últimos tiempos estamos trabajando sobre una evolución del concepto de reporting basado en el uso de una plataforma web con aspectos colaborativos. De momento es un prototipo muy preliminar, considerando solo aspectos de gestión de proyectos más bien tradicionales, pero cualquier comentario sobre la idea sería bienvenido:
    http://www.wipbi.com
    Un saludo.

  3. Muy buen post! me es de mucha utilidad 🙂
    Estoy recién comenzando como Lider de proyectos, y por supuesto utilizamos metodologías ágiles, ya me leí el primer libro de Javier y ahora voy por el segundo. En fin si tienen consejos feliz los recibo para ser importante dentro de mi equipo. mi correo de todas formas es mmartinesfs@gmail.com
    Saludos

  4. Excelente, estoy recien comenzando arealizar seguimientos de proyectos sencillos, tomo un curso pequeño e la catolica (de solo 15 dias)
    y en internet he revisadosobre el tema ya que las ideas igual las tengo pero las reafirmo on los comentarios y documentacion que sale en internet sobre seguimiento deproyectos.
    Asi que Gracias por la publiacion
    para mi Google.com es backan y eso que ya soy una mujer con años, encuentro fntastico google (encuestras de todo lo que quieras de informacion)

  5. En estos momentos tengo la ardua tarea en mi empresa entre otras cosas hacer el seguimiento de los Proyectos. El monitoreo lo realizo a través del Módulo Balanced Scare Card de OpenERP. El mayoy porblema que tengo es la mala presentación del Proyecto dentro del Software y la poca sistematicidad en la actualización del mismo. ¿Hay alguna mejor forma de realizar este monitoreo?

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba