Most root cause meetings fail before anyone speaks. The invite goes out with a title and no problem statement, half the room finds out what happened in the first fifteen minutes, and by the time the method starts there is time for one question, not five. This page is the document that prevents that: who is in the room, what happens in each block, and what has to exist before you move on.
Sixty minutes works when the chain is short and the data went out beforehand. Ninety minutes buys two things: a boundary that eliminates causes before the room argues about them, and the escape question — why nothing caught it. Invite by relationship to the problem, not by job title, and keep the room at five to seven. Every block ends when its output exists, not when its minutes run out.
Download the meeting agenda
Both agendas in one file — 60 and 90 minutes, block by block, with the output each block has to produce, plus the attendee sheet and the six-line pre-read. Fill in the header, send it with the invite. No signup, no email.
RCA meeting agenda — Excel (.xlsx)
Three sheets: 60 minutes, 90 minutes, and who is in the room with the pre-read and closing checklists.
RCA meeting agenda — Word (.docx)
The version to paste into a calendar invite or adapt to your own meeting template.
RCA meeting agenda — PDF (print)
Three printable pages — the copy that sits in front of the facilitator and keeps the clock honest.
This is the meeting. If you need the craft of running it — the longer formats, and what to do when the room turns on a person or stalls at why number three — that is in how to facilitate an RCA workshop. And if you are recording the result rather than running the session, use the RCA report template.
Who should be in the room
Invite by relationship to the problem, not by job title. A title tells you what somebody is responsible for; it does not tell you whether they saw the failure, hold the data or can authorise the fix. One person frequently covers two rows below, which is how you keep the room at five to seven.
| Relationship to the problem | Why they are in the room | What breaks without them |
|---|---|---|
| Saw it happen | First-hand facts about what the process actually does, rather than what the procedure says it does. | The room reasons from the documented process — which is rarely the one that produced the failure. |
| Owns the process | Can say what may change and what the real constraints are. | You agree actions nobody present has the authority to implement. |
| Can approve the change | Money, downtime, people — the decision that turns an action into a date. | You leave with intentions instead of commitments. |
| Holds the data | Brings the numbers and can say how reliable they are. | Twenty minutes disappear into debating what the data probably says. |
| Facilitates | Runs the method and the clock, with no stake in which answer wins. | The most senior voice in the room becomes the method. |
| Sees it from outside | Downstream, support or customer-facing: knows what the failure looked like to whoever received it. | Nobody asks the escape question — why the problem was not caught before it left. |
Who gets the summary instead of a seat. Anyone attending only to be informed. Every additional person costs airtime the method needs, and the cost is not linear: past seven, the quiet people stop contributing entirely.
The one invitation to think twice about
The line manager of whoever was closest to the failure. If they own the process or can approve the change, they belong in the room. If they are there as somebody’s manager, the meeting quietly becomes a performance conversation and people stop saying what actually happened. Send them the summary. This is the cheapest single thing you can do to keep the analysis honest — cheaper than any ground rule you read out at the start.
The 60-minute agenda
This assumes the pre-read went out a day earlier. Without it, the first two blocks take thirty minutes instead of fifteen and the method gets whatever is left.
| Min | Block | What happens | Output before you move on |
|---|---|---|---|
| 0–5 | Frame the problem | The facilitator reads the problem statement aloud exactly as written and asks one question: is anything in it factually wrong? No causes yet. | Everyone is working on the same problem, in the same words. |
| 5–15 | Agree the facts | Walk the timeline and the data from the pre-read. Anything nobody can source is marked unverified rather than argued about. | A list of agreed facts, and a separate list of open questions with owners. |
| 15–35 | Find the cause | Run the method: 5 Whys down one chain, or a fishbone first if the cause is contested. Every step points at evidence, not at a plausible story. | One candidate cause with its evidence — or two candidates and the test that separates them. |
| 35–45 | Test the cause | Two questions, out loud. If we remove this, does the problem stop? And does it explain why nothing caught it? | The cause survives both, or the team knows what to test before the next meeting. |
| 45–55 | Decide the actions | One action per cause, as high in the hierarchy as is feasible. Owners are named out loud while they are in the room. | Owner, date and verification method for each action. |
| 55–60 | Close | Read the actions and dates back. Agree who writes the summary and when the follow-up happens. | Follow-up date in calendars and a named summary owner before anyone leaves. |
The twenty minutes in the middle are the meeting. Everything before them exists to make them possible, and everything after them exists to make them count. If a block overruns, take the time from the closing block only as a last resort — a meeting that finds a cause and never assigns an owner has produced nothing that survives the week.
What the extra half hour buys
The 90-minute version is not the 60-minute version with more discussion. It adds two blocks that change the outcome:
| Added block | What it does | Why it matters |
|---|---|---|
| 20–30 — Bound the problem | Is / Is Not: what is affected, and what could equally have been affected and is not. | Candidate causes that cannot explain the IS NOT column are eliminated before anyone argues for them. This is the block that stops a meeting turning into competing theories. |
| Inside 55–65 — the escape question | Not just why it happened, but why none of your controls caught it. | It turns one corrective action into two, and its absence is the most common reason a customer rejects an 8D report. |
Use 90 minutes when the cause is contested, when more than two functions are involved, or when the failure reached a customer. Use 60 when a small group already agrees on the facts and the chain is short. Beyond ninety minutes without a break, the room stops testing the answer it has and starts defending it — at that point you are running a workshop, and it needs a different structure.
The pre-read: six lines, not a deck
How the meeting goes is mostly decided the day before. Six lines in the invite body — not an attachment nobody opens:
- The problem statement, one paragraph, with no cause and no blame in it. If writing it is hard, that is the meeting telling you something in advance — see how to write a problem statement.
- The data. How many, how often, since when, measured against target.
- The method you will use, and one sentence on why that one.
- The ground rule: we are looking for the cause, not the person. Written down, so it is a shared rule rather than an intervention you have to make later.
- What each person should bring — a document, a sample, a screenshot, a number. Named, not implied.
- The decision this meeting has to produce, stated as a decision.
A meeting that begins by explaining what happened has already spent its first quarter. The pre-read is what converts that quarter into analysis time.
Before anyone leaves the room
The meeting produced something only if all six exist
- A cause with evidence behind it — or a named test, an owner and a date
- One action per cause, each with a single owner rather than a team
- An acceptance criterion written before the action is carried out
- A verification date, and the name of whoever checks it
- A follow-up meeting in calendars, not in intentions
- Every unresolved point written down as an open question with an owner
The fourth line is the one most often skipped, and it is the one that makes the difference between a corrective action and a hope. Who checks, on what data, on what date. Tracking beyond that point — the ninety days after the meeting, when attention moves on — is its own problem, covered in corrective action tracking.
Four ways the clock disappears
The blame detour. The conversation moves to who did it. Recovery: write the person’s action on the board as a fact in the timeline, then ask what made that action possible. You have converted a dead end into a why.
Solution jumping. Somebody proposes a fix in the first ten minutes and the room starts evaluating it. Recovery: write it in a parking lot where everyone can see it is not lost, and return to the facts block. Proposals rarely survive the boundary check anyway.
The data debate. Two people disagree about a number that nobody in the room can verify. Recovery: mark it unverified, give it an owner and a date, and carry on. A meeting cannot resolve a measurement dispute, and trying costs twenty minutes every time.
No owner, so no action. The action list says “engineering” or “the team”. Recovery: ask for a name while the person is in the room. If nobody can be named, the action is not real and the honest outcome is an open question with a date.
These are the four that eat a one-hour meeting. The longer catalogue — the senior manager who takes over, the dominant voice, the chain that stalls at why three — is in the facilitation guide, which is about running the session rather than structuring it.
Frequently asked questions
How long should a root cause analysis meeting be?
Sixty minutes is enough for a single incident with a short causal chain, provided the data was sent beforehand and the problem statement is already written. Ninety minutes is the right length when the cause is contested, when several functions are involved, or when the failure reached a customer and you also have to explain why nothing detected it. Anything longer than ninety minutes without a break tends to produce a decision the room stops testing.
Who should attend a root cause analysis meeting?
Invite by relationship to the problem rather than by job title: someone who saw it happen, the person who owns the process, someone who can approve a change, whoever holds the data, a facilitator with no stake in the answer, and someone who saw the failure from the outside. Five to seven people. One person often covers two of those roles, and a job title on its own covers none.
What should be sent before a root cause analysis meeting?
Six lines, not a deck: the problem statement in one paragraph with no cause in it, the data (how many, how often, since when, against target), the method you will use, the ground rule that you are looking for the cause and not the person, what each person should bring, and the decision the meeting has to produce. A meeting that starts by explaining the problem has already spent its first twenty minutes.
What is the agenda for a 60-minute root cause analysis meeting?
Five minutes to frame the problem, ten to agree the facts, twenty to find the cause with the chosen method, ten to test whether the cause survives the removal and detection questions, ten to decide actions with named owners, and five to close with a follow-up date. Each block ends when its output exists, not when its minutes run out.
What does the extra half hour in a 90-minute meeting buy?
Two things the 60-minute version skips. A boundary — what is affected and what could equally have been affected and is not — which eliminates candidate causes before the room argues about them. And the escape question: why did none of your controls catch this? That second question is what turns one corrective action into two, and it is the one customers reject reports for missing.
Should the manager of the person involved be in the room?
Only if they own the process or can approve the change. Attending as the line manager of whoever was closest to the failure changes what people are willing to say, and the meeting quietly becomes a performance conversation. If they need the outcome, they get the summary. This is the single cheapest thing you can do to keep the analysis honest.
What has to exist before people leave the room?
A cause with evidence behind it — or a named test with an owner and a date. One action per cause, each with a single owner rather than a team. An acceptance criterion written before the action is carried out. A verification date and the name of whoever checks it. A follow-up in calendars. And every unresolved point written down as an open question with an owner.
Is a root cause analysis meeting the same as a workshop?
No, and the difference is scope rather than formality. A meeting of one to two hours handles a single problem whose chain is short enough to follow in one sitting. A workshop of half a day or longer handles a problem where the causes are contested, several functions have to agree, or the analysis needs breadth before depth. The agenda here is the meeting; the facilitation guide covers the longer formats and what to do when a session derails.
Related resources
- How to facilitate an RCA workshop — the craft: longer formats, eight pitfalls, follow-up cadence
- RCA report template — where the result of this meeting gets written down
- How to write a problem statement — line one of the pre-read
- 5 Whys template — the method for the twenty minutes in the middle
- Is / Is Not analysis — the boundary block in the 90-minute version
- Corrective action tracking — the ninety days after the meeting
- Kaizen event agenda — when one problem needs five days rather than one hour
- 5 Whys tool — run the chain on screen while the room watches