Gestión de proyectos ABC: R para el Root Cause Analysis

Llegar a la raíz de los problemas en los proyectos

¿Qué es el análisis de la causa raíz?

El análisis de la causa raíz es un enfoque estructurado para identificar el origen causal de un problema y no sólo su efecto visible.

Tomemos un ejemplo clásico:
Tu proyecto se retrasa repetidamente. La causa superficial parece ser un retraso en la entrega de componentes. Sin embargo, un ACR profundizaría más y preguntaría, por ejemplo

• ¿Por qué se entregaron los componentes demasiado tarde?
• ¿Por qué el proveedor ha planificado muy poca capacidad?
• ¿Por qué no se realizó una evaluación de riesgos antes de hacer el pedido?

Esto te llevará de los síntomas a las causas. Y sólo cuando las conozcas podrás aplicar soluciones sostenibles para evitar problemas similares en el futuro.

El Análisis de Causa Raíz en la práctica: un ejemplo bien conocido
La explosión del transbordador espacial Challenger en 1986 se utiliza a menudo como trágico ejemplo de ACR en ingeniería. En un principio, se achacó el fallo a un «fallo de material» de las juntas tóricas en frío. Sin embargo, el análisis de la causa raíz demostró que las decisiones de la dirección y la desatención a las advertencias de los ingenieros fueron la causa real.

Por tanto, un ACR a menudo descubre causas no sólo técnicas, sino también organizativas y comunicativas.

¿Por qué es tan importante el ACR en la gestión de proyectos?

1. Evita los problemas recurrentes y ahorra así tiempo, dinero y nervios. Quien domina el ACR deja de jugar a «bombero» y se convierte en diseñador estratégico.
2. Aumenta la calidad de forma sostenible, ya que un ACR persigue una mejora sistemática en lugar de agitadas reparaciones ad hoc.
3. Refuerza el pensamiento de equipo, porque el ACR no debe utilizarse para buscar culpables, sino que es un método neutral para aprender juntos.
4. Apoya las lecciones aprendidas.

Métodos típicos de análisis de la causa raíz

1. el método de los 5 porqués

El método de los 5 Porqués es la herramienta clásica del ACR. Fue inventado por Sakichi Toyoda como parte del conocido Sistema de Producción Toyota. El núcleo del método consiste en preguntar «¿Por qué?» cinco veces para desvelar paso a paso la cadena causal de un problema y llegar así desde la superficie del problema hasta la causa real. El número cinco no es una ley, a veces bastan tres «porqués», pero a veces se necesitan siete.
El método es muy fácil de poner en práctica y por eso se utiliza a menudo en los talleres. En primer lugar, se define con precisión el problema. A continuación, se formula la pregunta «¿Por qué?» sobre el acontecimiento inmediatamente anterior. En otras palabras, la primera pregunta es por qué se produjo el problema. Luego se pregunta sobre la respuesta anterior.

Ejemplo del trabajo cotidiano en un proyecto:
Problema: El progreso del proyecto se ha retrasado
¿Por qué? La tarea A no se completó según lo previsto
¿Por qué? El empleado X no tuvo tiempo suficiente para completar las tareas
¿Por qué? Las vacaciones del empleado X no se tuvieron en cuenta en la planificación de recursos
¿Por qué? No hubo comparación con el plan de vacaciones
¿Por qué? Los planes de vacaciones no se introducen en la herramienta PM
Causa: Falta de integración de los datos de RRHH en la planificación del proyecto.

Nuestro consejo: Aunque el método sea muy fácil de aplicar, deberías llevarlo a cabo en equipo y no solo en tu mesa. De este modo, el problema se ve desde distintos ángulos y puedes identificar la causa real. Juntos también es más fácil comprobar si una respuesta es realmente la causa o si sólo proporciona una explicación parcial.

2. diagrama de ishikawa (espina de pescado o diagrama causa-efecto)

El diagrama de Isikawa es ideal para problemas complejos con varios factores influyentes. Visualiza las relaciones y las causas en categorías como

• Personas (por ejemplo, falta de habilidades)
• Máquina (por ejemplo, error de software)
• Método (por ejemplo, procesos ineficaces)
• Material (por ejemplo, cuellos de botella en el suministro)
• Entorno (por ejemplo, la política de la empresa)
• Medición (por ejemplo, KPI incorrectos)

Puedes encontrar una explicación detallada del diagrama de Ishikawa en este artículo.

3. análisis del árbol de fallos (AEF)

El análisis del árbol de fallos es una técnica analítica que procede originalmente de la ingeniería de seguridad y riesgos, pero que también presta valiosos servicios en la gestión de proyectos. El AEF muestra sus puntos fuertes sobre todo en el caso de problemas técnicos o sistémicos. Funciona con visualizaciones de puertas lógicas («Y», «O») para identificar qué combinaciones de causas conducen a un problema.

Así funciona el método:

1. Empieza por el suceso superior. Es el suceso no deseado que se va a analizar (por ejemplo, «El sistema ha fallado»).
2. A continuación, identifica todas las causas inmediatas.
3. Representa las causas con enlaces lógicos. Hay dos opciones para los enlaces:
   • Y significa que todas las causas deben producirse simultáneamente para que se produzca el acontecimiento superior.
   • O significa que una de las causas ya puede desencadenar el suceso superior.
4. Disecciona cada causa más a fondo hasta que no puedas analizarla más a fondo o el análisis posterior resulte antieconómico.

Ejemplo de un proyecto de software:
Evento principal: El servidor web ha fallado
Causas (O enlace): Defecto de hardware O sobrecarga del sistema O actualización defectuosa. Por tanto, el suceso principal puede desencadenarse independientemente por cualquiera de las tres causas identificadas.
Sin embargo, al analizar más detenidamente la causa «sobrecarga del sistema», se reconoce que las causas «tráfico elevado repentino» y «no hay equilibrio de carga activado» desencadenan el evento superior cuando se producen simultáneamente (enlace AND). Por tanto, el TLC demuestra que el problema no es sólo el elevado tráfico, sino que la falta de arquitectura de escalado es el verdadero punto débil.

Nuestro consejo: La FTA es más compleja de crear. Por tanto, debes utilizarlo principalmente para riesgos críticos o problemas con relevancia para la seguridad y el cumplimiento.

Consejos para seleccionar los métodos

Buenas prácticas

• Define el problema de forma clara y mensurable. «Retraso del proyecto» es demasiado poco específico. «La entrega A supera el plazo en 3 días» sería mejor. Para ello, fundamenta el problema con hechos, por ejemplo, desde cuándo existe, a quién afecta, qué consecuencias o síntomas provoca el problema. Esto te dará una visión global del problema y te permitirá analizar las causas con más detalle más adelante.
• Implica al equipo. Las mejores ideas suelen proceder de los empleados operativos, no sólo del director del proyecto. Implicar a tu equipo también acelera el proceso de encontrar una solución y te ayuda a reconocer causas de las que puedes haber sido responsable.
• Separa causa y responsabilidad. Un ACR no es una asignación de culpas, sino una herramienta para la mejora continua. Si lo utilizas para asignar culpas, el equipo puede mostrarse reacio a participar en el futuro.
• Documenta los resultados. Las lecciones aprendidas sólo son útiles si se pueden encontrar más tarde y se toman las medidas adecuadas basándose en ellas. Por tanto, lo ideal es que documentes los resultados del ACR en tu sistema de gestión de proyectos y crees inmediatamente las medidas necesarias.
• Deduce medidas correctoras del ACR y asegúrate de aplicarlas. Esto suena banal, pero a menudo se olvida en la vida cotidiana. Sin embargo, un análisis sin medidas es una pérdida de tiempo.
• Utiliza los análisis de causa raíz también para los éxitos, no sólo para los problemas. Estos análisis pueden contribuir al éxito de futuros proyectos.

Errores típicos con el RCA

• Detenerse demasiado pronto: La primera causa rara vez es la raíz, por lo que tiene sentido hacer más preguntas o utilizar un método adicional para llegar al fondo de las causas reales.
• No priorizar: no todas las causas son igual de críticas. Analiza el riesgo y el impacto de las distintas causas.
• No hay sostenibilidad: La documentación, las sesiones sobre las lecciones aprendidas y la gestión del conocimiento forman parte de ello.

Conclusión

El Análisis de la Causa Raíz es un enfoque metódico para llegar a la raíz de los problemas en lugar de limitarse a curar los síntomas. Los directores de proyecto que aplican el ACR de forma coherente evitan los problemas recurrentes, mejoran sus procesos de forma sostenible y refuerzan su equipo mediante el aprendizaje conjunto.

Más información sobre el software de gestión de proyectos y carteras myPARM:

¿Quiere conocer myPARM en una demostración? Entonces, ¡concierte ya una cita con nosotros!