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.

2 thoughts on “De medir Proyectos (II)

  1. He estado impaciente esperando esta segunda parte de las métricas TIC y espero q hayan muchas más 😀
    A simple vista me ha parecido un buen compendio de ITIL (buenas prácticas, todo proceso debe ser medible y procesos concretos para cada función) y metodologías ágiles.
    Bajo mi punto de vista, no estar de acuerdo con establecer, evaluar y actualizar métricas en cualquier proceso TIC es negar valor al propio TIC. Otra cuestión es el coste de dicho trabajo.
    También es cierto que no poseer métricas estándares internacionales no ayuda al trabajo TIC.
    Respecto a las metodologías ágiles veo que el problema más grave es de la calidad e implicación de todos los participantes en el proyecto. Qué difícil es encontrar un proyecto en el que la mayoría de los participantes aunen las dos características anteriores.

  2. Hola Juan, no sé si vendrán más entradas sobre métricas porque el tema no me da para tanto. Creeme que no estaba pensando para nada en ITIL cuando escribía el post (entre otras cosas porque no tengo ni idea de ITIL) – de todas formas es más un tema de sentido común al fin y al cabo.

    Cierto que no cuestiono en serio la necesidad, abstracta, de medir pero sí cualquier forma de medir, y no sólo por lo que pueda costar sino, sobre todo, por su utilidad para contribuir al valor pretendido por el proyecto.

    Por otra parte, la falta de “calidad” e implicación del equipo es un problema en cualquier caso, sea ágil o tradicional. La única diferencia en ese aspecto es que en el primer caso queda patente en seguida y en el segundo se puede esconder un determinado tiempo – pero al final sale, vaya si sale

    Gracias por comentar

Deja un comentario

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

Uso de cookies

Este sitio web y subdominios asociados utilizan cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies

ACEPTAR
Aviso de cookies