El camino crítico solo “engaña” a los gerentes

camino.jpg

OK, lo confieso, soy un detractor del método del camino crítico (CPM)

La razón es que el CPM induce a enfocarse en las tareas críticas, y no en las tareas con más probabilidades de atrasarse.

En otras palabras, que una tarea pueda retrasarse un poco sin atrasar al proyecto, no quiere decir que no sea la que más probablemente termine atrasándolo, y si solo te enfocaste en las tareas del CPM estarás en problemas. En manos inexpertas, CPM es una herramienta potencialmente peligrosa.

En mi experiencia CPM si es útil a la hora de comunicar prioridades a la gerencia. Suena bien decir “deben aprobar de inmediato hacer esto o aquello porque está en el camino crítico”, y como dice crítico y está en rojo, en general la respuesta es rápida y te dan el visto bueno para proceder. El problema, y me ha ocurrido, es que la gerencia solo ve el camino crítico, y el atraso surge por otro lado.

El camino crítico solo “engaña” a los gerentes, para un PM es solo una herramienta más de planificación y comunicación.

9 comentarios en “El camino crítico solo “engaña” a los gerentes

  1. Si en el IAAP fuésemos legalistas deberíamos agregar en nuestra portada “Las opiniones de los autores de los posts en este Blog no necesariamente reflejan las opiniones del IAAP”, pero creo que no es necesario. Está buena esta idea de Adrián, y creo que merece ser analizada con más profundidad porque cuestiona una “Vaca Sagrada” de la metodología y eso es bueno en sí mismo. Yo personalmente estoy de acuerdo con gran parte de lo que dice en este post.

  2. Hola amigos, me permito disentir en este punto. Los gerentes deben ser stakeholders a favor del proyecto. Creo que si no saben, debemos educarlos, no engañarlos. Debemos se cuidadosos con esto. Si bien existe el gerente al que el PM y/o la PMO le molesta, existe el que quiere aprender y mejorar sus habilidades. Si uno se toma el tiempo de explicar que el camino crítico es importante pero no necesariamente determinante para el éxito del proyecto y también alguna técnica de mejoras para el schedule como puede ser la nivelación de recursos, cadena crítica, simulaciones y escenarios “what if?”, etc; creo que es más saludable y deja mejor parado al PM. Qué pasa si el el gerente realmente entiende sobre el tema? Qué pasa si es PMP? El PM quedará mal visto por parte de la gerencia, perdiendo credibilidad y apoyo.
    Saludos.

  3. Totalmente de acuerdo, de hecho es deber del PM informar correctamente a la organización sobre el proyecto. Lamento si se entiende lo contrario.
    El punto, (expresado de forma impactante, lo acepto), es que la herramienta CPM es potencialmente peligrosa y puede llevar a equívocos a quienes la tomen como única herramienta de planificación y control de cronograma.
    De todos modos, CPM es muy útil al momento de tener que estudiar donde reducir tiempos, y como herramienta de comunicación, en parte por ser una “vaca sagrada” como decía José. Pero creo que allí se queda, y por eso quizás deba ser complementada por técnicas tales como las que mencionabas.

  4. En mi humilde opinión creo que el post inicial tendría que replantearse ya que si una tarea tiene alta probabilidad de retrazarse seguramente habrá que afectar su duración por algún índice de riesgo y luego observar si esto no modifica el camino critico original.

  5. Efectivamente, CPM funciona muy bien como complemento de otras técnicas, por ejemplo el análisis cuantitativo de riesgos. Pero fijate que esta es una técnica mucho más moderna y sofisticada de trabajar con el cronograma que el clásico CPM.

    Una vez más se refuerza el punto inicial: CPM aplicado como única herramienta de planificación tiene serias limitaciones.

  6. Les cuento una historia real:

    Cierto día mi jefe me llama para asignarme como PM un nuevo proyecto. Cuando me informo del mismo me doy cuenta que los equipos a instalar ya habían arribado, pero la gestión de compras de los servicios de instalación y programación, como así también el relevamiento del sitio aún no se habían ni siquiera planificado.

    Cuando pregunte a mi jefe por qué había ocurrido esto me respondió: “como las tareas que mencionas no estaban en el camino crítico, no las inicié pensando asignarte el proyecto dentro de un mes y que vos lo hicieses. Pero los equipos llegaron mucho antes de lo previsto, transformando en críticas las tareas que antes no lo eran”

    Moraleja 1: el camino crítico “engaña” a los gerentes

    Moraleja 2: asigne al PM desde el momento cero

  7. Adrián:
    El artículo es muy interesante, porque muy brevemente expone el caso con claridad.
    Coincido en el concepto: el CPM no lo es todo, y es fundamental saber quiénes son los encargados de llevar a cabo las tareas que están en el CPM y fuera de él, porque el compromiso de los “stakeholders” no es el mismo, los recursos no son los mismos y por ende los riesgos no son los mismos.
    Respecto de la moraleja 2, lamentablemente (por lo menos en mi caso) algunas cosas nos vienen dadas cuando nos hacemos cargo de un proyecto.

  8. Tanto este post, como varios otros, me hacen reflexionar en que hoy, parte del trabajo del PM es ser un agente de cambio y “educar” a las organizaciones sobre la gestión profesional de proyectos.
    Oviamente esto demanda tiempo y esfuerzo adicionales por parte del PM, en especial si se está comenzando en la profesión en un ambiente donde no existía metodología de gestión.

  9. Coincido con que el CPM puede ser peligroso si “solamente” se enfocan los esfuerzos en esa tarea.
    De hecho, el CPM tiene algunas características que
    _ si le agregamos el factor riesgo, podremos llegar a un camino que quizás no sea el crítico al comienzo del proyecto, pero que probablemente se convierta en crítico, dado el impacto de los riesgos. Como comentó Marcelo, por ejemplo, utilizando herramientas para desarrollar simulaciones y escenarios “what if?” Creo que estas herramientas constituyen el complemento obligado de las planificaciones del futuro.
    _ el CPM no es estático. Creo que ejemplos de esto ya se expusieron en los comentarios anteriores
    _ ¿Cuándo una tarea es crítica? Más allá de la respuesta correcta del PMBOK, quiero enfocar en algo que parece técnico pero no lo es: MS Project puede parametrizar qué holgura le otorga criticidad a una tarea. Quizás una buena práctica para evitar la situación de “relax” sobre las tareas no críticas que comenta Adrián, pueda ser cambiar este parámetro.
    Entonces las tareas ya no serán críticas cuando tengan 0 días de demora (holgura), como es el default, sino cuando tengan, por ejemplo, 3 días, o una semana (dependiendo de la extensión total del proyecto, o de la frecuencia de las reuniones de seguimiento)

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s