When process improvement starts with the solution, it's common to anchor this improvement on the Bad Apple syndrome. The Dilbert Manager, the bad apple on the team, and another example of starting with the symptom and skipping to the solution, bypassing the root cause.
When this happens, those selling the solution need to defend the solution in the presence of hard questions:
- Will your solution actually correct my problem?
- Will your solution actually prevent the problem from coming back?
- What is the reason for that? Have you made a cause and effect assessment of the problem to the solution, to the sustainment of that solution?
This, of course, is the basis of Root Cause Analysis.
ISO/IEC 17025:2005 (4.11.2) ‒ The procedure for corrective action shall start with an investigation to determine the root cause(s) of the problem.
Here's a simple perspective for problem-solving
- Every problem in our lives, personal, business, civic, technical has three basic elements connected through causality
- Each effect has to two causes
- An Action
- A Condition
Before looking further, here's a principle that has served us well.
Ignorance is a most wonderful thing.
It facilitates magic.
It allows the masses to be led.
It provides answers when there are none.
It allows happiness in the presence of danger.
All this, while the pursuit of knowledge can only destroy the illusion. Is it any wonder mankind chooses ignorance?- from The Apollo Method, orginall from
This Action and Condition are critical to finding the solution. The classic misuse of the Five Whys of the root cause is the conjecture.
So when you hear a story about some undesired outcome - labeled as a dysfunction - and then here a quick and dirty solution to that dysfunction ask if there has been a Root Cause Analysis of the situation?
No? Then it's likely the person making the suggestion is trying to sell you something. A conference, a book, a consulting gig. Especially if that person's suggestion violates several of the principles of business and technical management.
And we're all selling all the time, but in our Federal Acquisition Regulation environment and other contract domain, there is a Past Performance Volume with a formal evaluation. So when a suggestion is made to a client (of ours) that Past Performance section must state what we did, what was the outcome, and what are the tangible benefits of that outcome to the decision maker. Always ask for those pieces of information before spending any more on anything.
Long ago a very senior piping engineer on a multi-billion refinery piping design system, asked us software weenies
That a nice idea boys (there were no females working there) what have you done for me lately
One of the engineers for the product we were using (Evans and Sutherland Picture System) went on to found Adobe. He asked if we wanted to join the startup. Na, I don't want to move from Southern California (Irvine) to Northern California. They had written a driver for a CalComp bed plotter to plot our 3D piping diagrams (ISOs) and were getting ready to approach laser printer manufacturers. That protocol was called PostScript.
