Every company has issues — things that go bump in the night. When mistakes happen (both system and human), people tend to play the blame game. This is because, as a business grows, more people become involved in the end-to-end process — and more opportunities arise for error and blame.

What happens is people tend to defend their “process” and blame someone else for the “problem.” They say things like, “They were responsible” or “It’s not my process that messed up.”

This is process ownership silos at work.

Now, you might be thinking, “Why would I take the blame when I didn’t have anything to do with the problem?” That is process ownership thinking. As a leader, you are accountable for all errors, like it or not.

The next step in owning the problem is to triage the problem. Immediately bring everyone together in a team meeting. Look at what happened (not how it happened), determine the severity, and find a way to fix the problem professionally.

Think about your company as a manufacturing line and the concept of an Andon Cord. When an error is found, everyone “on the line” needs to be empowered to pull the Andon Cord and stop the process to examine the error.

When people are used to playing the process ownership game, they would rather fix (and cover up) the problem than stop and examine the problem. When this happens, the root causes of the problem are never resolved, and the problem keeps happening repeatedly.

When leaders own all the problems, and everyone knows that, it is much easier for employees to pull the Andon Cord.

With the immediate problem triaged and fixed professionally, the next step is to identify and correct the root cause. Again, you bring the whole team together to identify and define the problem, measure and analyze the situation, identify the root causes of what went wrong, propose solutions, and implement them according to a plan. These steps are outlined below.

Identify and Define the Problem

As a team, write out the problem in a statement identifying the object (the thing that was impacted), defects (the things that went wrong), and impacts (the impacts to the object, the company, and the customer). The impact is often related to the cost of quality.

The second tool to use when identifying and defining the problem is the is/should matrix. It is four questions, typically pictured in a two-row by two-column matrix. The questions are as follows:

1. What is happening that should be happening (good)?

2. What is happening that should not be happening (bad)?

3. What is not happening that should be happening (bad)?

4. What is not happening that should not be happening (good)?

Measure and Analyze the Problem

This is process and data analysis. Define the process steps and document them visually. Determine how often the process occurs. Identify what would be considered defects in the process and measure how often they have occurred in the past — where there is one problem, there are bound to be more. This is a simple data collection activity — no judgment required. Data is what it is.

Perform a Root-Cause Analysis 

Walk through the process and identify where, when, and why failures occur. Typical problems arise because of multiple handoffs, lack of checks and balances, manual efforts, systems not talking to each other, and a lack of rigorous process guidance.

As the leader, you must accept responsibility when the process does not work correctly. Holding any single person in the process at fault would be unfair. As you work through this as a team, you will recognize this and fix the problems without emotion.

Propose Solutions

As a team, propose, through brainstorming, potential solutions. No idea is a bad idea — write them all down. Then, analyze the proposed solutions. Look at things like cost, feasibility, time, and effort to implement and their impact on the problem.

Implement and Execute the Solution

Develop a plan and start fixing the process to prevent the problems from reoccurring. Continue to measure the process to ensure the defects have gone away. Incorporate these process measures into a dashboard to ensure the problem does not come back.

This is owning the problem, not the process. I hope you can see how this approach takes the blame and emotion out of issues and transitions the whole company to a problem-identification and problem-solving culture.

When something breaks, everyone needs to be able to pull the Andon Cord and stop the process. That means you have a culture of owning the problem, not the process. And you can quickly fix and solve the problem, versus playing the blame game.

This article has been reprinted with permission from John Knotts´ Forbes page.