Root Cause Analysis: Methods, Examples and a Practical Template

When something goes wrong, the first priority is normally to fix the immediate problem.

A defective product may need to be replaced.

Nonconforming construction work may need to be repaired.

A customer may need a corrected document, refund or replacement service.

A production line may need to be stopped until the affected equipment is made safe and operational.

These immediate actions are important.

However, they do not necessarily prevent the same problem from happening again.

Root Cause Analysis, usually shortened to RCA, is the structured process used to investigate why a problem happened and identify the underlying causes that need to be addressed.

In simple words:

Root Cause Analysis tries to move the organisation from “What went wrong?” to “Why was the system able to let this happen?”

That distinction is extremely important.

If a construction team installs the wrong material, replacing it may correct the immediate issue.

But if the approved-material register was unclear, procurement used an outdated specification and the delivered material was not checked before installation, the organisation has several deeper control failures to address.

This guide explains how to conduct a practical Root Cause Analysis, when it is needed, which RCA methods can be used and how to turn the findings into effective corrective action.

It also includes practical construction, supplier and customer-complaint examples and a Root Cause Analysis template that can be adapted to different industries.

What is Root Cause Analysis?

Root Cause Analysis is a systematic process for identifying the underlying causes of a problem, failure or nonconformity.

The purpose is not simply to describe what happened.

The purpose is to understand why it happened and determine what needs to change to reduce the likelihood of recurrence.

A useful Root Cause Analysis should help the organisation answer five basic questions:

1. What happened?
2. What was the impact?
3. Why did it happen?
4. Could the same cause affect anything else?
5. What action will prevent or reduce recurrence?

The identified cause should be supported by evidence.

It should not be based only on the loudest opinion in a meeting, an assumption made by the Quality Manager or a convenient explanation that places all responsibility on one employee.

Root Cause Analysis can be used for:

• Product defects.
• Service failures.
• Customer complaints.
• Construction NCRs.
• Failed inspections and tests.
• Supplier problems.
• Equipment failures.
• Audit findings.
• Process delays.
• Repeated errors.
• Environmental incidents.
• Health and safety incidents.
• IT and information-security failures.
• Missed quality objectives.
• Significant business-process failures.

The depth of the analysis should reflect the significance and complexity of the problem.

A missing signature on one otherwise complete record may not need a large investigation team and a complicated fault tree.

A structural failure, repeated customer complaint or systemic failure affecting several projects may require a detailed, multidisciplinary investigation.

Root cause, direct cause and contributing factors

One of the main difficulties with Root Cause Analysis is that people use the word “cause” to describe several different things.

It helps to distinguish between the immediate cause, contributing factors and root causes.

Immediate or direct cause

The immediate cause is the event or condition directly connected to the problem.

For example:

The installed pipe failed because an incorrect pipe grade was used.

This explains the immediate technical failure, but it does not necessarily explain how the wrong pipe reached the site, passed through the receiving process and was installed.

Contributing factor

A contributing factor made the problem more likely or increased its consequences, but it may not have caused the problem by itself.

Examples might include:

• Programme pressure.
• Poor communication.
• Inadequate supervision.
• Similar packaging.
• Unclear labels.
• A complicated approval process.
• Staff turnover.
• Poor lighting.
• Incomplete records.

Root cause

A root cause is an underlying system, process or management failure that allowed the problem to happen or prevented it from being detected.

In the pipe example, possible root causes might include:

• The purchase order did not identify the required material grade.
• The supplier’s material certificate was not reviewed.
• The goods-receiving process did not require verification against the approved material submission.
• The installation team did not have access to the current specification.
• The inspection plan did not include a material-identification check before installation.

Removing or controlling these causes should reduce the likelihood of the same or a similar problem recurring.

There may be more than one root cause

Problems do not always have one single root cause.

This is especially true in construction, engineering, healthcare, manufacturing and other complicated operational environments.

A failure may result from a combination of:

• Inadequate planning.
• Unclear requirements.
• Poorly controlled information.
• Supplier failure.
• Missing verification.
• Inadequate competence.
• Uncontrolled change.
• Weak supervision.
• Ineffective management oversight.

Forcing every investigation to identify one root cause can oversimplify the problem and lead to ineffective action.

Root Cause Analysis, correction and corrective action

Root Cause Analysis is only one part of the complete problem-management process.

The following terms should not be confused.

Containment

Containment prevents the problem from spreading or creating additional consequences.

Examples include:

• Stopping affected work.
• Isolating defective material.
• Suspending delivery.
• Preventing access to a failed system.
• Informing affected customers.
• Checking other locations for the same problem.

Correction

A correction fixes the identified nonconformity or immediate problem.

Examples include:

• Replacing defective material.
• Repairing nonconforming work.
• Correcting a report.
• Repeating an inspection.
• Reissuing an invoice.
• Updating an incorrect record.

Root Cause Analysis

Root Cause Analysis investigates why the problem happened.

Corrective action

Corrective action addresses the identified cause to prevent or reduce recurrence.

Examples include:

• Changing the procurement process.
• Adding a material-verification stage.
• Improving design-review controls.
• Modifying software validation.
• Changing responsibilities.
• Introducing an approval Hold Point.
• Improving supplier monitoring.
• Redesigning a form or workflow.

Effectiveness review

The effectiveness review determines whether the corrective action has worked.

This could involve:

• Sampling later records.
• Repeating part of an audit.
• Monitoring recurrence.
• Reviewing performance data.
• Inspecting later work.
• Checking customer feedback.
• Reviewing supplier performance.

An action is not effective simply because somebody completed it.

Issuing a new procedure, providing training or adding a checklist demonstrates implementation. It does not prove that the original cause has been controlled.

My guide to ISO 9001 nonconformity and corrective action explains the full process from containment and correction to effectiveness review.

Does ISO 9001 require Root Cause Analysis?

ISO 9001 does not specifically require every problem to receive a formal investigation called “Root Cause Analysis.”

Clause 10.2 requires an organisation to react to a nonconformity, control and correct it, and deal with the consequences.

The organisation must then evaluate whether action is needed to eliminate the cause so that the problem does not recur or happen elsewhere.

Where corrective action is required, the organisation needs to determine the causes, implement appropriate action and review its effectiveness.

The response should be proportionate to the effects of the nonconformity.

This is important.

Not every minor isolated error requires a complicated Root Cause Analysis.

However, significant, repeated, systemic or high-risk problems should normally receive enough investigation to determine why they occurred.

For a broader explanation of the applicable requirements, see ISO 9001 requirements and Clauses 4 to 10 in plain English.

When should a formal Root Cause Analysis be conducted?

A formal analysis should be considered when:

• The problem has serious consequences.
• Customer requirements have not been met.
• Safety, environmental or regulatory requirements may be affected.
• The problem has happened before.
• Several similar problems appear to be connected.
• The immediate cause is unclear.
• The failure could affect other products, projects or customers.
• A supplier problem is repeated.
• A previous corrective action has failed.
• The issue indicates a possible system breakdown.
• Management needs reliable evidence before making a significant decision.
• A Client, regulator or contract requires a formal investigation.

The decision can be based on risk.

Ask:

• How serious is the actual consequence?
• How serious could the potential consequence have been?
• How frequently has the issue occurred?
• How likely is it to happen again?
• How widely could the same cause be present?
• How confident are we that the cause is already understood?

The organisation should avoid two extremes.

The first is completing a large investigation for every small mistake.

The second is treating every problem as an isolated incident and never looking for repeated or systemic causes.

How to conduct a Root Cause Analysis

A practical Root Cause Analysis can be completed through the following stages.

1. Control the immediate problem

Before investigating causes, make sure the issue is controlled.

This may involve:

• Stopping work.
• Isolating products or materials.
• Informing customers.
• Protecting completed work.
• Preventing further release.
• Inspecting other affected locations.
• Introducing a temporary control.

Do not allow the investigation to delay urgent containment.

2. Define the problem clearly

A vague problem statement will produce a vague investigation.

Avoid statements such as:

• Quality needs improvement.
• The subcontractor made a mistake.
• The process was not followed.
• There was poor communication.
• The employee was not careful.

A useful problem statement should explain:

• What happened.
• Where it happened.
• When it happened.
• What requirement was not met.
• How the problem was detected.
• What was affected.
• What the actual or potential impact was.

For example:

During the pre-pour inspection of Level 3 on 10 July, reinforcement cover was measured between 20 mm and 27 mm in five locations. The approved structural drawing and specification required 40 mm nominal cover. The concrete pour was placed on hold pending correction and reinspection.

This statement provides a much stronger starting point than:

Reinforcement cover was wrong.

3. Establish the investigation team

Select people who understand the process and can provide relevant evidence.

Depending on the problem, the team may include:

• The process owner.
• Quality personnel.
• Engineers.
• Supervisors.
• Operators or installers.
• Procurement personnel.
• Designers.
• Supplier representatives.
• Maintenance personnel.
• IT specialists.
• Customer-service personnel.
• Health, safety or environmental specialists.

Do not exclude the people who carry out the work.

They often understand practical conditions that are invisible in procedures, meeting rooms and management reports.

At the same time, avoid allowing one person to dominate the analysis simply because they are the most senior participant.

4. Collect objective evidence

Gather the available facts before selecting the cause.

Possible evidence includes:

• Drawings and specifications.
• Procedures and work instructions.
• Inspection and test records.
• Photographs and videos.
• Material certificates.
• Delivery records.
• Emails and formal communications.
• RFIs and design clarifications.
• Training and competence records.
• Equipment history.
• Calibration records.
• Software logs.
• Audit reports.
• Previous NCRs.
• Customer complaints.
• Supplier-performance data.
• Interviews.
• Site observations.
• Environmental conditions.
• Samples and test results.

Establish a reliable sequence of events.

Ask what happened before, during and after the failure.

Separate confirmed facts from opinions and assumptions.

5. Identify possible causes

Use an appropriate Root Cause Analysis method to generate and organise possible causes.

Methods may include:

• Five Whys.
• Fishbone or Ishikawa analysis.
• Fault-tree analysis.
• Pareto analysis.
• Process mapping.
• Change analysis.
• Barrier analysis.
• Problem-concentration diagrams.

The method should support the investigation rather than become the investigation.

A completed fishbone diagram is not proof that the correct root cause has been found.

6. Test and verify possible causes

Do not accept a possible cause merely because it sounds reasonable.

Ask:

• What evidence supports this cause?
• What evidence contradicts it?
• Would this cause explain the complete problem?
• Could it explain similar problems elsewhere?
• If this cause were removed, would recurrence become less likely?
• Can the cause be reproduced, tested or confirmed?
• Does the timeline support it?
• Is this a cause or another symptom?
• Is this within the organisation’s control or influence?

Where evidence is unavailable, record the point as an assumption that still requires verification.

7. Identify root causes and contributing factors

Document the confirmed causes clearly.

Avoid meaningless phrases such as:

• Human error.
• Lack of attention.
• Poor communication.
• Inadequate training.
• Procedure not followed.
• Subcontractor failure.

These may describe part of the problem, but they usually require further investigation.

If a procedure was not followed, ask:

• Was it available?
• Was it current?
• Was it understandable?
• Was it practical?
• Had the person been briefed?
• Was compliance supervised?
• Did the programme allow it to be followed?
• Was a conflicting instruction given?
• Had management accepted similar deviations previously?

“Procedure not followed” may be the starting point of the analysis, not the root cause.

8. Develop corrective actions

Each significant cause should have a corresponding action.

A useful corrective action should define:

• What will be done.
• Which cause it addresses.
• Who is responsible.
• Required resources.
• Target completion date.
• Required evidence.
• How effectiveness will be checked.
• When effectiveness will be reviewed.

Actions should focus on strengthening the process.

Changing the process is normally stronger than reminding people to be careful.

Possible actions, from stronger to weaker, may include:

• Eliminating the problematic activity.
• Redesigning the product or process.
• Automating a verification.
• Introducing an engineered control.
• Simplifying the workflow.
• Creating a mandatory approval stage.
• Changing procurement information.
• Improving supplier controls.
• Revising documented information.
• Providing competence-based training.
• Increasing supervision.
• Issuing reminders or briefings.

Training may be appropriate when a genuine competence gap exists.

It should not become the automatic corrective action for every problem.

9. Assess whether the problem exists elsewhere

ISO 9001 requires the organisation to consider whether similar nonconformities exist or could potentially occur.

Ask:

• Is the same process used in another department?
• Did the supplier provide the same material elsewhere?
• Was the same drawing used in another location?
• Could other customers be affected?
• Is the same software configuration used across the business?
• Have other projects adopted the same procedure?
• Were earlier products or services released using the same control?

This step can turn an isolated correction into meaningful system improvement.

10. Implement and verify the actions

Collect evidence that each action has been implemented.

Examples include:

• Revised procedures.
• Updated software.
• Approved design changes.
• New inspection records.
• Completed competence assessments.
• Updated purchasing templates.
• Supplier re-evaluation.
• Revised process maps.
• Meeting records.
• Photographic evidence.

Allow enough time for the changed process to operate before reviewing effectiveness.

11. Review effectiveness

The review should answer one question:

Did the corrective action control the cause and reduce the likelihood of recurrence?

Effectiveness may be evaluated through:

• No recurrence during a defined period.
• A reduction in defect frequency.
• Improved inspection results.
• Successful audit sampling.
• Improved supplier performance.
• Fewer complaints.
• Improved process capability.
• Interviews with process users.
• Verification that the new control is consistently followed.

If the problem occurs again, the analysis or action may have been incomplete.

Reopen the investigation where necessary.

Root Cause Analysis methods

No single method is suitable for every problem.

The appropriate tool depends on the complexity of the issue, available evidence and number of possible causes.

Five Whys

The Five Whys method repeatedly asks why a problem occurred until the investigation moves beyond the immediate symptom.

Despite the name, the investigator does not have to ask exactly five questions.

Some problems may reach a useful cause after three questions. Others may require more than five or develop into several separate branches.

Five Whys works best when:

• The problem is relatively simple.
• The cause-and-effect sequence is reasonably clear.
• The people involved understand the process.
• Evidence is available to confirm each answer.
• The analysis is not forced down one predetermined path.

Its main advantage is simplicity.

Its main weakness is that investigators may stop too early or follow only one chain when several causes exist.

Five Whys construction example

Problem: Incorrect concrete mix delivered to site.

Why 1: Why was the incorrect mix delivered?
Because the supplier received an order with the wrong mix reference.

Why 2: Why did the order contain the wrong reference?
Because the buyer copied the mix reference from an old purchase order.

Why 3: Why was an old purchase order used?
Because the procurement template was not linked to the current approved-material register.

Why 4: Why was the approved register not checked?
Because the procurement process did not require technical verification before the order was issued.

Why 5: Why was technical verification not required?
Because responsibility for checking technical purchasing information had not been assigned.

Possible root cause:

The procurement process did not assign responsibility or include a mandatory technical-verification stage for concrete orders.

Possible corrective action:

Revise the procurement workflow so concrete orders are generated from the approved mix register and technically verified by an authorised engineer before issue.

This is stronger than instructing the buyer to “be more careful.”

Fishbone or Ishikawa diagram

A fishbone diagram organises possible causes into categories.

Common categories in manufacturing are known as the Six Ms:

• Manpower.
• Method.
• Machine.
• Material.
• Measurement.
• Mother Nature or environment.

The categories can be adapted.

A construction investigation might use:

• Design.
• Materials.
• Method.
• People.
• Plant and equipment.
• Inspection and measurement.
• Environment.
• Management.

Fishbone analysis is useful when several causes may be involved, different departments need to contribute or the issue is more complicated than one cause-and-effect chain.

The diagram helps generate possible causes.

The investigation team must still collect evidence and test them.

Fault-tree analysis

Fault-tree analysis begins with an unwanted event and works backwards through combinations of failures that could produce it.

It commonly uses AND and OR relationships.

For example, a waterproofing failure may require:

• A defect in the installed membrane; and
• A path for water to reach the defect.

The membrane defect could have resulted from:

• Poor surface preparation.
• Damage by later trades.
• Incorrect installation.
• Unsuitable material.

Fault-tree analysis is useful for:

• Technical failures.
• Safety-critical systems.
• Complicated equipment.
• Problems involving several connected failures.
• Situations where different combinations of events create the same outcome.

Pareto analysis

Pareto analysis helps identify which categories of problems contribute most to the overall result.

For example, a company may review 200 defects and find that:

• 35% involve incomplete inspections.
• 25% involve outdated drawings.
• 15% involve material damage.
• 10% involve incorrect installation.
• 15% involve other causes.

This helps the organisation focus its investigation and resources.

Pareto analysis identifies where to investigate. It does not automatically prove the root cause.

Process mapping

Process mapping shows the sequence of activities, decisions, responsibilities and handovers involved in a process.

The investigation team can compare:

• The planned process.
• The process people believe they follow.
• The process that actually occurred.

This often reveals:

• Missing approvals.
• Duplicated activities.
• Unclear handovers.
• Uncontrolled shortcuts.
• Information gaps.
• Responsibilities that nobody owns.
• Checks performed too late.
• Software and manual processes that do not agree.

Process mapping is particularly useful for procurement failures, design coordination, customer complaints, document-control problems, approvals and handover failures.

Change analysis

Change analysis compares conditions before and after a problem appeared.

Ask:

• What changed?
• When did it change?
• Who was affected?
• Which equipment, supplier, material, software or method changed?
• Did the problem begin at the same time?
• Was the change reviewed and approved?
• Were unintended consequences considered?

This method is useful when a previously stable process suddenly begins failing.

Barrier analysis

Barrier analysis examines which controls should have prevented or detected the failure.

Barriers may include:

• Design reviews.
• Competence requirements.
• Software validation.
• Physical safeguards.
• Approval stages.
• Inspections.
• Hold Points.
• Alarms.
• Segregation.
• Supervisory checks.
• Document controls.

For each barrier, ask:

• Did the barrier exist?
• Was it suitable?
• Was it available?
• Was it used?
• Did it work?
• Could it be bypassed?
• Why did it fail to prevent or detect the problem?

Problem-concentration diagram

A problem-concentration diagram records where failures occur on a physical plan, product, building, site or system.

It can reveal location-based patterns such as:

• Water leaks concentrated around one façade detail.
• Concrete defects occurring in one placement area.
• Damage concentrated near a particular access route.
• Complaints originating from one office.
• Equipment failures occurring in one environmental condition.

Choosing the right Root Cause Analysis method

Methods can be combined.

A team might use Pareto analysis to identify the most significant defect category, a fishbone diagram to generate possible causes and Five Whys to investigate selected branches in more detail.

Practical Root Cause Analysis examples

Example 1: Low concrete strength

Problem: Concrete cube results from a structural pour fall below the specified strength.

Immediate actions may include:

• Informing the relevant engineer and Client.
• Identifying the affected concrete location.
• Reviewing available test results.
• Preventing dependent work where necessary.
• Considering additional testing and engineering assessment.
• Preserving delivery, sampling and curing records.

Possible causes to investigate include:

• Incorrect concrete mix.
• Excess water added on site.
• Long transport or discharge time.
• Poor sampling.
• Incorrect cube preparation.
• Inadequate curing.
• Laboratory testing error.
• Incorrect specification or order.
• Unrepresentative samples.
• Environmental conditions.

Relevant evidence may include:

• Delivery tickets.
• Batch records.
• Slump results.
• Site photographs.
• Concrete temperature.
• Sampling records.
• Cube identification.
• Curing-tank records.
• Laboratory reports.
• Interviews.
• Approved mix design.
• Purchase order.

The investigation should not automatically conclude that the concrete supplier was responsible.

The failure could relate to the concrete, sampling, curing, testing or a combination of factors.

A properly prepared Inspection and Test Plan should establish testing responsibilities, frequencies, acceptance criteria and records before the work starts.

Example 2: Repeated waterproofing defects

Problem: Waterproofing inspections repeatedly identify incomplete sealing around service penetrations.

A fishbone analysis identifies possible causes involving:

Design:

• Penetration details are unclear.
• Several drawings contain conflicting information.

Materials:

• Proprietary sealing components arrive late.
• Incorrect sizes are held on site.

Method:

• The Method Statement does not show the full sealing sequence.
• Inspection occurs after access becomes restricted.

People:

• Different subcontractor teams use different methods.
• Supervisors have not received manufacturer training.

Management:

• Programme pressure encourages areas to be closed early.
• Responsibility for coordinating penetrations is unclear.

Inspection:

• The ITP does not contain a Hold Point before closure.
• The inspection form contains only a general waterproofing check.

The analysis could identify several root causes rather than one.

Corrective actions may include:

• Resolving and issuing a standard penetration detail.
• Updating material schedules.
• Revising the Method Statement.
• Introducing a pre-closure Hold Point.
• Using a location-specific checksheet.
• Assessing installer competence.
• Assigning coordination responsibility.

Example 3: Repeated supplier delivery errors

Problem: A supplier repeatedly delivers components with incorrect identification and incomplete certificates.

A process map identifies that:

• Purchase orders contain the technical requirements.
• The supplier’s sales team manually transfers those requirements into another system.
• Certificates are produced by a separate department.
• The delivered components are not cross-checked against certificates before dispatch.
• The receiving team records quantity but does not verify technical identification.

Possible root causes include:

• The supplier’s order-transfer process is uncontrolled.
• The dispatch process lacks technical verification.
• The receiving process does not check identification and certification before acceptance.

Corrective action may need to involve both the supplier and the purchasing organisation.

Simply raising another supplier complaint will not strengthen either process.

Example 4: Customer receives an outdated report

Problem: A customer receives Revision 2 of a report after Revision 3 has already been approved.

Immediate correction: Send the current approved report and explain the error.

Possible investigation findings include:

• Both revisions were stored in the same uncontrolled folder.
• File names did not clearly show approval status.
• The email attachment was selected manually.
• The document-management system did not restrict superseded versions.
• The issue process did not require a final revision check.

Possible corrective actions include:

• Separating working and approved-document locations.
• Locking superseded revisions.
• Generating customer transmittals directly from the approved-document register.
• Adding a release-verification stage.
• Simplifying document naming and status identification.

This is not simply a case of an employee attaching the wrong file.

It is a document-control failure that made the error reasonably easy to commit.

Common Root Cause Analysis mistakes

Starting with a predetermined cause

Do not begin the investigation with the objective of proving what management already believes.

Stopping at human error

People make mistakes, but systems should help prevent mistakes or detect them before they create serious consequences.

Blaming the employee or subcontractor

Blame discourages honest reporting and rarely explains why the existing controls failed.

Confusing a symptom with the root cause

“Incorrect material installed” describes the failure. It does not explain why procurement, receipt, supervision and inspection failed to prevent it.

Using Five Whys without evidence

Each answer needs support. Five unsupported opinions do not create a reliable analysis.

Forcing the analysis to produce one cause

Complicated failures may have several root causes and contributing factors.

Treating training as the default action

Training is appropriate when a competence or awareness gap is confirmed. It will not correct unclear design, faulty equipment, missing materials or an ineffective workflow.

Changing a procedure without checking practicality

The revised procedure may introduce another control that people cannot realistically follow.

Failing to consider the wider extent

The same cause may affect other products, projects, departments or customers.

Closing the action when it is implemented

Implementation and effectiveness are not the same.

Failing to involve process users

Managers may understand the planned process. The people doing the work understand how it operates in practice.

Writing vague root causes

A cause such as “poor communication” should explain exactly what information was missing, who needed it, when it should have been provided and why the established communication process failed.

Practical Root Cause Analysis template

A practical RCA form should contain the following sections.

1. General information

• Investigation reference.
• Related NCR, complaint, audit or incident reference.
• Date raised.
• Process, project or department.
• Location.
• Investigation leader.
• Investigation team.
• Target completion date.

2. Problem description

• What happened?
• Where did it happen?
• When did it happen?
• How was it identified?
• What requirement was not met?
• What products, services, locations or customers were affected?
• What was the actual or potential consequence?

3. Immediate containment

• What was done to control the problem?
• Who completed the containment?
• When was it completed?
• What evidence is available?
• Were customers or other parties informed?

4. Correction

• How was the immediate problem corrected?
• Was corrected work inspected or verified again?
• Who authorised acceptance?
• What evidence confirms completion?

5. Extent of condition

• Could the same problem exist elsewhere?
• Which other products, projects, departments, suppliers or customers were checked?
• What were the results?

6. Evidence reviewed

• Documents.
• Records.
• Photographs.
• Test results.
• Interviews.
• Observations.
• Data.
• Previous problems.
• Applicable requirements.

7. Analysis method

• Five Whys.
• Fishbone analysis.
• Fault-tree analysis.
• Pareto analysis.
• Process mapping.
• Change analysis.
• Barrier analysis.
• Other method.

8. Possible causes

For each possible cause, record:

• Description.
• Supporting evidence.
• Contradictory evidence.
• Verification required.
• Conclusion.

9. Confirmed root causes

For each confirmed root cause, record:

• Root-cause statement.
• Supporting evidence.
• Related contributing factors.
• Processes or locations potentially affected.

10. Corrective-action plan

For each action, record:

• Action.
• Cause addressed.
• Responsible person.
• Resources required.
• Target date.
• Completion evidence.
• Actual completion date.

11. Effectiveness review

• Review method.
• Review period.
• Performance measure or acceptance criteria.
• Evidence examined.
• Result.
• Further action required.
• Reviewer.
• Review date.
• Closure approval.

Example of a strong root-cause statement

Weak statement:

The supervisor failed to check the material.

Stronger statement:

The material-receiving process assigned responsibility for checking delivery quantities but did not assign responsibility or provide criteria for verifying technical material identification against the approved submission before release to the installation team.

The stronger version identifies a process failure that management can address.

Example of a strong corrective action

Weak action:

Remind supervisors to check materials more carefully.

Stronger action:

Revise the receiving process to require the responsible engineer to verify material identification and certification against the approved-material register before materials are released for installation. Record the verification in the digital receiving form and prevent release where approval evidence is incomplete.

The stronger action identifies what will change, who will be responsible and how the control will operate.

Root Cause Analysis and construction NCRs

Root Cause Analysis is often included within the construction NCR process.

However, not every construction NCR should automatically receive the same level of investigation.

The response should reflect:

• The significance of the nonconforming work.
• Potential structural, safety or performance consequences.
• Whether the issue is repeated.
• The cost and programme effect.
• Whether the same problem may exist elsewhere.
• Contractual and Client requirements.
• Whether previous corrective actions have failed.

A practical construction NCR process should connect:

1. Identification.
2. Containment.
3. Description of the breached requirement.
4. Proposed correction or disposition.
5. Technical approval where required.
6. Reinspection.
7. Root Cause Analysis where appropriate.
8. Corrective action.
9. Effectiveness review.
10. Final closure.

The guide to what an NCR means in construction explains how the overall process should work.

It is also useful to understand the main categories of construction NCRs, because process and documentation failures may require different investigations from physical defects in completed work.

Using RCA results for continual improvement

The value of Root Cause Analysis should extend beyond the individual report.

Organisations should review RCA information across time.

Useful questions include:

• Which causes appear repeatedly?
• Which processes create the most significant failures?
• Are corrective actions completed on time?
• How many actions are reopened?
• Which suppliers generate repeated problems?
• Are the same failures occurring across several projects?
• Are procedure changes reducing recurrence?
• Are problems detected internally or by customers?
• Do particular locations or teams need additional support?
• Are management-system risks being updated?

Root-cause categories can form part of the organisation’s quality metrics.

However, the data needs to be interpreted carefully.

A department with more reported problems may have a stronger reporting culture than one that records nothing.

My guide on how to measure quality in construction projects explains how NCRs, inspections, audits, supplier data, document-control metrics and Client feedback can be used together.

Internal audits can also verify whether corrective actions have been implemented and whether they remain effective. See the complete ISO 9001 internal audit guide and checklist for practical audit questions and evidence examples.

Root Cause Analysis should support learning, not encourage people to hide issues to protect their statistics.

Frequently asked questions

What is Root Cause Analysis?

Root Cause Analysis is a structured process for identifying the underlying causes of a problem, failure or nonconformity so that suitable corrective action can be taken to prevent or reduce recurrence.

What are the main Root Cause Analysis methods?

Common methods include Five Whys, fishbone analysis, fault-tree analysis, Pareto analysis, process mapping, change analysis, barrier analysis and problem-concentration diagrams.

What is the easiest RCA method?

Five Whys is usually the simplest method. It works well for relatively straightforward problems but may be inadequate for complicated failures involving several interacting causes.

Does every NCR require Root Cause Analysis?

No. The response should be proportionate to the significance and risk of the nonconformity. Significant, repeated or systemic issues normally need more detailed investigation than minor isolated errors.

Is human error a root cause?

Human error is rarely a complete root cause. The investigation should determine why the error was possible, why it was not prevented or detected and whether competence, information, equipment, supervision, workload or process design contributed.

What is the difference between a root cause and a contributing factor?

A root cause is an underlying failure that needs to be addressed to reduce recurrence. A contributing factor made the problem more likely or increased its effect but may not have caused the failure by itself.

Can a problem have more than one root cause?

Yes. Complicated failures often result from several connected technical, process, organisational and management causes.

What is the difference between correction and corrective action?

Correction fixes the identified problem. Corrective action addresses its cause to prevent or reduce recurrence.

How do you verify corrective-action effectiveness?

Review later evidence to determine whether the changed process is operating as intended and whether the original problem has been prevented or reduced. Evidence may include audit samples, inspection results, performance data, customer feedback and recurrence monitoring.

When should an RCA be closed?

The investigation should only be closed after the causes have been supported by evidence, required corrective actions have been implemented and their effectiveness has been reviewed.

Final thoughts

Root Cause Analysis should not be a paperwork exercise completed only because an NCR form contains an empty box labelled “root cause.”

It should help the organisation understand why a problem happened and what needs to change.

The strongest investigations begin with a clear problem statement, gather objective evidence, involve the people who understand the process and test possible causes before selecting corrective actions.

They do not stop at human error.

They do not automatically prescribe another training session.

They do not close actions simply because a procedure has been revised.

Most importantly, they recognise that the purpose of Root Cause Analysis is not to find someone to blame.

The purpose is to learn from the failure, strengthen the process and reduce the likelihood of the same problem affecting another product, project or customer.

For more practical resources covering inspections, NCRs, audits, document control and improvement, visit the Construction Quality Management Hub.