Skip to content

Simple root cause analysis techniques

How can I find the real reasons behind process problems?

Fixing symptoms gives temporary relief. Fixing root causes stops problems from coming back. Root Cause Analysis (RCA) is a set of techniques that help you trace a problem back to its real source. Here are two practical methods that work well for office and service environments.

How does the 5 Whys technique work?

The 5 Whys is simple: state the problem, then keep asking “Why?” - usually about five times - until you reach a fundamental cause.

How to use the 5 Whys:

  1. Define the problem clearly: Start with a specific statement. Example: “The monthly sales report was submitted two days late.”
  2. Ask “Why?”: Why did the problem occur?
    • Problem: The monthly sales report was submitted two days late.
    • Why? The data from the CRM system wasn’t available on time.
  3. Ask “Why?” again: Take the answer and ask why that happened.
    • Why wasn’t the CRM data available? The CRM had unscheduled downtime on the data extraction day.
  4. Keep asking “Why?”: Repeat for each answer.
    • Why did the CRM have unscheduled downtime? An emergency patch was applied without proper testing.
    • Why was the patch applied without testing? The IT team felt pressured to fix an urgent bug quickly.
    • Why did the IT team feel pressured? There’s no clear protocol for balancing urgent fixes with testing requirements.
  5. Identify the root cause(s): By the fifth “Why” (sometimes earlier or later), you’ll uncover a deeper systemic issue. Here, the missing IT protocol is the real root cause - not just “CRM downtime.”

Tallyfy tip for 5 Whys: When a problem is flagged in a Tallyfy task comment, use the comment thread to run a collaborative 5 Whys session. Each “Why” and its answer becomes a reply in the thread, keeping the analysis in context.

How does the Fishbone diagram help identify problem causes?

The Fishbone Diagram (named for its fish skeleton shape) is a visual tool that helps teams brainstorm and categorize potential causes of a problem.

How to create a Fishbone Diagram for office processes:

  1. Define the problem (the “head”): Write the problem statement at the “head” of the fish, on the right side.
  2. Draw the “spine”: Draw a horizontal line extending left from the problem.
  3. Identify cause categories (the “bones”): Brainstorm broad categories. For office processes, common ones include:
    • People: Skills, training, communication, motivation.
    • Process: Workflow issues, unclear steps, handoffs, policies.
    • Technology: Software, hardware, systems, data.
    • Environment/Policy: External factors, company policies, workspace issues. Draw diagonal lines branching off the spine, labeling each with a category.
  4. Brainstorm specific causes: For each category, list specific causes as smaller “bones” branching off the main ones.
    • Example problem: Low customer satisfaction with support ticket resolution.
    • People: Insufficient training, high agent turnover.
    • Process: Too many handoffs, unclear escalation procedures.
    • Technology: Slow CRM system, knowledge base hard to search.
  5. Analyze and investigate: Discuss the most likely causes and plan next steps - perhaps running 5 Whys on the top suspects or gathering data via Tallyfy Analytics.

Visualizing the Fishbone diagram

This diagram shows a Fishbone analysis for why support tickets aren’t resolving satisfactorily.

Diagram

What to notice:

  • The problem statement (fish head) sits at the right as the focal point
  • Main categories branch off like bones, organizing causes into logical groups
  • Specific causes connect to their categories, showing how individual issues feed into the bigger problem

Tallyfy tip for Fishbone Diagrams: Tallyfy doesn’t have a built-in Fishbone tool, but you can create one on a whiteboard (physical or virtual) and attach a photo or summary to a relevant Tallyfy task or template description. The insights can then drive improvements in your process.

Advanced techniques for harder problems

The 5 Whys and Fishbone work well for straightforward issues. Harder problems may need these additional approaches:

Pareto analysis: focus on the vital few

The Pareto Principle (80/20 rule) suggests that 80% of problems come from 20% of causes. This helps you prioritize where to spend your effort.

How to conduct Pareto analysis:

  1. Collect data: Track problem frequency over time (defect types, customer complaints, error categories)
  2. Sort by frequency: Arrange causes from most to least frequent
  3. Calculate cumulative percentage: Add percentages as you go down the list
  4. Identify the vital few: Find where cumulative percentage reaches 80%

Example: A call center analyzed customer complaints:

  • Wrong information provided: 45% of complaints
  • Long hold times: 25%
  • System errors: 15%
  • Attitude issues: 10%
  • Other: 5%

The first two categories (70% combined) likely share root causes. Focusing here yields maximum impact.

Tallyfy application: Use form fields to categorize issues as they occur. Analytics generates frequency data you can use for Pareto analysis.

Failure mode and effects analysis (FMEA): prevent problems before they happen

FMEA identifies what could go wrong before it does. Originally from aerospace, it’s valuable for any critical business process.

Simple FMEA approach:

  1. List process steps: What could fail at each step?
  2. Rate three factors (1-10 scale):
    • Severity: How bad if it fails?
    • Occurrence: How often might it fail?
    • Detection: How likely to catch before impact?
  3. Calculate Risk Priority Number (RPN): Severity × Occurrence × Detection
  4. Address highest RPNs first

Example: New employee onboarding

  • Step: “Send IT equipment”
    • Failure: Equipment arrives late
    • Severity: 8 (employee can’t work)
    • Occurrence: 3 (happens occasionally)
    • Detection: 2 (hard to know until too late)
    • RPN: 48
  • Action: Add tracking notifications and buffer time

Tallyfy tip: Build prevention into templates based on FMEA findings. Add checkpoints where high-risk failures might occur.

Statistical thinking for service processes

Numbers reveal patterns you can’t spot by casual observation. A few useful techniques:

Run Charts: Plot process performance over time. Look for:

  • Trends (6+ points moving same direction)
  • Shifts (8+ points on one side of average)
  • Patterns (repeating cycles)

A loan processor noticed approval times spiked every Monday. Root cause? Weekend applications piled up and overwhelmed Monday morning staff. Solution: stagger Monday start times.

Scatter Diagrams: Plot one factor against another to spot correlations.

Example: Plotting “training hours” against “error rates” for new employees showed a strong negative correlation - 20+ hours of training dramatically cut errors, justifying the investment in thorough onboarding.

Choosing the right tool

Match technique to problem complexity:

Use 5 Whys when:

  • Problem is relatively simple
  • Need quick analysis
  • Single root cause likely

Use Fishbone when:

  • Multiple causes possible
  • Need team brainstorming
  • Categories help organize thinking

Use Pareto when:

  • Many problem types exist
  • Resources are limited
  • Need to prioritize efforts

Use FMEA when:

  • Implementing new processes
  • Consequences of failure are severe
  • Prevention beats correction

Use statistical tools when:

  • Data is available
  • Patterns aren’t obvious
  • Need to prove relationships

Making root cause analysis stick

Analysis without action is wasted effort. Make sure findings drive real change:

  1. Document findings: Attach RCA results to relevant Tallyfy processes
  2. Link to solutions: Every root cause should connect to a specific process change
  3. Verify effectiveness: Did addressing the root cause actually solve the problem?
  4. Share learnings: Similar processes often have similar vulnerabilities