We all screw up from time to time.
It’s in those moments when the most important thing is to know who to blame.
Blame Management
Just kidding.
I just had an eye-opening experience. One of those ‘duh’ moments where something didn’t go as planned with my project. It was a simple, small piece of our system design that sounded great in discussions and on paper, but turned out to be unworkable.
After beating myself up a bit because we should have been able to discover this about 5 months ago, I reframed the problem.
Here’s how.
The 5 Whys
Developed by Sakichi Toyoda, this technique for root cause analysis is a big part of Lean Thinking. It’s also what we just used on my team to extract a big lesson learned from this problem.
Very simply, you start with the problem and ask why it happened. It’s important to not place blame per se and focus on objective causes instead.
Here’s an example that’s fresh in my mind, made generic for public consumption.
The Problem
Even though all stakeholders got together to discuss the new design and no flaws were found with it, we have uncovered a fatal flaw with the design now. It could have been discovered 5 months ago but was only found just now.
We’ve already solved the technical problem, what we’re doing here is discovering why it was a problem in the first place and why it took so long to discover it.
Why # 1
Why did a flawed design get universally accepted as valid?
It looked good to everyone at the time. We didn’t spot the flaw.
Why # 2
Why didn’t we spot the flaw?
This was an implementation detail no one thought about at the time.
Why # 3
Why didn’t anyone think about this implementation flaw at the time?
Because we hadn’t implemented anything.
Why # 4
Why hadn’t we implemented anything 5 months ago to validate our design?
We don’t release software until our waterfall milestones come around for major releases. Our development is done in silos with coordinated releases. We didn’t have a minumum viable product (MVP) or prototype to work with.
Why # 5
Why didn’t we have an MVP or prototype to work with?
Because we have not fully adopted lean thinking in this area.
Solution
Further adopt lean thinking and processes by developing rapid prototype code every time there is a major design change, a minimum viable product (MVP). Iterate on the MVP while getting continuous feedback from stakeholders.
Original link: Blame Failure On Your Project Stakeholders
Related posts:
Fantastic post, Josh. You know, those “5 Why’s” are one of the enduring lessons from my project management training…and yet I never use it to get to the root of failure (at least, not formally). This post is a great reminder.
So often we blame people vs. a process that got us to a point of breakdown. It’s never one person that leads to a loss. There’s always a team of folks and a perilous path that led to the moment of recognition that something has gone (terribly?) wrong.
Thanks Andy. The trick is that when things go wrong, it’s human nature to point the finger at the other guy, the team across the hall, etc. That’s why the process along is necessary, but not sufficient. The facilitator of the 5 Whys process must possess the leadership ability to stop the blame game and refocus the group on root causes and looking at the chain of causes as a value stream — a system from end to end. The systems thinking mentality is key.
Although I will say this…there ARE times where the root cause is a disgruntled sponsor, team member, customer, or other stakeholder. In those cases we need to realize that office politics is also part of the system, and there may be actions we can take to address the root cause of people who aren’t working well with us, and nurture that relationship. Sometimes it’s as simple as giving candid feedback to the sponsor who isn’t being supportive or making a team member aware of the impacts of their behavior.
The great thing is, if you’ve done a good 5 Whys analysis you have something very objective and concrete from which to base your feedback. Walk them through your analysis and how you came to this conclusion and see if they agree. Better yet, make them a part of the analysis in the first place if it’s clear in the beginning they are part of this system (chain of causes).
And sometimes when all else fails, you have to fire people. But that’s a different discussion…
Yep Robert, I was just kidding. I admit, it was a bait-and-switch tactic but my message is the exact opposite of the title.
I agree with your conclusion on constantly keeping the stakeholder involved in the project work but, how successful of a career does a project manager have if they focus the blame on the stakeholders?
It is best to examine what you did wrong as the project manager because this will make grow and develop. Even if you are only 1% to blame for the failure, it is the 1% you can improve because you will have an impossible task of trying to improve the stakeholders.
Sometimes you have to overcompensate in your work to make up for the lack of ability and focus in your stakeholders. That’s just part of the job of delivering a successful project.
Thanks Bill. I think my intent wasn’t clear, probably because my joke didn’t come across as distinctly as I would have liked. My message is the complete opposite of blaming anyone, and instead focus on the process of learning from problems by using systems thinking and lean approaches.