Viaje a las catacumbas de un proyecto

Gestionar proyectos con un número medio de 280 actividades directamente ejecutables no es un asunto trivial, aunque tampoco imposible, y de hecho se hace. Digo lo de actividades directamente ejecutables porque, si contamos todas aquellas que están en niveles superiores en la jerarquía de la estructura y desglose del trabajo (EDT o WBS en el acrónimo inglés), es decir todas aquellas que se descomponen en otras subactividades y, por tanto, no se ejecuta trabajo en ellas, entonces los proyectos a que me refiero tienen un número medio de 355 actividades, es decir 355 barritas de diferentes longitudes y texturas pintadas en nuestro flamante cronograma o diagrama de Gantt, de red o tu fetiche gráfico preferido. Me podréis advertir que, desde el punto de vista de gestión, sólo importan las 280 actividades donde se ejecuta trabajo puro y duro, y puedo estar de acuerdo. Pero, si tenemos en cuenta la estructura lógica de toda la red de actividades, las 355, lo cosa se puede complicar. Me refiero a la existencia de interrelaciones, no sólo entre actividades directamente ejecutables, sino entre cualquier tipo de actividades en cualquier nivel del EDT. Además, pensad que no son pocas sino todo lo contrario y todas aparentemente justificadas -creedme que no son mancos definiendo el alcance de sus proyectos, y lo que es el sueño añorado de muchos puede ser la pesadilla consumada de unos pocos. Así que os podéis imaginar el cronograma que nos saca el plotter –de cosas menores que un A2 olvidaos. Podría servir de decorado para una película de Tarzán. Y claro, a ver quien es el guapo homo sapiens, economicus a gantensis que interpreta todo aquello. Y por interpretar quiero decir acciones como las de entender por qué el cronograma ha quedado de la forma que lo ha hecho después de una replanificación –se da por sentado que para todo esto se está utilizando un software que, en este caso, no es MSProject sino otro más potente. Como, por ejemplo, que después de actualizar tres actividades para dar cuenta de sus desviaciones actuales, y replanificar el proyecto, veamos que una actividad posterior se retrasa dos semanas cuando la de la que parece provenir solo se ha retrasado una, y cuando intentas averiguar el por qué, resulta que las posibles rutas de una a otra no son pocas. La labor se hace ardua y acabamos por abandonar –siempre podemos alegar que disponemos de muy poco tiempo como para perderlo en estas cosas.

Bueno, cosas de la complejidad. Nadie dijo que gestionar, lo de dirigir es harina de otro costal, proyectos de esta envergadura fuera fácil, y de hecho no lo es qué cojones, a pesar de que muchos jefes de proyecto no quieran reconocerlo. No sólo de buenas intenciones y palabrería se dirige un proyecto, también hay viajar a sus catacumbas e informarse de qué se cuece ahí abajo. Y ese viaje no tiene por qué ser en limusina. Otra cosa es que se puedan, y deben, simplificar las cosas. Aunque, independiente de todo esto, me gustaría resaltar aquí un par de paradojas dignas de una nube de evaporación de Mario. La primera es una queja muy común que se hace a los cronogramas realizados mediante paquetes de software, consistente en argumentar que el seguimiento se hace imposible porque está demasiado automatizado y es demasiado inflexible a los avatares cotidianos del curso de un proyecto –Murphy y todo eso. El resultado es que la programación resultante no es del agrado porque no refleja totalmente la realidad del proyecto –y descarto aquí el caso nada extravagante en que no gusta al jefe de proyecto poco amante de la realidad. Aquí habría que reconocer un hecho, que los resultados del paquete de software no son definitivos ni perfectos porque no son inteligentes como nosotros. Siempre hay que hacer algo manualmente, sobretodo en las replanificaciones. Y cuando son conminados a hacer ese esfuerzo de puesta a punto manual, entonces se quejan de que la herramienta debería proporcionar resultados automáticos, que no estamos para perder tiempo con eso -¿seguro?, diría yo, entonces, ¿a que nos dedicamos?

La segunda paradoja tiene que ver con la lógica de tareas. Si tantas interrelaciones provocan que las replanificaciones sean menos intuitivas, e incluso errores debidos a inconsistencias –es más fácil que cojee una mesa de cuatro patas que una de tres, no pongamos tantas. “Ya, pero son necesarias”, responde con los ojos iluminados de quien piensa que ha dado en la línea de flotación. Pero, ¿necesarias para qué? Yo entiendo que la mayor utilidad de las interrelaciones radica en el uso del cronograma para hacer el seguimiento del proyecto: dado el impacto de la realidad sobre un grupo de actividades en curso, las desviaciones son transmitidas al resto de actividades subsiguientes en el tiempo a través de la estructura lógica proporcionada por la red de interrelaciones. Así, de un plumazo. El ajuste fino, si necesario, a mano. Y lo que precisamente me importa del proyecto en ese momento es lo que queda por hacer. Lo hecho, hecho está y forma parte de pasado, y cuanto antes lo aceptemos mejor. Así que no quieren eliminar interrelaciones y simplificar la red porque las necesitan, pero luego no las usan porque el ruido que generan les hace imposible aprovecharlas.

Qué oscuras son las catacumbas y qué contradictoria la naturaleza humana.