25 agosto, 2017 piadmin

The boundaries of CCPM / Las fronteras de CCPM, Eli Schragenheim

Las fronteras de CCPM, Eli Schragenheim

Critical-Chain-Project-Management, CCPM, is the most successful and widely known application of TOC. The most striking feature of CCPM is the handling of uncertainty, and the second most striking feature is the understanding of the impact of performance measurements on the human behavior and how it affects the performance.

CCPM es la aplicación más conocida y exitosa de TOC. La característica más sorprendente de CCPM es el manejo de la incertidumbre, y la segunda es el entendimiento del impacto de los medidores de desempeño sobre el comportamiento humano y cómo esto afecta el desempeño.

I’ve put handling of uncertainty first, because adding a visual project buffer time at the end of the project is a bold statement that we do not really know the exact date when the project would finish. It is a clearer buffer than the DBR buffer, which seems like a regular lead-time attached to a chain of operations.  This concept of the project-buffer is a significant contribution to handling of “common and expected uncertainty”.

He colocado primero el manejo de la incertidumbre, debido a que el agregar un amortiguador de tiempo visual al final del proyecto es una afirmación clara de que no sabemos exactamente cuándo va a terminar el proyecto. Es un amortiguador más claro que el amortiguador de DBR (Drum – Buffer – Rope) , que parece como un tiempo de entrega normal agregado a una cadena de operaciones. Este concepto del amortiguador de tiempo es una contribución significativa de manejo de la incertidumbre común y esperada.

The famous Goldratt saying “Tell me how you measure me and I’ll tell you how I’ll behave” was coined a decade before CCPM. The realistic negative impact of performance measurements on the behavior of humans is clearly seen in the shop floor and it is even more relevant for projects, where people are the key resources.  The devastating use of multi-tasking is also derived from performance measurements that judge every project manager in isolation from all other open projects and by that force him to fight for “his project.”

El famoso dicho de Goldratt “Dime cómo me mides y te diré cómo me comportaré”, fue elaborado una década antes de CCPM. El impacto realista negativo de los medidores de desempeño en el comportamiento  de los seres humanos se ve claramente en el piso de la planta y es más relevante  en proyectos, en donde las personas son los recursos clave. El uso devastador de las multitareas también se deriva de los medidores de desempeño, que juzgan a cada gerente de proyectos de forma aislada de los demás proyectos abiertos y con ello los obligan a ir a pelear por “su proyecto”.

While CCPM is a breakthrough of huge value, one should always ask:

Mientras que CCPM es una solución de ruptura de alto valor, uno siempre debe preguntarse:

What are the boundaries of the given methodology?

¿Cuáles son las fronteras de esta metodología?

In other words, when the use of CCPM is beneficial and when certain changes have to be introduced?

En otras palabras, ¿cuándo es beneficioso el uso de CCPM y cuando hay que introducir ciertos cambios?

It all comes to checking the assumptions behind the methodology and when they are not valid.

Todo se relaciona con verificar los supuestos detrás de la metodología y cuándo no son válidos.

!Se acerca la hora!
Gerencia de proyectos con cadena crítica

Asegura el descuento por pronto pago del 20% antes del 12 de septiembre

 

Just to illustrate the point let’s think about a program to find a cure for cancer. At the beginning of such a research is it possible to give it a due-date?  Is it possible to build the network of tasks for the whole project?  Do we have any idea how long it would take?  Is there any role for a project buffer when you do not have a due-date to start with?

Para ilustrar este punto, pensemos en un programa para hallar la cura para el cáncer. ¿Al inicio de esta investigación es posible ofrece una fecha de entrega? ¿Es posible construir la red del proyecto de las tareas de todo el proyecto? ¿Tenemos idea de qué tanto va a tomar? ¿Hay algún rol para un amortiguador del proyecto cuando ni tenemos una fecha de entrega desde el inicio?

Here is my list of basic assumptions behind CCPM, which might be sometimes invalid in certain situations:

Esta es mi lista de supuestos básicos detrás de CCPM, que a veces pueden ser inválidos en determinadas situaciones:

  1. We have a good enough idea how to perform the project from start to finish.
    • In particular, we have a good idea, from the start of the project, what features have to be developed.
    • We do not have conditional points in the project that could dramatically change the downstream operations or go backwards to an earlier task.
  2. Completing the project before or at the due-date is of utmost importance.
  3. Finishing on-time is nicely correlated to meeting the specifications and budget.
  4. The control on the progress and its timing issues are at our hands.
  5. We plan to work continuously on the critical chain.  Without that the definition of the critical chain as what determines the duration of the project is meaningless.

 

  1. Tenemos una idea suficientemente buena de cómo realizar el proyecto desde el inicio hasta el final.
    1. En particular, tenemos una buena idea, desde el inicio del proyecto, de las características que hay que desarrollar.
    2. No tenemos puntos condicionales en el proyecto que puedan cambiar dramáticamente las operaciones siguientes o devolvernos a una tarea anterior.
  2. Completar el proyecto antes o en la fecha de entrega prometida es de la mayor importancia.
  3. Terminar a tiempo está altamente correlacionado con cumplir con las especificaciones y con el presupuesto.
  4. El control del progreso del proyecto y los temas de ser oportuno están en nuestras manos.
  5. Planeamos trabajar continuamente en la cadena crítica. Sin ello la definición de la cadena crítica como lo que determina la duración del proyecto no tiene sentido.

 

What happens when one or more of the basic assumptions are not valid?

¿Qué sucede cuando uno o más de estos supuestos no son válidos?

Let’s view two examples:

Miremos dos ejemplos:

Suppose the client has to confirm certain stages in the project, and the client takes his own time to confirm. Two assumptions are not valid: the fourth and the firth. The fourth is invalid because we do not have the means to force the client to adhere to our timetable.  The fifth is invalid as the whole project is in hold during the client’s check. One might include the client’s task in the planning and assume a certain 50% time for that task. The point is – when the client delays the signal to go ahead how can the project people keep the due-date?

Supongamos que el cliente tiene que confirmar determinadas etapas en el proyecto, y el cliente se toma su tiempo en confirmar. Hay dos supuestos que no son válidos: el 4 y el 5. El 4 es inválido debido a que no tenemos los medios para forzar al cliente a que se ajuste a nuestro cronograma. El 5 es inválido dado que todo el proyecto está detenido mientras que el cliente revisa. Uno puede incluir la tarea del cliente en la planeación y asumir cierto 50% de ese tiempo para esa tarea. El punto es – Cuándo el cliente atrasa la señal para seguir avanzando ¿cómo puede la gente de proyectos mantener la fecha de entrega prometida?

My recommendation for such a case is to cut the overall project into subprojects. The project team controls the progress until the client gets the output for confirmation and that is the completion of project one.  Once the client confirms to go ahead, even with new requirements, the second project starts.

Mi recomendación para este caso es cortar el proyecto global en sub-proyectos. El equipo del proyecto controla el progreso hasta que el cliente recibe el resultado para confirmar y ese es el final del proyecto uno. Una vez que el cliente confirma que se puede seguir adelante, incluso con los nuevos requerimientos, se inicia el segundo proyecto.

Another problematic project is one where the due-date is mandatory, so no delay is possible. In such a case the content of the “complete project” might be much less than the original plan, or the costs might go up sharply, which means the third assumption is invalid. The time buffer does not protect all the truly relevant variables. The planning of such a project has to make clear distinction between “must-have” and “nice-to-have” features.  I can see a direction of solution with a buffer-of-nice-to-have-features on top of the project-buffer protecting the mandatory due-date.

Otro proyecto problemático es en donde la fecha de entrega prometida es mandatoria; así que no hay retrasos posibles. En esos casos el contenido del “proyecto completo” puede ser mucho menos que el plan original, o el costo puede subir demasiado, lo que significa que el supuesto 3 es inválido. El amortiguador de tiempo no protege todas las variables realmente relevantes. La planeación de un proyecto como éste tiene que hacer una distinción clara entre lo que “se debe tener “y lo que “es bueno tener”. Puedo ver una dirección de solución con un amortiguador de características de lo que es bueno tener al final del amortiguador del proyecto, protegiendo la fecha de entrega prometida mandatoria.

A general comment: I find CCPM as the least holistic methodology in TOC.  It is target to solve a problem that is quite common, but not necessarily the key problem of the organization.  I’m troubled by solving an undesired-effect (UDE) without seeing the overall picture.  You can improve the management of projects and the organization would not reach more of the goal.

Un comentario general: considero que CCPM es la última metodología holística de TOC. Está orientada a resolver un problema que es bastante común, pero no es necesariamente el problema clave de la organización. Tengo problemas para resolver los efectos indeseables sin ver la imagen global. Usted puede mejorar la gerencia de los proyectos y la organización puede que no logre más de su meta.

As a concluding anecdote: I met a high executive is a huge international conglomerate.  When I mentioned the nice CCPM implementation done in Israel, the executive commented: “They finished early the WRONG project!”

Una anécdota para concluir: Me reuní con un alto ejecutivo de una gran empresa. Cuando le dije de la excelente implementación de CCPM hecha en Israel, me dijo: “Terminaron a tiempo el proyecto EQUIVOCADO”

Shouldn’t TOC be involved not just in the planning and execution of the projects, but also making sure they are the RIGHT projects with the right choice of content and specifications?

¿No debería TOC involucrarse no solo en la planeación y ejecución del proyecto sino también en asegurarse que son los proyectos CORRECTOS con la correcta selección de contenido y especificaciones?

Can we do it without being involved with the Strategy of the organization?

¿Podemos hacer esto sin involucrarnos con la Estrategia de la organización?

 

Tagged: , , , , ,