I was teaching a business analysis course recently and noted that few students had used a Fishbone Diagram along with the Five Whys for root cause analysis. This motivated me to write an article on root cause analysis using the combo method along with a short example.
Purpose
The purpose of the combined Fishbone/Five Whys [1], [6] is to provide a structured approach (i.e., the fishbone it is not a process model – no flow) on seeking out the source of a problem in a service process or a product defect. This source is called, “the root cause,” in that problems typically are due to a falling domino effect. To effectively remove the problem, you must trace back to the first falling domino so the problem does not reoccur (i.e., a permanent correction). In other words, provide a cure rather than a band aid.
The key to doing this is to have a method that leads a group [2] to alternate areas for possible causes and promote a consensus on what is the root cause (first domino). With the root cause identified, the group can then determine all the corrective actions. Seldom is there a single corrective action; there can be a corrective action for each succeeding falling domino.
Setting up the Fishbone
The diagram is the shape a fish skeleton. At the fish’s head, the problem is described. Also, at the tip of each fish spine, the group states an area to investigate. In Figure 1, the fish head is on the far right; but, the fish head can be drawn at either end. The spines are then drawn; the number of spines can vary depending on the number of areas the group wants to investigate; note, there is no order to the spines.
Figure 1: Setting up the Fishbone
Once the initial fishbone is drawn, the group then describes the problem. For example, a credit process sometimes results in a customer application approval in error (i.e., Process Error). The investigation group now needs to determine what areas to investigate; the number of areas is subjective (i.e., 1 or more). The group can brainstorm [6] to identify the areas and related questions. In this article, there are 10 areas along with possible questions to pursue. Note the questions that are highlighted in red are used in the follow-on example.
- Organization Structure
- Are there control advantages for the process to be worked within a single function (department)?
- Are there advantages for distributed or centralized resources?
- Are there control advantages for the process to be worked by a single team or by a single case manager?
- System Interaction
- Can tasks be accomplished more efficiently with primary users interacting with a system?
- Is there new technology that can enhance the process?
- Can the usability of an existing system be improved?
- Do existing system interactions execute valid business rules?
- Can the existing system be extended to eliminate delays in the process?
- Workflow Tasks (i.e., the term “workflow” is used here since it is referencing to a specific process)
- Is the workflow completely documented? [7]
- Does each task add value to the final result? (caution – although task may appear not to add value it may be a necessary management control task)
- Can tasks be combined to eliminate wait or idle time due to setup time, time triggers or delayed input?
- Can serial tasks be reordered or done in parallel with little additional risk?
- Is there movement of work product with no value added?
- Are any of the tasks inhibited due to the work environment?
- Are there any tasks that can be cloned as a result from benchmarking?
- Can tasks be moved toward the customer?
- Can tasks be outsourced to gain efficiency?
- Can supplier tasks be integrated into the process?
- Management Control
- Are the current business decisions based on valid business rules?
- Can business rules be changed to allow opportunities for efficiencies? (challenge business rule assumptions and constraints – more agile rules may eliminate work tasks)
- Are business rules used to handle process exceptions?
- Is business rule consulting available?
- Primary Users
- Do the primary users have the adequate
- training? [8]
- licenses?
- certifications?
- experience?
- Do the job descriptions need updating?
- Are the business decisions assigned to primary users at the appropriate organization level?
- Is the primary user inhibited due to the work environment?
- Organization Staffing
- Is a single process owner needed?
- Is more staff needed?
- Is staff empowered to make decisions within the process?
- Are there advantages in maintaining process generalists or task specialists?
- Communication Network
- Are message flows effective between
- users?
- systems?
- processes?
- Is there a single point of contact for customers and suppliers?
- Is there a standard interface for systems?
- Information Flow
- Are the required data collected upstream in the process and made available to the downstream tasks?
- Is the needed information provided to accomplish each task?
- Is information stored appropriately per nonfunctional requirements (audit trail, data retention, backups, disaster recovery)?
- Are there opportunities to gain efficiencies by automating tasks (see System Interaction)?
- Are there possibilities of implementing new or enhanced tools for the primary users?
- Performance Measurement
- Are the current business decisions based on valid business rules?
- Can business rules be changed to allow opportunities for efficiencies? (challenge business rule assumptions and constraints – more agile rules may eliminate work tasks)
- Are business rules used to handle process exceptions?
- Is business rule consulting available?
- Business Decisions
- Are business rules documented? [9]
- Are the current business decisions based on valid business rules?
- Can business rules be changed to allow opportunities for efficiencies? (challenge business rule assumptions and constraints – more agile rules may eliminate work tasks)
- Are business rules used to handle process exceptions?
- Is business rule consulting available?
Figure 2. Fishbone Diagram with stated problem and investigation areas
Analyzing the Areas using the Five Whys
With the fishbone diagram setup, the group now investigates one or more of the areas on the diagram using the Five Whys. The group states an area question that they think can lead to the cause of the problem stated at the fish head. However, the answer typically is only a surface indication of the real cause of the problem. Therefore, like a doctor following a symptom of a patient, the group traces down to what caused the symptom. The group simply asks an iteration of “Why” questions for each follow-on cause until the final cause or root is discovered. The “Why” question can be repeated up to five times per Toyoda [1]; hence the technique name. After the group can trace no further (i.e., root cause identified), the group develops a corrective action plan to address the root cause(s) for each area. [3]
Don’t Tell Me, Show Me
For this example, the group choses to start with the area of Workflow Tasks; another option is to start with the Primary Users area. They need to determine what might be missing or wrong with the workflow to possibly cause the process error. Note the use of footnotes to tie the article text to Figure 4. The group initially asks:
- Is the workflow completely documented? [7] No. There is incomplete documentation.
Now is the time for the group to use the Five Whys. The technique is to ask an iteration of whys 1-5 times until the group determines that the tracing can be carried no further. The theory is that the root cause can be traced from the symptom which indicates the cause of the problem.
1. Why is the workflow documentation incomplete? It lacks references to the business rules used in gateway decisions [4] (i.e., how is the correct path chosen (A, B, C)). [10]
Figure 3. Workflow Gateway with multiple paths [4]. Note that the workflow decisions are made in the task prior to the gateway.
2. Why are business rules missing? There is no standard that measures when workflow documentation is complete. [11] For this example, the group determines that the tracing can be carried no further for the Workflow Tasks area.
Root Cause: No standard for workflow documentation. See Figure 4 on how this is documented on the fishbone diagram via sub-branches off the Workflow Tasks spine and stating the cause.
The analysis of Workflow Tasks leads the group to investigate Primary Users.
- Are primary users making workflow decisions per documented business rules? [8] No. They base their decisions on experience which varies; this leads to inconsistent results.
- Why are primary users basing decisions on their individual experience? There is a lack of training on business rules. [12]
- Why are business rules missing from training? No rules are documented. [13] Again, for this example, the group determines that the tracing can be carried no further for the Primary Users area.
Root Cause: No business rules are documented for training. Again, see Figure 4 on how this is documented on the fishbone diagram.
The analysis of Primary Users leads the group to investigate Business Decisions.
- Are business rules documented for business decisions? [9] No.
1. Why are business rules undocumented? There is no requirement for workflow teams to document business rules. The teams focus only on the sequence of tasks. [14] Once again, for this example, the group determines that the tracing can be carried no further for the Business Decisions area.
Root Cause: No rules document required for business decisions. Again, see Figure 4 on how this is documented on the fishbone diagram.
Figure 4: Fishbone Diagram with root cause analysis for example (causes are numbered per footnotes for instructional purposes only)
Corrective Action Plan
The final step is for the group is to summarize the root causes identified in each area and develop a corrective action plan. For this example:
- Develop and issue a workflow standard that requires business rules in documentation [5].
- Develop a data base of business rules for workflow reference purposes.
- Include business rules in primary user training for decision making.
- Measure results to insure that the problem is permanently resolved.
Imagine if the group did not identified all of the root causes. Can the process error reoccur in this workflow or perhaps other processes (i.e., band aid vs. cure)? The fishbone diagram along with the Five Whys help provide a thorough investigation.
Author: Mark Monteleone, CBAP, CSM, CSPO, CBA
Mr. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University. He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business is Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) by the Scrum Alliance. He holds an Advanced Master's Certificate in Project Management and a Business Analyst Certification (CBA®) from George Washington University School of Business. Mark is also a member of the Association for the Advancement of Cost Engineering (AACE) and the International Association of Facilitators (IAF).
Mark is the President of Monteleone Consulting, LLC and author of the book, The 20 Minute Business Analyst: a collection of short articles, humorous stories, and quick reference cards for the busy analyst. He can be contacted via email - [email protected].