Tenemos el proyecto en marcha, con una estrategia de comunicación bien definida capaz de acelerar el avance del proyecto cuando lo necesitemos. Es momento ahora de ver cómo podemos gestionar la incertidumbre para evitar sorpresas. Porque, como he explicado en lecciones anteriores, los proyectos están vivos y puede comportarse de una manera devastadora. Por eso, siempre suelo tener en cuenta estas reglas que veremos en esta lección del curso de gestión de proyectos.
Como consultor independiente, uno tiende a ver patrones de comportamiento en el funcionamiento de las empresas por las que pasa. Al margen de su sector, de su complejidad o de su contenido, las mismas situaciones y comportamientos se repiten en una y otra empresa dando origen a los mismos problemas, haciendo que todos los gestores de proyectos se enfrenten con problemas similares al planificar proyectos.
En el sector de consultoría y de Corporate Management, existen multitud de metodologías de gestión de proyectos como Lean, Six Sigma, técnicas BPM Design thinking, Scrum, Kanban y otras muchas técnicas. Todas ellas, se centran en corregir el factor humano sin embargo, solemos dejar de lado el hecho de que muchas situaciones imprevistas en la gestión de proyectos no se deben siempre a errores humanos, sino que responden a características intrínsecas de todos los proyectos como entidad.
Limitar la gestión de proyectos a técnicas de gestión es como limitar la carrera de medicina al estudio de herramientas médicas, en lugar de el cuerpo humano, o limitar la carrera de ingeniería al estudio de materiales y maquinaria, en lugar de las leyes de la física.
Índice
Ten en cuenta la visión sistémica de proyectos
Podemos entender qué es un proyecto, y cómo se comportan los flujos de trabajo a la hora de planificar proyectos, si no pensamos en ellos como una sucesión de tareas con un objetivo común. Si los vemos como entidades propias y desvinculadas de su contexto, de su contenido, de sus objetivos y de sus recursos, podremos ver cómo, independientemente de las herramientas que utilicemos, existen una serie de características comunes que nos permiten prever su comportamiento y gestionarlos en base a nuestras necesidades.
Fue el biólogo Ludwing Bertalanffy quien en 1969 formuló por primera vez la teoría general de sistemas según la cual, un sistema es una entidad formada por dos o mas partes pero que no puede ser dividida entre partes independientes. Dicha teoría puede explicar el comportamiento de los organismos como sistemas, pero también puede explicarnos el comportamiento de un coche, el de un ordenador, el del gobierno de un país o incluso el de cualquier proyecto. De hecho, Rusell Ackoff fue uno de los pioneros en la utilización de la teoría de sistemas aplicado a la toma de decisiones estratégicas militares y posteriormente en el mundo de la gestión empresarial.
Primera regla de comportamiento:
el proyecto es un sistema
Si entendemos un proyecto como un sistema, y una actividad como una de las partes que lo forman, la teoría general de sistemas nos dice que:
Ninguna de las actividades de un proyecto tiene un efecto independiente en el mismo. El efecto de cada actividad en el proyecto, depende de lo que estén haciendo el resto de las actividades.
He visto en numerosas ocasiones cómo a mitad de un proyecto el Project Manager (PM), tras recibir el feedback de algún técnico reportando un imprevisto, decide retocar parte de su planificación. Tras abrir el complicado Gantt en su herramienta de gestión de “proyectos”, prolonga la tarea un par de semanas y ajusta alguna otra duración, escogida en base a su experiencia previamente a sumar los costes correspondiente a su informe de gastos. Éste es una aberración muy instaurada en gestión de proyectos que explica por qué el PM no será capaz de terminar el proyecto dentro de lo acordado, por qué dedicará su tiempo a apagar fuegos, y traspasará las consecuencias de su incompetencia al resto del equipo.
En estos casos no se trata de un problema a la hora de planificar proyectos, puesto que es normal que los proyectos evolucionen y cambien. El problema es que, en contra de las características de comportamiento de los sistemas, el Project Manager espera causar un impacto global en el proyecto a través de cambios puntuales. Para hacer las cosas bien debería haber aplicado una solución sistémica, a través de herramientas capaces de visualizar y medir las relaciones entre las actividades, más allá de su experiencia personal.
Os cuento un caso que me pasó hace unos años:
Hace unos años trabajé en el desarrollo de una innovador sistema médico que utiliza la luz para solventar unas dolencias médicas. A mitad del proyecto se decidió cambiar su diseño estético y apostar por un acabado con una pintura arenosa al tacto. Llevamos a cabo técnicas de análisis para medir el impacto del cambio de acabado, aparentemente sencillo, y nos dimos cuenta de que el nuevo acabado requería un cambio de material y, el ser la carcasa responsable de filtrar la luz, descubrimos que no solo era necesario modificar el diseño de la carcasa, sino que también debíamos cambiar la luminaria, re-diseñar por completo el reloj que debía verse a través de ésta, reestructurar el ensamblaje del producto para el nuevo diseño e incluso modificar el embalaje.
Además, a nivel de proyecto no solo tuvimos que alargar la tarea de definir el nuevo material, también tuvimos que añadir muchas actividades para nuevas piezas, re-diseñar el flujo de trabajo del proyecto, asignar más recursos, cambiar de proveedores, re-definir la fecha de lanzamiento, se incrementaron sus costes, se reajustó su plan de marketing, se cambiaron las proyecciones de ventas para compensar la nueva inversión e incluso se tuvo que incrementar su producción.
Todo ello, junto con su impacto en otros proyectos. Se evaluó si continuar o eliminar el proyecto y, sólo después de conocer todas las implicaciones se procedió a tomar una decisión.
Si el cambio de material inicial se hubiese planeado como una intervención puntual en una actividad, las consecuencias de esa decisión nos hubieran golpeado de improvisto y muy posiblemente no hubiésemos tenido capacidad para corregir el resto de cosas y terminarlo a tiempo. La teoría de sistemas nos dice que la forma en la que cada actividad individual afecta al proyecto depende de todas las demás actividades, y no a sí misma. Y gracias a que el proyecto se gestionó de manera sistémica y medimos esas relaciones, terminó siendo un éxito.
Este comportamiento de los sistemas también nos indica que cuando en un proyecto se optimiza de forma independiente cada una de sus actividades, el proyecto no tiene por qué optimizarse en su conjunto, sino que tiende a empeorar.
Definamos por ejemplo el tiempo, el equipo, los costes y el flujo de trabajo como las propiedades importantes básicas que intervienen al planificar proyectos, la teoría de sistemas nos dice que mejorando la misma propiedad de cada una de las actividades del proyecto, no tiene por qué mejorar esa actividad a nivel de proyecto.
Centrémonos, por ejemplo, en la duración como una propiedad tanto del proyecto como de cada una de sus actividades que lo forman. A priori podríamos pensar que al acortar todas las actividades del proyecto deberíamos acortar la duración del proyecto, sin embargo tal y como nos indica la teoría general de sistemas u otras técnicas de planificación más instauradas, como el método del camino crítico o CPM (Critical Path Method), no funciona de esta manera.
Nota: el Camino Crítico es la sucesión de actividades que marcan el final del proyecto, definidas por las duraciones y relaciones de todas las actividades del proyecto, teniendo en cuenta también sus fechas fijas.
Ejemplo de camino crítico de un proyecto
La realidad es que si prolongamos una actividad dentro del camino crítico de nuestro proyecto, lo mas posible es que nuestro proyecto se prolongue en consecuencia. Sin embargo, si prolongamos una actividad que no se encuentre en nuestro camino crítico, la duración total del proyecto no tiene por qué verse afectado en absoluto.
Esto es debido a que como bien demuestran técnicas CPM, la duración de un proyecto depende tanto las relaciones entre las actividades como de su duración.
Ejemplo: al construir una casa podemos pensar que debido a su importancia, construir los cimientos puede ser parte del camino crítico, sin embargo al aplicar técnicas CPM no sería extraño descubrir que en realidad lo sean otras aparentemente menos importantes, que se realizan en paralelo, como conseguir un determinado permiso, traer una excavadora, construir un muro de contención o pre-fabricar las paredes.
Segunda regla de comportamiento:
hay un camino directo o indirecto
Otra regla de comportamiento de los procesos que podemos extraer de la teoría general de sistemas, nos dice que entre todas las partes del proyecto hay un camino directo o indirecto.
Esta es en mi opinión, una de los comportamientos más interesantes dado que si podemos medir y visualizar las relaciones entre las actividades, podemos definir por completo el flujo de trabajo óptimo para cada proyecto.
Ejemplo: si queremos abrir un restaurante, el objetivo de alguna de las actividades del proyecto ha de ser el de obtener una licencia de apertura. Dicha licencia es el output la actividad del proyecto en la que se genera y es, a su vez, necesaria como input para muchas otras actividades como puede ser su apertura o la inauguración del local, dado que obviamente no podemos abrir sin haber recibido la licencia.
Haciendo el ejercicio de ‘mapear’ los objetivos de cada actividad y su posterior empleo en otras actividades, podemos determinar la relación directa e indirecta entre todas las actividades del proyecto. Al ‘mapear’ estas relaciones con técnicas PERT (Project Evaluation and Review Techniques), podemos determinar el flujo de trabajo óptimo para cada proyecto.
Esto es un diagrama de PERT
Además, podemos demostrar, tal y como avanza la teoría de sistemas, que la relación entre las distintas actividades de un proyecto, vienen definidas por el flujo de sus entregables. Esto se cumple también a un nivel superior dado que el comportamiento de una empresa es, a su vez, la relación entre las necesidades y objetivos de cada proyecto.
Gestor de tareas vs. gestor de proyectos
Me gustaría terminar con una observación al respecto de lo anteriormente explicado, que puede ser el comienzo de una solución a largo plazo, y que puede facilitar mucho nuestra labor como miembros de un equipo de trabajo.
Existen muchas herramientas en Internet que pueden ayudarnos a gestionar y planificar proyectos. Sin embargo, a la hora de elegir no debemos confundir un gestor de tareas con un gestor de proyectos.
Un buen gestor de proyectos debe utilizar herramientas sistémicas de planificación interactiva, capaces de implementar técnicas PERT o CPM que ayuden a visualizar el impacto real de cada cambio. La mayoría de las herramientas en Internet no poseen éstas capacidades, dado que requieren de un potente motor de cálculo y una complicada gestión de datos. Afortunadamente, existen herramientas de planificación interactiva y fácil manejo como Sinnaps, que permiten gestionar nuestra planificación y recursos de forma sistémica para darnos apoyo y flexibilidad en la toma de decisiones.
Por eso, antes de planificar proyectos, es indispensable plantearnos su estilo de gestión, así como sus características como sistema y las del contexto en el que vamos a llevarlo a cabo.
¿PREGUNTAS? ¡NO TE CORTES! RESPONDO A TODAS ✌
Como cada lección, iré actualizando vuestro feedback. Así que no tengas dudas en hacer comentarios o aportar momentos de vuestra experiencia, para que otros usuarios puedan salir de dudas.
Por cierto… No hace falta que seas usuario para seguir el curso, pero te animo a que pruebes gratis cuenta Bussines de la app de Sinnaps para que puedas ser más productivo y efectivo con tu trabajo. Descubre que se puede trabajar más rápido y mejor. ¡Usa el tiempo restante en lo que más te guste!
¡Hasta la próxima!
Richard de Sinnaps – Lets get things done!!
