De medir Proyectos (II)

En una entrada anterior introducía el tema de cómo el hecho de cómo medir un proyecto puede distorsionarlo y ser incluso de un coste comparable al mismo proyecto.

Como medir los proyectos es algo necesario (¿seguro?), en esta entrada pretendo aportar mi pequeño granito de arena a la discusión de cómo evitar esos males antes mencionados, para que la ingrata tarea de medir realmente aporte valor al proyecto.

Para ello me basaré en un puñado de principios básicos que creo que hay que tener siempre en cuenta:

• Dudar y revisar. Cuestionar de forma recurrente el proceso de medir y las métricas utilizadas. Es más simple de lo que parece: Cualquier métrica que se utilice debería ayudar a contestar la pregunta ¿se están consiguiendo los objetivos del proyecto (valor aportado y calidad) en tiempo y coste?

• Comprimir: Intentar trabajar con periodos de medida y control con tiempos prefijados e intentar que estos periodos sean cortos. Lo que haya que medir que sea corto en el tiempo. Hay que ayudar, ya desde la medida de los proyectos, a evitar la demoníaca Ley de Parkinson, que se puede enunciar de forma corta y rápida como El tiempo dedicado a una tarea tiende siempre al tiempo máximo disponible para hacerla. Esto no quiere decir que renunciemos a medir periodos largos sino que, en ese caso, midamos y controlemos con muestras frecuentes.

• Simplificar:  Cuestionar cualquier complejidad o cualquier acción de medir por medir. Medir y comunicar sólo lo necesario y nada más. Eliminar el reporting enlatado y periódico que toca cuando toca porque lo dice la metodología.

• Acercar: El proceso de medir debe ser público, conocido, transparente, con la cocina mínima y accesible a cualquiera bajo demanda. Se supone que no hay nada que esconder en el equipo de proyecto. Además, en la medida de lo posible hay que favorecer el contacto directo y frecuente del equipo (incluyendo al cliente que nadie se olvide de él, que es el que paga al fin y al cabo).  Este roce ayudará a evitar la confección de largos informes para que todos tengan el contexto de lo que está pasando. Es mejor estar al día que actualizarse cada mes. El objetivo es minimizar el tiempo en informar y optimizar el de gestionar (entendido como medir, analizar y decidir)

Como ejemplos, algunos radicales y no siempre aplicables lo reconozco, que se me ocurren de aplicación de estos principios:

• Nada de reuniones de progreso mensuales- máximo semanal en un día/hora concreta, de duración corta/prefijada y sin acta, como mucho una lista de objetivos a cumplir y verificar en la próxima reunión.

• Cero reporting – o el que quiera saber algo que lo pregunte ad-hoc o mejor… que se lo busque él mismo. En una reunión de proyecto ¿qué porcentaje de la información que se muestra es ya conocida por la audiencia? – según mi experiencia, casi toda. Todo ese tiempo destinado a informar sobre el contexto que se destine a discutir alternativas, mejoras, problemas, etc.

• Favorecer la interacción constante de todos con todos. La tecnología debe ayudar mucho aquí. Desde tener toda la información en línea (hay que superar ya por favor lo de tener carpetas de proyecto en la red), entornos colaborativos de gestión de proyectos – imaginad la potencialidad de poder estar al tanto de todos los microintercambios de información relevante que se producen en el seno de un equipo (aunque reconozco que en este punto se plantean dificultades de posible saturación e infoxicación, pero ese es otro tema).

• Uso de paneles/tablones para exponer la información relevante del proyecto. Visibilidad en tiempo lo más real posible de como avanza y se mide el proyecto.

• En proyectos donde se pueda, evitar la figura de gestor de proyecto que sólo gestiona el proyecto. Que tenga algo más que aportar, como un conocimiento concreto, por ejemplo en el ámbito funcional. Se trata de evitar perfiles únicamente administrativos.

• Evitar que las métricas de control de avance del proyecto se refieran al pasado. Por ejemplo, no tiene sentido para ver si el proyecto va a lograr sus objetivos medir el esfuerzo incurrido hasta la fecha, ¿no es mejor estimar el esfuerzo que falta?

• Involucrar al equipo en una evaluación periódica: supuestos, métricas utilizadas, reglas de cálculo, objetivo, propósito de cada medida y cómo contribuye -de forma cuantificada- a los objetivos del proyectos, …

Seguro que entre todos podéis aportar alguno más, ¿quién se atreve?…

PD. A estas alturas a pocos de mis hipotéticos lectores ya se les escapará que este post ha sido escrito bebiendo de fuentes inspiradas en los principios ágiles y metodos Scrum. Es un tema que me interesa mucho y del que hay varios artículos por aquí.

(1): Esta entrada es una actualización de una publicada anteriormente.