- Tiempo de lectura: 5 minutos
- Problema: no poder detectar de forma temprana los desvíos en la ejecución de proyectos
- Observación: ya contamos con métodos para evaluar el rendimiento de un proyecto cerrado, tomando esa base tenemos que poder hacerlo con proyectos en curso
- Propuesta: modificar los mismos mecanismos que utilizamos para evaluar el rendimiento de un proyecto para que sean aplicables cuando el proyecto está abierto
Este es otro caso relacionado con la serie de posts relativos a la evaluación que estoy haciendo sobre el rendimiento de nuestra nueva Intranet a los 6 meses de su implantación. Esta vez centrado en detectar otro problema también habitual: desvíos en la ejecución de proyectos. De nuevo intento buscar una solución sencilla pero eficaz, basada en la interpretación inteligente de datos objetivos recogidos en un sistema de gestión.
Imagen: detección temprana de desvíos en proyectos, de Syslan
En estos años que he trabajado como gerente, he podido apreciar que es difícil inculcar al equipo técnico una verdadera preocupación por el impacto que tienen sus acciones y decisiones sobre la cuenta de resultados. Y sin embargo en las NEBT este impacto es fortísimo. De ello puede llegar a depender el éxito o fracaso de un proyecto brillante.
Si empatizamos con el equipo, y nos ponemos en su piel, en su día a día, rápidamente estaríamos cayendo en el mismo juego. En las empresas en crecimiento, el volumen de trabajo y la urgencia del mismo habitualmente sobrepasa la capacidad de producción de las unidades técnicas. Es muy difícil asignar un espacio de “tiempo limpio” que permita realizar un seguimiento diario de la efectividad de nuestro trabajo y nuestro entorno.
Por tanto la conclusión es clara; la detección de desvíos tiene que ser automática, tiene que realizarse de forma temprana, y tiene que generar los avisos pertinentes hacia las personas que tienen capacidad de actuar sobre ello.
Las métricas
Son tres las métricas principales que utilizamos para evaluar la marcha de un proyecto:
- ETA: Estimated Time of Arrival, normalmente calculado en forma de días restantes hasta la entrega (o la fecha establecida para cumplir el hito, tarea, subtarea, etc.)
- % completado: ratio de completado del proyecto, normalmente viene calculado por el ratio de completado de sus tareas y subtareas.
- % recursos utilizados: se refiere al consumo que ya se ha realizado de los recursos que se habían asignado al proyecto. Es un indicador que agrupa el consumo de horas, desplazamientos, materiales, etc.
La parte más automática es la relacionada con los recursos utilizados. Se alimenta del registro de actividad de la propia intranet, es decir, sabiendo lo que está haciendo cada trabajador en cada momento, asigna su coste horario al proyecto sumándolo a sus recursos utilizados.
Boceto: detección temprana de desvíos en proyectos. Autor: Fernando Sáenz
Las alertas
Las alertas más evidentes se dan cuando alguna métrica sobrepasa el umbral, por ejemplo si superamos los recursos disponibles, o si nos pasamos de fecha. Pero este tipo de alertas tiene poco de temprana. Es como si el GPS nos avisara de la presencia de un radar en la carretera en el momento de sobrepasarlo. No tenemos margen para reaccionar.
Las alertas tempranas son también sencillas, pero eficaces. Y dejan mayor margen de reacción. Por ejemplo hay una muy útil que avisa si se están consumiendo recursos de un proyecto, pero su % completado no se ve incrementado proporcionalmente. Otros incluyen el aviso por la proximidad de la fecha de entrega si el % completado no está por encima de un umbral, o si el consumo de recursos está siendo desproporcionado respecto a la evolución del proyecto.
Las alertas más avanzadas tienen relación con el modelo de comportamiento del cliente al que pertenece el proyecto (leer: pre-clasificación de proyectos en base a la modelización de clientes). Pese a que todavía no las tenemos operativas, su diseño lo tenemos claro; tenemos perfectamente identificadas las tareas relacionadas con el cierre de proyecto (subida a producción, puesta en marcha, etc.), y el modelo de comportamiento del cliente puede predecir la tendencia de coste de cierre de proyecto. Se generará una alarma temprana siempre que un proyecto se acerque al umbral que sobrepasa el margen que necesita ese cliente concreto, tanto en recursos como en tiempo.
Resultados positivos
- El equipo técnico ha aumentado su conciencia sobre el impacto que tienen sus acciones y decisiones sobre la cuenta de resultados de la empresa. En contra de ser un elemento de presión, ha resultado ser un elemento de motivación.
- Los responsables de los proyectos tienen el Gantt en tiempo real, con el estado de desarrollo de todas las tareas y subtareas, recursos consumidos y ETA. Pero además pueden ver la evolución del Gantt, detectando rápidamente los consumos de recursos que no generan avance en el proyecto. Incluso reciben alarmas al respecto.
- La combinación de este Gantt en tiempo real junto al modelado de comportamiento de clientes permite que el sistema establezca los márgenes necesarios para cada proyecto, minimizando la probabilidad de pérdida de rentabilidad en fases post-desarrollo.
Puntos de mejora
- Hemos apreciado que la especificación de tareas y subtareas para un proyecto hace que el indicador de “% completado” sea más preciso, ya que se calcula en base a los sub-indicadores de todas las tareas y subtareas que componen el proyecto. Cuando el indicador se calcula manualmente para un proyecto entero, su factor de error crece proporcionalmente al tamaño del proyecto. Por tanto hay que evitar los cálculos generales, cada responsable de cada tarea tiene que hacerse cargo de especificar el cálculo pormenorizado.
- Existen situaciones que generan desvíos justificados. Para esos casos, conviene integrar en una única interfaz las gráficas analíticas y la meta-información del proyecto. Digamos que se necesita un mecanismo para marcar los “falsos positivos”.
Conclusión
Hoy en día tengo que reconocer que nosotros mismos nos sorprendemos de lo obvio de este diseño, pero también nos sorprende lo poco que se aplica en otras empresas, especialmente las NEBT. Su gestión de proyecto suele estar habitualmente dirigida por metodologías con un punto de vista de ingeniería, como Scrum, o Agile, lo cual es perfecto y necesario. Pero en nuestro caso vimos que necesitábamos algo más, algo automático, que trabajase en tiempo real, que generase alertas tempranas, y sobre todo que trasladase adecuadamente al equipo técnico la responsabilidad que tienen sobre la cuenta de resultados.