Cause and effect analysis is based on the premise that many problems are not the direct result of a single cause, but the effect of a number of causes combined together. It can be very helpful in breaking down a seemingly unexplained or complex problem into a number of contributory causes. This can make a problem easier to understand and overcome.

RCA is a problem solving process for conducting an investigation into an identified incident, problem, concern or non-conformity.  Root cause analysis is often seen as a completely separate process to incident management and immediate corrective action, although they are often completed in close proximity.  That is the CAR management system may report a summary of the RCA (or the entire RCA).

Root cause analysis (RCA) requires the investigator/s to look beyond the solution to the immediate problem and understand the fundamental or underlying cause/s of the situation and put them right, thereby preventing re-occurrence of the same issue. This may involve the identification and management of processes, procedures, activities, inactivity, behaviours or conditions.

RCA has the benefits of preventing waste in repeated non-conformance; presents permanent solution/s preventing reoccurring failures; provides a systematic approach to problem solving that engages a wider team.

Full implementation of RCA is required by many 3rd party certification programs.  The Proposed Action Plan (PAP) should ensure that there is distinct RCA, PAP, and it follows Verification of the proposed action if required.

It is satisfactory to combine these activities.  That is, the CAR management system may contain the RCA and PAP and include subsequent verification that the corrective action and preventive action was effective.  To maintain control, it is recommended that the RCA activities be appended to the specific CAR that the RCA and PAP relates to.  Attaching the Fishbone Diagram and other working documents to the CAR ensures visibility over time.

Although there are many methods to establish root cause around CARs and Incidents within a business, two (2) of the most commonly used are summarized below.

5 WHYs (5 Ys)

Optional, recommended for specific issues that require a quick solution that can be addressed in a group engagement.  The technique was originally developed by Sakichi Toyoda and was used within the Toyota Motor Corporation during the evolution of its manufacturing methodologies.  The tool has limitations to the current knowledge of the investigation team, therefore it is recommended to involve cross function groups to brain storm the 5 WHYs.

As a RCA tool it is regarded as the simplest to use and gain engagement from a wider team.  5 Whys gets its name as this is the number of times that it generally takes to find the root cause of the problem.  It may take 10 or 20, the method ensures that WHY is repeated until the root cause is found. The number ‘5’ is arbitrary, but used because it normally takes 5 Whys to arrive at root cause.

The concept of 5 WHYs is relatively simple:

  1. Identify the problem.
  4. Repeat until steps 2 and 3 have been completed five (5) times. You should have identified the root cause by this stage.
  5. Find solutions and countermeasures to fix the root cause.

It is important to brainstorm as many likely causes by a cross functional team, this provides a sound base to apply step 3.

Fishbone Template (Cause and Effect)

Fishbone or Ishikawa Diagrams are recommended for Root Cause Analysis (RCA) around process change and cross departmental communication.  Ishikawa Diagrams are often applied when the problem is complex and the 5 Whys method has not provided a viable solution.


  • 4P’s – Policies, Procedures, People and Plant
  • 5P’s – People, Processes, Products, Plant, Premises (the best mix for primary production)

The Fishbone method must arrive at controllable, manageable or adjustable processes.  Unmanageable outcomes such as ‘they forgot’, ‘not enough time’, ‘not enough money’, ‘not enough staff’, ‘staff sickness’ or ‘made a mistake’, these answers may be true, but in most cases they are out of our control.  If these answers are evident it is worth going back into the process to establish whether there is any other cause, for example by asking specific questions such as, ‘Why did the process fail?’ or ‘What system allowed the mistake to be made?
