Los 7 pecados capitales de un líder de proyectos de mejora continua

1-Proyecto sin un adecuado sustento estadístico que valide el problema: es común ver como muchas de las propuestas que me hacen constantemente de proyectos, para que los avale, responden a cuestiones en extremo cualitativas, pero sobre todo subjetivas. Esto no quiere decir que no debamos confiar en alguna medida en nuestros instintos, no por nada el instinto es un mecanismo evolutivo que le a permitido al ser humano mantener lecciones de vida en su “ADN” y que le permite día a día sobrevivir. Sin embargo, un aspecto clave de poder tener un buen proyecto en ciernes es precisamente que si se le plantea administrar un proyecto este claro el problema. El problema se sabe por los efectos manifiestos que tiene en los procesos, dado lo anterior deberíamos contar con estadísticas claras que den visibilidad al impacto en nuestro cliente o en nuestras utilidades de dicho problema. Le recomiendo, siempre trate de buscar esa estadística estrella, aquella que resume el efecto más significativo del problema que le están planteando resolver, si la estadística no esta clara o no existe pero hay un consenso de que existe el problema no se preocupe, le recomiendo recurrir a las técnicas de muestreo y de ahí generar su línea base; esto es fundamental, uno de los aspectos que mayor inciden en el fracaso de los proyectos que he visto en los últimos 15 años de experiencia es precisamente empezar sin un buen “porqué”. Si usted no tiene claro ese “porqué” del proyecto mejor desista de iniciar el mismo.

2-Sobredimensionar la meta del goal: cierto, lo comprendo, todos tenemos la camisa bien puesta y tenemos esa ansiedad de generar el mayor impacto en el proceso con nuestro primer proyecto de mejora, pero en general no es una buena apuesta pensar en metas que cambien radicalmente una situación que pudiera estar mal en nuestra organización. La cuestión es entender que es mejor un enfoque gradual, paso a paso, donde se pueda ir mejorando poco a poco un indicador clave de proceso a lograr cambios extremos que puedan generar eventualmente también retrocesos extremos. Sea comedido con la meta que ofrece, analice la situación con su comité de mejora si la empresa cuenta con esta figura, o al menos con un black belt de experiencia. Su sponsor es también parte fundamental de definir la meta, pero sobre todo trate de manejar la ansiedad y ofrecer metas realistas y alcanzables.

3-Ambigüedad en la definición de la meta: Si usted me conoce sabrá la importancia que le doy a tratar de evitar los proyectos de problemas “esotéricos”1. Los problemas de corte “esotéricos” les llamo a cosas que pueden ser difícilmente tangibilizables (no sé si la palabra existe, perdón RAE) o que encontrar una métrica, KPI o algo que lo mida adecuadamente pueda ser difícil. Ejemplo de esto sería cuando hablamos de la palabra “optimizar” que al fin y al cabo es demasiado ambigua o tocamos temas asociados a moral, a performance, a estética, a empatía, entre otros. No quiero decir con esto que no se puedan trabajar temas como los que anteriormente expuse, creo fervientemente que todo es medible en esta vida, sin embargo, hay que saber ser cautos en determinar métricas adecuadas, al fin y al cabo tener un buen norte en el proyecto es crucial para poder llegar a buen puerto con el mismo.

4-Mal abordaje en la determinación de los factores causales: este tema es fundamental, es sumamente común encontrar etapas de medición (MEASURE) pesimamente diseñadas. Cuando enseñamos a construir el Árbol de Críticos de Calidad, tenemos en mente que la persona entienda que si vamos a tratar de resolver un problema debemos generar la estadística necesaria que sustente las razones del porque se da el problema. Es común ver arboles de críticos de calidad con más indicadores de efectos derivados del mismo problema, si el problema es mal servicio al cliente, ponemos indicadores de perdidas en ventas por clientes que ya no compran, pero eso no es la idea, la idea es definir que aspectos pueden estar generando ese mal servicio al cliente y medirlos, por ejemplo, viendo los niveles de capacitación, viendo aspectos de reclutamiento de personal, etc. Cuando usted construya su árbol de críticos de calidad empiece por plantear las posibles razones que puedan estar generando su problema, ésto no quiere decir que le este pidiendo que resuelva su problema sin haber llegado a la fase de ANÁLISIS como se debe, pero si que con base a este primer esbozo de razones usted sepa que tiene que medir. Considerar aspectos básicos como:

a. ¿Las estadísticas son confiables?

b. ¿Las muestras son representativas y generadas adecuadamente?

c. ¿Son las poblaciones normales para poder aplicar tratamientos estadísticos basados en teoría de la normal?

d. ¿Estoy aplicado adecuadamente las diferentes pruebas estadísticas?

e. ¿Qué cuestiones puedo hacer ante escenarios de poblaciones no normales?

f. ¿Son estas métricas la manifestación de las causas que generan el problema?

5-Aplicación incorrecta de las técnicas de causa raíz: olvídese que en este mundo de análisis lo único que existe es el diagrama de Ishikawa, si bien es cierto es una técnica poderosa también no es la única y puede irle mejor aplicando otras. En mi experiencia es común ver análisis de causa raíz donde el Project manajer y equipo realizan la etapa de ANÁLISIS como un ejercicio libre e independiente de la fase de medición (MEASURE) y es ahí donde esta el grave error. Me han dicho un sinfín de veces como el diagrama de Ishikawa se construyó con base a una “tormenta de ideas” y a la pregunta de, si tomó en cuenta las estadísticas del MEASURE obtengo en muchos casos largos silencios. Le quiero dar algunas pautas valiosas para hacer su fase de ANÁLISIS:

a. Si va a hacer una tormenta de ideas, hágala en MEASURE para construir un borrador de Ishikawa que le oriente a determinar que debe medir.

b. Recuerde que su Ishikawa se puede hacer en dos fases, una primera exploratoria, para con su equipo de proyecto determinar que esta generando el problema, pero inmediatamente debe tomar TODO el acervo estadístico que se supone ya recopiló en MEASURE y usar el mismo para validar o descartar causas del Ishikawa exploratorio que había hecho. Todas, absolutamente todas las causas que al final quedan en el Ishikawa deben quedar validadas y sustentadas en MEASURE, prefiera siempre Ishikawas con pocas causas raíces a “arbolitos de navidad de CEMACO” con un montón de causas pero sin sustento, además de que eso no se ve bien en un proyecto.

c. Recuerde que existen otras técnicas de análisis de causa raíz tales como la matriz de cinco porqués y el árbol lógico, excelentes técnicas que permiten ante escenarios de alta incertidumbre por la complejidad del problema, facilitar la determinación de las causas raíces. Soy fiel creyente que el Ishikawa es mejor aplicarlo cuando usted tiene un gran dominio de la situación o el proceso y si no es así mejor optar por un 5 porque que a través de su metodología de repreguntar puede facilitar establecer esa causa raíz.

6-Construir el Plan de acción con base a las causas raíces del ANÁLISIS: me es común encontrar lideres de proyectos que aunque usted no lo crea se olvidan de las causas raíz que determinaron en su fase de ANÁLISIS y plantean un Plan de Acción como otra lluvia de ideas. Dado esto le recuerdo que como expliqué al principio un buen proyecto de mejora es una acción reacción. Si usted tiene buena determinación de causas raíz en ANÁLISIS ahora plantee al menos una propuesta de mejora por cada una de esas causas raíces. No se vale dejar causas raíces huérfanas en su plan de acción, sí usted dijo que era causa raíz alguna situación en particular, y la deja por fuera del plan de acción cómo pretende usted entonces que el problema se resuelva? Siempre y en la medida que los alcances de su proyecto lo permitan debe contemplarse todas las causas raíz como acciones propuestas de mejora si lo que quiere es realmente solucionar el problema en cuestión.

7-Medir, medir, medir: y aquí no hay que inventar el agua tibia, si usted quiere saber si su proyecto generó mejora hay que remedir, y la remedición no es un ejercicio de preguntarse de nuevo que hay que medir, la respuesta a qué debo medir ya la sabemos, los CTQs, esos pequeños bichitos que tanto dolor de cabeza nos dieron en MEASURE. Definitivamente la única forma de saber si mejoramos es volver a medir los críticos de calidad y no solo en IMPROVE sino también en fase de CONTROL, no por nada una causa raíz se soluciona si no solamente aplicando nuestro plan de acción los resultados fueron los esperados sino también en el tiempo la mejora se mantiene.