¿Por qué la gestión clásica de proyectos falla?

El entorno de negocio es cada vez más dinámico y competitivo. En consecuencia los métodos de gestión y organización del trabajo en las empresas se ven afectados. El resultado es que la gran mayoría de las organizaciones están aprendiendo y adoptando métodos ágiles. No obstante, esta transformación es un desafío para muchas de ellas.

Los 15 años dedicados a la mejora de procesos me han enseñado que las prácticas que perduran en las organizaciones son las que facilitan el trabajo diario de las personas a través de soluciones apropiadas para el contexto organizativo. La clave no está en elegir un método al que adaptarse, sino en conseguir que las personas entiendan y sepan adaptar sus procesos de forma continua.

Respecto a la gestión de proyectos y servicios, hace varios años empecé a estudiar los problemas con los que se encuentran las organizaciones tradicionales. Quise entenderlos bien, hasta sus raíces, para poder definir soluciones viables.

Este post es para todas aquellas empresas que están emprendiendo el cambio de la dirección clásica a una enfocada en la agilidad y en la eficiencia del flujo de trabajo. Lo puedes usar también como un tipo de autodiagnóstico rápido para identificar si las prácticas de Lean Kanban podrían resultar de utilidad en el contexto de tu organización.

Vamos a profundizar en las causas que provocan los impedimentos y la falta de agilidad.

Gestión PUSH

Los problemas en los proyectos y sobre todo en los grandes y de larga duración, empiezan desde la planificación. El desarrollo tradicional de los planes está basado en la hipótesis que todo ocurrirá según lo previsto en el momento de hacer el plan y el proyecto dispondría de todos los recursos (personas, datos, información, herramientas, dispositivos, etc) para realizar el trabajo planificado. Por tanto, una vez desarrollado, el plan “se empuja” a través de la organización para que las personas realicen las tareas definidas según el planteamiento aprobado.

Sin embargo, todos sabemos perfectamente que cuando un proyecto arranca, empiezan a producirse las diferencias con lo esperado. En consecuencia, el plan del proyecto se vuelve obsoleto y necesita ajustarse a la nueva situación, es decir requiere esfuerzo adicional de re-planificación.

Debido a la importancia de cumplir el plan se procura empezar los trabajos planificados aunque otros no hayan terminado al tiempo esperado. Esto produce la sensación engañosa de que se está avanzando en varias tareas. En realidad los efectos son los siguientes:

Llevar a cabo un trabajo por encima de la capacidad de las personas (el equipo) aumenta los retrasos y los sobrecostes. Además, requiere un elevado esfuerzo de re-planificación para mantener los planes. Cada vez cuando el plan cambia debido a una modificación del alcance o el rendimiento de las personas que participan en el proyecto, el jefe de proyecto tiene que re-estimar y re-alinear las tareas de su equipo, los proveedores, la logística asociada, los otros equipos vinculados (pruebas, producción, operaciones), etc. Los efectos de este tipo de gestión son numerosas urgencias, frecuentes interrupciones, demasiada carga administrativa, largo tiempo de ejecución de los trabajos, de toma de decisiones, horas extras de trabajo y re-trabajo,  y, a menudo, un cliente insatisfecho.

El único trabajo que no necesita más seguimiento es el trabajo acabado y entregado.

En resumen, la gestión tradicional (PUSH), trata de predecir la carga de trabajo con antelación y es poco flexible, sobre todo en contextos dinámicos, en los que se juntan diferentes factores de incertidumbre.

 

Confundir tiempo y esfuerzo

Es importante entregar a tiempo, sin embargo se mide y controla el esfuerzo.

Este es un error típico. Rara vez las organizaciones tradicionales recogen datos del tiempo que ha transcurrido entre empezar y terminar una tarea. Lo más habitual es que se mida y controle el esfuerzo dedicado al trabajo. Sin embargo tiempo y esfuerzo son dos medidas diferentes. Por ejemplo, si hemos tardado 7 horas para llegar de Bilbao a Madrid, no significa que hemos estado conduciendo 7 horas. O si el tiempo necesario para hacer 1 pizza es de 10 min aprox, si tenemos una cola de 3 pizzas pedidas antes, el tiempo de espera será más largo (dependiendo de la capacidad de la pizzeria).

De la misma manera, el tiempo para realizar un trabajo no es equivalente al esfuerzo que una o más personas le han dedicado.

No obstante, en la gran mayoría de los casos a la pregunta “¿cuánto tardarás en hacer ABC?” se responde “X horas”, sin tener en cuenta todas las interrupciones que se producirán inevitablemente, los imprevistos y el resto del trabajo que se tendrá que hacer en paralelo.

Y a la pregunta: “¿cuándo podemos planificar la tarea ABC?”, siempre se trata de colocar la tarea en el eje temporal y de nuevo se comete el error de suponer que mientras se está realizando este trabajo no ocurrirá nada que lo interrumpa.

Reflexiona sobre tu organización: ¿Recogéis datos para saber cuánto tiempo lleva terminar un trabajo, además del esfuerzo que se haya consumido? ¿Cuál es el promedio de Esfuerzo / Tiempo de realización?  ¿Cómo lo interpretas?

Tiempo y Esfuerzo son medidas distintas. Las dos son importantes. El tiempo para la estimación de plazo y el esfuerzo para la de presupuesto.

 

Falta de visibilidad para todo el equipo en el estado real del trabajo

Hablando de visibilidad en el estado del trabajo es habitual que los jefes de proyecto respondan “tenemos toda la información en nuestro sistema; podemos sacar un informe y conocer el estado del proyecto”.

En muchas ocasiones esto es verdad aunque generar el informe con información en tiempo real a veces requiere un esfuerzo adicional de una o varias personas, es decir no es tan fácil y rápido.

Sin embargo, si se hiciera la pregunta ¿cuál es el estado del proyecto en este momento? a cualquiera de los miembros del equipo que no sea el Jefe de Proyecto, seguramente se obtendrán tantas respuestas como personas preguntadas. Cada uno conoce el estado de sus tareas y muy poco sobre los trabajos y las dificultades que intentan resolver sus compañeros.

La falta de perspectiva por parte de todos los miembros del equipo sobre la situación actual del proyecto dificulta la comunicación y la coordinación, e impide la colaboración y la auto-organización del equipo.

Es como pedir a un equipo de futbol que jueguen un partido limitando la visibilidad de los jugadores a 1 metro alrededor de cada uno, sin que vean el campo completo en cada momento.

Reflexiona sobre tu organización: ¿Qué tiene que hacer tu equipo para que todas las personas estén al corriente sobre los problemas y los riesgos que van surgiendo en el proyecto/servicio y puedan decidir cómo resolverlos cuánto antes? Cuando surge algún imprevisto, ¿quién y cómo decide resolverlo para que afecte lo menos posible al resto del trabajo que estáis llevando a cabo como equipo? ¿Qué asegura que la decisión es correcta?

¿Qué consecuencias habéis sufrido por identificar tarde algunos problemas en los proyectos/servicios? ¿Cómo hubierais podido descubrirlos antes?

 

Falta de enfoque en hacer el trabajo fluir

El concepto de flujo de trabajo (workflow) apenas se menciona en los modelos CMMI, el estándar ISO 15504 y el método PMBoK.

El seguimiento tradicional de un proyecto controla el cumplimiento del plan. Los parámetros típicos que se utilizan son esfuerzo (estimado y actual), avance (estimado y actual) y fecha fin (estimación inicial y actual). En caso de desviaciones del plan, se analizan los problemas y se definen acciones que corrijan la desviación. Sin embargo, se hace relativamente poco o nada por hacer el trabajo fluir.

La persona responsable de resolver los problemas suele ser el Jefe de Proyecto. El resto de los involucrados apenas pueden ayudar proactivamente a su resolución debido a la poca visibilidad que tienen en el estado real de todo el proyecto y los asuntos bloqueantes.

Además el desconocimiento de las leyes de gestión del flujo de trabajo (Ley de Little, del cuello de botella, y del efecto de la variabilidad en la carga de trabajo) hace que las acciones correctivas no necesariamente resuelven los problemas correctos y por eso no siempre llevan a una entrega rápida de resultados de valor para el cliente.

Así mismo, la gestión de los riesgos es poco efectiva. Otra vez el Jefe de Proyecto es el principal responsable de revisar y abordar los riesgos. Sin embargo, para que los problemas potenciales se identifiquen a tiempo y se afronten correctamente, es necesario que todo el equipo esté atento y comunique las posibles dificultades. Para esto, de nuevo, hace falta tener visibilidad en el estado del trabajo que se está llevando a cabo.

Reflexiona sobre tu organización: ¿En promedio cuántas tareas abiertas tiene una persona de tu equipo? ¿Es factible y efectivo trabajar en todas ellas en paralelo? ¿Qué efectos observáis debido a esta organización del trabajo? ¿Qué consecuencias experimentáis debido a que algunos trabajos se extiendan mucho en el tiempo? ¿Sois efectivos en identificar trabajos/tareas bloqueados/as y en resolver rápidamente los problemas?

 

Resumen

Las principales razones por las que la gestión tradicional de proyectos y servicios falla en entornos dinámicos y de alto nivel con incertidumbre son las siguientes:

  • La gestión PUSH que trata de predecir la vida del proyecto/servicio y controla en base a esta previsión en lugar de fortalecer las capacidades del equipo de responder adecuadamente a los cambios en el contexto
  • Enfoque primordial en la medida de esfuerzo cuando el problema más doloroso es el cumplimiento de los plazos
  • Falta de visibilidad en el estado real del trabajo debido a que los problemas se identifican tarde o no se abordan correctamente
  • Falta de enfoque en hacer el trabajo fluir

El método Kanban está diseñado para resolver este tipo de problemas y mejorar la agilidad y la eficiencia de las organizaciones.

 

Teodora Bozheva
Accredited Kanban Consultant
Accredited Kanban Trainer
www.berriprocess.com

Share on facebook
Share on twitter
Share on linkedin

Comentarios cerrados.