Root Cause Analyses (RCAs)

A root cause analysis (RCA) records why something went wrong and what you'll do about it. Use one when an incident hits production, a defect slips through, or a deliverable fails acceptance. It captures what happened, the underlying cause, the evidence for it, and the solutions you chose, so the same problem doesn't come back.

RCA Properties

Basic Information

• Title: A short name for the problem, such as "Checkout outage, 14 March"
• Summary: A brief overview of the problem
• Project: The project the RCA belongs to (required)
• Organization: The organization that owns the project
• Status: Investigation while you work it out, Complete once the root cause and solutions are agreed. The close date is recorded when it's completed.

The Investigation

• Events: What happened, in order
• Problem source: Where the problem was observed or originated
• Severity: Low, medium or high, with a severity justification
• Root cause summary: The underlying cause, in a sentence or two
• Root cause rationale: The evidence and reasoning, such as a "five whys" chain, that leads to the root cause
• Measurement of success: How you'll know the fix worked

Solutions

Each RCA lists one or more corrective or preventive actions. Every solution has a title, a description, its potential risk, and a risk level (low, medium or high; medium if you don't choose).

Collaborators

The person who starts the RCA is its owner. Collaborators can view and edit it with them.

Linking RCAs to SOW Versions

An RCA can be linked to the statement of work versions it concerns:

• Introduced in: the version where the issue first appeared
• Identified issue: the RCA found an issue in this version
• Resolved by: the version whose changes fix it

Links let reviewers see, from a SOW version, which problems it caused or fixed. The SOW must be in the same project as the RCA.

Working with RCAs

In the web app, open Root Cause Analyses from the navigation to list, filter, create and edit them.

From Your AI Assistant

If you've connected Claude, ChatGPT, Codex or another assistant to Tanda (MCP Client Setup), it can work with RCAs for you:

• Find and read: "List the RCAs still under investigation in project Website Rebuild" or "Show me the checkout outage RCA."
• Start one: "Start a root cause analysis for last night's checkout outage, severity high." It begins in Investigation, and you're its owner.
• Find the root cause with the five whys: see below.
• Fill it in as you learn more: "Add the timeline from this incident channel." Only the fields you mention change. A new list of solutions replaces the existing ones, so the assistant reads them first.
• Link and close: "Link it to SOW Phase 2 v1.3 as the version that introduced the issue, then mark it complete."

The assistant follows your permissions: you need access to the RCA's project to read it, and write access to create or change it. Deleting RCAs and managing collaborators are only available in the web app.

The Five Whys

When an RCA doesn't have an agreed root cause yet, your assistant walks you through the five whys before it writes one:

1. Problem statement. It agrees one observable fact with you, such as "Checkout returned HTTP 500 for 40 minutes on 14 March", not a guess at the cause.
2. Why, one step at a time. It asks "Why did that happen?" and waits for your answer. It may suggest likely answers from the evidence it has, but you confirm every step, and it asks what evidence supports each one (logs, metrics, tickets, test results).
3. Stop at a cause you control. Each answer becomes the subject of the next question. It stops when it reaches a cause your team controls whose fix would stop the problem recurring, usually around the fifth why. It goes further if an answer is still a symptom, and follows each branch separately when one answer has several causes.
4. Systems, not people. "An engineer forgot" leads to another why: why did nothing catch it?
5. Saved on the RCA. The numbered chain goes in Root cause rationale, and the final cause in Root cause summary. If you stop partway, it saves the chain so far.

It then proposes solutions that remove the root cause, not just the symptom, plus a way to measure success, and saves the ones you accept. It marks the RCA complete only when you agree. If you already know the root cause, it offers the five whys to confirm it rather than insisting.

A saved chain looks like this:

Problem: Checkout returned HTTP 500 for 40 minutes on 14 March.
1. Why did checkout fail? Because the payment service rejected every call. (Evidence: gateway logs)
2. Why were calls rejected? Because its TLS certificate had expired. (Evidence: certificate expiry 14 March 02:00)
3. Why did it expire? Because renewal is manual and was missed. (Evidence: no renewal ticket)
4. Why was it missed? Because nothing tracks certificate expiry dates. (Evidence: no expiry alerting)
5. Why is there no tracking? Because certificates were never part of the service onboarding checklist.
Root cause: Certificate renewal depends on memory; nothing tracks or alerts on expiry.

Related Concepts