top of page

Event Reviews: How to Fix Problems Without Fixing Blame

Writer's picture: Jake MazulewiczJake Mazulewicz
  • Many incidents involve miscommunications, misunderstandings, and other errors in expert decision-making.

  • Root Cause Analyses weren’t designed for this.

  • So, here’s a unique 6-step process you can use to analyze error-based incidents and help prevent future recurrences.

 Six steps of the Event Review process
Six steps of the Event Review process

Several years ago, I got called to help with an incident investigation in an electric power utility.

 

Several thousand customers lost power unexpectedly.

Executives were frustrated.

They wanted answers.

 

But it wasn’t clear what caused the outage.

 

All we knew is that there were multiple miscommunications, misunderstandings, and other errors between about a dozen field technicians, dispatchers, and managers over about 12 hours.

 

Within the first hour of the investigation, I knew that something was wrong.

 


The two senior investigators seemed far more interested in fixing the blame than in fixing the problem.

 

They treated every error as a failure to be reprimanded, or even a crime to be punished.

 

And what little process they used seemed loosely based on traditional Root Cause Analyses (RCAs) for complex mechanical failures, or some kind of police investigation designed to convict someone of a crime.

 

After a few hours, I told them I thought we were headed down the wrong path.

And I suggested what I thought was a better alternative.

 

Then something unexpected happened.

 

They listened.

After some discussion, they all agreed to use my process instead.

 

So, instead of treating front-line workers as suspects or criminals, we started treating them as trusted colleagues who had great insights on how to prevent similar problems in the future.

 

Instead of searching for root causes of “what went wrong” we agreed that everyone makes errors in every job they do. So we all started sharing insights on simple ways to: apply defenses, improve processes, and build resilience to reduce the risk of errors.

 

Instead of coming up with 10, or 20, or 30 or more corrective actions that would likely just get forgotten or pencil whipped, we distilled our findings down to the 5 or so best process improvements we found. 

 

And instead of writing a 30-page report that nobody would read, we led an interactive hour-long question and answer session with company executives to discuss our results and how to apply them.


Finally, instead of calling this an “Investigation” I called it an “Event Review.”

 

Did it work?

 

The manager who called me into help with the investigation wrote that it…

 

“…was the most thorough and well-documented of any we have had to date... the interviews… were not threatening in any way… we have already implemented some changes to our processes.”

 

Here are the six basic steps of an Event Review.

 

1) Lead an After Action Review (AAR)



In the late 1970s, the US Army developed a simple, quick, non-punitive, post job team debrief that nearly any team could use to assess its own performance and continually improve. They called it an After Action Review (AAR). Though it can take years of practice and a great deal of emotional intelligence to be able to lead AARs well, the basics are very simple. And best of all, you can use AARs to learn from both everyday jobs that go well, and from incidents that don’t. Here’s how.

 

Gather your team together away from distractions. Create psychological safety and agree on ground rules. Ideally assure them that everything said during the AAR will stay confidential, and that no one will be blamed or punished for anything they say during the AAR, unless it violates some civil law (like coming to work drunk).

 

Then discuss these five questions:

 

  1. What did we set out to do in this job?

  2. What did we actually do in this job?

  3. How did it turn out the way that it did?

  4. What should we keep doing the same way next time?

  5. What should we do differently next time?

 

I participated in my first AAR when I was a 19-year-old volunteer firefighter. I found them so incredibly effective and engaging that I’m still leading them more than 30 years later. When led properly, and non-punitively, AARs can reveal basic facts about an incident very quickly, sometimes in as little as 30 minutes. And even more importantly, they can reduce fear, accelerate, communication, and build trust that can benefit your company for years to come.

 

For simple incidents that involve only 1-2 people and perhaps 1-2 isolated errors, you might learn everything you need to know about the incident and end your event review right here! Just write up the key answers to all 5 questions and ensure that everyone in the AAR approves of the write up. For simple incidents, that may be all you need.

 

For more complex incidents, use these additional steps.

 

2)  Write a Target Question



The questions you ask during an investigation or an event review will guide how you think and what conclusions you come to. Most importantly the questions you ask will guide you to treat certain beliefs as unquestionable truths.


The single most important question to ask in any investigation or Event Review you lead is the target question. That question acts as a compass guiding the rest of your Event Review.


So, it’s essential to ask the right kind of target question before diving any deeper.

 

Let’s use the Titanic incident of 1912 as a real world example.

 

Imagine for a moment that you’re in charge of leading the Event Review for this incident. Because the incident is so famous, you likely already know many of the relevant facts. But what target question will you write to guide your Event Review?

 

How about, “Why did the Titanic sink?”

Is that a good target question, or not?

 

In many workshops I lead, most people initially think this is a great target question. Yes, it’s concise. And it will certainly help reveal the flaws and weaknesses that led to the disaster.


Here’s the problem. Understanding why the ship sank is descriptive, but not prescriptive. It tells us what happened. But it doesn’t tell us how to prevent future reoccurrences. 

In mechanical systems, finding the “Root Causes” of why a system failed in the past, does tell you which widget to replace to get if functioning again. But incidents involving misunderstanding, miscommunication ot other complex decision-making errors don’t have a “Root Cause.”


For incidents like this, retroactive questions nearly always lead to analysts assigning a root cause instead of discovering it. That leads to fault finding, finger pointing, and blame. And blame silences learning.

 

So, consider target questions like this. “What lessons can we learn from the Titanic incident to prevent large scale loss of life maritime passenger cruises from now on?”

 

This question focuses your limited time, effort, energy, etc. on finding practical answers to fix the most important problem without fixing the blame.

 

 

3)  Create Timeline & Find Anomalies



Now that you have your target question and some initial facts and details from your After Action Review, you can create a timeline. Timelines are one of the elements of classic investigations that I agree with and find useful.


Here’s the twist.


As you and your team assemble the bits and pieces of data from your After Action Review into your timeline, you’ll notice certain gaps, or you’ll come up with certain questions, or you’ll be confused at certain details.


Label those as “anomalies” as soon as you think of them.


I usually use a single editable Word document for the entire Event Review process. In each Event Review meeting, I project it on a monitor so my entire team can clearly see all the edits in real time.


Every time we find an anomaly in the timeline, I simply highlight it in yellow.


This reminds us come back to it until we answer it or conclude it’s not relevant. As you and your team finish writing your timeline, choose 3 to 7 most important anomalies that you want to explore more deeply -- the ones that are most relevant to answering your target question. We’ll do that in the next step.

 

 

4)  Ask Six Levels of Questions


This is the step where we dive deep into understanding what truly happened with each anomaly and why.


To do this, to start by asking these six questions of each anomaly:

 

  1. How do frontline experts do this job, task, decision, etc. accurately, safely, efficiently, etc., most of the time?

  2. What Individual Actions led to this anomaly?

  3. What Situational Factors led to this anomaly?

  4. What Supervisory Factors led to this anomaly?

  5. What Organizational / Cultural Factors led to this anomaly?

  6. What Process Improvements do you suggest?

 

This unique set of questions gradually evolved over the course of many discussions and event reviews, and was inspired by the work of other thought leaders, including: Eric Hollnagel, Scott Shappell, and Douglas Weigmann.

 

Start with these six questions. But definitely plan to generate your own follow-through questions specifically tailored to your unique incident.

As you ask and answer these questions, make sure to avoid the As, Bs and Cs -- Assumptions, Blame, and Counterfactuals (descriptions of events that you think “should” have happened, but didn’t).

 

This step may take a fair amount of time, since you’ll almost certainly want to interview everyone involved with the incident, plus a few other frontline experts who do that job, but who were not directly involved in the incident.


You may find it useful, as I have, to use a simple FAQ or Q&A format in your Word document to capture both the question you asked and the verbatim answers you get.

 

 

5)  Distill 3-7 Best Process Improvements


Once you’ve answered all your questions about the 3 to 7 anomalies you identified, you’ll have lots of ideas. At this point, in one large incident review I led, we had about 30 ideas for good process improvements.


Some traditional investigations list out all of these as corrective actions. I disagree with that approach.


Why?


That big of a list almost always feels intimidating or overwhelming. So it either gets pencil whipped, or slowly ignored over time.

 

So take the time to identify a small and manageable number of process improvements to present to your leaders as your conclusions. I find a 3 to 7 is an ideal number to aim for.

 

As you and your team debate or even argue over which 3 to 7 process improvements to include, something interesting will happen. You’ll wind up having to be brutally honest, transparent, and concise about the pros and cons of each process improvement. This allows you to separate the great from the merely good.


Your mission?


Identify the 3 to 7 process improvements that are lowest risk, lowest cost, lowest maintenance (easy to implement), highest value, and non-obvious.

 

Here are two quick examples from the Titanic incident.

 

First, abandon the idea that any ship is ever “unsinkable.” Instead, design every ship, assuming that at some point in its life, it will start to sink and take on water. That one process improvement will lead designers to build ships with fail safes, resources-in-reserve, and other elements to make it more resilient.

 

Second, have crews regularly practice hands-on, live action, high-fidelity emergency drills, using actual rescue equipment whenever practical. For example, lifeboat drills or person overboard drills. Debrief each of these emergency drills with an AAR, then share insights and lessons learned. This will build trust, confidence, engagement, and create a priceless cycle of continuous learning.

 

 

6)  Share, Apply & Follow Through


Instead of spending days or weeks writing a 30+ page report that almost no one ever reads, consider this much simpler and more practical alternative.


Prepare a 10 to 12 slide PowerPoint presentation. Include these key elements on separate slides: the event title, your target question, a summary of this six step process you used (a.k.a. your methodology).


Then simply show your 3 to 7 recommended process improvements separately, one per slide. Then, plan on spending about 20% of your time presenting your slides, and about 80% of your time discussing them. That’s it!

 

Schedule about 30 to 50 minutes to lead this interactive briefing with the executives or senior leaders who commissioned the Event Review in the first place. Don’t drown them in the hundreds of details.


Instead, give them the BLUF, (bottom line up front). Then invite them to ask questions. For each process improvement, decide: who will take responsibility for it, when they will take action on it, and how they will update everyone on progress, completion, and final results.

 

Those are the basic steps of how to lead an Event Review.

____________


  • This article will be published in the April 2025 issue of "The Sentinel" from the International Institute for Risk and Safety Management (IIRSM.org).

  • The magazine is only available to IIRSM members.

  • But I can share a copy of my article publicly.

  • Contact me to get a copy.  

____________


I'm Jake Mazulewicz. I help technical experts prevent dangerous & expensive errors. I lead workshops, keynotes and Event Reviews for clients worldwide.

Contact me at jake@reliableorg.com or connect with me on Linkedin.

 
 
 

Comments


bottom of page