Preventing Project Failure

I realized today that I never wrapped up the Making Theory Usable series.  The idea for Making Theory Usable was to provide useful tips to mitigate for project failure in six key problematic project areas.  I wrote posts based on the top reasons for IT project failure summed up by the UK’s National Audit Office  to elaborate how to fix project problems within those areas.  Note that I added my flavor based on my own experience.  To recap, the project failure areas are:

Intent Failure – Occurs when the project doesn’t bring enough added value or capability to beat down the obstacles inherent throughout the process.  This suggests the original intent of the project was flawed from the beginning.

Don't think about it, just use it

I have some highly talented PMs on my team and my goal in all of this is to allow them to have the tools they need to quickly ascertain if they are on track for project failure or not.   I think that theory is most useable day-to-day when it can be quickly and easily applied.   To provide a metaphor from emergency medicine, it’s not the fact that you know what the ingredients are in Neosporin, or that a band-aid should be sterile.  Rather, it’s that you know to keep a supply of antiseptic wound  cleaner and  band-aids handy to use right away should the situation arise.  This is the true application that makes theory and science usable.

In that spirit,  I’ve distilled a list of 6 key questions from the Making Theory Usable posts that help get the analytic juices flowing when trying to figure out where your project is hurting.  I won’t bore you with re-hashing everything in the posts, so if you want more details in each area, links are provided for you above.  Anyhoo, here is a list of questions that can enable you to quickly ascertain if your project is headed down the project failure chute:

6 Project Failure Questions:

1. Is the project bringing clear value add and capability?
2. Is the project sponsor engaged?
3. Is the project scope clear?
4. Do the team members/suppliers understand what they are supposed to do?
5. Are communications frequent and honest?
6. Is project methodology enforced?

This list isn’t perfect but if you can answer yes to all of them, I doubt that your project will fail.  If you can answer no to any of them, my suggestion would be to dig deep into that area and see where you can plug the leaks.  If you answer no to almost of all of them, I would say that your project is in deep trouble.

Run your Project like the Navy runs boats

Ok – so the analogy is like this.  Think of your project like a Navy boat. There’s the Captain, he’s like the Project Sponsor.  There’s the whole reason you are out on the sea,  that would be the Intent of the project.  Then, there is what you are supposed to be doing on said sea; ie where you are going and what your mission is, that would be the Scope of the project.   The various sailors on the boat are the Suppliers/Vendors on the project.  And you, Project Manager, you are the Executive Officer, the XO (the Denzel), the person making it all happen.  You are manning the communications and ensuring that everyone knows what’s going on, you are following process and methodology.  You’ve got a guy on the lookout, constantly scanning the seas for risks like iceburgs and enemies and you are coordinating it all and communicating up and down the chain.  To the extent that you are disciplined and coordinate and enforce communications, is the extent that your ship is tight.

Let’s break down this analogy into our project failure checklist areas.

Intent failure – Is the project bringing added value and capability?  In our analogy, the national interest of the United States combined with achieving geo-political dominance and protection are probably good enough reasons to put some big boats on the water.   I’d say that intent is a good, clear one.

Sponsor Failure – Is the project sponsor engaged? Well, hey, we’ve all seen the movies with whisy washy Navy captains, but I think that’s probably a bit rare.  Can you imagine if you went to the captain with an issue and he was like “Ya know..I’m just not sure…yeah, I didn’t even realize – where are we again?  Gulf of Mexico? I wasn’t paying attention.  Hmmmmm..maybe we should get a committee to talk about this.”  Not!  You need a clear decision  – and that is what a good sponsor does.

Design and Definition/Scope Failure – Is the project scope clear?  Not to be confused with intent – this is more about the details of what the mission is.  So, in our analogy, the intent is to protect the United States – no argument there.  But does that mean patrolling lake Michigan against the Canadians?  Probably not .  And then there is even more specifics; ie coordinates, and how you reach those coordinates.   And what do you do when you reach those coordinates?  If you don’t know where you are going and why you are going there, then you’ve fallen victim to the scope failure.

Project Discipline and Communications Failure – Is project methodology enforced?  Are communications frequent and honest? Well, on a Navy boat, discipline is part and parcel of the game.  So this is not an issue.  There’s someone looking ahead for risks at sea, there’s another capturing important readings and analyzing them, there’s another making sure all the communications equipment is fully functioning.  And they all report to the XO who is monitoring all of it.  The PM is like this.  On your project,  who is watching for your risks? Who is measuring your project variances?  Who is making sure that your communications are happening clearly and deliberately?  That’s most likely you, Project Manager.

Supplier/Vendor failure – Do the team members understand what they are supposed to do?  On a Navy ship roles are clearly defined, the hierarchy is clearly defined, and when the time comes to act, everyone acts in unison as a team.  For us landlubbers, it’s not that easy, but the important point is that everyone knows their role and that everyone understands the mission.   Further, there’s got to be flexibility for changes from the bottom up as well as the top down.   Communication has to go both ways, if an ensign observes something that can affect the boat, the XO should listen and allow that ensign to adjust so that the mission is satisfied.

Final Thought  I think there’s a lot to be gained by looking at the world around us using the lens of the 6 project failure questions.   You can ask these questions of sports teams or community organizations or political action committees…or YOUR projects.  If anything, they’ll help point you in the right direction if you get a funny feeling about your project, but don’t know where to start digging.

12/17/2009 Update – TechRepublic created a video from the content of this post – check it out >>>>http://blogs.techrepublic.com.com/hiner/?p=3464

• • Comments [7]
  • Tags [project failure]
  • Categories [Communications, Making Theory Usable Series]