Critical Chain Project Management (CCPM)

Escrito el 20 de Junio de 2007 a las 10:07 

CCPM CCPM nace en el 97 a raiz del libro de Eliyahu M. Goldrat, padre putativo no solo de esta criatura sino de la famosa Teoría de las Limitaciones.

Se basa en dos principios bastante elementales (si obviamos las partes que no son específicas de CCPM sino generales de TOC):

buffers

Aunque sin duda la teoría tiene sus defensores, que aseguran que la mejora en los tiempos de desarrollo y ahorros de coste en los proyectos es cercana al 50% y que incrementa drásticamente el éxito de los proyectos, la verdad es que yo no acabo de identificarme con ella. Para empezar, y como posible razon de mi poco gusto por CCPM, el libro en sí es insfurible. Son unas 100 páginas solamente, lo cual es relativamente poco para un libro teórico, pero es que encima está escrito al mismo estilo que “La paradoja“, es decir, novelado y contando un teórico curso sobre gestión de proyectos que el autor imparte, y en el que va contando línea a línea las conversaciones con sus alumnos. Para que os hagais una idea, el comienzo del capítulo 11:

Rick es de los últimos en llegar. Para su sorpresa, el pequeño auditorio está casi lleno. Probablemente se ha corrido la voz de que este coloquio iba a ser diferente. Muy diferente. Jim le hace señas con la mano. ‘Te he guardado un asiento’. Ahora no se podrá escabullir a los quince minutos”.

Pues así todo el rato. Respecto a la teoría, CCPM no deja de ser, desde mi humilde perspectiva, un PERT con esteroides. Así que empezamos mal, ya que no son pocos los que empiezan a renegar de PERT por varias razones: por ser más antiguo que los rodapies de la cueva de altamira y por asumir que la duración de las tareas es estimable de forma determinista al principio de los proyectos, optimizando un camino crítico que, a lo mejor, luego no es tal. La realidad es que la planificación no es un proceso discreto, sino un elemento situacional y continuo, y ese reajuste constante de la planificación es mucho más efectivo que CCPM.

¿Por qué? Pues veréis, a mi esto del buffer de proyecto siempre me ha recordado al sketch de Little Britain en el que el grupo de apoyo para obesos defiende una dieta en la que puedes comer cualquier alimento con el doble de calorías de lo recomendado siempre que comas solo la mitad. Pues vaya. Haz una estimación de tiempos, quitales un tercio y ponlo al final del proyecto: en el peor de los casos, tienes lo mismo que si hubieras hecho un PERT, pero si alguna tarea dura menos, eso que has ganado y que puedes emplear si se retrasan otras tareas.

Así mismo, CCPM tiene a mi juicio un problema grave: se basa en engañar de alguna forma a los recursos para que piensen que hay menos tiempo disponible del que realmente hay, y a exprimirlos para que finalicen las tareas antes de lo que naturalmente se supone que deberían durar. Por tanto hay varias posibles perversiones del modelo: que las personas que proveen las estimaciones se den cuenta del tinglado e incrementen sus estimaciones o que, aunque les digas que deben entregar en determinada fecha, piensen “total, ya consumiremos tiempo del buffer de proyecto”.

Por otra parte, CCPM asume que todos los proyectos tienen una estructura de “construcción”, con todos los recursos orientados a la convergencia en un último producto, por lo que si un recurso se retrasa, afecta al resto de recursos. Y lamentablemente todos los proyectos no son tan “cuadriculados” (estos son casi los mejores). Tal vez es que mi ámbito natural de trabajo son las TIC y las telecomunicaciones, quizas si me moviese en entornos más industrializados sentiría una mayor simpatía por CCPM…

En fin, que tengo mis razones para no ser un devoto de CCPM… Pero también soy una persona que, si bien no voluble, me dejo convencer con argumentos. Así que si alguien tiene a bien ilustrarme, le estaré devota y eternamente agradecido…

Categorías: Gestión de Proyectos, Libros
Tags:
Compártelo

Comentarios

10 comentarios a “Critical Chain Project Management (CCPM)”

  1. Enrique , el 20 de Junio de 2007 a las 23:41 | Trackback

    Pues la verdad que aunque el método en sí es una estupidez, tiene su utilidad.

    Es una estupidez porque todos sabemos que cuando tienes N personas trabajando en M proyectos nunca planificas lo que corresponde y siempre pones algún dia de más para asegurarte que aunque haya achuchones por un problema, las cosas se entregarán a tiempo -así lo he hecho yo-. Y ahora viene el “listo” de Eli y dice que una leche, que te quita esos dias. Si ya sabemos que están de “clavo” pero es una clavada justificada y necesaria.

    A favor está que como vas viendo el consumo del buffer -es lo que se vigila- en cuanto vas gastando más de la proporción adecuada avance de proyecto/consumo de buffer la gráfica te canta enseguida que algo se quema.

    Esto es muy útil cuando lo que haces es gestionar diferentes proyectos concurrentes de distintas empresas para obtener un proyecto conjunto común.

    Así lo usamos en el Centro de Gestión Aeroportuaria de Barajas y se hizo -lo que se hizo, y hasta aquí puedo leer ;-) - a tiempo para la apertura de la T4.

  2. telemaco , el 21 de Junio de 2007 a las 14:11 | Trackback

    Pues personalmente no estoy muy de acuerdo con tus argumentos.:(

    La base de CCPM es “dar prioridad a cumplir la fecha de entrega de los proyectos” vs “dar prioridad a mantener a todos los recursos muy ocupados”.

    El síndrome del estudiante es un efecto real que ocurre y que por tanto es conveniente gestionar. E igual de real es la ley de Parkinson (la duración real de la tarea se dilata hasta ocupar todo el tiempo disponible) y también sería conveniente gestionarla. Esto es lo que la gestión del buffer (que no has mencionado) hace en CCPM.

    Y estos dos efectos anteriores combinados con las dependencias entre tareas (si el proyecto no las tiene entonces no hay mucha complejidad que gestionar..pero… ¿no tienes más de un proyecto a la vez?¿las tareas de tus proyectos no comparten ni siquiera un recurso?, si es así ahí tienes tu dependencia) provocan que los retrasos se multipliquen y los adelantos se pierdan (a no ser que uno haga algo al respecto, que es lo que intenta CCPM).

    Tampoco estoy de acuerdo con lo del “engaño” y la presión a los recursos, es obvio que esa presión sólo agrava los problemas. La gestión de buffer de CCPM consiste precisamente en sacar a la luz la verdad del proyecto, cuyo retraso o adelanto global, conocido por todo el mundo a través del consumo del buffer del proyecto, es lo único que puede presionar.

  3. Ángel , el 21 de Junio de 2007 a las 18:13 | Trackback

    Estupendo, debate… :-)
    A ver, para empezar yo tampoco digo que CCPM sea estúpido. Solo un poco elemental y quizás algo ilusoria. Parte, como digo en el artículo, de la premisa de estimar la duración de las tareas y luego reducir ese tiempo por si hay suerte y se acaban antes. Como explica Enrique, se basa en eliminar a priori los “días de clavada”… Pero es que lo que no es lógico es que hayan días de clavada, y el Jefe de Proyecto debería estar en ello. Lamentablemente, es cierto que el Jefe de Proyecto debe ser generalista, y puede que el especialista se la pueda colar (”es que para esgorciar el condensador de fluzo hay que dejarlo reposar una semana mientras jugamos al God Of War II”).

    Tampoco digo que sea inutil: solo que es fácilmente pervertible en el momento en que el equipo sea consciente de cómo se está gestionando la red de tareas. Por cierto, que en Dirección de Proyectos hablan precisamente estos días de CCPM en términos bastante glamourosos, así que a lo mejor deberíamos darle un toque a Diego y decirle que se pase por aquí a despotricar con nosotros ;-)
    Telemaco, no hace falta que pongas un smiley triste por no estar de acuerdo conmigo… Si estuvieramos siempre de acuerdo, menudo rollo y que poco aprendizaje mutuo, ¿No? ;-) . Respecto a la gestión del buffer, bueno, no he abundado en detalles en el artículo, pero es que tampoco quería hacer una explicación exhaustiva de CCPM, sólo de las raxones por las que no me acaba de convencer. Será que soy mucho más devoto de las soft-skills que de las herramientas técnicas, que le vamos a hacer ;-). Pero incluso admitiendo que la gestión de un buffer de proyecto sea una herramienta (OTRA herramienta) util … ¿es de verdad como para que haya gente que la defienda como la re-panacea de la gestión de proyectos?

    Una pregunta ya que os veo puestos: ¿qué herramienta habéis usado para observar y gestionar el consumo de buffer?

  4. telemaco , el 21 de Junio de 2007 a las 22:21 | Trackback

    Hay unas cuantas (p.e. concerto) pero la herramienta no es lo importante, se puede hacer con una simple excel (lo difícil es conseguir que los recursos reporten el estado de su tarea de forma periódica).

    Por cierto el buffer de proyecto está para ir gastándolo desde el primer día. Porque se parte del hecho de que no es posible conocer la duración de las tareas a priori.

    Lo de los días de clavada y demás “efectos” es algo inherente al ser humano e inevitable, uses el sistema de gestión que uses. No sirve de mucho intentar afinar y eliminarlo, se trata de gestionarlo de la manera más efectiva posible.

    Si se parte del hecho de que preveer el futuro es imposible, es más lógico no gastar energías en afinar las previsiones de cada tarea y focalizar todo ese esfuerzo en los puntos donde realmente impacten directamente en la fecha de entrega del proyecto de forma global (básicamente en la cadena crítica y en el recurso más cargado).

    Se trata de aplicar visión sistémica, dejar de perder el tiempo en perseguir máximos locales para dedicarse a buscar el máximo global del sistema. Ya sabes: “evitar que los árboles nos oculten el bosque”.

  5. Sergio , el 16 de Julio de 2007 a las 2:20 | Trackback

    Soy Jefe de Obras, y por experiencia puedo decir que la única forma posible de dar utilidad a un planning es imprimiéndolo en papel higiénico. Lo único que se puede hacer, en el caso de disponer de un planning suficientemente extenso y detallado, lo cual en la empresa, por sus propias razones de planning tampoco te lo permiten hacer, por cuestiones de tiempo, es buscar, con los recursos de que dispones, la realización de tareas que no son críticas en el caso de que las críticas se te atrasen, si bien esto nos lleva al recorte del buffer que puedas tener, si es que lo tienes.

  6. Ángel , el 16 de Julio de 2007 a las 8:49 | Trackback

    Sergio, si bien los plannings pueden ser inútiles, el proceso de planificación es absolutamente indispensable (Eisenhower dixit). Lo que no puedes hacer es realizar un planning a principio de obra y observar durante toda la obra como se va desviando sin hacer nada. El planning debe ser mantenido, corregido y alimentado con frecuencia (a veces a diario). Si no, uno acaba poniendo “parches” todo el rato y acaba conviertiéndose en el “campeón o heroe de proyecto”, ya que los diferentes recursos no son conscientes de lo que se espera de ellos ni de las implicaciones que tienen sus retrasos.

  7. telemaco , el 16 de Julio de 2007 a las 9:24 | Trackback

    Sergio y Angel… habéis conseguido deprimirme.

    ¡También ayuda que hoy es lunes!.;)

    Pero ¿además de la opción de creer que la planificación es totalmente inútil, no cabría la posibilidad de que estuvieseis haciendo algo mal?.

  8. Ángel , el 16 de Julio de 2007 a las 11:29 | Trackback

    Me he debido expresar mal, telémaco. Para mi, repito, la planificación es indispensable, no “totalmente inutil” como dices tú. Lo que resulta totalmente inutil es hacer un diagrama de gantt al principio del proyecto, colgarlo de la pared y, al final del proyecto, decir “esto se parece a la realidad como un huevo a una castaña”. Por eso, más que el plan (el gantt, en la versión minimalista hasta el paroxismo de un plan de proyecto), que es algo situacional, es inutil si no se acompaña de todo lo que conlleva el proceso de planificación, que es algo continuo y no solo debería englobar tareas/tiempos/costes/dependencias entre tareas, sino aspectos mucho más amplios como riesgos y oportunidades, organización, liderazgo, comunicación, marketing de proyecto, control de cambios, informes de gestión, visibilidad…

  9. Andrés , el 20 de Mayo de 2008 a las 18:07 | Trackback

    Por favor alguien tiene algún modelo que no sea un software de gestión para el seguimiento de proyectos ccpm?
    Independientemente de control de buffers cuando la situación de la cadena es amarilla o roja, cuando debo actualizar el Buffer?
    Si un recurso de una tarea en curso hoy no vino a trabajar, actualizo el buffer diciendo que he consumido un día?
    Si cambia el recurso de una tarea, replanifico la cadena crítica y asigno nuevos Buffers?
    Si en el seguimiento identifico que hay una nueva tarea no prevista?
    Gracias

  10. David Villalobos , el 1 de Septiembre de 2008 a las 23:48 | Trackback

    Saludos a todos, excelente nivel de debate… Soy nuevo en la administración de proyectos, pero considero que “solo se hace camino al andar”. Comenzaré por aplicar el CCPM antes que el recetario completo del PMBOK… pues veo a aquel más simple, enfocado y lógico, más allá de las desventajas que comenta Ángel… os comentaré mis avances…

Deja tu comentario




Buscar:

Suscriptores:

Tags

Que se dice por aquí:

Qué se dice por ahí:

Twitter


Fotos

www.flickr.com
angel.medinilla fotos Más fotos de angel.medinilla
Cerrar
Enviar por Correo