fbpx

Cómo integrar Gantt y Kanban y generar más beneficios para el equipo de gestión del proyecto

Cuando pensamos en cómo gestionar un proyecto, sin duda nos viene a la cabeza la palabra planificación: crear un plan, más o menos definido, que defina cómo prevemos se debería desarrollar las tareas del proyecto y cómo y cuándo se generarán los entregables. En realidad, lo que necesitamos es un medio para comunicar la estrategia del proyecto válido para los equipos de especialistas, el cliente, la junta de proyecto, áreas departamentales y, en general, a los principales stakeholders.

Cada proyecto, necesita una estrategia de gestión

Debido a la cada vez mayor complejidad de los proyectos, en generarlos  y su posterior control,  cada proyecto debe adaptarse a las necesidades del proyecto, el entorno y las propias características de la organización que lo desarrolla. A grandes rasgos, podemos identificar una tipología de proyectos bien porque se han realizado proyectos similares o porque está definido lo que se quiere conseguir, el nivel de incertidumbre no es demasiado alto.  Un enfoque predictivo sería la mejor opción.

En contraposición, encontramos proyectos en los que se conoce la necesidad del cliente, pero no está tan claro cuál será exactamente la solución ni cómo se resolverán los requisitos ni las funcionalidades. En estos casos, la incertidumbre es alta y por tanto,  una planificación predictiva no sería demasiado eficiente y optar por enfoques más ágiles sería una mejor idea.

En otros casos, para complicar la situación, puede que nos encontremos con una mezcla de las dos situaciones en una parte del proyecto o a nivel global.

Cómo planificar

En los proyectos de consultoría en los que participa Wolf Project, cuando nos enfrentamos a la decisión de seleccionar la mejor herramienta de planificación y gestión, utilizamos este mismo  criterio y nos hacemos la siguiente pregunta: ¿Usar herramientas predictivas, tipo Gantt o usar otras  más sencillas y emergentes como flujos de trabajo y tableros Kanban?

Identificamos las claves a tener en cuenta para ayudar a seleccionar la mejor opción, describiendo los pros y contras de cada una.

En cualquier caso, generar un calendario de trabajos puede resultar fácil, pero lo realmente difícil es  que esté correctamente realizado y que sea creíble. Lo primero que debemos tener en mente es que el resultado sea creíble y realizable.

 

 

El Diagrama de Gantt

Es quizás la herramienta más conocida cuando pensamos en generar una planificación y consiste básicamente en dibujar en un calendario las actividades a realizar en el proyecto y grafiarlas con una barra, indicando cuándo se prevé que comience y termine. Puede parecer muy sencillo, pero para poder realizar una buena planificación, recomendamos tomar de ejemplo el Practice Estandard for Scheduling editado por PMI® y que es un estándar que recopila las experiencias y lecciones a tener en cuenta cuando tenemos que generar una planificación.

Otros recursos a tener en cuenta son los marcos que ayudar a determinar “la salud” de nuestro cronograma, como el 14-Point Assessment Metrics desarrollado por DCMA, Defense Contract Management Agency y que establece unos criterios para poder determinar su calidad. También podemos resaltar el modelo Deltek Acumen Fuse.

Aspectos a tener en cuenta

De cara a generar una buena planificación, os recomiendo que no os olvidéis de los siguientes aspectos:

  • La duración de la tarea. Debe basarse en los recursos disponibles –realistas-.
  • Relacionar las tareas entre sí. De forma que todas ellas deberán tener al menos, una predecesora y una sucesora.
  • Basarla en la planificación por productos. El primer paso que debemos realizar es identificar los entregables/productos que se generarán a lo largo del ciclo de vida del proyecto y, generar, por tanto, la EDT (Estructura Desagregada del Trabajo, también denominada WBS –Work Breakdown Structure-. Y sobre ésta se identificarán las actividades a planificar.
  • Seguir los procesos definidos en el PMBoK® de PMI®. En el área de gestión del tiempo del proyecto y que fundamentalmente, nos guían sobre los pasos a seguir, a saber:
    1. Planificar cómo se gestionará el cronograma del proyecto y crear el Plan subsidiario correspondiente.
    2. Definir las actividades, a partir de los entregables de la EDT. Como norma básica, los equipos de especialistas que desarrollarán el trabajo deberán participar y comprometerse con todo lo relacionado con las actividades.
    3. Relacionarlas entre sí, definiendo sus vinculaciones y generando un modelo de planificación, que, independientemente de la duración de las actividades, defina la estrategia de desarrollo del proyecto.
    4. Estimar la duración de cada actividad, identificando e indicando el tipo y número de recursos planificados.
    5. Fijar la línea base. En este último caso, y a partir del modelo generado, se deberá re-analizar todos los parámetros anteriores, identificar el camino crítico e identificar los escenarios que permitan cumplir las exigencias de tiempo, combinando adecuadamente los costos incurridos y el nivel de riesgo. El objetivo es asegurarnos que, de todas las posibilidades, elegimos la más eficiente y con un nivel de riesgo adecuado. Os invito a leer este artículo para conocer más: ¿Y si planificasen los robots?

Así, una planificación realizada con un Gantt debería tener un aspecto similar al siguiente esquema realizado con el open software Project Libre:

*Planificación realizada con Gantt con el open software Project Libre

 

Esta planificación, tiene todas las características que hemos hablado. Además, la planificación por productos permite ir “abriendo” y “cerrando” las tareas de los diferentes paquetes de trabajo, entregables o fases, simplificando la gestión. Así podemos generar una vista a alto nivel del proyecto. Muy útil para reportar a los niveles directivos y al cliente del proyecto.

 

 

*Vista a alto nivel del proyecto

En la vista WBS se identifican los entregables del proyecto, estructurados de forma jerárquica:

*Vista WBS

El tablero Kanban

Si tenemos muchas tareas y queremos tenerlas controladas adecuadamente y el cronograma actualizado, el esfuerzo necesario va a ser muy importante y podemos caer en el error de dedicar más tiempo a la “herramienta” que al trabajo a realizar. Además, si el nivel de incertidumbre es alto y se prevén muchos cambios, el mero hecho de mantener actualizado el cronograma a un nivel de detalle pequeño es todo un reto y su eficacia, discutible.

Cuando esto sucede, podemos emplear un enfoque diferente, más basado en la comunicación directa entre los miembros del equipo y donde las vinculaciones se traten de una forma verbal e incluso no se indiquen, ya que el equipo será capaz de auto-gestionarse y organizarse.

La herramienta que más se está usando en estos casos y con mucho éxito, es el tablero Kanban, importado –evidentemente- de la metodología Kanban y que se usa como artefacto clave en los equipos gestionados con Scrum.

Es una simplificación de Kanban y usualmente se usa a nivel de los equipos desarrolladores o especialistas (delivery), para gestionar el trabajo a realizar en un periodo cerrado de tiempo (sprint). Se compone de los siguientes elementos (se puede ir ampliando conforme se considere oportuno):

  • TO DO: En esta columna aparecerán las actividades (productos o funcionalidades) que el equipo se ha comprometido a ejecutar durante el time box (sprint). Descompuestos adecuadamente para que se pueda gestionar al detalle deseado. Es una buena idea disponer de algunas tareas ya planificadas y que estén a la espera por si el equipo termina más rápido de lo planificado y quedase tiempo hasta el final del sprint.
  • DOING: También conocido como WIP (Work In Progress), donde se localizan las actividades que han comenzado. Una buena práctica es limitar el número de actividades comenzadas, de forma que el equipo se centre en terminar las que estén activas.
  • DONE: No se podrá pasar a esta columna hasta que no se haya terminado completamente la actividad, pudiendo establecer unos criterios para determinarlo de forma objetiva.
  • Otras: Podemos incluir muchas más columnas, algunas que son muy usadas son: testing, impedimentos, riesgos, lecciones aprendidas, etc.

Una de las ventajas de este sistema es que es visual y muy sencillo, por lo que el foco se pone en la comunicación del equipo. De ahí que para que realmente sea efectivo, hay que utilizarlo con reuniones tipo daily meetings, en las que el equipo –cada uno independientemente- expone lo que ha realizado buscando transparencia y aumentar la comunicación.

En esta reunión que no debe durarmás de 10 – 12 minutos, todos los participantes exponen lo que hicieron el día anterior, lo que van a hacer hoy y los impedimentos que encuentran para ello. De forma que todo el equipo pueda colaborar y resolver los problemas grupalmente.

Se puede realizar en modalidad física: con post-it (cada actividad es uno) que cada miembro del equipo va moviendo a través de las diferentes columnas –un momento ideal sería en las daily meetings-. También se puede hacer con software en modo digital. En estos momentos hay múltiples opciones tales como TRELLO, ASANA, MONDAY, TEAMS, JIRA,.. que pueden funcionar análogamente al mundo “físico”. En este último caso, hay que tener mucho cuidado de no eliminar o reducir las reuniones face-to-face del equipo, ya que, como hemos indicado, la comunicación es clave.

Cómo funciona

Paso1: Identificar los entregables o funcionalidades que se pretenden generar en el periodo de tiempo que se tiene por delante (sprint), para que el equipo de especialistas defina las actividades a realizar para conseguirlo, descomponiendo dichos entregables.

Paso2: Estimar las actividades. Se suelen usar técnicas denominadas light weight estimation, es decir que se estima de forma rápida y por analogía. Un método muy utilizado es el de puntos, por el cual, se define una actividad como base (todos los miembros del equipo conocen el esfuerzo necesario para conseguir realizarla –se ha realizado muchas veces antes-), y el resto de actividades se refieren a ella. De este modo, si se considera que el esfuerzo necesario será el doble, si la actividad base tiene un valor de 1, a ésta le asignaremos un 2. Y se creará el burndown chart, es una representación gráfica del trabajo por hacer en un proyecto en el tiempo muy sencillo para controlar la evolución del trabajo, una vez se inicie la ejecución del sprint.

Paso3: Antes de comenzar la ejecución, seleccionar las actividades a realizar por parte de cada miembro del equipo,  De forma que cuando comience, actualice el post-it o ticket si se realiza con software– a DOING. Cuando se finalice, podrá pasar a DONE.

Importante: priorizar de forma que las actividades situadas en la parte superior sean más prioritarias, aporten más valor al sprint, esas son las que deben realizarse primero. Y si no fuese posible entregar todo el trabajo, deberían quedar las tareas situadas en la parte inferior.

Conclusiones: La tendencia natural en la planificación de proyectos

Estamos analizando dos herramientas, o mejor dicho, dos formas de planificar muy diferentes con un enfoque también muy distinto. Pero realmente, más que tener que enfrentarlas y seleccionar una, lo que está ocurriendo es que se usan conjuntamente en un mismo proyecto para beneficio del equipo de gestión.

Esto es posible porque la  la planificación a alto  o medio nivel,  en la que se ve la totalidad del proyecto y/o fases, se puede planificar y gestionar muy eficientemente con un diagrama de Gantt, y una vez que determinamos el trabajo a realizar en una fase (si es corta) o en un sprint (entre 2 y 3 semanas), se puede usar un tablero Kanban de forma realmente eficiente y útil.

Tanto es así, que estos software de gestión de tareas, permiten a través de plug-ins, visualizar las tareas en un diagrama de barras. Y lo que es más representativo, herramientas de software potentes tipo PPM (Project and Portfolio Management) como TRISKELL permiten planificar conjuntamente con los dos enfoques, lo que nos da una idea  de cuál es la tendencia de evolución natural en la planificación de proyectos.

 

2019-10-15T13:16:43+00:00

Sobre el autor:

Ángel Nájera Pérez
PhD en Gestión de Proyectos
PMP® PRINCE2® Practitioner RMP® P3O® PMO-CP® SDC/SMC/SPOC®, Auditor ISO 21.500,
CEO Wolf Project
+34 607 147 641
angelnajera@wolfproject.es

Deja tu comentario

Los mejores artículos sobre Gestión de Proyectos

Un único mensaje al mes.
Suscribirse
close-image