Pregunta 1

RCA (Root Cause Analysis).

Análisis de Causa Raíz (ACR o RCA en sus siglas en inglés) es un método para la resolución de
problemas que intenta evitar la recurrencia de un problema o defecto a través de identificar sus
causas.

Existen varias medidas efectivas (métodos) que abordan las causas raíz de un problema, Por lo
tanto ACR es un proceso reiterativo y una herramienta para la mejora continua.

Esta metodología es usada normalmente en forma reactiva para identificar la causa de un evento,
para revelar problemas y resolverlos. El análisis se realiza después de ocurrido el evento. Con un
buen entendimiento de los ACR permite que la metodología sea preventiva y pronosticar eventos
probables antes de que sucedan

El análisis de causa raíz no es una metodología simple y definida; hay muchas herramientas,
procesos y filosofías a la hora de realizar un ACR. Sin embargo, existen varios abordajes de amplia
definición o corrientes que pueden identificarse por su tratamiento sencillo o su campo de origen:
basados en la seguridad, basados en la producción, basados en los procesos, basados en las fallas,
y basados en los sistemas.

ACR basados en la seguridad provienen del campo de los accidentes y de la seguridad y salud
laboral

ACR basados en la producción se origina en los campos del control de calidad para la manufactura
industrial.

ACR basados en los procesos es una variación de los ACR basados en la producción, pero con un
alcance que se expandió para incluir a los procesos de los negocios.

ACR basados en las fallas surge de las prácticas del análisis de fallas como se emplea en la
ingeniería y mantenimiento.

ACR basados en los sistemas es el resultado de la mezcla de corrientes anteriores, en conjunto a

ideas tomadas de campos como gestión de cambios, gestión de riesgos y análisis de sistemas.

A pesar de los distintos abordajes entre las distintas corrientes del análisis de causa raíz, todos
tienen algunos principios en común. Lo que permite definir procesos generales para realizar un
ACR.

Diagrama de Ishikawa.

El diagrama de Ishikawa, también llamado diagrama de cola de pescado, diagrama de causa-

efecto, diagrama de Grandal o diagrama causal, es un diagrama que por su estructura ha venido a
llamarse también: diagrama de espina de pez. Consiste en una representación gráfica sencilla en la
que puede verse de manera relacional una especie de espina central, que es una línea en el plano
horizontal, representando el problema a analizar, que se escribe a su derecha. Es una de las
diversas herramientas surgidas a lo largo del siglo XX en ámbitos de la industria y posteriormente
en el de los servicios, para facilitar el análisis de problemas y sus soluciones en esferas como lo
son; calidad de los procesos, los productos y servicios. Fue concebido por el licenciado en química
japonés Kaoru Ishikawa en el año 1943.

Este diagrama causal es la representación gráfica de las relaciones múltiples de causa-efecto entre
las diversas variables que intervienen en un proceso. En teoría general de sistemas, un diagrama
causal es un tipo de diagrama que muestra gráficamente las entradas o inputs, el proceso, y las
salidas u outputs de un sistema (causa-efecto), con su respectiva retroalimentación (feedback)
para el subsistema de control.

Diagramas de Flujo.

El diagrama de flujo o flujograma o diagrama de actividades es la representación gráfica de un

algoritmo o proceso. Se utiliza en disciplinas como programación, economía, procesos industriales
y psicología cognitiva.

En Lenguaje Unificado de Modelado (UML), es un diagrama de actividades que representa los

flujos de trabajo paso a paso. Un diagrama de actividades muestra el flujo de control general.

En SysML el diagrama ha sido extendido para indicar flujos entre pasos que mueven elementos
físicos (p. ej., gasolina) o energía (p. ej., presión). Los cambios adicionales permiten al diagrama
soportar mejor flujos de comportamiento y datos continuos.

Estos diagramas utilizan símbolos con significados definidos que representan los pasos del
algoritmo, y representan el flujo de ejecución mediante flechas que conectan los puntos de inicio y
de fin del proceso.

Pregunta 2
Quienes somos

La Asociación Project Management de Guatemala (APMgt) fue constituida legalmente ante

Gobernación como una entidad sin fines de lucro con el objetivo de promover la Gestión
Profesional de Proyectos en Guatemala.  El Organismo Certificador IPMA de Guatemala (OCIgt)
aunque se encuentra conformado dentro de la APMgt tiene total independencia de las funciones
de la APMgt.

Certificaciones

Publicaciones
5Ws 1H: una técnica para mejorar la eficiencia de la gestión de proyectos

La gestión de proyectos puede considerarse como una actividad tecno-gerencial polivalente. La

diversidad de sus aplicaciones requiere que la gestión de proyectos sea inclusiva. Una forma de
hacerlo es ampliar su circunferencia de conocimiento mediante la integración de nuevas
herramientas y técnicas con el objetivo de mejorar la calidad de los procesos de PM y la calidad de
los productos / servicios producidos utilizando estos procesos. Sin embargo, en retrospectiva,
parece que el uso de herramientas y técnicas de gestión de la calidad no ha captado la atención
merecida de las personas que trabajan en los proyectos. Puede haber varias razones; desde
personas que carecen de conocimiento o intención (o ambos) de cómo usar la gestión de la
calidad en los proyectos, hasta un problema más sistemático de falta de integración de
herramientas, técnicas, estándares y conciencia general para que las personas utilicen técnicas de
gestión de la calidad de manera regular y efectiva.

Con la intención de desarrollar un pensamiento más profundo y proponer algunas herramientas /

técnicas nuevas, una técnica que tiene un buen potencial de uso en PM para la resolución de
problemas se llama 5Ws 1H (oa veces 5Ws 2H).

5Ws 1H (o 2H) explicado

5W significa qué, por qué, cuándo, dónde y quién. 1H (o 2H) significa cómo (y cuánto). Para
obtener una descripción detallada del origen y la historia del concepto, consulte
https://en.wikipedia.org/wiki/Five_W

Qué : Pensar en qué inicia el proceso de comprender los conceptos básicos del tema, problema o
escenario en cuestión. Se trata de un mapeo cognitivo del alcance del tema, problema o escenario.

Por qué : Preguntar "Por qué" implica aclarar por qué ocurrió el problema, el problema o la
situación en cuestión. Tiene como objetivo identificar los factores desencadenantes y racionalizar
la aparición de un problema o problema.

Cuándo : este elemento se trata de sellar la fecha y hora de la ocurrencia de un problema o

problema. Tener una comprensión del momento en que ocurrió podría ayudar a secuenciar los
factores desencadenantes y el impacto del problema o problema.
Dónde : este elemento se utiliza para señalar la ubicación o el lugar del suceso y, por lo tanto,
podría ser útil para identificar a las personas y otras cosas presentes / existentes en ese lugar que
pueden haber contribuido a la aparición de un problema o problema.

Quién : se trata de identificar a las personas que pueden tener una participación directa o
indirecta en causar o contribuir al problema o problema.

Cómo : Este elemento de la técnica se utiliza para examinar la secuencia de cosas y

desencadenantes y cómo se desarrolló el problema o asunto resultante.

Cuánto : Indica la cantidad, volumen o tamaño.

5Ws 1H (o 2H) explicado a través de un escenario basado en la gestión de proyectos .

Tomando un proyecto de desarrollo de software como ejemplo, consideramos un escenario en el

que el equipo de desarrollo ha encontrado que la tecnología que está utilizando no es totalmente
compatible con los sistemas existentes de su cliente, como se pensaba anteriormente. Entonces, el
equipo del proyecto puede considerar usar 5Ws 1H (o 2H) para comprender el problema y su
alcance.

1. Qué: el equipo puede hacer las siguientes preguntas para comprender el problema fundamental
y el alcance del problema

¿Cuál es la tecnología que estamos usando para el desarrollo de software?

¿Qué tecnologías se consideraron inicialmente para este proyecto de desarrollo?

¿Qué se sabía sobre los sistemas existentes del cliente?

¿Qué comprobaciones y verificaciones se realizaron para confirmar la compatibilidad de la

tecnología que se está construyendo y la aceptabilidad de la implementación de la nueva
tecnología en los sistemas cliente existentes?

¿Qué modificaciones / cambios (si los hay) aprobados o no aprobados se han realizado después de
las discusiones sobre compatibilidad tecnológica desde el inicio del proyecto?

¿Qué experiencia está disponible para el equipo para ayudarlos a comprender el problema de
compatibilidad?
¿Cuáles son los procesos aceptados para gestionar la compatibilidad y las sinergias tecnológicas?

¿Qué pautas o procedimientos operativos estándar (POE) están disponibles para abordar estos
problemas?

¿Qué acciones se tomaron una vez que se detectó el problema?

2. Por qué: El equipo del proyecto puede hacer preguntas de 'Por qué' para obtener una
comprensión más detallada del problema y tratar de aclarar los factores desencadenantes o
impulsores que pueden haber contribuido al problema. Algunas de las preguntas que se pueden
hacer son:

¿Por qué ha sucedido que ahora se descubre que dos tecnologías son incompatibles?

¿Por qué no se identificó este problema antes o al inicio del proyecto?

¿Por qué las tecnologías no se pueden compatibilizar?

¿Por qué los procesos de garantía de calidad no pudieron detectar el problema?

¿Por qué el equipo del proyecto o los expertos involucrados en el proyecto no pudieron detectar
el problema?

3. Cuándo: mediante el uso de preguntas de "Cuándo", los miembros del equipo del proyecto
pueden marcar la hora de los eventos y comprender las relaciones entre varios eventos que
pueden haber influido en el surgimiento del problema de incompatibilidad.

¿Cuándo se detectó el problema por primera vez?

¿Cuándo se evaluó la arquitectura / información de los sistemas cliente?

¿Cuándo se mapearon y discutieron los problemas de compatibilidad?

¿Cuándo se realizaron las pruebas de compatibilidad y se consideró aceptable la compatibilidad?

¿Cuándo se realizó una evaluación de impacto de incompatibilidad?

¿Cuándo se trató el asunto con el cliente o se informó al cliente?

4. Dónde: Al hacer preguntas de "Dónde", el equipo del proyecto puede manejar mejor la (s)
fuente (s) del problema. Algunas preguntas que se pueden hacer:

¿Dónde se encuentran los sistemas cliente?

¿Dónde se encuentran los equipos de desarrollo?

¿Dónde se encuentran los probadores / aseguramiento de la calidad?

¿Dónde se guarda la documentación sobre la compatibilidad del sistema?

¿Dónde se guarda la documentación de aprobación / gestión de cambios sobre la arquitectura y la
compatibilidad del sistema?

5. Quién: El equipo del proyecto puede hacer preguntas para identificar a las personas
involucradas en contribuir al problema. Algunas preguntas que se pueden hacer:

¿Quién es responsable de asegurar la compatibilidad tecnológica dentro del equipo del proyecto?

¿Quién es responsable de la recopilación de datos y el mapeo de los sistemas del cliente en el lado
del equipo del proyecto?

¿Quién es responsable de las aprobaciones de gestión de cambios y diseño?

¿Quién es responsable de proporcionar información sobre los sistemas del cliente y los detalles
técnicos al equipo del proyecto desde el lado del cliente?

¿Quién es responsable de supervisar las pruebas de compatibilidad y los informes?

¿Quién es responsable de la detección y escalada de problemas?

¿Quién es responsable de la lucha contra incendios y el enlace de problemas?

¿Quién detectó el problema o llegó a conocerlo primero y a quién se informó primero?

¿Quién intensificó el problema e informó a los bomberos?

6. Cómo: Para comprender la secuencia de varios eventos interrelacionados, el equipo del

proyecto puede hacer preguntas como:

¿Cómo sucedió el problema?

¿Cómo ha llevado la secuencia de eventos a la detección del problema?

¿Cómo se manejan los problemas de compatibilidad y las actividades clave identificadas en el

proyecto?

¿Cómo se preparan, comparten y almacenan las documentaciones de compatibilidad?

¿Cómo se realizan las pruebas de compatibilidad?

¿Cómo se minimiza el potencial de incompatibilidades y se obtiene una mejor comprensión sobre

la compatibilidad tecnológica?

¿Cómo se delinean los roles y responsabilidades dentro del proyecto y cómo se asegura la
rendición de cuentas?

¿Cómo se minimiza la desconexión entre los equipos del proyecto y se mantiene una
comunicación adecuada?
7. Cuánto: Una adición posterior a la técnica 5Ws 1H, este elemento se usa para medir el tamaño
del impacto. Algunas preguntas que se pueden hacer son:

¿Cuál es la pérdida estimada de tiempo y costo para el proyecto debido a la aparición de este
problema de incompatibilidad?

¿Cuánto tiempo y costo estimados se necesitan para resolver el problema?

¿En qué medida aumentan los riesgos para los objetivos centrales del proyecto debido a este
problema?

¿Qué impacto tendrá este problema en la inducción de vulnerabilidades del sistema a largo plazo,
incluso después de que se resuelvan los problemas de compatibilidad?

¿Cuál sería la pérdida para la empresa de este cliente o clientes similares debido a la aparición del
problema?