Why Projects Fail

I listened to a recent podcast (several times in fact) featuring Patrick Hynds on DotNetRocks.com. I thought I would share some real gems I found in there. The following info was culled from that interview.

Let’s start with some agonizing realities:

• About 50% of software development projects fail
• About 60% of off shore projects fail, but they’re cheap, so people keep trying
• Agile methodologies improve success, yet about 30% of those projects fail

Patrick lays out some fundamental principles that resonated with me. These principles tend to leave deep scars when you deviate from them. I encourage you to listen to the podcast the next time you’re on a drive, riding the bus, or washing the dishes after a meal. Just to whet your appetite, here are some of the high points.

Status
No status, no check. The team needs to communicate status to the project manager. If you don’t report on your status, Patrick assumes you were not working and fires you for job abandonment. What doesn’t get checked doesn’t get done. Most people do a status check, but not until late in the project when things are hard to fix. Do them early and often.

Never Assume
When you assume, you make an ass out of you and me. When you make a statement and have no proof, then I’ll pick my opinion over yours any day of the week. You must have evidence to back up your statement.

Don’t Be Wishful
A project is not done until after the coding is done, followed by *lots* of other things. When Patrick asks if something is done, the answer is either “yes” or “no, and this is why”. There are no “yes, buts”. Everyone needs the same definition of “done”. If you haven’t confirmed it with the customer, then it’s not true.

No Spec, No Estimate
Patrick will happily work for you from now until the end of time to rewrite, redesign, or recode anything you ask of him on a T&M basis. A lot of people want a fixed bid price when they give a T&M spec.

Here’s a great analogy for when a client might bring you onsite, walk you through their existing application, explain what they didn’t like about it, and then expect a fixed price bid proposal for the new system:

Suppose I asked you to build my next house. I show you my current house, and explain what I hate about the doors, the stairs and windows. Can you give me a fixed bid on my new house? Of course not. You only know what annoys me. I haven’t told you what type of materials I do like or what type of building would make me happy. Software applications are a close analog to this.

And here’s what I found most inspirational in Patrick’s statements:

“If we can reign in that failure rate, so that we fail just 5% of the time, think about the productivity boost to the country and the world.”