Part 2: Five Root Cause Techniques to help get to Business Needs

Part 1 of this series explored the notion that business needs represent “a problem or opportunity to be addressed” (BABOK Guide v3 definition from IIBA (International Institute of Business Analysis). It stands to reason that root cause techniques are then uniquely suited to understanding those needs since they are designed to get to the bottom of a problem or opportunity.

In this part I review five of my favorite root cause techniques and suggest the kinds of situations for which they are most appropriate.

Five Techniques

These five techniques are not an exhaustive list, but they are some of my favorite tools I have found helpful over my career to understand and ultimately solve business problems. They all have their purpose and are in the BABOK or PMI BA Standard or both:

1. Consultative interviewing – essential when using the other techniques, including…
2. Five-whys – more of a mindset, but often overlooked when we are busy – which is usual!
3. Fishbone/Mind Map – great brainstorming tools to help structure your root cause analysis.
4. Pareto diagram – A technique that uses data to help find the primary causes of a problem.
5. Interrelationship Diagram – excellent tool when there are compounding, interactive, (and possibly even competing) root causes.

1.      Consultative Interviewing

As we saw in the first part of this series, it is easy to jump to solutions. I believe we need to understand the problem first and use consultative interviewing to do that and to start uncovering business needs.

Consultative interviewing is a special kind of elicitation that is professional and focused on goals and is respectful and collaborative. When done right, it builds credibility, trust, and ultimately buy-in. The latter point is important if the root cause suggests a different solution than one favored by our sponsors.

Many of us already use this form of questioning or interviewing automatically. We know that it requires good listening skills and genuine curiosity and interest to determine both needs and expectations. Consultative interviewing leads to positives such as informed advice, confident recommendations, and viable alternatives. (Confidence is important if, again, we end up recommending a different solution than the assumed one.)

The Right Questions the Right Way

Increase Buy-In. Consultative Interviewing helps discover together what the client’s needs and wants are, and how our solutions can meet them. Eliciting needs, whether in sales or business analysis, is best done as a collaborative discovery process, and not as an “extraction.”

Avoid leading questions. Consultative questions are designed to broaden the conversation and encourage clients to open up and share their needs and concerns. Otherwise, “leading” questions give the impression the questioner has a hidden agenda and is pushing a certain solution. This also helps build trust.

Examples of leading questions to avoid as you interview consultatively include:

• “Don’t you think that ________?”
• “Isn’t it better to _________?”
• “Have you ever thought about a _________?”

Instead work to use consultative phrases that promote open, thoughtful dialogs such as:

• Tell me more about…
• Let me see if I understand…
• Could you elaborate on…

2.      Five WHYs

Remember the Jefferson Memorial story form part 1 of this series? It was an example of 5 whys in action. This is not a technique as much as a mindset. It has been part of business since the 1930’s because it is effective and reminds us we need to go deep enough to get to the real needs.

It is simple and easy to use and can be employed often with little preparation. On its own it can lead us to the root cause of a problem, but we can be led down the wrong path if we ask the wring people or those with hidden agendas. Five “whys” is part of other analysis tools as we will see and works best with a consultative interviewing style to ask “why.”

Five WHYs Example

Here is a favorite (and simple) example of mine to illustrate Five whys. Suppose you faced a problem like this:

We need to fix the potholes on Main Street again. How can we patch the potholes the fastest and cheapest way?

1. Why do they develop again so soon?  A: The holes develop every year and they do not go away.

2. Help me understand that.  A: Over time the asphalt deteriorates and develops holes.

3. Why does that happen?  A: The freezing and thawing of the asphalt wears it out.

4. I thought asphalt lasted forever?  A: Asphalt is durable for 10-15 years, then the coating begins to wear out, and it cracks easier.

5. Tell me more…A: The City has not resurfaced Main Street for over 20 years – the cost of repairing potholes in any year is less than resurfacing it.

So, the root cause of this example is a funding or budgetary problem, not deteriorating asphalt.

---

---

3. Fishbone Diagram/Mind Map

Once we use consultative interviewing or other tools to understand the problem or situation, we can use other more elaborate techniques that incorporate Five Whys to get to the root cause. These two root cause techniques do just that.

Fishbone diagrams and mind maps are snapshots of what is going on today. Assembling them makes use of Five Whys to help get to the root cause. The resulting diagram often exposes areas where we lack knowledge and/or data. See Figure 1 for the structure and Figure 2 for an example.

The Diagram

Figure 1: Fishbone Diagram Structure

Fishbones start with the “Effect” as many fishbones call the problem. Because of that, it is also commonly called a cause-end-effect diagram or Ishikawa Diagram after the inventor. It usually has 4-8 major sub-causes, which can be “5 why-ed” down into sub and sub-sub-causes.

The major causes on the tips of the “bones” can be any relevant categories, but in practice usually come from a standard group such as People, Policy, Process, Place, Machines, Measurements, and Systems.

For example, say you have a problem of transferring medical records too slowly. Here is how to complete the fishbone:

1. Start by asking why verifications are so slow (consultatively of course).
2. Maybe you determine there are 4 main categories – People, Process, Measurements, and Systems. Note them on the diagram as shown on Figure 2.
3. For each of the main categories, ask how the category, like Process, slows down the transfer of records.
4. Maybe you get the reason of “inefficient transfer process.” From there ask how does an inefficient transfer process slow down transfers. You might hear “too many manual processes” and “serial, one-at-a-time processes.” Note these too on the diagram in a hierarchical structure like Figure 2 below.
5. Continue adding additional sub-causes as appropriate.
6. Move on to each of the major categories you identified and drill down each of them. Tip: For both the mind-map and fishbone, I recommend only going about 3 levels deep, otherwise your diagrams are too detailed and “bony.”

Figure 2: Example Fishbone Diagram

Mind Maps

A mind-map is basically the same as a fishbone, but with a format more like an octopus (bad joke). Start with the problem in the middle, like the head of the octopus. Instead of fishbone ribs, the tentacles are the causes, and they in turn can have sub-causes.

Figure 3 shows the same medical records example done as a mind map.

Figure 3: Example Mind Map

Tip: There is no need to do both a fishbone and a mind map since they both diagrams accomplish the same thing. Use whichever one is more appealing or is a standard at your organization.

4. Pareto Diagram

Pareto diagrams are graphical tools applying the Pareto Principle, which is based on the 80/20 rule. They use data to focus efforts on the factors and causes that offer the greatest potential for improvement. 

They display the relative importance of problems in a simple, quickly interpreted, and user-friendly format. They are best used when you face problems that have many symptoms that can be measured.

How to Create a Pareto Diagram

1. Decide on the problem, such as customer complaints.
2. Choose the issues or causes. (Five whys can help).
3. Collect data for the potential causes.
4. Order data from largest to smallest and draw the bar graphs. See Figure 4 for an example.
5. Calculate the percentage of the total that each category represents and the cumulative percentage starting with the largest category. Excel makes this fairly easy.
6. Graph the cumulative percentage line.
7. Analyze the “vital few” breakpoint when the curve hits 80%. These are the most significant causes – the 20% that cause 80% of the problem.

Figure 4: Example Pareto Diagram

5. Interrelationship Diagram

Fishbones and Mind maps have their limitations, with one big one being they are hierarchical. What if your problem is more complex with some causes also being the symptom of other causes and so on like a chain reaction?

The Interrelationship Diagram helps with that situation. It is an excellent tool that helps when there are compounding (and possibly competing) root causes.

1. Starts with a situation / problem like “Customer reports are not getting out on time.” See Figure 5.
2. Add in the potential causes as bubbles, using the most likely ones you found, such as from a Fishbone Diagram or Five Whys. Tip: try to limit the causes to no more than 7 plus or minus 2 to keep the diagram at a high level.
3. Add “cause lines” by drawing arrows from one bubble to the next according to whether a factor is a cause of another or an effect. (For example, Low Wages cause staff shortages and Scheduling problems. Staff Shortages in turn cause paper to run out, database extract delays, and scheduling issues.)
4. When done with all causes, add numbers to indicate how many times a factor is being caused by another (“Incoming Causes”) or is the cause of another (“Outgoing Effects”). For example, 3,1 for “Not Enough Paper” means it is a symptom 3 times from other factors and is itself the cause of 1 other factor.
5. Make determinations of which are the most significant (or “big”) causes. These are the important factors to correct such as “Shortage of Staff.” Working on symptoms like “DB extract delays” will not be as fruitful to solving the problem.

Figure 5: Example Interrelationship Diagram

Summary

Understanding and addressing business needs are arguably the most important factors for any successful project, program, or product. This series covered the importance of needs and five techniques that will help discover the root cause of business problems, which equate to the important factors for learning business needs.

Part 1: What are Business Needs and why are they so Important?

What makes a successful project? There are many objective measures (such as on time and on budget) and subjective options (e.g., customer satisfaction) to answer that question. As a generality, I think a project is successful when we apply an appropriate solution to a business problem, one that addresses the underlying cause. In short, we are successful when we address the “business need.”

We all know it is easy to jump to solutions or to fix just the symptoms of a problem. We are all guilty of it and is so common it has a name: “jumping to solutions.” When we do this, we often fail to get to or seemingly even want to get to the root cause of a problem.

As an example, let me paraphrase a classic story of solution jumping vs. getting to the root cause. The Jefferson Memorial in Washington DC had a problem a few years back with large amounts of paint chipping off. It required repainting every six months to a year, far more frequently than it should have needed.

If you know this story, then you know it was not poor-quality paint or shoddy workmanship that caused the need for frequent re-paintings. It was because of bugs! Near dusk when they turned the lights on this beautiful monument, a certain type of bug came out. Not a bug, but hordes of them! With so many bugs, the birds in the area swooped in to eat them and then left bird droppings as a souvenir after their insect feasts. The root cause of the problem was bird dung from bugs that caused frequent power washing to clean it, that then wore away the paint that caused the need for frequent re-painting.

To make a long story short, once the U.S. Interior Department got to the root cause, they found that turning on the lights a little bit later fooled the bugs. Far fewer of them swarmed around which in turn reduced the bird droppings and the solution drastically reduced the power washing and repainting needed.

This series of articles will explore how to understand business needs using five common and proven root cause analysis techniques. By finding root causes we can truly understand business needs and not rely on what our business stakeholders tell us their needs are. It is a repeatable way to provide appropriate, cost-effective, and lasting solutions like they finally did for the Jefferson Memorial. Part 1 will focus on what are business needs.

What are Needs?

So, what are needs? I do not mean psychological needs like in Maslow’s hierarchy. I am also not differentiating between needs vs. wants so that if I say I need a new pair of shoes, I do not literally mean I am currently shoeless. What I essentially mean is “I really want a new pair and I’m willing to pay for them.” And that is what any project or program requires – a sponsor willing and able to pay for something new.

When considering “business needs,” what do sponsors pay for? Too often it is a predefined solution. I am sure many of you have experienced a sponsor bringing you a solution. In that case the project or program’s objective is to implement the predefined solution with business needs either previously explored, assumed, or possibly overlooked.

I frequently hear people tell me they are brought into projects after the solution has been chosen – seemingly too late for any needs assessment or root cause analysis. I often respond: “It is never too late!” You can always help forestall project disasters if you are diligent about wanting to get to root causes and actual business needs.

---

---

Business needs have many facets including:

• They represent business problems
• They represent business limitations
• They reduce the chance of “solution jumping”
• They lead us to requirements and designs
• They justify projects

Why are needs so important?

Figure 1: From Needs to Solutions

Anything a project team creates “should” stem from needs. Needs are at the heart of what we do, and they tie back to business problems or opportunities. They lead us to the requirements and are also the basis for designs, both “logical” or physical designs. Designs are turned into constructed things such as solution components, which in my experience has been software, but could be any constructed deliverable. Finally, all the components add up to one or more solutions.

You may intuitively know this but having a visual helps me to see the relationships and the importance of getting needs right. If we fail to understand needs, we risk delivering solutions that will not address underlying business problems and the resulting solutions will have decreased value and may even be scrapped.

What do IIBA and PMI-have to say about Needs?

The BABOK Guide v3 from IIBA (International Institute of Business Analysis) defines needs as “A problem or opportunity to be addressed.”

Looking further into the BABOK Guide, it literally starts with Needs as the core input when planning the BA approach. It is the very first task in the Guide. I realize the tasks are not intended as sequential items, but the placement is hard to ignore.

Figure 2: Needs in BABOK Guide v3

Needs are also the primary input when eliciting requirements, which leads to virtually every other task in the BABOK Guide.

The first Domain in The PMI Guide to Business Analysis (from Project Management Institute) is Needs Assessment. The Business Need for a project or program in that standard is defined during the “Assess Current State” task along with a current state assessment. It is also the entire first chapter in the PMI publication Business Analysis for Practitioners: A Practice Guide.

Figure 3: Needs in PMI Guide to Business Analysis

Needs are formally defined in PMI’s BA Standard as “…the impetus for a change in an organization, based on an existing problem or opportunity.“ It is entirely consistent with the IIBA definition and both standards remind us why root cause analysis techniques are so important for clarifying business needs before analyzing and defining solutions.

In the next article of this series, look for descriptions of five common and useful techniques for root cause analysis, and by extension, business needs.

Sources:

A Guide to the Business Analysis Body of Knowledge (BABOK® Guide) v3 from International Institute of Business Analysis, published 2015.

Business Analysis for Practitioners: A Practice Guide from Project Management Institute, published 2015

The PMI® Guide to Business Analysis from Project Management Institute, published 2017