In 1982, Kaoru Ishikawa (1915 – 1989) created the cause and effect diagram also known as the fishbone diagram. The fishbone diagram is often used in root cause analysis to identify linkages between systems or events (parallels can be drawn from the term “root” in root cause analysis and the root of a plant).
Identifying issues that are the “cause” can be difficult and time consuming, much like identifying the extent of a plant’s root system. Roots are typically hidden, and the size can’t be determined without digging up the plant completely. Similarly, problems are often not visible, and determining their overall effect on the project without digging into the issue is impossible. It takes a great deal of effort to dig out the root and identify the problem.
It would be difficult to be in the workforce for any length of time without running into the term root cause analysis. The concept is quite simple to understand, however, it can be a challenge to perform and solve. The Rubik’s Cube puzzle is a simple concept as well – also not easy to solve.
When there are major mechanical disasters, such as the NASA Space Shuttle explosion, people immediately think that a root cause analysis study must be performed to determine what happened. Typically we associate root cause analysis with mechanical or electronic mechanisms that are part of products or systems. Since products and systems are created by people, let’s entertain the thought of performing a root cause analysis of team members.
From time to time, even the best performing, individual contributors will have a decline in performance. Once the performance issue has been identified, rather than hope the situation will change, a proactive approach should be taken by sitting down with the individual and discussing the situation. This can be time consuming and, possibly, uncomfortable for both the team member and the manager, but it’s important that the team member is aware that his or her performance is not meeting expectations. The manager should communicate specific examples of poor performance (the effects) which may be: tardiness; poor quality of work product; late completion of deliverables; poor attitude; etc.
By having a list of predefined “effects,” the manager can get responses from the team member as to what they feel is the cause. Start with general categories such as work responsibilities, home life, health issues, etc. These categories can be further broken down into subcategories. For example, under work responsibilities you could have: current work assignment; work area environment; dislike of other team member; compensation; time line of deliverables; inadequate tools; or work schedule. Home life could be broken down into living arrangement; family members; transportation, etc. You get the idea. Once the cause(s) have been identified, the manager and the team member can then begin to try to resolve the cause.
Dr. Eliyahu M. Goldratt, in his book Theory of Constraints, contends that to improve quality, management must identify the weakest link in a project and elevate that link in order to raise the quality of the project. By identifying the team member(s) who are performing below expectations, and by performing a root cause analysis (Goldratt refers to the exercise as cause, effect, cause), the manager can elevate the probability of success for the project. By taking the time and effort to understand the team member better, the manager may develop a valuable, loyal employee.
From Darrell Stiffler