Análisis de las causas que nos impiden identificar las verdaderas causas de los problemas (5W)

Simplificando, las causas principales de los problemas pueden agruparse en las siguientes categorías:

• Problemas Técnicos
• Comportamiento Inadecuado
• Falta de Recursos
• Procesos mal establecidos

Están ordenadas en función de un indicador mágico: el grado de satisfacción que provocan en el Responsable de Calidad cuando es capaz de identificarlas.

Perdonadme este desfalco a la honestidad, profesionalidad y responsabilidad del Responsable de Calidad. Es una inocente ocurrencia para reflexionar sobre uno de los grandes problemas: llegar al fondo de las causas que provocan los problemas y asumir las consecuencias de tales hallazgos.

Mi intención no es desarrollar una taxonomía exhaustiva de la causa raíz, ni exponer las diferentes técnicas que pueden aplicarse para la detección y solución de problemas. En su lugar, voy a centrarme en algunos problemas típicos cuyas causas reales suelen ser mal identificadas. Estos ejemplos permitirán analizar las causas que provocan la mala identificación de las causas de los problemas.

PROBLEMAS TÉCNICOS

¿Hay algo mejor que detectar un fallo en un sistema de gestión o en el algoritmo que calcula un indicador?.

Desde la perspectiva del Responsable de Calidad, un fallo técnico es una gran noticia. La causa del problema está clara (hay un error de programación, por ejemplo), la solución también (basta corregir el error) y, analizar la eficacia, casi evidente (se prueba el sistema y se comprueba que todo funciona correctamente).

Por desgracia, ésta no suele ser la causa raíz del problema. Si lo fuera, estaríamos hablando de un fallo puntual que podría corregirse de forma inmediata sin necesidad de un plan de acciones correctoras. En consecuencia estaríamos declarando que el análisis realizado nos lleva a pensar que el problema no se va a reproducir en el futuro. Conociendo a los informáticos (y yo soy uno de ellos) esto no va a ser así.

Si profundizamos un poco más, por ejemplo utilizando la técnica de análisis de los "5 porqués", quizás lleguemos a conclusiones muy diferentes:

1. ¿Por qué ha fallado el sistema?: porque ha habido un fallo de programación en un módulo
2. ¿Por qué ha habido un fallo de programación?: porque se han realizado unos cambios recientes en otro módulo que han provocado efectos laterales que se ha transmitido al que ha fallado
3. ¿Por qué no se han controlado los efectos laterales?: porque las pruebas de integración no se realizaron de forma adecuada
4. ¿Por qué las pruebas no detectaron el problema?: porque no hubo tiempo para hacerlas de forma exhaustiva
5. ¿Por qué las pruebas no se realizaron de forma exhaustiva?: porque había que realizar la entrega a tiempo y el producto salió de sistemas demasiado tarde
6. ¿Por qué no hemos dispuesto de tiempo suficiente?: porque se planificó mal el nuevo desarrollo o porque fallaron las estimaciones o porque no había recursos suficientes o porque los programadores no están correctamente cualificados.

Un problema que se puede solucionar con un simple cambio en la programación se ha convertido ahora en un gran dolor de cabeza. ¿Despedimos a los programadores?, ¿solicitamos más recursos para el Departamento de Sistemas a sabiendas que no los van a conseguir?, ¿cambiamos la metodología de desarrollo empleada para hacerla más pesada y menos tolerante al fallo lo que supondrá la necesidad de disponer de más recursos?, ¿compramos mejores herramientas de testing para que, con los mismos recursos humanos, podamos mejorar la validación del producto?.

Todas son soluciones factibles pero todas suponen cambios importantes y planes de acción que se van a extender en el tiempo al igual que la evaluación de la eficacia. Cambiar a un programador o instalar una nueva herramienta no garantiza "per se" la mejora. Habrá que analizar el número de fallos detectados en los próximos meses, analizar cada uno de ellos, etc.

Así que, con cierta probabilidad, optaremos por planificar una formación en pruebas de sistemas, la panacea de la solución de casi todos los problemas (es un decir).

Una curiosidad, Panacea era la hija de Lampetia y Asclepio (Eusculapio para los romanos), dios de la medicina y la sanación adorado en Epidauro y en todo el Peloponeso. Su hermana más conocida es Higia de donde ha derivado el término higiene; una familia con bastante presencia en el diccionario.

COMPORTAMIENTO INADECUADO

Si no podemos encontrar algún problema técnico, siempre podemos recurrir al fallo humano:

• Ha sido un despiste
• No hay suficiente conciencia de la importancia de seguir el proceso
• No se conoce suficientemente bien el proceso que debe seguirse
• El Jefe de Proyecto ha estado dos semanas de baja

Otra gran noticia: instamos a la persona a que no sea tan despistado, planificamos una formación, una acción de concienciación o esperamos a que el Jefe de Proyecto recupere el tiempo perdido. En todos los casos, el fallo detectado puede corregirse de forma casi inmediata.

No digo que no sean acciones que haya que plantear o que puedan alegarse como causas circunstanciales, pero me temo que tampoco son la causa raíz del problema.

• ¿Por qué se ha despistado el Jefe de Proyecto?: porque no le ha dado la suficiente importancia al proceso
• ¿Por qué no le ha dado importancia al proceso?: porque no lo considera un aspecto crítico en su trabajo
• ¿Por qué no lo considera crítico?: porque no le aporta suficiente valor para dedicar los recursos necesarios
• ¿Por qué no le aporta valor?: porque el proceso o metodología no se adapta a sus necesidades
• ¿Por qué el proceso no se adapta a sus necesidades?: porque está mal diseñado

Y, nada, nos tomamos otra aspirina. Tenemos que redefinir la metodología de gestión y desarrollo de proyectos, crear nuevas herramientas de control (por ejemplo, checklists o herramientas de gestión de proyectos), planificar formaciones y acciones de concienciación. Y, finalmente, ver si con todo esto se consigue que se produzcan menos "despistes".

Por último, comentar que la baja médica no es la causa raíz de ningún problema; es un síntoma de un enfermedad mucho más grave de la que hablaremos a continuación.

FALTA DE RECURSOS

Descartados los problemas técnicos y los fallos humanos, siempre podemos investigar un poco más para ver si los recursos asignados al proyecto no son adecuados:

• Hay demasiadas bajas médicas 
• Hay demasiada carga de trabajo
• La rotación del personal es muy elevada
• La capacitación del personal no es adecuada

Fácil de nuevo. Las bajas o la carga de trabajo podemos considerarlos temas puntuales; la rotación del personal es consecuencia de la situación del mercado, no hace sino constatar la excelencia de los profesionales de la empresa tan deseados por la competencia; planteamos algunas formaciones y, en seis meses,  convertimos a un junior sin experiencia en un senior.

Tampoco ahora nos enfrentamos con una buena enumeración de causas primeras. En realidad hemos identificado algunos síntomas de una grave enfermedad que afecta a los fundamentos de la organización. Las acciones que podamos tomar para aliviarlos serán como los medicamentos para la gripe: alivian los síntomas pero la enfermedad sigue allí, latente.

Profundizando un poco más:

1. ¿Por qué no hemos entregado a tiempo?: porque ha habido rotación, bajas medicas y una carga de trabajo excepcionalmente alta.
2. ¿Por qué estos factores han afectado a la entrega?: porque no se han considerado en las estimaciones del proyecto
3. ¿Por qué no se han realizado correctamente las estimaciones?: porque el análisis de riesgos no se ha realizado de forma adecuada
4. ¿Por qué el análisis de riesgos no es correcto? porque no se han planificado acciones de mitgación eficaces

Esta línea de razonamiento no es la única, las hay mucho peores:

1. ¿Por qué no hemos entregado a tiempo?: porque carecemos de los recursos adecuados
2. ¿Por qué no disponemos de recursos?:  porque el presupuesto del proyecto no lo permite
3. ¿Por qué el presupuesto no se ha corregido?: porque de hacerlo no habríamos ganado el proyecto
4. ¿Por qué no podemos ganar el proyecto?: porque nuestros costes nos dejan fuera del mercado

El azar como causa raíz de un problema, se ha convertido, en el mejor de los casos, en una mala planificación o, en el peor, en la constatación  de la quiebra inminente de la empresa.

Concentrándonos en la primera causa, la mala planificación (la segunda requiere de un plan estratégico y un replantamiento global que afectará a todos los estamentos de la empresa) necesitaremos, probablemente, planificar un conjunto amplio de acciones, todas dolorosas (en el sentido de que requieren un gran esfuerzo para ser implementadas con éxito):

• Mejorar el proceso de análisis y control del ramp-up de recursos del proyecto (la planificación futura de la carga de trabajo estimada) que será la base para el subsiguiente análisis de riesgos
• Incluir la disponibilidad de recursos en los análisis de riesgos y asegurar que se definen acciones de mitigación incluyendo el coste, coste que debe ser asumido en el presupuesto del proyecto lo que provocará una bajada del margen operativo o pérdida de competitividad al obligar a incrementar la oferta económica
• Establecer un proceso de análisis, validación y revisión de las competencias de los equipos de trabajo de los proyectos. De este análisis deberán surgir acciones de formación (cuando el proyecto lo permita) o la solicitud de nuevos recursos
• Crear una Oficina de Gestión de Programas que garantice la disponibilidad y adecuación de los recursos en el todo momento

Todas ellas requieren un alto nivel de madurez en la organización, suponen un coste y asumir que, a veces, no podemos vender al precio que exige el mercado.

PROCESOS MAL ESTABLECIDOS

Casi todo lo expuesto anteriormente queda reflejado en una mala definición de los procesos de la organización: causas mayores.

Si un Jefe de Proyecto no da importancia a realizar un correcto análisis de riesgos, seguramente es porque no le encuentra utilidad alguna. Puede ser incompetente, pero es más probable que hayamos reducido este análisis a la selección de unos cuantos elementos de una lista definida hace años por un comité de sabios a los que luego debe asignar una probabilidad y un impacto a partir de unas escalas definidas siguiendo un proceso similar. Es un problema del proceso de estimación, no del Jefe de Proyecto.

En la elaboración del presupuesto de un proyecto debe siempre incorporarse el riesgo como un factor que incrementa el coste: se calcula el presupuesto en condiciones ideales y se aplica el factor de riesgo obtenido a los costes estimados. Aumenta el precio pero también aumenta el margen (si todo va bien) o lo aseguramos en cierta medida si hay problemas. ¿Qué va a ocurrir?. Probablemente, el Jefe de Proyecto tienda a subestimar los riesgos a sabiendas de que el cliente no aceptará una oferta económica más elevada o se vea forzado por la necesidad de obtener un cierto margen impuesto por la organización. Y esto no se puede evitar pero sí controlar. Cuando se detecta una desviación es siempre necesario analizar el plan de riesgos establecido y el grado de incertidumbre trasferido al presupuesto. Y, sobretodo, exigir responsabilidades cuando estos análisis hayan sido mal realizados o menospreciados.

Cuando no disponemos de los recursos técnicos o humanos adecuados está de nuevo fallando el proceso de estimación pero también el proceso de selección (recrutamiento) o el proceso de capacitación. También es posible que no seamos capaces de mover los recursos con la suficiente celeridad de unas áreas a otras. Probablemente no exista un proceso que nos permita conocer de forma global las necesidades de recursos a corto y medio plazo (el famoso ramp-up).

Las situaciones expuestas requieren, probablemente, la creación de una Oficina de Proyectos/Programas y la redefinición de algunos de los procesos de gestión para, entre otras cosas, hacer a la nueva oficina partícipe en ellos.

Y cambiar un proceso de forma sustancial implica, en ocasiones, un cambio cultural y, casi siempre, unos costes iniciales elevados (nuevos roles y responsabilidades, formación, etc.) que, en no pocas ocasiones, tardan en ser rentabilizados. No se puede hacer magia, los márgenes o la calidad de las entregas no van a cambiar en unas semanas. No se puede mejorar la capacitación de los equipos de trabajo con veinte horas de formación.

Una aspirina no va ser suficiente cuando el Responsable de Calidad plantea este tipo de acciones, va a necesitar una buena inyección de morfina.

LAS CAUSAS DE LAS CAUSAS

De las anteriores reflexiones podemos deducir algunas de las causas que provocan un incorrecto análisis de las causas de los problemas:

1. ¿Por qué no analizamos correctamente las causas?: porque tendemos a buscar sólo la que ofrece la solución más sencilla o inmediata.
2. ¿Por qué la facilidad o la inmediatez son factores determinantes en la selección de una solución?:  porque cuanto más sencilla e inmediata sea menos recursos deberemos dedicar a la ejecución, seguimiento y medida de la eficacia de los planes de acción. Tenemos recursos limitados y no siempre queremos o podemos asumir las consecuencias de un análisis más sincero.
3. ¿Por qué no disponemos de los recursos necesarios?: porque no resulta sencillo transmitir a la organización el coste de la "no-calidad"
4. ¿Por qué no somos capaces de transmitir el coste de la no-calidad a la organización?. Porque es complicado demostrar el Retorno de la Inversión de algunos cambios sustanciales y más aún demostrar con datos empíricos las consecuencias de no implementarlos.
5. ¿Por qué no somos capaces de justificar el retorno de la inversión?. Porque no siempre se obtendrá a corto plazo y las organizaciones suelen estar presionadas por la inmediatez, por la necesidad de obtener resultados antes de que termine el año fiscal.

Este análisis no es el único que puede realizarse pero si es sustancial. Incluye un factor humano (siempre tendremos a no buscar más problemas de los necesarios), un factor organizacional y económico (tenemos que trabajar con los recursos de que disponemos; debemos ser realistas) y un factor técnico o metodológico sobre el que se lleva décadas discutiendo: cómo justificar el coste de la no-calidad.