The "theory" of 5-whys is that with a proper mindset and the right questions (coming out of that mindset), you can find a root cause to anything in at most 5 linear steps.
You are certainly free to adapt it in whatever way you wish, but you don't call that "5 whys" anymore. TBH, your approach looks closer to fishbone diagrams instead.
>The "theory" of 5-whys is that with a proper mindset and the right questions (coming out of that mindset), you can find a root cause to anything in at most 5 linear steps.
I have never heard of this before. I had heard that the 5 why's was a way to force a person or team to be more than surface level about why a feature is needed or a problem happened.
And also, ONE way to represent the work was through a fishbone.
But part of the 5 why's is that multiple "why's" converge (e.g. why did this break? because we have no change control... why does X process suck? Also, because we have no change control)
My favorite feature of 5 why's is they push you into going deeper. If a process keeps failing, the 1st level reason for the failures can be different (X person changed the data, dates suck, the primary server crashed), but the 3rd or 4th reasons should show some similarities and ideas on how to prioritize (e.g. if we have automated unit tests, it would have prevented 25% of our outages!)
You are certainly free to adapt it in whatever way you wish, but you don't call that "5 whys" anymore. TBH, your approach looks closer to fishbone diagrams instead.