audio


 

 



Blame Failure On Your Project Stakeholders

by Josh

Blame Failure On Your Project Stakeholders

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.

(Important point: This is where it’s tempting to place blame on ‘those guys’. Don’t let the 5 Whys turn into the 5 Blames here. Think about the process, the system first. Usually it’s not a bad apple.  But sometimes it is….)

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.

Leave a Comment

{ 2 comments… read them below or add one }

Joan Sellers February 3, 2012 at 12:30 pm

Many times we find that one symptom is the oversight in targeting the stakeholders. There may be a significant ‘user’ that is overlooked due to size. One lone individual that may be a key asset in observation and testing. This is a shortfall that I have observed several times. Make sure to cover all the bases when determining the stakeholders that are impacted by the changes that you are working to implement. Though only one or two people, they can be your greatest ally in identifying weaknesses that could cost you time and money later on.

Example: I was handling the phones/reception for a company that had 22 offices globally. I was the primary user of the company “people-finder” website. IT decided to make major adjustments and deletions from the information and location process on the site. Though reception used this tool in 90% of their job, they were never included in the project to revamp the site. Once the changes were rolled out, IT had to spend much time making further changes and putting things back in because reception couldn’t do their job without those tools that were removed. The rest of the employees used this tool maybe 2% of their work time and they were the ones that were invited to review the project. Lots of wasted time and frustration.

Reply

Josh February 4, 2012 at 2:35 pm

Perfect example and point Joan! And I’d bet money that a 5-whys analysis on the problem “We had to do a ton of rework” would have yielded a solution about better stakeholder identification.

Reply

Previous post:

Next post:

audio