¡Prueba gratis myPARM ProjectManagement!
Logotipo Parm AG
M
Your registration could not be saved. Please try again.
Your registration was successful. Please check your mailbox and confirm your registration.

Register for testing now!

M

El ABC de la gestión de proyectos: R de «Root Cause Analysis»

Abordar los problemas de los proyectos desde la raíz

ABC de la gestión de proyectos: R de «Root Cause Analysis»

Los problemas en la gestión de proyectos son como las malas hierbas. Puedes cortar las hojas y tratar así los síntomas, o bien arrancarlas de raíz. Aquí es precisamente donde entra en juego el análisis de la causa raíz (RCA). Te explicamos en qué consiste, por qué merece la pena el esfuerzo y cómo los jefes de proyecto pueden aplicar el RCA de forma práctica.

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

El análisis de la causa raíz (Root Cause Analysis) es un enfoque estructurado para identificar la causa real de un problema y no solo sus efectos visibles.

Pongamos un ejemplo clásico:
Tu proyecto lleva varios retrasos. La causa aparente parece ser un retraso en la entrega de los componentes. Sin embargo, un análisis de causa raíz (RCA) iría más allá y preguntaría, por ejemplo:

  • ¿Por qué se entregaron los componentes tan tarde?
  • ¿Por qué el proveedor no calculó bien su capacidad?
  • ¿Por qué no se hizo una evaluación de riesgos antes de hacer el pedido?

Así es como pasas de los síntomas a las causas. Y solo cuando las conozcas podrás poner en práctica soluciones duraderas para evitar problemas similares en el futuro.

El análisis de la causa raíz en la práctica: un ejemplo conocido
La explosión del transbordador espacial Challenger en 1986 se suele citar en ingeniería como un trágico ejemplo de RCA. Al principio, se achacó el fallo a un «fallo del material» de las juntas tóricas debido al frío. Sin embargo, el análisis de la causa raíz reveló que las decisiones de la dirección y el hecho de ignorar las advertencias de los ingenieros fueron la verdadera causa.

Así que un RCA a menudo no solo pone de manifiesto causas técnicas, sino también organizativas y de comunicación.

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

  1. Evita que se repitan los problemas y, así, ahorra tiempo, dinero y nervios. Quien domina el RCA deja de hacer de «bombero» y se convierte en un diseñador estratégico.
  2. Mejora la calidad de forma sostenible, ya que un RCA se centra en la mejora sistemática en lugar de en reparaciones apresuradas y puntuales.
  3. Fomenta el espíritu de equipo, ya que el RCA no debe usarse para buscar culpables, sino que es un método neutral para aprender juntos.
  4. Fomenta las lecciones aprendidas.

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

1. El método de los 5 «por qué»

El método de los 5 «por qué» es el clásico entre las herramientas de RCA. Lo inventó Sakichi Toyoda como parte del famoso Sistema de Producción de Toyota. La esencia del método consiste en preguntarse «¿por qué?» cinco veces para desentrañar paso a paso la cadena causal de un problema y así llegar desde la superficie del problema hasta la causa real. El número cinco no es una regla fija; a veces bastan tres «¿por qué?», pero otras veces se necesitan hasta siete.
El método es muy fácil de aplicar y, por eso, se usa mucho en los talleres. Lo primero es definir el problema con precisión. A continuación, se plantea la pregunta «¿por qué?» respecto al suceso inmediatamente anterior. Es decir, primero se pregunta por qué surgió el problema. Después, se formula la pregunta sobre la respuesta anterior.

Ejemplo de lo que pasa a diario en los proyectos:
Problema: el avance del proyecto va con retraso
¿Por qué? La tarea A no se completó según lo previsto
¿Por qué? El empleado X no tuvo tiempo suficiente para hacer las tareas
¿Por qué? En la planificación de recursos no se tuvo en cuenta las vacaciones del empleado X
¿Por qué? No se hizo ninguna sincronización con el calendario de vacaciones
¿Por qué? Los planes de vacaciones no se introducen en la herramienta de gestión de proyectos
Causa: falta de integración de los datos de RR. HH. en la planificación del proyecto.

Nuestro consejo: aunque el método sea muy fácil de poner en práctica, deberías hacerlo en equipo y no tú solo en tu mesa. Así podréis analizar el problema desde diferentes perspectivas e identificar la causa real. Además, juntos es más fácil comprobar si una respuesta es realmente la causa o si solo ofrece una explicación parcial.

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

El diagrama de Ishikawa es ideal para problemas complejos con varios factores que influyen. Permite visualizar las relaciones y las causas en categorías como:

  • Factores humanos (p. ej., falta de habilidades)
  • Máquina (p. ej., fallos de software)
  • Método (p. ej., procesos ineficientes)
  • Material (p. ej., problemas de suministro)
  • Entorno (p. ej., política de la empresa)
  • Medición (p. ej., KPI erróneos)

En este artículo encontrarás una explicación detallada del diagrama de Ishikawa.

3. Análisis de árbol de fallos (FTA)

El análisis de árbol de fallos (Fault Tree Analysis) es una técnica analítica que tiene su origen en la ingeniería de seguridad y riesgos, pero que también resulta muy útil en la gestión de proyectos. El FTA destaca especialmente cuando se trata de problemas técnicos o sistémicos. Funciona con representaciones de puertas lógicas («Y», «O») para identificar qué combinaciones de causas provocan un problema.

Así funciona el método:

  1. Empieza por el «evento principal». Se trata del suceso indeseado que hay que analizar (por ejemplo, «El sistema ha fallado»).
  2. A continuación, identifica todas las causas inmediatas.
  3. Representa las causas mediante relaciones lógicas. Hay dos opciones para las relaciones:
    • «Y» significa que todas las causas deben darse a la vez para que se produzca el evento principal.
    • O significa que basta con que se produzca una sola de las causas para que se desencadene el evento principal.
  4. Desglosa cada causa hasta que no puedas profundizar más o hasta que seguir analizando resulte poco rentable.

Ejemplo de un proyecto de software:
Evento principal: el servidor web ha fallado
Causas (operador «O»): fallo de hardware O sobrecarga del sistema O actualización defectuosa. Así pues, el evento principal puede desencadenarse de forma independiente por cualquiera de las tres causas identificadas.
Sin embargo, al analizar más a fondo la causa «sobrecarga del sistema», se observa que las causas «aumento repentino del tráfico» y «no hay equilibrio de carga activado», cuando se producen a la vez (operador «Y»), desencadenan el evento principal. Así pues, el FTA muestra aquí que el problema no es solo el alto tráfico, sino que la falta de una arquitectura escalable es el verdadero punto débil.

Nuestro consejo: Elaborar un FTA lleva bastante trabajo. Por eso, te recomendamos que lo uses sobre todo para riesgos críticos o problemas relacionados con la seguridad y el cumplimiento normativo.

Consejos para elegir un método

Método

Ámbito de aplicación

Ventaja

Método de los 5 «por qué»

Identificación rápida de la causa en problemas bien definidos

Es sencillo, no hace falta ninguna herramienta

Ishikawa

Problemas complejos con varios factores que influyen

Visualización clara

FTA

Problemas técnicos y de sistema, evaluaciones de riesgos

Estructuras lógicas detalladas, relación precisa entre causas

Buenas prácticas

  • Define el problema de forma clara y cuantificable. «Retraso en el proyecto» es demasiado impreciso. Sería mejor decir «La entrega A se retrasa 3 días respecto a la fecha límite». Para ello, respalda el problema con datos concretos, por ejemplo, desde cuándo existe, a quién afecta y qué consecuencias o síntomas provoca. Así obtendrás una visión completa del problema y podrás analizar las causas con más detalle más adelante.
  • Involucra al equipo. Las mejores ideas suelen venir del personal operativo, no solo del responsable del proyecto. Además, involucrar a tu equipo acelera la búsqueda de soluciones y te ayuda a ver también las causas de las que tú mismo podrías haber sido responsable.
  • Separa la causa de la responsabilidad. Un análisis de causa raíz (RCA) no sirve para buscar culpables, sino que es una herramienta para la mejora continua. Si lo usas para echar la culpa a alguien, puede que el equipo se muestre reacio a participar en el futuro.
  • Documenta los resultados. Las lecciones aprendidas solo sirven de algo si luego se pueden consultar y se toman las medidas adecuadas basándose en ellas. Lo ideal es que documentes los resultados del análisis de causa raíz (RCA) en tu sistema de gestión de proyectos y que, desde allí, crees directamente las medidas necesarias.
  • Saca conclusiones del RCA y toma medidas correctivas, y asegúrate de ponerlas en práctica. Suena trivial, pero a menudo se olvida en el día a día. Sin embargo, un análisis sin medidas correctivas es una pérdida de tiempo.
  • Aprovecha los análisis de causas también cuando las cosas salgan bien, no solo cuando haya problemas. Estos análisis pueden ayudarte a llevar a cabo con éxito proyectos futuros.

Errores típicos en el RCA

  • Parar demasiado pronto: la primera causa rara vez es la raíz del problema, así que tiene sentido seguir preguntando o usar algún método adicional para llegar al fondo de las causas reales.
  • No establecer prioridades: no todas las causas tienen la misma importancia. Analiza el riesgo y el impacto de las distintas causas.
  • Falta de sostenibilidad: la documentación, las sesiones de «lecciones aprendidas» y la gestión del conocimiento forman parte de ello.

Conclusión

El análisis de la causa raíz (RCA) es un enfoque metódico para abordar los problemas desde la raíz, en lugar de limitarse a tratar los síntomas. Los jefes de proyecto que aplican el RCA de forma sistemática evitan que los problemas se repitan, mejoran sus procesos de forma sostenible y fortalecen a su equipo a través del aprendizaje conjunto.

Con el software de gestión de proyectos myPARM ProjectManagement, puedes documentar los resultados de tu análisis de causas raíz (RCA) de forma estructurada directamente en el sistema. Las tareas, los análisis de causas, las medidas correctivas y las responsabilidades se pueden vincular entre sí, por lo que están disponibles en cualquier momento. Así, las lecciones aprendidas se pueden poner realmente en práctica, en lugar de quedarse acumulando polvo en unas carpetas.

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

¿Quieres conocer myPARM en una demostración? Entonces, ¡concierta ahora una cita con nosotros!

Your registration could not be saved. Please try again.
Your subscription was successful. Please check your mailbox and confirm your registration.

Newsletter

Subscribe to our monthly newsletter and stay informed about Parm AG products, news, trends in project management as well as offers and events.