Diagramas Gantt cómo arma de destrucción masiva de proyectos. Maneras de usar un Gantt para matar un proyecto

Hace unos meses, en una de esas asesorías que de vez en cuando me piden sobre qué pasa en un proyecto software en crisis. Ocurrió entonces una de esas reuniones de proyecto en las que los participantes tienen, y muestran, decenas de diagramas Gantt, esos de Microsoft Project, con decenas de barras azules horizontales, flechas de dependencias, porcentajes de avance dentro de las barras, porcentajes de uso de recursos, columnas de fechas de inicio, fin, real, etc.
Siempre que en una reunión salen estos diagramas, diagramas que, algunos, por su tamaño, son impresos en varios folios pegados con celofán, tengo la sensación de que la mente de los participantes se traslada a otro plano astral, en el que la única preocupación es cuadrar barras, flechas y recursos, en un espacio temporal…  donde dichos pronósticos la mayoría de las veces no se cumplirán.
He de confesar que años atrás fui un gran usuario y creyente en dichos diagramas. De hecho, en algunas de mis presentaciones muestro un Gantt gigante que hicimos hace años con una planificación a 4 años, repleto de barras y flechas.
Pienso que, en parte, la razón de su gran uso en el mundo del desarrollo software viene de la formación que casi todos los ingenieros en informática hemos recibido en gestión de proyectos, aun hoy en un 99% basada en aprender Gantt, Perts, rutas críticas, etc. Es decir, planificación tradicional, aquella heredada de la gestión y construcción de productos físicos cómo barcos, casas o coches (te recomiendo aquí el post de fabricar software no es lo mismo que fabricar coches o construir casas).
Y esa “visión Gantt” de que fabricar software debe hacerse como se construyen cosas físicas está tremendamente arraigada en la cultura de ciertas organizaciones, incrementada aún más en los últimos años por el uso de macro marcos de gestión de proyectos (no específicos para software) como PMP.
Por supuesto, no digo yo que este mal aplicar y estudiar este tipo de gestión de proyectos, pero me sorprende que en la Universidad casi ni se estudié la otra manera de gestionar proyectos, muchas veces más cercana al software: ágil, adaptativo, iterativo, etc. Y que muchas empresas no vean que hay proyectos en los que la planificación Gantt es una buena manera de gestionar… pero en otros no lo es.
En cualquier caso, después de haber pasado ya por tantas empresas, he ido recopilando un conjunto de errores típicos a la hora de gestionar un proyecto con diagramas Gantt. Y en este post he querido dejaros un breve resumen de las 5 maneras más típicas de usar un diagrama Gantt para matar un proyecto:


1 Confiar ciegamente en los porcentajes de avance que muestran las barras del diagrama Gantt. En innumerables ocasiones he visto como los jefes de proyecto actualizan las barras de % de avance de un Gantt según a) el tiempo transcurrido (que no el trabajo terminado) b) preguntando a la gente «cómo vais». Y, por alguna de las anteriores, normalmente los diagramas Gantt acaban en c) el 90% de la vida de la barra Gantt está en 90% de avance. Curiosamente, esta manera tan poco rigurosa de saber el estado del proyecto la usan muchos directivos para conocer el estado de sus proyectos, lo que acaba en que gran cantidad del tiempo… no saben exactamente el estado de sus proyectos.
2 Planificar un Gantt de proyecto en función del tiempo disponible y no en función del tamaño del software a desarrollar. O «estimar» de adelante hacia atrás. Es decir, fijada una fecha de finalización del proyecto, normalmente impuesta por motivos comerciales, construir un Gantt cuyas barras y recursos encajen de cualquier forma entre la fecha actual y la de fin. Un recurso muy usado en estos casos es tener que abusar de las tareas que, supuestamente, se pueden hacer en paralelo.
3 Crear un Gantt ajeno al calendario real. Es decir no considerando el tiempo que llevan las reuniones, que la gente se toma vacaciones, que los proveedores de hardware se retrasan a la hora de traer las máquinas, que hay días festivos, etc.
4 Fijar inamoviblemente una fecha “real” de fin de proyecto, independientemente de la fecha de comienzo del proyecto. Decenas de veces he visto, y he sufrido, como el departamento comercial manda al cliente un diagrama Gantt con una fecha real de comienzo y una fecha fin de proyecto. Finalmente, al cliente se le fija inamoviblemente en la cabeza la fecha exacta de finalización que el proveedor le ha ofrecido… pero el proyecto comienza meses después de haberle entregado al cliente dicho Gantt. Empieza meses después de la que en su día era la fecha de comienzo prevista.
5 Crear un Gantt gigante, a veces de años, y en el mismo fijar el día exacto en el que finalizará el proyecto. Este es otro clásico. Una regla básica de la estimación software es que la precisión de la estimación es menor cuanto mayor es el tamaño del proyecto. Te recomiendo aquí una breve introducción a la estimación software. Recomendaciones y buenas prácticas (4/4). Es decir, que en un proyecto de un mes puedo prever el día exacto de finalización, pero en uno de 4 años… te aseguro que si pones un día concreto de finalización vas a fallar. Las estimaciones deben usar rangos, la semana x, el mes z, etc. Un proyecto de años puede aventurarse a dar un mes o unos meses previstos de finalización, lo demás es jugarse la palabra del jefe de proyecto al azar.

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

0 comentarios en “Diagramas Gantt cómo arma de destrucción masiva de proyectos. Maneras de usar un Gantt para matar un proyecto”

  1. Pingback: Bitacoras.com

  2. Claro Javier, el tema es como manejas ciclos (iterativo e incremental) usando Gantt?
    Otro tema, puede que contribuya a la destrucción pero si no se hace de alguna manera una planificación también terminamos en la destrucción!!!
    Saludos

  3. Hola,
    No si no digo yo que no se planifique, salveme de pensarlo, lo que quiero decir es que, aparte del Gantt, existen otras maneras de planificar / gestionar un proyecto. Incluso maneras que se pueden combinar. Se puede ser más predictivo, o más adaptativo, trabajar por iteraciones, etc.
    Normalmente el Gantt no es la mejor herramienta para manejar un proyecto iterativo e incremental.
    Saludos!!

    1. Estimados:
      el estandar del PMI propone una tecnica denominada Rolling Wave Planning.
      Implica que se planifica con precision para plazos cortos pero se estima con un mayor grado de incertidumbre para plazos mas lejanos.
      Esta tecnica es util para proyectos complejos y de un gran periodo de duración.
      Saludos

  4. Excelente artículo, y 100% real, para Pedro podría sugerir planear cada iteración y suponer como un hito el comienzo de la siguiente ( Aunque de seguro tendrá que moverse )
    Saludos

    1. En proyectos agiles, no tiene sentido un diagrama de gant; por lo siguiente:
      Tu planificacion es de 2 semanas, 4 semanas max. Es un tiempo muy corto que tiene actividades especificas para lograr un objetivo puntual.

  5. Pingback: Resumen de la semana – del 18 al 24 de Junio - Javier Garzás, sobre calidad software y otros temas relacionados

  6. Hola,
    El problema de un gantt viene cuando intenta predecir a muy largo tiempo (años p.e) lo que va a pasar en un proyecto… sin tener de partida la seguridad de que los requisitos son los que son y están cerrados.
    Frente a la gestión predictiva que típicamente usa Gantts (aunque no siempre, hay que decir que los gantt también se pueden usar en la gestión evolutiva) está la gestión evolutiva. Y está gestión evolutiva, basada en hacer entregas de producto regularmente durante el proyecto para captar requisitos, se puede hacer a su vez de varias formas, p.e haciendo entregas a intervalos fijos de tiempo o iteraciones, como se hace en Scrum o dividiendo el trabajo en entregas, como hace kanban, o incluso uniendo las anteriores.
    Bueno, espero haber resumido claramente el tema en un breve comentario.
    Saludos

  7. Excelente articulo 🙂
    El principal enemigo de muchos proyectos de software es el departamento comercial, a veces pienso que las metodologías de desarrollo de software deberían empezar por ayudarles a vender proyectos de forma que sea posible que un equipo de desarrollo los haga y la empresa obtenga ganancias.
    Un par de erratas:
    cercana la software
    nos aben exactamente
    puedo proveer el día exacto de finalización

  8. buenas tardes amigos, estoy terminando el 4to semestre del TSU en informática y solo conocemos el metodo de Gantts, seria muy interesante aprender estas nuevas metodologias y ponerlas en practicas para innovar, en mi caso en el trabajo y la universidad. gracias….

  9. Buenas Javier, estoy de acuerdo en lomque dices pero, de los 5 errores que comentas, poca culpa tiene el pobre diagrama de Gaant. Esos erorres son independientes del diagrama y respinsabilidad directa de un mal director del proyecto. Si a quien cometa esos errores te lo llevas a un entorno Agile, los cometera pero en ese caso con las herramientas Agile. O al menos esta es mi opinion 😉

  10. Saludos a todos.
    Las herramientas por si solas no hacen el plan, sino que te ayudan a hacer lo que quieras, por consiguiente depende de la habilidad de uno para que el resultado sea bueno o malo. Considero que los diagramas de Gantt te ayudan a llevar un buen control pero depende tu habilidad para representar allí tu plan incluso cualquier cantidad de ciclos que se definiera, así como tu habilidad para reflejar el avance real.

  11. Buenas tardes.
    En esta aspecto no veo gran diferencia con los proyectos de ingeniería clásicos. Los plazos impuestos, la cultura empresarial que hay detrás y la forma de control es la misma que en la ingeniería tradicional por lo que veo.
    He hecho proyectos de máquinas y herramientas y ha sido más o menos similar. Los diagramas se los pasaban al cliente para que viera el desarrollo y los problemas eran los mismos.

  12. Buen post Javier,
    Creo que Gantt fue una herramienta visual muy útil, sin embargo, ahora los que hacemos agilidad entendemos que existen otras herramientas que pueden apoyarnos de mejor manera. Desde mi punto de vista, las premisas que colocas no son propiamente del Gantt, sino errores que cometíamos al hacer un plan. Un abrazo.

  13. Buenos días:
    Es gracioso, pero cuando estuve en la universidad los profesores, hablaban mucho del Gantt. Ciertamente llevo varios años trabajando en diferentes campos, recientemente algunos años en informática, y puedo decirles que los periodos nunca se cumplen.
    Esto debido a que el Gantt, trabaja sobre supuestos de Productividad/Tiempo, es decir, tarea 1 tiempo estimado 1, tarea 2 tiempo estimado 2, y muchas veces por el nivel de análisis o interacciones que posee el desarrollar un software, y el nivel de experiencia que se posea, un mismo proyecto no le tomará lo mismo a una persona, que a otra.
    Y al menos cuando trabajan equivocadamente en base a fechas de entrega muy ajustadas, resultado: 1) Se crea un Gantt ilusorio que solo se cumplirá en el papel, o 2) Se entrega un producto con fallas, que después deberá ser revisado para poder sacar una nueva versión.

  14. Siempre he pensado que Project es una cosa horrenda que no se acopla al desarrollo de software, ni a la realidad, ni a la personas…….Aún así es triste ver como está tan profundamente arraigado en los huesos funcionales de algunas organizaciones y particulares. ¿Cuantos años tiene Proyect y la gestión de proyectos en forma de cascada? ¿Unos 30?

  15. Excelente artículo.
    Puedo colaborar con una manera adicional de matar un proyecto de software con Gantt y es: Dar protagonismo al gantt, el foco no debería estar en usar correctamente un Gantt.

  16. Excelente pero entonces que se puede usar para medir los tiempos??? como le dices cuando empieza y cuando acaba un proyecto a tu jefe?? si no es con el gantt

  17. En mi opinión, el problema no está en el Gantt, sino, como bien dices en su mal uso, en la forma enn que los profesionales mienten, mentimos, con él, a veces conscientemente para que encajen las fechas y los recursos.
    Como bien dices, la forma de medir tiempos no se puede predecir correctamente si el proyecto es a muy largo plazo y sobretodo, si no incorporas todos los posibles riesgos que participan que, en el caso de las nuevas tecnologías, puede crecer exponencialmente y abocar al desastre; o decrecer, convirtiéndose en un acelerador de proyectos, como el caso de la salida al mercado de nuevos equipos (hw, sw y humanos) que minimizan tiempos de proceso y agilizan procedimientos de trabajo.
    Un buen gantt, es una forma de trasladar a los jefes, clientes o usuarios la situación del proyecto, de trasladar el conjunto de tareas a realizar y entregables necesarios y poder definir un compromiso entre todos los participantes.
    Y si va acompañado de la desviación de línea base tras incorporar los datos reales y de la lista de incidencias, un buen aliado para calcular costes reales, especialmente los imprevistos.
    Como herramienta de apoyo tiene utilidad en cualquier proyecto, sea o no de software, siga o no el ciclo de vida clásico. Siempre que la dirijamos nosotros y no nos dejemos arrastrar por él, claro.
    Un saludo.

  18. Excelente artículo. Es muy bueno leer las experiencias de quienes han podido puntualizar las lecciones aprendidas en su quehacer diario. En mi opinión particular, creo que con Gantt ha ocurrido que la herramienta se convirtió con mucho en el protagonista del proceso, cuando precisamente debería ser un aliado a la hora de desarrollar cualquier proyecto.

  19. Interesante artículo. pues me está ayudándo de mucho. además se puede copiar, dado que en los vídeos o tutoreales no se pueden descargar.
    Saludos.

  20. Pingback: La combinación perfecta para la gestión de tareas y equipo » Diseño con Cabeza

Dejar un comentario

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