Ideas on avoiding project failure

In December,  Pawel Brodzinsk post the following article on his blog, Failed Projects: You Can Do Worse. In that article, he puts a really good list of contributors to project failure. While Pawel writes from a formal project environment, I find his list of contributors project failure relevant to informal PM environments — Cottage PM.

Here’s his list in summary (you should read his post for more perspective):

• Crappy Estimation
• Scope Creep
• Wishful Thinking
• Ignoring process on client side
• Compromising quality

These risks face any project, but may be even more risk for you in an informal project environment. Just because your organization may not use formal PM practices doesn’t mean the project you’re undertaking doesn’t have a big upside or downside for the organization. You’re doing the project for some reason, and you need to deal with these risks.

You don’t have to use fancy PM tools to handle it (although you can). But fancy tools or not, you have to start in the same place:  Just be aware of the risks and handle them in your own way. Do it in a spreadsheet. Do it on the back of a napkin. Speak in terms of end results and impact, always in light of the intended results and payoff for the organization, and you’ll get more traction.

For example:

• Crappy estimating: Whether you have a formal estimating process or not, you’ve made some assumptions and some estimates on cost, time, quality, scope, etc. Are those estimates sound? Or are you in a totally new space, using a new technology, and really have no basis for estimates? Maybe you can’t change it, but you can help everyone know the risks associated with that weakness.
• Scope Creep: Using whatever process and approach you like, did you lock in the project vision and scope? Do you all know and agree on “what done looks like?” Do you have a clear list of deliverables? Are the specific enough to provide a basis for control of the list? (Tip: Consider using a Work Breakdown Structure – WBS – to provide better visibility to scope. Click here for some more info about using WBS.)
• Wishful Thinking: Yeah, well, you know better.
• Ignoring process on client side: This may be less of an issue for you if you’re working within your own organization instead of hiring your PM services out to a client. Still, even if you’re working with other internal organizations, such as your IS&T group, then you need to explore this possibility.
• Compromising quality: If you lose control, this may be the last ditch effort just to get something out the door, something delivered. But something bad could be worse than nothing at all. Be careful.  Re-scoping is valid as constraints change, but do it openly, consciously, purposefully, and knowing full well the impact of the changes.

If you do some very basic project planning, and focus work on the WBS, you can avoid myriad problems, even if — perhaps especially if — you’re new to PM.

No related posts.