Métricas de proyectos y errores en proyectos IT

Hoy quiero hacer referencia a un par de artículos publicados en CIO.com que me han parecido bastante interesantes.

En primer lugar, publican un informe de Forrester en el que se comenta que utilizar las métricas clásicas de evaluación de éxito de un proyecto IT lo condena al fracaso. Estas métricas clásicas consisten en comprobar si se completó en tiempo, coste y cumpliendo los requisitos iniciales.


Lo que insinúa el artículo es que este tipo de valoración ignora la necesidad de cambios a lo largo de un proyecto debido, por ejemplo, a requerir una mayor calidad en el resultado final, o a modificaciones en el entorno como una nueva legislación. Estos cambios pueden suponer un incremento en el coste del proyecto o en el tiempo estimado para completarlo, pero a la vez pueden incrementar el beneficio obtenido por el proyecto. El artículo no propone cambiar dichas métricas sino que sugiere acciones que la oficina de proyectos debería realizar para mejorar el rendimiento del proyecto y comunicar su complejidad. Desde mi punto de vista, lo principal es valorar la aportación que el proyecto hace al negocio mediante el uso del business case como elemento de decisión para continuar un proyecto en las distintas etapas del mismo y su actualización en función de los cambios externos al proyecto (legislación, competencia, huelgas...) e internos al mismo (planificación demasiado optimista...).

El otro artículo hace referencia a los 14 errores más comunes en gestión de proyectos de los departamentos IT.

Interesantes también los comentarios de la gente que discuten sobre la validez o importancia de los mismos o de las soluciones propuestas y proponen algunos errores y soluciones alternativas. Los que comentan originalmente son:

• Carecer de los recursos correctos con la habilidades adecuadas para el proyecto.
  
• Falta de experiencia del director de proyecto.
  
• El departamento de IT no sigue un estándar o metodología de gestión de proyectos.
  
• IT pierde eficiencia y flexibilidad debido al uso de demasiados procesos.
  
• No se lleva un seguimiento de los cambios en el alcance del proyecto.
  
• Falta de información actualizada sobre el estado del proyecto.
  
• Ignorar los problemas.
  
• No definir inicialmente el alcance del proyecto en colaboración con la gente de negocio.
  
• No ver la relación y dependencias entre proyectos.
  
• No considerar la ley de Murphy (gestión de riesgos).
  
• Prestar escasa atencion a la gestión del cambio (quién ha de adoptar la tecnología).
  
• El plan de proyecto no está completo en cuanto a qué debe entregarse y cuándo.
  
• IT no discute fechas imposibles de cumplir sugeridas (o impuestas) por el CEO.
  
• Mala comunicación con patrocinadores y actores principales en cuanto a requisitos.
  

¿Cuáles de estos errores has encontrado en los proyectos IT de tu departamento? ¿Crees que existen otros más importantes? ¿Consideras que las métricas de evaluación de proyectos clásicas deben ser revisadas o cambiar al menos su importancia?