I read a post by Lydia Leong of Gartner on her blog about the 5P’s for root cause analysis for any given problem (the 6th P). You can read the entire post here.
In the post the 5P’s that she talks about allow someone to go deep to find out what really happened and understand why it happened, so that whatever correction action needed to be taken can be done to avoid a similar problem arising again.
She picks this framework from Macneil’s Five P factors model used in medicine/psychology and applies it under the IT management.
The first ever boss that I worked for had taught me that if you are not making mistakes, you are not pushing the envelope at all and if you are making the same mistakes again and again, you are not learning from them at all. So, in order to learn from our mistakes, we need to diagnose what happened and put in measures that avoids the same mistake from happening again.
The 5Ps’ that Lydia talks about are as below:
The presenting problem is not only the core impact, but also its broader consequences, which all should be examined and addressed.
The precipitating factors are the things that triggered the incident. There might not be a single trigger, and the trigger might not be a one-time event (i.e. it could be a rising issue that eventually crossed a threshold, such as exhaustion of a connection pool or running out of server capacity).
The perpetuating factors are the things that resulted in the incident continuing (or becoming worse), once triggered.
The predisposing factors are the long-standing things that made it more likely that a bad situation would result.
The protective factors are things that helped to limit the impact and scope (essentially, your resilience mechanisms).
The present factors are other factors that were relevant to the outcome (including “where we got lucky”).
– Lydia Leong on Gartner
If you look closely, I believe that you can compare this with my earlier post about listening as leaders.
In this post, I talk about the different levels of listening that leaders can adopt (What happened?, What did we make it mean?, What was it really about?, Are we missing something?, What’s this connected to? and finally, So what?
I believe that both these frameworks are working towards the same thing. We need to understand what happened (irrespective of whether it is a problem that we are trying to solve in an IT deployment or it is a inter-personal challenge between two colleagues or when we are trying to find out the reason for the runaway success or failure of the product that we recently launched), why it happened and what does this mean for our future.
If what happened is important, it warrants an analysis and irrespective of the framework we choose, we need to have one in place, one that enables us to think in full spectrum.
If as leaders, we are able to consistently do this, it has a supersized impact on our business. It improves our success rates as leaders. It creates a culture of thinking full spectrum within the team and creates future leaders who will continue to think full spectrum wherever they go.
