So, you’ve investigated a problem, asking why and how.

Now you’ve got to write up a root cause analysis report. And that’s where the art comes in.

A good RCA is one that can, ideally, be used to make changes at the root cause to avoid having this sort of problem occur again.

In some cases, an RCA won’t be able to achieve that goal, but even then it can provide value if it helps make clear how to work around the problem, or why the problem cannot be easily solved.

So a RCA report should focus on what is relevant and actionable for the audience.

In this application crash example, talking about issues around development practices (compiler settings, IDEs, code review practices) might be quite helpful for the developers, but it doesn’t help the end user of the software; they can’t influence the development process. Instead, focus on what is actionable for them. In this example, this could include both staying current on maintenance releases, and making sure the relevant details of the end user’s scenario or environment is communicated to the developers, so they can be included in test cases.

So you might produce an RCA for the customer from this which focuses on those aspects, and doesn’t go down the development path. Of course, it’s still a good idea to share those items with the development team!

Related posts:

Root Cause Analysis: Five Why’s

Root Cause Analysis: Don’t just ask “Why?” — also ask “How?”