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):
- Empieza las cosas cuanto antes, no las dejes para el último momento (lo que Goldratt bautiza adecuadamente como el “síndrome del estudiante”).
- Reservar una fracción de la duración estimada de cada tarea, intentando acabarla antes y posponiendo esa fracción al final del diagrama de Gantt para crear un denominado “buffe de proyecto”
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…
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.
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.
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?
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”.
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.
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.
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?.
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…
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
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…
Hola:
Sinceramente creo que el planteamiento de esta entrada fue ¿cómo puedo criticar el CCPM? Y realmente las críticas hasta ahora son deprimentes.
De ninguna manera se le quita el 50% del tiempo necesario a una tarea; sino que se hace una estimación correcta pero asumiendo que todo va a ir bien (información completa, sin interrupciones, experiencia suficiente, etc).
El concepto de “hacemos un bote con todos los margenes de seguridad y lo distribuimos según sea necesario” es incontestable.
Saludos.
Empiezas atacando y terminas proclamando la incontestabilidad de tu dogma. No sabía que habían fundado la religión del CCPM.
Y mira que he dicho “tiene sus defensores”, “a mi personalmente no me convence”, “me dejaré convencer con argumentos”…
Hola Angel:
Supongamos que tenemos 3 tareas
1.- Abrir zanja
2.- Tender cable de fibra
3.- Cubrir zanja
y que la única incertidumbre es de un 50% de probabilidades de que llueva (si llueve no se puede trabajar).
La estimación si no llueve es de
1.- Abrir zanja: 10 días
2.- Tender cable de fibra: 10 días
3.- Cubrir zanja: 10 días
¿En cuanto tiempo le dirías a los operarios que tienen que hacer cada tarea? ¿En 10 días o en 20 días?
Si les dices 20 días… ¿qué ocurre si le llueve 10 días a la tarea 2 y 20 días a la tarea 3? ¿Y si no llueve nunca?… puede que llueva todos los días el siguiente mes.
Saludos.
Si dimensionamos un buffer de 30 para unas tareas de 30, damos una fecha de finalización para dentro de 60 días, con la tranquilidad de que si lo hacemos en 30, el cliente estará contento porque entregamos en la mitad de lo que estimamos (worst case scenario), ¿No?
Ya puestos, dile que lo vas a hacer en 200, y así el cliente más contento todavía…
Lo siento, no comparto la filosofía de esconder los márgenes o barajar orquillas de posibilidades (“puede que tardemos 30, o puede que tardemos 60, ya veremos”).
Pero que sí, que vale, que yo explico CCPM en mis cursos y hablo de vigilar la velocidad a la que se consume el buffer, que es lo suyo, y que prefiero que el “acolchonamiento” sea visible en forma de buffer a que sea invisible… Ahora bien, creo que existen soluciones mejores que usan parte de CCPM y parte de otras metodologías.
Dicho lo cual, en ninguna parte del articulo digo que esto sea inutil, digo que a mí, para mí, no me convence.
Me parecen muy válidos los comentarios de nuestros colegas que postean en este blog.
Desde mi punto muy personal de vista sobre el CCPM, lo único valioso que aporta es la perspectiva con la cual se administra el proyecto, lo cual te lleva a anticipar acciones de manera natural mediante el monitoreo de los buffers.
Tengo ya 10 años de experiencia en Proyectos de TI y siendo realistas, el tema de los buffers es algo que molesta a cualquier stakeholder, en especial quienes pagan por el proyecto.
Aún si se les convenciera que es tiempo inherente en la estimación original de cada tarea, el hecho de que se le reste tiempo a las actividades estimadas y se cree un buffer de proyecto practicamente garantiza que el buffer de proyecto se va a consumir muy a pesar de las acciones que tomemos con anticipación.
Por otro lado, inevitablemente existe una RUTA CRITICA que automaticamente cambiará la fecha de fin del proyecto si una de sus actividades se retrasa. Si una actividad predecesora termina tarde, la actividad sucesora empezará tarde, a menos que se haga “fast-tracking” o “crashing” a las tareas, que en cualquier caso incrementa el riesgo de no concluir en tiempo. Aqui el CCPM intenta revertir este efecto aplicando el “empieza lo más tarde” en tareas que no tienen predecesores, y “solo una tarea a la vez y termínala lo antes posible” en tareas que si están en la CC. Esto es, incrementar la probabilidad de terminar antes o en tiempo las asumiendo que las personas, por el hecho de saber que se tiene que terminar lo antes posible, va a aprovechar el tiempo desde el principio y en efecto buscará terminar antes.
Para que esto pudiera tener éxito, se requeriría: 1) Buena información estadística. Por persona la probabilidad de que termine antes o en tiempo un tipo de tarea en específico. De esta información estadística carecemos en casi todos los proyectos durante la etapa de planeación, y limita de igual forma tanto al método de ruta crítica como a la cadena crítica.
2) Las personas solo conocen las tareas, su fecha de inicio y su prioridad, no necesariamente las estimaciones de las mismas. El pequeño problema con este tipo de gestión es que generalmente en proyectos de IT son las personas del equipo quienes dicen con mayor precisión cuánto se toma hacer cada una de las tareas, al querer pedirles que terminen dichas tareas lo antes posible generaría una resistencia a terminarlas antes, descartando la premisa del CC donde se asume que el 50% de la tareas se terminan antes y el 50% se terminan después haciendo una variabilidad total de 0 en las tareas de la cadena crítica.
3) El equipo de trabajo no debe saber de la existencia de los buffers en el proyecto, implica una resistencia para quienes se asignen en la cadena crítica a atender las tareas lo antes posible dado que ellos mismos definen las estimaciones de las tareas.
Por otro lado, el CCPM probablemente tome en cuenta el uso de los mismos recursos en diferentes proyectos, pero no resuelve los problemas de cómo producir software de alto costo (80,000 HH) y en masa, los cuales en mi opinión son los grandes retos a vencer en la industria del software.
Agradezco mucho su tiempo, espero que mis opiniones sean de su interés.
Que buen debate! estoy estudiando exactamente esto que se habla acá (el si es en realidad la gran novedad este método…) todos los aportes que he logrado leer acá me han sido de gran utilidad y en mi humilde opinion de novato me parece que lo nuevo en la administración por cadena crítica no es en sí la herramienta, sino la filosofía que está detras de ella. Es claro que antes de que la teoría de restricciones se conocian conceptos como la nivelación de recursos y la incertidumbre, pero me parece que es hasta ahora que se analiza un poco más a fondo estos conceptos.
Se renombra de ruta crítica a cadena crítica, pero en el fondo para mi es lo mismo. La única diferecia en la herramienta se da a la hora de llevar control (gestión de buffers) pero dentro del llegar y simplemente seguir una receta en la planeación a cuestionarnos la importancia del factor “ser humano” y la necesidad de mejorar continuamente se da la veradadera novedad (califiquenla relevante o no es ciertamente una novedad para la gran mayoría de APs).
Espero que el debate siga, es importante mencionar lo de las bonificaciones en lugar de los castigos…
…me gusta este debate y aunque no soy muy bueno expresando lo que tengo en la cabeza espero que por lo menos se entienda lo que escribí! jeje!
Por si a alguno le interesa, estoy traduciendo una EXCELENTE forma de saber que lo que dice el libro es cierto… con cientos de gerentes de empresas que ha utilizado el CCPM y ha mejorado MUCHISIMO su rendimiento! Creer o reventar (como decimos en Argentina) Pero qué mejor que distintas empresas (con productos que varían desde la construcción de aviones a la construcción de piezas de autos) que avalan esta teoría, no?! A mí me sorprendió y realmente es algo que no dudaría en utilizar si tuviera un negocio para el cual sirviera el dato!
saludos
Hola a todos. Me dedico a implantar CCPM y me parece que gran parte de lo que nos lleva a criticar CCPM es porque se identifica CCPM con el libro de Cadena Crítica de Eli Goldratt. ¡Y la realidad es más dura de lo que parece! El otro día un cliente nuestro presentó una planificación realizada con CCPM (la primera de la compañía) y le pusimos un 20% de Project Buffer y solo un 10% de Feeding Buffer ya que si no alargaba demasiado el plan del proyecto. Al finalizar la presentación uno de los directivos de la empresa me preguntó: ¿Según tu experiencia, si solo le habéis puesto un 20% de PB y un 10% de FB, qué probabilidad hay de cumplir ya que en teoría siempre hablamos de un 50% de Buffer? Ante todos los presentes le tuve que decir la verdad: Esta pregunta no tiene respuesta. Depende de su hemos conseguido Focus Duration (duración sin protección) pero sobretodo depende de si el seguimiento se realiza adecuadamente y se aprovecha la información que proporciona el sistema para tomar decisiones.
Pingback: Libro: Cadena Crítica - Eliyahu M. Goldratt (y III)