project management

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.

{ 2 comments }

Project Management Myths Debunked

Oh yes, let’s have fun with this one, shall we?

I want your myths in the comments, bucko!

Good Project Managers Make All Decisions By Themselves

While it’s true that project managers do have to make the final decisions in many cases on a daily basis, we certainly should not make them by ourselves. We utilize a portion of our daily stand-up meetings on my teams for discussion topics. These can be technical decisions or issues someone has run into which need to be addressed, or sometimes it’s just a new idea someone had about how to make our product better.

There are cases where I ask various individuals what they think and then make a decision, and other cases where I can delegate the decision to a team member or lead. Whenever possible, I like to have the team make their own decisions and not rely on me for this. Intelligent empowerment makes for a better team and a better end product.

Good Project Managers Deal With Problems Themselves

Dilbert.com

There is an ironic reality in which the more you fear failure, the more likely you are to fail. I’ve seen project managers try to cover up problems many times, and I’ve even done it myself. But that’s not a good way to run a project. The more open and transparent you can be with everyone, the better your chances of success. This is because you build trust by being open and honest, and you get help from other players when you need it.

Good Project Managers Are Control Freaks

Many have the image of a project manager as being a micro-managing control freak. Scheduling down to the nth degree is the best possible schedule, right?

Wrong.

I think the best project managers I’ve worked with do the exact opposite. They let the team manage their workflow and concern themselves mainly with interfaces to other teams or dependencies of some sort. I think project managers should be just another participant on the team when it comes to managing the day-to-day workflow of the team, unless the team runs into a problem and asks for help. For example, sometimes team members may have difficulty making a priority call about what to work on next. The project manager (or product owner if you are doing Scrum) can help by prioritizing items in the backlog this way.

Good Project Managers Make Projects More Complex

Dilbert.com
In my experience, this happens when the models of the project (WBS, schedule, etc.) do not accurately reflect reality. There certainly are cases where the project really IS that complex too. I think the best project managers are able to employ the least amount of complexity in project planning and execution artifacts as is possible and responsible.

If every one of your stakeholders can’t look at each and every project artifact and understand it intuitively, it’s too complex.

So, what project management myths would you like to debunk in the comments? I’m excited to see them!

{ 4 comments }

Your Customers Don’t Care

Thumbnail image for Your Customers Don’t Care by Josh April 5, 2011 Leadership

I was in a local cafe the other day working on a Kanban training course I’ll be making available sometime soon. I grabbed the usual coffee for fuel and then a sugar avalanche of a toffee bar caught my eye. And I bought it. Because I have no impulse control whatsoever. I chewed the first [...]

Click to continue…

Project Management Institute NA Global Congress 2010 Webcast – Part 3

Thumbnail image for Project Management Institute NA Global Congress 2010 Webcast – Part 3 by Josh October 28, 2010 Lessons Learned

Dux corralled Bas De Baar, Cornelius Fichtner, and myself and we did a collaborative webcast on Ustream while we were at the Project Management Institute’s North America Global Congress in Washington D.C. Bas provided several lessons learned for us in this video: Focus on “What does ‘done’ look like?” – specifically to your stakeholders Focus [...]

Click to continue…

Project Management Institute NA Global Congress 2010 Webcast – Part 2

Thumbnail image for Project Management Institute NA Global Congress 2010 Webcast – Part 2 by Josh October 25, 2010 Lessons Learned

Dux corralled Bas De Baar, Cornelius Fichtner, and myself and we did a collaborative webcast on Ustream while we were at the Project Management Institute’s North America Global Congress in Washington D.C. Cornelius discusses the importance of building customer relationships early in this segment, and focusing on your customer. His second point is on the [...]

Click to continue…

Project Management Institute NA Global Congress 2010 Webcast – Part 1

Thumbnail image for Project Management Institute NA Global Congress 2010 Webcast – Part 1 by Josh October 21, 2010 Lessons Learned

Dux corralled Bas De Baar, Cornelius Fichtner, and myself and we did a collaborative webcast on Ustream while we were at the Project Management Institute’s North America Global Congress in Washington D.C. We went around and discuss our top 3 lessons for project managers in general, and then gave our thoughts about the conference. I’ll [...]

Click to continue…