The idea of “root cause analysis” is deeply embedded in project management disciplines. You’ll find it in Agile, Lean, Six Sigma, Kaizen, and it’s among the many analytical techniques referenced by the Project Management Institute in their PMP body of knowledge, the PMBOK.
However, you don’t need to be a full-time project manager to make use of a root cause analysis (or “RCA”), and understanding how to approach a root cause analysis can be a powerful tool for the learning and development professional who is tasked with scoping a learning solution to a performance or business problem.
In its simplest terms, a root cause analysis is a series of steps you follow to understand what is causing a problem. In manufacturing, this could mean finding the root cause of a defect; in services, it could be identifying a gap in process which is causing an unexpected or undesired customer experience.
In either case, the root cause analysis serves to help ensure the solution that is put into place is aligned with the underlying problem: in other words, you want to make sure the actions you take to solve the problem will be effective. You want to prescribe the right solution for the problem at hand, and that starts with understanding and defining the problem at a fundamental level.
Be Responsive to your Stakeholders: Keep Asking Questions
More often than we might like, requests are made to the learning and development staff based on a problem that a stakeholder has identified, with the request to jump to a specific action plan or conclusion.
Guiding the conversation to a root cause discussion can be a means for the learning professional to establish both they and the stakeholder fully understand the problem and are fully in agreement about the desired outcome. It doesn’t necessarily have to be saying “no” to the stakeholder, but building on the ‘order’ you’ve been given.
Related Topic: Navigating stakeholder expectations and building credibility as a “trusted learning advisor” – listen to the tips shared on this episode of the AXIOM Insights podcast.
Root cause analysis is an important facet of project intake in L&D. In addition to asking questions about the desired on-the-job performance and the current status of the intended learners, it asks you to ask questions about the business strategies the learning will support, and to dig down to connect the very clear vision of an intended future state (learner and performance outcome) with concrete factors which need to be addressed to make it happen. It’s ensuring you and your stakeholders have a clear understanding of the scope, challenges and goals of your learning project, and by so doing, setting your project up to succeed.
Root Cause Analysis Frameworks, Tools and Approaches
When project managers approach a root cause analysis, one path is to gather available data to understand failures and contributing factors. These data-driven approaches can be applied to learning programs, when and if there is a sufficient amount of data available.
- Pareto chart: This structured bar chart is intended to help you identify which measures contribute to a problem most frequently, allowing you to focus interventions or solutions where they would be likely to have the greatest effect.
- Scatter diagram: When you have data and are seeking to make sense of the relationship between factors, this graphic representation can help you visually identify trends.
- Barrier analysis: Sometimes used as a rapid assessment tool, this behaviorally-focused analysis focuses on understanding how a hazard came into contact with an item of value (i.e., how the problem came to be) and what role inadequate or missing controls (rules, barriers, etc.) may have played in the process.
In learning and development, we often find the underlying data difficult to identify or access at the early stages of a performance issue; this is why developing a learning program with desired outcomes and a measurement strategy is important to being able to measure and demonstrate success.
In addition to the methods above, there are several interrogatory approaches which are useful to support root cause analysis in learning and development. We’ll explore two of them here: the fishbone diagram and the “five whys” analysis. Both of these are frameworks and guides which are centered around you asking questions — often, many questions — until you and your stakeholders are satisfied you understand the factors that have created the problem you aim to solve.
The Fishbone Diagram
While the fishbone diagram can be used in combination with a Five Whys analysis (explored further below), it is also useful as a standalone analytical tool and structure. It can be effectively used to guide a meeting with stakeholders as you begin to complete the diagram (adding detail to the ‘bones’) together.
To begin, establish the desired outcome or effect. This should clearly state the problem and what the desired future state looks like, without prescribing how you will achieve it. You will build that detail as you complete the next several steps.
Then, discuss and come to agreement about the major categories of issue that are contributing to the problem. This could be human factors, supply chain factors, rules or procedures, or equipment issues. These will become the main branches from the ‘spine’ of the fish.
For each branch, you will then examine why each cause exists. Each cause may have sub-causes, and you would represent these as sub-branches off of each branch. Continue (much as in a ‘five why’ process) until you have reached a root cause for each branch and sub-branch.
The final step in applying the fishbone diagram is to determine the relative severity or urgency of the branches and begin defining a solution for each. As with the Pareto analysis, you may find that the 80/20 rule (the “Pareto Principle”) applies here: the top 20% of causes contributing to an issue cause 80% of the damage, and addressing those causes first may help you prioritize your efforts for greatest immediate impact.
Five Whys Analysis
The structure and process of a “five whys” technique was first and famously introduced by industrialist Sakichi Toyoda — the founder of Toyota — beginning in the first half of the 20th century, and subsequently embedded as a tenet of the Toyota Production System (the inspiration for Lean Manufacturing) by industrial engineer Taiichi Ohno. It is centered around the practice of digging beyond the immediately obvious answer to a problem to make sure the (more complex, more meaningful, and otherwise obfuscated) underlying cause is understood.
By repeating why five times, the nature of the problem as well as its solution becomes clear.
The Five Whys analysis can be represented or documented by a Fishbone Diagram (as described above), or the process documented in a table, flowchart or list.
No methodology is without some shortcomings, and so when applying a Five Whys analysis, it is also important to consider the ways it can fall short.
First, it’s possible for two people to conduct a Five Whys analysis and arrive at different conclusions (a risk that can be mitigated in part by making the Five Whys process collaborative, so you and your stakeholders agree with the assumptions and conclusions you reach).
It’s also true that all problems may not require five levels of analysis (it’s possible that some issues will be resolved on the first or second level of ‘why,’ while others may require further digging in order to avoid a superficial conclusion).
In practice, it is helpful and important to make sure the answer you reach is a meaningful ‘why’ and not itself a symptom of another underlying issue. Here is an example of how a Five Whys process can lead you to identify a performance issue and a solution through training:
Hypothetical problem: Customer satisfaction ratings for a product line have fallen or are below targets.
Why #1: Why is customer satisfaction down?
Customers are complaining about broken product.
Why #2: Why are there more complaints?
The number of damaged items reaching retailers has increased.
Why #3: Why have products become more prone to damage?
A recent change to the product packaging has resulted in more damaged boxes.
Why #4: Why are the boxes getting damaged?
The new packages are being stacked too high on pallets at the factory.
Why #5: Why are they being stacked improperly?
The packing guides and training at the point of manufacture have not been updated to reflect the new packaging and pallet rules.
In each case, you would continue to ask ‘why’ until the last answer gives you information that can be used to address the problem. In the above example, it may have been convenient to stop after ‘why’ #3, based on a conclusion that the product was not being correctly assembled into its new packaging. While it’s possible this could also be a contributing factor, it does not capture the underlying root cause of the packages being overloaded onto pallets at the factory, and the understanding of why this is happening — the information you need to be able to act and solve the problem.
These processes are examples. You may also find it useful to explore the Failure Mode and Effects Analysis (FMEA) and the Fault Tree Analysis models, both of which seek to link a specific fault to the issues and processes which create (or contribute to the creation of) the fault.
Of course, not all business problems will or should have a root cause solely attributed to training. This is another reason why having your stakeholders closely engaged during the root cause investigation will help ensure the solutions you assemble are meaningful and effective.
Learn More
AXIOM Learning Solutions is a leading provider of learning services and learning content development, including new content creation, learning program and project management, content curation, content updating, and learning content and program delivery. We will work with you to scope and execute learning programs that meet your performance goals.
Contact us by completing the form below for a free consultative conversation about your learning challenges—we have decades of experience building learning solutions and are happy to help.