Cómo mejorar la gestión de proyectos tecnológicos e industriales con Kanban y KMM: Los primeros pasos
En el primer artículo de esta serie, vimos las fuentes de insatisfacción habituales que encontramos en gestión de proyectos. En el segundo artículo hablamos de identificar la situación de partida y entender qué motiva la iniciativa de cambio, para hacer una propuesta, a la luz del KMM, de cómo transitar del nivel de madurez actual al siguiente.
En este artículo revisamos cuáles son los primeros pasos al poner en marcha una iniciativa de gestión de proyectos con Kanban, qué prácticas se despliegan, los resultados que pueden observarse en el corto plazo, las resistencias al cambio que emergen y los desafíos que todo esto supone para los responsables de las áreas organizativas.
Los primeros pasos
En la ejecución de proyectos industriales es habitual encontrar múltiples áreas involucradas: ingeniería, comercial, compras, logística, fabricación, postventa, etc. Análogamente en proyectos tecnológicos complejos participan áreas especializadas en conjuntos de funcionalidades o componentes de producto, que a su vez se subdividen en subáreas de negocio y tecnología.
Al poner en marcha una iniciativa de cambio, se involucra a personas de todas estas áreas, habitualmente a aquellas que por su perfil están más predispuestas al cambio y tienen una actitud más proactiva. Este grupo de personas conforma el equipo inicial de soporte a la iniciativa y asumen la responsabilidad de transmitir conocimiento y liderar el esfuerzo de cambio en sus respectivas áreas.
Los integrantes del equipo de soporte se forman en el diseño de sistemas kanban y luego realizan con el resto de sus compañeros sesiones STATIK (Systems Thinking Approach to Introducing Kanban [enlace a post STATIK]) por área o equipo, en el mejor de los casos con el acompañamiento de los coaches Kanban.
STATIK es un proceso que sirve para realizar colaborativamente el diseño inicial de los sistemas kanban, y que se repite periódicamente para ir mejorando dichos sistemas. Como parte del proceso STATIK se comentan las causas de insatisfacción internas y externas, se identifican los tipos de trabajo y sus flujos de trabajo correspondientes y se obtiene una aproximación a la demanda y la capacidad real.
En algunas empresas ya hay definidos flujogramas de proyectos que describen las fases de un proyecto, los entregables o bloques de trabajo por fase, las actividades de cada fase, y las áreas involucradas. Cuando es así, estos sirven de base para la definición de los flujos de trabajo.
Se realizan sesiones STATIK adicionales para los flujos de trabajo extremo a extremo que integran diversas áreas, por ejemplo, el flujo de producción que suele involucrar a las áreas de compras, logística, fabricación, y calidad.
A partir de los tipos y flujos de trabajo identificados, se realiza el diseño de los tableros (columnas, carriles, etc.) y las tarjetas. No hay que perder de vista que el objetivo es poder identificar rápidamente el estado de los elementos de trabajo y los posibles problemas de flujo (bloqueos, dependencias, etc.). Los elementos visuales elegidos en tableros y tarjetas han de servir a este objetivo.
Por ejemplo, el desglose de un proyecto en entregables o bloques de trabajo y sus actividades puede trasladarse al diseño de los tableros modelando las actividades como columnas. Pero si cada bloque requiere un conjunto de actividades muy distinto, el diseño final de los tableros se complica. Una opción es definir un flujo de trabajo simplificado que se puede visualizar en un tablero simple y dejar el detalle de las actividades en las tarjetas en forma de casillas de verificación o de tarjetas hija de la tarjeta que representa el bloque.
Al final se suelen tener tableros a distinto nivel para visualizar el portafolio de proyectos y el desglose de cada proyecto en sus entregables, a los que hay que añadir los tableros de área y aquellos que representan flujos extremo a extremo que suponen la integración de varias áreas, como el flujo de compras y aprovisionamiento, el de producción, etc.
Los tableros de área suelen incluir flujos para las tarjetas hija de los bloques de trabajo de los proyectos que ese área desarrolla, y también flujos para los elementos de trabajo internos que no están ligados a proyectos.
Una vez concebidos los tableros y las tarjetas a partir de los tipos y flujos de trabajo, lo siguiente es trasladar estos diseños a una herramienta Kanban (como Kanbanize), y empezar a cargar elementos de trabajo para representar la situación actual de los proyectos y de las áreas. Con todo lo anterior realizado, sólo queda empezar a gestionar el trabajo diario por esta vía.
Las primeras prácticas kanban
Visualizar el trabajo, su flujo y aquello que pone en riesgo el flujo de trabajo es la primera práctica general de Kanban, y tal como acabamos de describir la primera que se pone en marcha, pues es la que posibilita gestionar el trabajo de forma colaborativa.
En el artículo anterior establecimos que, con la ayuda del KMM, se seleccionan las prácticas que facilitan la transición de nivel o aquellas que consolidan el nivel de madurez presente. A continuación listamos las prácticas de transición y algunas de consolidación, generalizando lo que hemos observado en casos reales:
Visualizar
-
Visualización del flujo extremo a extremo de los proyectos en tableros por proyecto o multiproyecto y de las relaciones entre las tarjetas que representan el desglose de los proyectos (bloques de trabajo, componentes, módulos, etc.)
-
Visualización de los flujos de trabajo de cada equipo/área
-
Visualización de flujos extremo a extremo indirectamente relacionados con los proyectos que integran varias áreas
-
Visualización de bloqueos, defectos, retrabajos, y dependencias de otras áreas
Limitar el WIP
-
Aunque esta práctica tarda en introducirse, lo habitual es que cada área comience con límites WIP en la columna Comprometido, y un límite único para todo lo que tienen en progreso sin discriminación de actividades.
Gestionar el flujo de trabajo
-
La identificación de bloqueos y retrabajos y la gestión de las dependencias entre áreas suelen ser las primeras prácticas incorporadas
-
Luego suele venir la definición de sistemáticas y plantillas del proceso de gestión de proyectos y tiempo después la gestión explícita de la demanda y la capacidad
Políticas explícitas
-
Las políticas básicas que suelen introducirse son las políticas de arrastre, la definición de terminado, cómo se van a gestionar bloqueos, defectos, retrabajos y dependencias y qué hacer con los elementos de trabajo que están envejeciendo innecesariamente
-
En los flujos que integran varias áreas, políticas sobre cómo han de colaborar entre ellas con el fin de evitar tener que devolver trabajo o que éste quede bloqueado
-
Enseguida empiezan a incorporar criterios de priorización para decidir entre elementos de trabajo de uno u otro proyecto
-
Los tiempos de entrega suelen recopilarse automáticamente en la herramienta, pero al principio no se sabe cómo usarlos para tomar decisiones y además los datos no suelen ser de suficiente calidad
-
Más adelante, incorporan otros indicadores y analizan tiempos de ejecución y esos indicadores para tomar decisiones
Bucles de feedback
-
Las primeras reuniones que se llevan a cabo son la Reunión Kanban y la de Reposición del Flujo de Trabajo (planificación de la carga de trabajo)
-
Al principio es habitual que la reunión Kanban se haga más larga de lo estrictamente necesario. Los equipos que ya han alcanzado cierta madurez resuelven en menos de 15 minutos hablando sólo de bloqueos, cambios y en general impedimentos al flujo. Los equipos noveles dedican más tiempo a actualizar el estado del tablero, o comentar quién está haciendo qué
-
Más tarde incorporan retrospectivas o reuniones de análisis de bloqueos y retrabajos, reuniones de planificación y seguimiento del proyecto o revisiones multiproyecto
-
Para los flujos que integran varias áreas se establecen reuniones específicas de revisión del flujo extremo a extremo
Mejorar y evolucionar
-
En reuniones de retrospectiva o revisión validan si algunas de los obstáculos, encontrados al hablar de fuentes de insatisfacción en las sesiones STATIK, han desaparecido o se han atenuado
-
Más tarde se enfocan en revisar políticas que no están funcionando, analizar qué está causando los retrasos, y ponen en marcha acciones de mejorar haciendo un seguimiento de su ejecución en un tablero ad hoc
Expectativas y resultados conseguidos a corto plazo
El principal resultado que ha de esperarse con una iniciativa de cambio de este tipo es ser capaces de tomar decisiones rápidamente a todos lo niveles, lo que se traduce en que:
-
Los directores y responsables de área tendrán formas de ver el progreso de los proyectos al nivel de detalle que precisen, decidir en qué ha de concentrarse el esfuerzo de su gente, y ayudar a resolver aquello que dificulta el flujo de trabajo
-
Los responsables de área tendrán a la vista la carga de trabajo de su área y conocerán su capacidad real, podrán identificar cuellos de botella y analizar sus causas, y dispondrán de indicadores y métricas
-
Las áreas comerciales o de negocio aprenderán a configurar mejor la demanda para comprometer plazos atendiendo a la capacidad real disponible y la carga de trabajo actual, y poder responder a los clientes con mayor confianza cuándo estará listo el siguiente bloque de trabajo comprometido. Si no llegan al plazo de entrega, podrán saberlo con antelación para poder comunicarlo a tiempo al cliente
-
Los equipos de las distintas áreas aprenderán a gestionar mejor su flujo de trabajo: si hay un trabajo que se está retrasando, sabrán qué está causando el retraso, reaccionarán antes a bloqueos y cambios, entenderán cómo lo que hacen se integra con el trabajo de otros para que los proyectos progresen, y tendrán claras las dependencias con otras áreas o equipos
Por supuesto, todo lo anterior habrá de conseguirse sin perder la orientación a servicio al cliente y el alineamiento con los objetivos de negocio.
En el corto plazo, los resultados más visibles son de índole cultural: la visualización fomenta la transparencia y por tanto la confianza y la colaboración, y las reuniones promueven la comunicación que, aunque parezca extraño, en general no fluye como debería a pesar de las tecnologías que en estos días la facilitan.
Los miembros de los equipos, y los responsables de área lo expresan con frases como “por fin podemos ver algo en esta maraña de proyectos”, “parece que estamos poniendo algo de orden al caos”, “la actitud de la gente de diferentes áreas ha cambiado, ya no se echan las culpas, ahora colaboran“, “incluso aquellos que aún no participan, están deseando empezar con Kanban”, etc.
Por supuesto, lo anterior se traduce en disminución de la sobrecarga, reducción de interrupciones y tiempos de espera, menos retrabajos, y menor tiempo de ejecución.
Resistencias al cambio
No es raro encontrar resistencias al cambio que desde el primer momento se hacen notar a través de comentarios variopintos: “esto no encaja aquí, somos diferentes”, “hemos intentado con otras metodologías y no han funcionado, por qué va a funcionar ésta”, “esto va requerir mucho tiempo extra y ya estamos saturados con lo del día a día”, “vamos a tener que duplicar trabajo en nuestra herramienta y en la herramienta kanban”.
La clave para lidiar con estas resistencias, tal como describe el KMM, es plantear primero prácticas que permitan predisponer favorablemente al cambio. Visualizar para “empezar a ver“, y tener regularmente conversaciones para colaborar en la toma de decisiones es fundamental.
Reflexionar sobre los obstáculos que encuentran en el desempeño del trabajo y qué resultados o beneficios se esperan conseguir, es crucial porque nadie quiere cambiar si no ve la necesidad.
Por otra parte, parafraseando a Peter Senge, nadie se resiste a cambiar sino a ser cambiado, por eso es preciso capacitar a aquellos que hacen el trabajo para gestionar su propio cambio, son ellos quienes han de decidir cómo mejorar su forma de trabajar de forma colaborativa y consensuada.
Desafíos para los responsables
Cuando empezamos con una iniciativa de este calado, algunos responsables relatan sentirse al margen de la misma, generalmente porque no han tenido ocasión de aprender sobre Kanban y el KMM, o sobre la herramienta Kanban que se ha desplegado, y lo qué está ocurriendo no saben cómo interpretarlo. Otras veces, sienten que sus funciones van a quedar en entredicho porque los equipos empiezan a tener mecanismos para auto-gestionarse.
Estas y otras percepciones, generan respuestas emocionales que pueden desembocar en un rechazo a la iniciativa más o menos evidente, y no es sencillo deshacer el nudo gordiano que se forma cuando los equipos de un área están encantados con sus sistemas Kanban y su propio responsable está en contra.
Por supuesto, antes de llegar a tal situación, hay que asegurar la formación de los responsables, y hacerlos partícipes de reuniones donde revisar el progreso de la iniciativa y compartir el feedback que cada uno tiene del área que dirige.
Por ello pautamos reuniones de seguimiento con periodicidad mensual como máximo. Al principio la reunión es facilitada por los coaches Kanban, pero con el tiempo pasa a ser liderada por algún directivo que formula preguntas acerca de lo observado desde la última reunión, los resultados conseguidos, y cómo se está lidiando con las dificultades aparecidas.
Es importante que cada responsable de área haga por estar al tanto de cómo la iniciativa está cambiando comportamientos y relaciones internas en su área y con otras áreas, y también que esté disponible para ofrecer soporte cuando sus equipos tropiezan con impedimentos en el flujo de trabajo cuya solución requiere la intervención de alguien con autoridad para ello.
Una duda habitual es cuánto tiempo va a llevar esta iniciativa de cambio. La mejor respuesta posible es que no acaba nunca, porque su propósito es seguir mejorando continuamente, o en términos del KMM ir incrementando el nivel de madurez hacia la agilidad organizativa. Son precisos varios meses para que el impacto puede trasladarse a número y ciertas prácticas se hayan definitivamente consolidado al punto de que los participantes rechacen volver a trabajar como antes. Es baladí precisar cuántos porque depende de muchos factores: la cultura organizativa de base, la dedicación del equipo de soporte interno, la actitud de los responsables y de los miembros de los equipos, el número de equipos o áreas involucradas, etc.
Artículos relacionados:
- Primer artículo de la serie: Cómo mejorar la gestión de proyectos tecnológicos e industriales con Kanban y KMM – Introducción
- Segundo artículo de la serie: Cómo mejorar la gestión de proyectos tecnológicos e industriales con Kanban y KMM – Diagnóstico y propuesta
- Comienza el cambio con el corazón
