Avoid Order-Taker Syndrome with Root Cause Analysis

The Order-Taker Mindset Hurts Our Reputation

On a bad day, it may feel as though you’re little more than an order taker. Perhaps a department head requests a course, and you suspect training won’t solve the underlying problem. But you do it anyway because the department head is closed to other ideas or you’re not sure your hunch is right.

Developing training that doesn’t solve the problem wastes time and money and hurts our professional credibility.

This is where root cause analysis becomes valuable. It’s one of the best ways to avoid jumping to a training solution before understanding the problem. By adopting a systems thinking mindset and adding root cause analysis to your toolbox, you can often identify the underlying causes of performance problems and become a more valuable consultant to decision-makers. This approach can shift your role from order-taker to a strategic-minded partner.

Root Cause Analysis (RCA)

Root cause analysis (RCA) is a collection of methods that analysts use to identify the underlying causes of problems. It was first used to analyze equipment failures and later became widely used in accident and safety investigations. It is widely accepted as a structured method for identifying the underlying causes of complex problems.

It’s an important career step too. Investigating a problem during analysis and drilling down to its root cause helps you avoid the order-taker trap and prevents wasted time and money on ineffective solutions. Rather than accepting a requested solution, your job is to understand the problem first. The following process can help you do that.

Prepare for the Analysis

Gather Relevant Evidence

A root cause analysis requires evidence to avoid guessing at the underlying causes. The first step involves gathering information about the problem and the conditions under which it occurs. Relevant sources may include incident reports, interview transcripts, performance metrics, shift patterns, system logs, observations, customer complaints, and other records. This evidence helps the analysis team identify patterns, avoid relying on opinions, and base the analysis on facts.

Define the Problem in Measurable Terms

Use the evidence gathered in the previous step to state the problem objectively and support it with relevant evidence. Defining the problem in objective terms keeps the analysis focused on the actual issue rather than assumptions about its causes.

A well-defined problem often makes the complexity clear enough to justify further investigation before deciding whether training or another intervention is appropriate. For example, below are a few performance problems stated in measurable terms with supporting data.

• Measurable Problem: Six weeks after rollout, only 28% of eligible transactions are processed using the new POS features, even though all sales associates have completed the required training.
  Supporting Data: POS transaction logs show adoption rates ranging from 18% to 42% across regions. Customer traffic has remained consistent with previous quarters, and LMS records confirm that 98% of associates completed the required training before the rollout.

• Measurable Problem: Safety incidents on the manufacturing floor have increased by 12% over the past six months.
  Supporting Data: Incident reports show that 68% of accidents occur during the evening shift, while incident rates on the day shift have remained relatively stable.

• Measurable Problem: Customer complaints about long wait times in the morning have increased by 12% across Northeast coffee shop locations over the past three months.
  Supporting Data: Average customer wait time during the morning rush has increased from 4.5 minutes to 8.2 minutes. Staffing levels have remained unchanged despite higher morning customer traffic. Complaint rates in all other regions have remained stable.

Invite a Team

Whenever possible, conduct the analysis with a cross-functional team with diverse expertise. Include people with relevant expertise who understand the work, the systems that support it, and the organizational context. Participants should contribute evidence and observations rather than defend existing practices or preferred solutions. Avoid relying on a single perspective, as it can introduce bias. Also, avoid limiting the team to the people requesting training.

Choose an Analysis Method

Two well-known methods for conducting a root cause analysis are the 5 Whys and the Ishikawa (fishbone) diagram. These techniques can help you diagnose complex performance problems and determine whether training is likely to address the underlying causes. Then you’re more likely to know whether training will fully or partly solve the problem or if there might be other underlying causes.

The Ishikawa (fishbone) diagram helps you organize and visualize the possible causes of a complex problem by grouping them into categories such as people, processes, equipment, materials, the environment, and management. The fishbone technique allows you to go broad.

The 5 Whys is a straightforward technique that involves repeatedly asking why until you reach a promising underlying cause. The 5 Whys allows you to go deep.

These two methods are often used together. It is common to start with the fishbone diagram to organize and visualize the possible causes of a complex problem. Then apply the 5 Whys to drill down on the most high-impact branches of the fishbone.

Using the Fishbone Diagram

The fishbone or Ishikawa diagram was developed by Kaoru Ishikawa in the 1960s as part of Japanese quality management. The name is descriptive because the diagram resembles a fish skeleton, with the problem at the head and relevant categories of possible causes branching off the spine. Beneath each category branch, you list specific factors that could contribute to the problem. Rather than seeking an immediate answer, this approach encourages exploration. You may find causes that appear across multiple branches, pointing to an area you should examine further.

In manufacturing, the classic fishbone categories are: Machine, Method, Material, Man (labor), Measurement, Mother Nature (environment). The approach is flexible, so that you can select categories that fit your context. For example, in healthcare, service industries, and business, you often see categories such as: People, Process, Equipment or Technology, Materials, Environment, Management, Measurement, Culture, and Policy.

Fishbone Diagram Example

Below is an example of using a fishbone diagram to find the possible causes of why a coffee chain is seeing an increase in customer complaints in the Northeast.

Using The Five Whys

The 5 Whys is a well-known technique for investigating the underlying cause of a problem. It’s a linear process that moves from the symptom or problem to the systemic root cause.

Start with a clear, specific problem statement, then ask, “Why did this happen?” For each answer, you ask why that happened, continuing until you reach a systemic cause (a process, policy, or structural gap) that you can act on. If you land on a cause that’s beyond your control, back up to the last one you can influence. It commonly uses a cascading list to show how one answer leads directly to the next question, as shown below.

Although it is called the 5 Whys, that is just a guideline. Continue past five if you need to dig deeper, or stop prior to five once you’ve found your cause.

This technique does not require statistical training or special software. It’s simply repeated questioning with the output diagrammed or written as a chain with no branching, as shown below.  In practice, real problems often branch, so using a single linear method is one of the most common criticisms.

The Five Whys Example

The fishbone diagram identifies several possible causes but does not determine the root cause. After identifying the most likely causes, you have the option to investigate them further.

The Five Whys can help you drill down from a contributing factor to an underlying systemic cause. For example, staffing issues show up in both the People and Management factors. This indicates that staffing is the most likely contributor. You can now use the Five Whys to investigate that branch in greater depth, as shown below.

Notice that lack of training was not a root cause of the problem. Therefore, a training intervention would not have been the solution to an increase in customer complaints, which was a system process issue. Also note that the analysis does not end by blaming the regional manager for reducing staff. Instead, it continues until it identifies a systemic issue: the lack of a process for validating staffing changes against customer demand.

Addressing that process would help prevent similar problems across the organization, regardless of who makes future staffing decisions. While the fishbone seeks to find contributing causes, the 5 Whys looks for systemic issues. In a real situation, you could then drill down on other factors that look like they may contribute to the problem.

Limitations of the Root Cause Analysis

It’s important to understand the limitations of any tool you use and the root cause analysis does have limitations. The quality of the results depends on the available evidence, the cross-functional team members, and an open-mindedness to challenge assumptions. Some problems have multiple root causes or hidden causes that are difficult to identify. Even so, a thoughtful root cause analysis is far more likely to identify effective solutions than relying on assumptions or jumping to conclusions.

The Cheat Sheet Summary

In conclusion, you can remember these two methodologies like this:

• Fishbone: Brainstorm and organize possible causes.
• Five Whys: Select one promising branch and investigate it more deeply.
• Root Cause: Arrive at a systemic issue that can be addressed.