One of the things I was responsible for in a previous life was the troubleshooting and correction of processes within my organization. There weren’t always circumstances where something was broken per say, just not optimally performing. In this role, I did various things, such as at the request of a manager, review the steps in a particular workflow to determine if any efficiencies could occur, or to review utilization in a department of staff resources.
Early on, I started to look at common practices across the enterprise that by their nature created problems. After studying best practices on how to do this, I got into the practice of Root Cause Analysis. It’s a relatively simple practice in that you are supposed to ask “why” multiple times. You ask things like “Why do you scan and copy that document?” or “Why do you store multiple backups of the database in the same location?” Once you drill down into the core (root) of the issue, you can start suggesting solutions or identify the things causing that particular issue.
I had an IT manager come to me once and say, “I have a particular copier in a part of the office that has a utilization three times the amount of the other units in similar sized departments.” The company was getting killed on lease overage payments, and I was tasked to find out why. I went over to the department and started observing the workflow. It was a customer service department, much like several others in the company that made appointments with medical clinics for our government clients.
After less than 20 minutes, I noticed each agent would print out a double-sided document, copy both sides, thus creating two single sided documents. Then they would shred the original. I walked over to one of the agents and asked, “Why do you copy the printout into two separate documents?”
Her response was, “One is mailed to the client, and one is mailed to the clinic.”
“Why not just copy it once and send that to clinic or client?”
Her response was that each side had instructions that the other could not see, (pricing, medical data, and the examinee’s agency were typically kept separate.) “Why not have IT convert the printout to single sided?”
“We’ve asked, and they are too busy,” came the response.
With this information, I went back to the IT manager and explained the issue. Pointing out that this particular report is printed several hundred times a week, and is the most likely candidate for the overage. My suggestion was that an hour spent by one of the developers would be money well spent in saving the company money, creating a quicker workflow, and save a few trees.
This is a simple example of Root Cause Analysis and its usefulness to a set of issues. It’s a widely used practice by IT, mechanics, engineers, and other industries wordwide. Even the Six Sigma organizations use it in the ‘Analyze Phase’ of the DMAIC methodology DMAIC (Define, Measure, Analyze, Improve, Control.)
I’m interested in hearing your approach to using Root Cause Analysis in your own life, both personal and in business. Email me at [email url=”jchamberlain@ktlsolutions.com” class=””]jchamberlain@ktlsolutions.com[/email].
JEFF L. CHAMBERLAIN, PMP | Project Manager
Jeff comes to KTL Solutions with an extensive background in healthcare IT, technical consulting, and telecommunications. He has been a project manager for almost 20 years, holding certifications from the Project Management Institute as a Project Management Professional, from the Management and Strategy Institute as a Six Sigma Lean Professional, and he holds a Scrum Master Certification from the Scrum Alliance. He has managed both hardware and software implementations for both the government and private sectors, in industries such as healthcare, insurance, telecommunications, staff augmentation, supply chain and shipping.
Jeff has provided training for clients globally, working in Europe, Russia, North and South America on various topics from system optimization to wireless theory and design. He possesses a Bachelor’s Degree in Technical Writing from the University of Baltimore.
