The 'Seven Laws of Projects'

Anyone who reads this blog knows projects can go very wrong. While that's not news, an unexpected source -- American Express OPEN Forum -- published a blog post neatly summarizing why:

We have delusions of success. We take on more than we should, routinely exaggerating the benefits and discounting the costs. We over-scope, over-scale, and over-sell. At the same time, we under-estimate, under-resource, and under-plan.

I think that does indeed state the problem simply and with complete accuracy.

The post comes from Matthew E. May, author of In Pursuit of Elegance: Why the Best Ideas Have Something Missing, who describes what he calls the Seven Laws of Projects:

1. A major project is never completed on time, within budget, or with the original team, and it never does exactly what it was supposed to.
2. Projects progress quickly until they become 85% complete. Then they remain 85% complete forever. Think of this as the Home Improvement Law.
3. When things appear to be going well, you’ve overlooked something. When things can’t get worse, they will. (Murphy’s Law says, “If something can go wrong, it will”—this is a corollary).
4. Project teams hate weekly progress reports because they so vividly manifest the lack of progress.
5. A carelessly planned project will take three times longer to complete than expected. A carefully planned project will only take twice as long as expected. Also, ten estimators will estimate the same work in ten different ways. And one estimator will estimate ten different ways at ten different times.
6. The greater the project’s technical complexity, the less you need a technician to manage it.
7. If you have too few people on a project, they can’t solve the problems. If you have too many, they create more problems than they can solve.

These laws have nothing to do with technology or IT, which makes sense because failure rarely does. To understand failed projects we need to look into dimensions of collaboration, relationships, and management.

Why do failed projects persist? Because it's easier to fix bugs than to be ruthlessly honest with the team, the project and, most especially, with oneself. And that's the truth... think about it.

[Thanks to Guy Kawasaki for the pointer. Photo from iStockphoto.]