On-screen

Narration

Anna: We've spent time exploring how to hold post-mortems without pointing fingers. Now we need a toolkit for digging into the technical reasons behind failures. We'll cover two proven methods: the Five Whys and the fishbone diagram. Each provides a step-by-step path to go beyond symptoms and uncover the underlying system weaknesses.
Greg: Using a framework keeps the conversation grounded in evidence rather than opinions. Everyone participates by examining facts, which builds a shared understanding of the incident. These methods also help with documentation, since the process itself guides what to record. We'll see how they fit into the overall post-mortem workflow and how you can apply them in your own environment.

On-screen

Narration

Anna: Without a framework, teams often jump straight to a fix and miss patterns hiding in the data. When we slow down and follow a structured approach, every step requires evidence. This keeps the analysis objective and prevents the conversation from veering into blame or guesses.
Greg: Frameworks also save time over the long run because they are repeatable. If each incident is analysed differently, new members struggle to learn. By following a shared checklist, we build a knowledge base of root causes, which in turn improves reliability metrics like MTTR. Studies show companies using consistent RCA methods cut repeat incidents by over fifty percent.

On-screen

Narration

Anna: The Five Whys method begins with the problem statement. Let's say a website went offline. We ask, "Why was the site down?" The first answer might be "The database became unreachable." We then ask, "Why was the database unreachable?" Maybe "Because a deployment script changed the network settings." The next why digs deeper: "Why did the script change them?" Because there was no peer review before the deploy. "Why wasn't there a review?" Because our automation pipeline doesn't enforce it. At the fifth why we discover the real issue: the pipeline needs a mandatory approval step.
Greg: The trick is not to stop after the second or third why. Each answer should be backed by evidence so we avoid speculation. It's easy to fall into solution mode too early, but the point is to expose the hidden weakness in the process. Document each question and answer chain so others can follow the logic later.

On-screen

Narration

Anna: A fishbone diagram looks like the skeleton of a fish, with the issue at the head and major cause categories branching off the spine. Common categories include People, Process, Technology, Environment, Materials, and Methods. For each branch you list possible contributing factors. In an IT context, the "Technology" branch might include network configuration, while "Process" could reveal gaps in change management.
Greg: This technique works well when failures have several intertwined causes. The visual layout helps teams brainstorm systematically without losing track of ideas. As you fill in the branches, patterns emerge that highlight where to investigate first. Draw the diagram on a whiteboard or in collaboration software so everyone can contribute. It's also a good way to record findings for future reference.

On-screen

Narration

Anna: So how do you decide which tool to use? Start with the Five Whys if the problem seems to follow a single chain of events. It's fast and requires nothing more than a whiteboard. If the conversation stalls or new branches appear, switch to a fishbone diagram to capture the wider context. Sometimes you'll use both: the fishbone to map categories, then a Five Whys on each branch.
Greg: Keep in mind that no tool fits every situation. Highly complex or political issues may need a formal investigation beyond these techniques. Always document the questions asked, the evidence gathered, and the conclusions. That record becomes part of your post-mortem notes, and it helps the next team understand how you arrived at the root cause.

On-screen

Narration

Anna: Whether you prefer the simplicity of Five Whys or the visual power of a fishbone diagram, the goal is the same: uncover the underlying cause so you can fix it for good. Treat each incident as a chance to strengthen your system, not as a failure to hide. When done consistently, these frameworks build a culture of learning.
Greg: Make it a habit to share your findings with the whole team and to track the resulting action items. Over time you'll see patterns in your incident trends and you'll develop a more robust improvement process. Mastering these analysis techniques is a valuable skill for any IT professional who wants to lead problem management efforts.