Root Cause and “5 Why’s”

This week, we’re working with a team in Atlanta, and we did an exercise today where the students went through problems they were having, and then the issues which underlie those problems. One of the interesting things was how often the underlying "issues" weren’t issues at all because they weren’t going deep enough.

As an example, let’s take an issue that was listed titled "Managing Dependencies." Is managing dependencies really an issue? I would argue no, it’s not – at least not by itself, because in fact managing dependencies is a good thing. Even if you turned it around and said "Not Managing Dependencies" was an issue, it isn’t descriptive – after all, that could be a solution to an organization that was too strictly "managing dependencies"!

Rather than argue semantics, let’s look at the root cause and ask some of the 5 Why’s around the listed item to see what root cause we can get to. The exchange I had with the team looked like this:

Me: Why is ‘Managing Dependencies’ an issue?
Team: Because we lock down requirements from teams.
Me: And why is that an issue? Doesn’t seem like that harms anything.
Team: Because we have an architecture team and a shared services team, and they both have to be locked down.
Me: OK, but I still don’t understand why that’s a problem.
Team: Because we need those components in other parts of our products.
Me: Well, then it seems to be a good thing to lock it down! (Wink, wink)
Team: No, it’s not, because when we discover we need a change to one of the locked down systems, it has to be put into the queue.
Me: And why is that a problem?
Team: Because it means that we can’t respond to changes late in the cycle!
Me: So the *problem* is that you are having difficulty responding to changes late in the development cycle, correct?
Team: Yes.
Me: And the issue that is causing that is…managing dependencies?
Team: Not…really. It’s because we have component teams, and have to do handoffs between them.
Me: OK, so your problem is that you are having difficult responding to change, and one of the underlying issues is that the component team model you all have established introduces handoffs and delays into the process?
Team: Bingo.

Now, of course we probably all had a tacit understanding of what "managing dependencies" meant. But it is important that we build a culture which converts tacit knowledge to explicit knowledge to allow us to both understand and begin addressing the impact and the potential solutions available to us.