This is a ready-to-use facilitation checklist. It is not the RCA worksheet itself, the tools for that (5-Whys, fishbone, fault-tree, structured report) live in the root cause analysis toolkit; this checklist covers the part that worksheet does not: how to run the live session where a group actually generates and tests the candidate causes. A poorly run session produces a weak RCA even when the right tool was chosen. Replace every <<FILL: ...>> placeholder with your own specifics and attach the completed checklist to the investigation record as evidence the session was run with discipline. A filled specimen follows. Verify each cited regulation against the current source before you rely on it.
Document control header
| Field | Entry |
|---|---|
| Document title | RCA Facilitation Session Guide |
| Document number | <<FILL: FORM/CHK-ID, e.g. CHK-QA-045>> |
| Version | <<FILL: version, e.g. 1.0>> |
| Effective date | <<FILL: effective date>> |
| Supersedes | <<FILL: prior version or "New">> |
| Document owner | <<FILL: role, e.g. Head of Quality Assurance>> |
| Applies to | <<FILL: sites / departments in scope>> |
| Governing procedure | <<FILL: deviation/OOS/complaint SOP-ID this session supports>> |
1. Purpose
This checklist gives a facilitator a repeatable way to run a group root cause analysis session so the conclusion reflects the evidence and the widest reasonable set of candidate causes, not whoever spoke first or loudest. It applies to any session using a group brainstorming method (fishbone, Is/Is-Not) and to a group review of a 5-Whys or fault-tree already drafted by an individual investigator.
2. Scope
This checklist applies to root cause analysis sessions for deviations, OOS and OOT results, and complaints where more than one person is contributing to the cause analysis, whether in person, by video call, or hybrid. It does not replace the analysis tools themselves or the investigation report; it governs how the session that produces the analysis is run. Use it alongside the governing investigation procedure and the RCA toolkit referenced in the header.
3. Roles for the session
| Role | Responsibility |
|---|---|
| Facilitator | Runs the agenda, states and enforces ground rules, keeps time, protects the quiet voices, withholds their own theory until last, does not have to be the investigation owner |
| Scribe | Captures candidate causes, their disposition (ruled in / out / open), and the evidence cited, visible to the group in real time; not the same person as the facilitator |
| Investigation owner | Presents the problem statement and known facts, drives the record afterward, may facilitate if a trained facilitator is not available but should recognize the conflict of protecting their own early theory |
| Participants | Contribute facts and candidate causes from their area of knowledge, challenge causes they believe are wrong, respect the ground rules |
| QA observer | Confirms the session followed this checklist, challenges a cause that looks like an unexamined stopping point, especially a bare human-error finding |
4. Before the session
- Facts, timeline, and objective data (batch record, equipment log, system data) are gathered and available before the meeting starts.
- A draft problem statement is written in advance, factual, free of any presumed cause.
- Attendee list is set: people who touched the process or record, QA, and any technical SME needed to challenge a proposed cause. Target
<<FILL: e.g. 4 to 8>>participants; more produces noise, not breadth. - Session length and agenda are set with a time box per stage (see section 6), circulated in advance.
- The tool for the session (fishbone, Is/Is-Not, or a group review of a drafted 5-Whys or fault-tree) is chosen and stated in the invitation, matched to event risk per the governing procedure.
- Meeting space or virtual whiteboard/document is set up and ready before participants arrive.
5. Ground rules to state at the start
- No blame. The session investigates the system, not a person’s character.
- One conversation at a time; no side conversations that exclude the group.
- Park proposed fixes and corrective actions until the cause is established. A room that jumps to “we should just retrain everyone” has derailed the analysis before it started.
- Every candidate cause gets a disposition, out loud, with a reason: ruled in, ruled out, or open pending more data. Nothing is silently dropped.
- Disagreement with the group’s leading theory is expected and welcomed, not a disruption.
6. Running the session: timed agenda
| Stage | What happens | Suggested time box |
|---|---|---|
| Confirm problem statement | Group validates or corrects the draft problem statement; disagreements resolved before moving on | <<FILL: e.g. 10 min>> |
| Silent individual brainstorm | Each participant writes candidate causes alone, no discussion yet | <<FILL: e.g. 5 to 10 min>> |
| Group share and capture | Each person shares their causes in turn; scribe captures all of them before any are debated | <<FILL: e.g. 15 min>> |
| Disposition | Group discusses and dispositions each candidate: ruled in, ruled out (with evidence), or open | <<FILL: e.g. 20 to 30 min>> |
| Drive survivors to depth | 5-Whys or fault-tree run on the ruled-in candidates, either live or assigned to a sub-team with a follow-up date | <<FILL: e.g. 20 min or assigned>> |
| Close | Root cause(s) and contributing factors stated; open items assigned an owner and a date; next session scheduled if needed | <<FILL: e.g. 10 min>> |
7. Facilitator’s bias watch-list
Watch for these during the session and intervene when you see them; do not wait for the write-up to catch them.
| Signal in the room | Likely bias | Facilitator intervention |
|---|---|---|
| One person’s early guess becomes the frame everyone else argues within | Anchoring | Return to silent brainstorming; explicitly ask “what haven’t we considered yet?” |
| The group stops generating candidates once one theory feels right | Confirmation bias / premature closure | Ask “what evidence would prove this wrong?” before allowing the group to move on |
| Junior participants go quiet once a senior voice states an opinion | Groupthink / authority bias | Name individuals directly for their view; collect input in writing before further discussion |
| ”It should have been obvious” statements about a person’s past decision | Hindsight bias | Ask what information was actually available to that person at the time, from records made before the event |
| The group defaults to “the analyst should have been more careful” | Fundamental attribution error / blame bias | Ask whether a different, similarly trained person would likely have done the same thing under the same conditions |
| The group resists abandoning a theory it has spent the most time on | Sunk cost | Time-box each theory in advance; state plainly when the time box has expired |
8. Remote and hybrid session adjustments
- A shared virtual whiteboard or document is used so the fishbone or Is/Is-Not table builds visibly for everyone, not just the facilitator’s screen.
- Silent brainstorming is done by typing into a chat or shared document rather than speaking, before discussion opens.
- The facilitator checks in by name with participants who have not spoken, since a quiet camera is harder to notice than a quiet room.
- Recording, if used, is disclosed to participants in advance and handled per
<<FILL: recording/retention policy reference>>.
9. Session record
| Field | Entry |
|---|---|
| Record/investigation reference | <<FILL>> |
| Date and duration of session | <<FILL>> |
| Facilitator | <<FILL>> |
| Scribe | <<FILL>> |
| Participants and roles | <<FILL>> |
| Tool(s) used | <<FILL>> |
| Candidate causes raised (all, including ruled-out) | <<FILL: attach fishbone/Is-Is-Not output>> |
| Root cause(s) / contributing factor(s) reached | <<FILL>> |
| Open items, owner, due date | <<FILL>> |
| Follow-up session scheduled (if needed) | <<FILL>> |
10. Acceptance criteria
A facilitated session is acceptable when all of the following are true:
- The problem statement was confirmed by the group before analysis began.
- Candidate causes were generated individually before group discussion (silent brainstorm), not only through open discussion.
- Every candidate cause has a recorded disposition and, where ruled out, the evidence that excluded it.
- No proposed corrective action was accepted as the conclusion before a root cause was established.
- Every open item from the session has a named owner and a date.
- The session record is attached to the investigation.
11. References
21 CFR 211.192 (investigation of discrepancies and failures). ICH Q10, Pharmaceutical Quality System (CAPA and investigation expectations). ICH Q9(R1), Quality Risk Management (proportionate investigation effort).
Confirm the current version of each reference before issue.
12. Revision history
| Version | Date | Author | Summary of change |
|---|---|---|---|
<<FILL: 1.0>> | <<FILL: date>> | <<FILL: author>> | Initial issue. |
13. Approvals
| Role | Name | Signature | Date |
|---|---|---|---|
| Author | <<FILL>> | ||
| Reviewer (QA) | <<FILL>> | ||
| Approver (Quality Head) | <<FILL>> |
Filled specimen
The following shows the checklist completed for an example fishbone session on a packaging line deviation. The details are illustrative.
| Field | Entry |
|---|---|
| Record/investigation reference | DEV-2026-0398 |
| Date and duration of session | 14-Aug-2026, 60 minutes |
| Facilitator | J. Alvarez (Quality Systems, not the line owner) |
| Scribe | M. Okafor (Quality Engineer) |
| Participants and roles | Line supervisor, two packaging operators, maintenance technician, QA reviewer |
| Tool(s) used | Fishbone, followed by 5-Whys on the surviving branch |
| Candidate causes raised | 11 total across 5 categories; 2 ruled in, 7 ruled out with evidence, 2 left open pending vendor data |
| Root cause(s) / contributing factor(s) reached | Root cause: carton-coding printer’s message-verification setting was reconfigured during a firmware update and defaulted to a lower confidence threshold, allowing a smeared code to pass. Contributing: the firmware update checklist did not include a post-update settings verification step. |
| Open items, owner, due date | Vendor to confirm default threshold behavior on this firmware version, owner: maintenance technician, due 21-Aug-2026 |
| Follow-up session scheduled | Not needed; 5-Whys reached an actionable root cause in-session |
Session notes: the first candidate raised, before silent brainstorming began, was “operator missed the smeared code during visual check.” The facilitator ran the silent brainstorm anyway per the checklist, which surfaced the firmware-update angle from the maintenance technician, a fact the operators had no way to know. Without the silent step, the session would likely have anchored on the visual-check theory and closed with a re-training action that would not have prevented recurrence, since the printer would have kept producing under-threshold codes regardless of how carefully the operator looked.
Common inspection findings this checklist prevents
- An investigation record shows only one theory was ever discussed, with no evidence a broader set of candidates was considered.
- The write-up reads as though the most senior person’s early opinion was simply confirmed rather than tested.
- Corrective actions appear in the record before any stated root cause, a sign the session skipped straight to fixes.
- No documentation exists of who ruled out which causes or why, so “considered and excluded” cannot be demonstrated.
- Open items from an investigation meeting have no owner or date and are never closed.
How to adapt this checklist
- Set your document number, owner, and effective date in the header, and point the governing-procedure field at your real deviation, OOS, and complaint SOPs.
- Adjust the suggested time boxes in section 6 to your typical event complexity; a critical, multi-cause event may need a half-day session rather than one hour.
- Add your organization’s virtual whiteboard or documentation tool name to section 8 so remote participants know what to expect.
- Train facilitators specifically on section 7, the bias watch-list; it is the part of this checklist that a written procedure alone cannot substitute for.
- Confirm every regulation in section 11 against the current published version before issue.