Root Cause Analysis training presented

Photo By Eric Hamilton | Kevin Fuqua, the Lean Six Sigma / Continuous Process Improvement Deployment Director at Headquarters, U.S. Army Corps of Engineers, provided training on Root Cause Analysis to the Far East District. The first day of training was to an audience comprised primarily of engineers from the Engineering Division on Tuesday, May 17, 2016.  

SEOUL, 11, SOUTH KOREA

06.06.2016

Story by Eric Hamilton 

U.S. Army Corps of Engineers, Far East District

Kevin Fuqua, the Lean Six Sigma / Continuous Process Improvement Deployment Director at Headquarters, U.S. Army Corps of Engineers, provided training on Root Cause Analysis to the Far East District.

The first day of training was to an audience comprised primarily of engineers from the Engineering Division on Tuesday, May 17, 2016.

The training began with an overview of what Root Cause Analysis does and how it works, using any one of several tools available from decades of working with process review and improvement.

Fuqua outlined how Root Cause Analysis related to processes. Processes consume resources, he said, and these processes determine outcomes, success and efficiency and effectiveness. They also influence decision-making and help us understand boundaries, stakeholders and interim objectives.

“You don’t get results by focusing on the results, you get results by focusing on the actions that produce the results,” Fuqua said.

Fuqua gave an example of a problem solved by Root Cause Analysis. The Jefferson Memorial was experiencing accelerated damage by an excess of bird droppings when compared with other similar monuments in the same area. Initial solutions proposed addressed symptoms of the problem: cleaning methods, bird management or changing the monument itself, either by covering, moving or closing it.

Instead of immediately using one or more of these potentially drastic and costly methods of treating symptoms, Root Cause Analysis was used. The “Five Whys” approach was used to discover and remedy the underlying cause:
1) Why was the finish of the Jefferson Monument becoming degraded?
a. Because of the need to clean excessive bird droppings off of the monument.
2) Why were so many birds at the Jefferson Monument?
a. Because there were lots of spiders there, and birds came to eat the spiders.
3) Why was there so many spiders?
a. Because there were many insects on and around the Monument.
4) Why were the large numbers of insects there?
a. Because lights at the Jefferson Monument were on longer than at other similar areas.
5) Why are the lights on longer at the Jefferson Monument?
a. No reason. This was the root cause of the problem and was something that could be easily fixed.

The context Fuqua worked within were common to the Corps operating environment, and he asked questions familiar to many of those present: “What if we have a problem delivering what the customer wants? How do we deal with that? What if an audit result, customer survey or stakeholder feedback identifies process problems? How do we respond? How do we determine whether it’s an ongoing problem or an isolated incident?”

More of a philosophy that allows for use of one or more different tools, Root Cause Analysis instruction isn’t a specific single approach to use for every problem or project. Instead, the focus of the training was to demonstrate how to avoid common pitfalls in problem solving.

“Do not attempt to ‘Solve World Hunger’,” Fuqua said, using that as a metaphor for a common scoping flaw sometimes known in military circles as “mission creep.” Another problem to avoid is coming at a perceived problem with a predetermined solution; this can often cause the problem to be mischaracterized. As Abraham Maslow wrote in the Psychology of Science, “I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”
One outcome Fuqua wanted participants to take from the training, despite the familiarity of some or all of the content presented, was to be able to “think differently.”

How to “think differently” came up in every demonstration of the tools Fuqua showed: DMAIC (Define, Measure, Analyze, Improve, Control, Sustain); Ishikawa (Fishbone) Diagrams; Deming’s PDCA (Plan, Do, Check, Act); BPR (Business Process Re-engineering); the U.S. Air Force’s OODA Loop (Observe, Orient, Decide, Act); and the U.S. Army’s seven-step MDMA (Military Decision-Making Process).

The goal is to improve and innovate, then implement and monitor, he said. The goal? “Remove waste and non-value added activities,” Fuqua said. Key to this process is separating personalities from activities; it’s not the person that’s non-value-added, it’s the activity or process that should be the target of Lean tools and technologies, he said.

But technology isn’t going to provide all of the answers; it’s not a “silver bullet” for process problems, Fuqua said. “All too often, someone assumes that implementing a technology tool like SharePoint is the only thing they need to do” to fix problems, he said. Alone, no technology or tool provides all of the answers, but possibly can provide the framework for the solution.

The methodology of the Root Cause Analysis approach is meant to help ask the right questions when dealing with process evaluation, as demonstrated by the Five Whys example of the Jefferson Monument. This training emphasized how to asking the right questions leads to getting the right answers.

• Date Taken: 06.06.2016
• Date Posted: 07.13.2016 20:02
• Story ID: 203904
• Location: SEOUL, 11, KR