The Top 7 Reasons Projects Fail

August 30, 2007 at 11:04 am 5 comments

We’re cowards, we lie, we cheat, we don’t plan, we’re too optimistic, we steal and we make it all up as we go along – but other than that? We’re well intentioned.

1) We’re CowardsBefuddled
A project is only as good as the accuracy of the last status report – which means that most projects are doomed from the very first status meeting. Why? Because we’re afraid to provide accurate assessments of project progress.

We could try to argue that it’s not fear that prompts us to lie (we’d prefer the words ‘spin’ or ‘shade’) about where we are on the project, about how badly we’ve missed a deadline, or how hopelessly clueless we are about the problem that’s delaying us. If it’s not ‘fear of consequences’ that prevents accurate reporting then what is it? The version of the Project Management tool we’re using?

2) We Lie
From the very first moment a project is presented to us we begin to lie. We offer estimates of how long we think it will take us to deliver the project, and swear that they are an accurate assessment of the work involved, time required and eventual cost.

What we always fail to mention is that we’ve factored in things that have nothing to do with the doing. Things like, our perception of what we think you want to hear, our overconfidence in our ability to deliver, our financial need and how if we don’t take this assignment we won’t be able to pay the mortgage,

3) We Cheat
We can always get ‘back on schedule’ by doing less and cutting the unseen corners. We whine about scope creep and hide the secrets of scope erosion. There are vital design elements never included in the client’s spec’s which need doing regardless of the client’s savvy. We include them when originally estimating the project, but when that clock on the wall begins ticking too quickly, we’ll sacrifice quality on the altar of false pride.

4) We don’t Plan
Here’s a golden yardstick for measuring a person’s ability to deliver a project on deadline. If they can’t make it to a meeting on time, they cannot deliver a project on time. Other than the fact that the former is far simpler than the latter, there’s no difference between arriving on time to a planned meeting and delivering a project on time.

Just like catching a plane, or attending a meeting at noon, projects with pre-determined deadlines are planned by thinking backwards. If I have to catch the plane at 3:00pm, then I need to be at the airport by 1:00pm. If I have to be at the airport at 1:00pm, then the cab must pick me up at 12:30pm… since the cab is often late, I’d better order it for 12:15pm. Since the cab will be here at 12:15pm I’d better be ready by 12:00pm… and so back we step, and so back we plan.

5) We’re too Optimistic
We suffer from an over inflated sense of future ability. It’s summed up by the following mantra, “Tomorrow we’ll be more productive than yesterday.” Here’s a hint, when we’re 10 days into a 100 day project and we’re already 50% behind schedule, we have a problem. Not a little problem, a huge problem. We will not, regardless of our best intentions, more than double our demonstrated level of productivity in the remaining 90 days. If we do… then a pointed question needs asking, “Why were we slacking off in the first 10 days?”

6) We Steal
When we constantly shift priorities, when we add work to projects on the fly and neither add resources nor extend the deadline, then we’re stealing from our current integrity and future credibility. A project plan is a promise, both to ourselves and to our clients, and every deviation from the plan is self theft of the highest order. We can’t ‘borrow’ time from a critical path, the time taken is time lost.

That’s the definition of ‘critical path’. Like the Knights Templar, the role of a Project Manager is to protect the project path from bandits and brigands to the the very bitter end, with their broken bleeding bodies and last gasp of breath.

7) We make it up as we go along
thinking To add some soothing salve to the wounds I’ve inflicted, here’s an inevitable truth regarding all projects (and even of life); We make it up as we go along.

Where we go wrong is that we come to believe our estimates are anything but our best guesses.

We allow considerations other than those directly related to the work in the project and the available resources, to dictate schedules and priorities. Not to mention quality. None of the transgressions mentioned are executed out of malice. We never (okay… we rarely) deliberately strive to make a project fail. All of the above ‘failings’ are a result of normal, daily workplace pressures. It’s not that we can’t alleviate, or even avoid, these pressures, it’s just that they exist and create the environments in which projects crash and burn.

In spite of all the above… we’re well intentioned, but good intentions are seldom enough to bring a project home safely.

Advertisements

Entry filed under: Management, Managing, Project Management.

The Mechanics of Tasking 3/5 — Good tasks start with Why The Mechanics of Tasking 4/5 — Let them Fail

5 Comments Add your own

  • 1. seesshootsandleaves  |  August 30, 2007 at 11:30 am

    For all of the reasons Peter has given above, this is why I believe all estimates should be multiplied by 2.4. You say to me Monday morning that you’ll be done by Friday? I think it’s going to be two weeks today (the Monday following the following Friday). The airport and cab example makes the same point.

    Of course, no one higher up wants honesty in estimating, either. It’s a vicious circle. But it has to be broken somewhere.

    Reply
  • 2. Cecilia Sepp  |  August 31, 2007 at 11:07 am

    I find this an excellent overview of why things go wrong. We are well-intentioned, but human nature tends to be based on fear rather than bravery. So, we are afraid to give the proper reports, estimates, and assessments for fear of “getting in trouble.”

    Reply
  • 3. Gregg Marshall  |  August 31, 2007 at 11:20 am

    Of course there is also the reality that for many projects we simply don’t really know how much work is involved. When I was a software engineer my first project doubled it schedule at that half way point of time remaining (at least for the first 3 times). Our estimated 10-15,000 lines of code ended up being almost 100,000.

    The second time we did a similar project we did get the initial estimate to within 15% of the actual effort.

    Reply
  • 4. Scientific Ink » Blog Archive » links for 2007-09-03  |  September 3, 2007 at 7:28 pm

    […] The Top 7 Reasons Projects Fail « The Sisyphus Chronicles When we constantly shift priorities, when we add work to projects on the fly and neither add resources nor extend the deadline, then we’re stealing from our current integrity and future credibility. (tags: projectmanagement productivity planning work fear feedback) […]

    Reply
  • 5. Ann Feeney  |  September 4, 2007 at 2:12 pm

    I’d add “we hide from accountability” right at the top. Even when we know that a project is going badly, we smile and pretend that all’s well because admitting otherwise would cast a shadow on our work in planning and staffing the project. If you wait long enough, you can find something else to blame failure on. “Market downturns,” “gas prices,” “terrorism,” “the weather,” etc..

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed


August 2007
M T W T F S S
    Sep »
 12345
6789101112
13141516171819
20212223242526
2728293031  

Categories

Feeds


%d bloggers like this: