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.

• Acerca de
• Últimas entradas

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.

Últimas entradas de jgarzas (ver todo)

• Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
• Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
• Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024