Sometimes an incident is so complex that a linear "5 Whys" chain is insufficient. Multiple independent failure threads converged simultaneously, and you need a way to map and categorize the chaos before you can analyze it.
A Fishbone Diagram — also called an Ishikawa Diagram or Cause-and-Effect Diagram — is a visual brainstorming tool that helps a team systematically explore all possible contributing factors across multiple categories at once.
How to Build One
Draw the problem statement at the "head" of the fish on the right side of a whiteboard or collaborative document. Draw a horizontal spine extending left. Off the spine, draw angled "bones" for each major category of failure. Then brainstorm specific contributing factors as smaller branches off each bone.
Common categories for software incidents:
| Category | What to Examine |
|---|---|
| Technology | Hardware failures, software bugs, network issues, dependency failures |
| Process | Skipped deployment steps, unclear runbooks, missing review gates |
| People | Fatigue, knowledge gaps, miscommunication, unclear ownership |
| Environment | Cloud provider changes, traffic spikes, seasonal load, regulatory changes |
By forcing the team to look across all four categories, you prevent the common failure mode of fixating on the most obvious technical cause while ignoring the process or organizational factors that made the technical failure catastrophic.
Key Point: The Fishbone Diagram is most valuable as a facilitation tool during the post-mortem meeting itself, not as a deliverable. Use it to structure the group discussion and ensure all voices are heard. The output — the identified contributing factors — then feeds into the written post-mortem report. Teams that skip this structured brainstorming phase tend to produce post-mortems that reflect only the loudest voice in the room.