Project Management Blog

Learn how to manage projects efficiently. Tips and strategy from experts. Stories, & new approaches to project management, videos & training.

Jan 17, 2013 by Oz Nazilli in Project Management 101 & Tools

Guest Post: The Five Whys of Troubleshooting

Inevitably, in any business, things go wrong. Murphy’s Law and whatnot. In many instances, investigations of what went wrong end at perceived technical problems. What author Eric Ries conveys in his book “The Lean Startup”, however, is that behind every technical mishap is a human error. He advises businesses and project managers to get to the root of the problem—and learning the lessons therein—by implementing a very simple procedure that children do every day: ask “why,” or rather, ask “why” a seemingly ridiculous number of times.

Let’s take Toyota’s Taiichi Ohno’s example, which Ries himself uses in the book. Supposing a machine stopped functioning, it would be up to a team to ask the Five Whys, which would be:

  1. Why did the machine stop?
    There was an overload and the fuse blew.
  2. Why was there an overload?
    The bearing was not sufficiently lubricated.
  3. Why was it not lubricated sufficiently?
    The lubrication pump was not pumping sufficiently.
  4. Why was it not pumping sufficiently?
    The shaft of the pump was worn and rattling.
  5. Why was the shaft worn out?
    There was no strainer attached and metal scrap got in.

These questions are not something a project manager can answer alone (at least, not fairly). This procedure must be executed in the presence and with participation from everyone affected by the mishap in an otherwise private environment. Decision-makers should also be involved not just to oversee the unraveling of the error but to share the collective responsibility. In fact, Ries notes that “most problems that at first appear to be individual mistakes can be traced back to problems in training or the original playbook for how the service is to be delivered.”

Avoiding the Five Blames
A room full of people with the potential to be blamed at every step of the Five Whys presents the very real possibility of the procedure turning into what Ries calls the Five Blames. As a project manager, it’s important to remind everyone that the purpose of the exercise is to pinpoint bad processes, not bad employees.

This is why it’s important to have everyone affected present when asking the Five Whys. Inevitably, employees not present are the ones that tend to get the blame, and scapegoating will do nothing to prevent future mishaps.

Scapegoating, however, is the tendency. This is why senior employees and managers are present—to share the blame. To prevent the team from rending itself to pieces from within, it is the responsibility of senior members to repeat this mantra: “if a mistake happens, shame on us for making it so easy to make that mistake.” In this way, the Five Whys promote system analysis as much as a section or employee examination. Senior members of these meetings must also act as mediators to keep the team on track as well as to ensure that morale isn’t sacrificed for damage control. At the same time, it’s important to not pull punches when asking the Five Whys, since failing to pinpoint sources of mishaps may lead to future errors. And that’s hardly a morale boost.

One thing we can’t avoid with the Five Whys is uncovering unpleasant truths about the company in its current state. Senior and project managers must prepare themselves as well as other employees for this inevitability, and take steps to bolster camaraderie and morale during and after the Five Whys. After all, although they may be riddled with errors, teams are what make businesses go ‘round.

Sarah Clare is a writer and oversees the site projectmanagementsoftware.com, where she has recently been researching issue tracking software. In her spare time, Sarah enjoys cooking and scrapbooking.

Image credit: Hellabella, Flickr

oz-nazilli
Oz Nazilli

Comments