Why projects fail

Brick wall © Les ChatfieldWhy are Projects so hard? Why do we fail here so often, even in workplaces featuring thorough planning and highly disciplined execution?

We do not fail despite, but because of these. We believe that turning a project into a success is like baking a pizza, while in fact, it resembles much more creating a pizza recipe.

Why? In our projects, we're not into producing identical results from identical ingredients. Every project is unique - it is like research & development, not like production. In R & D, diversity of results is what we strive for. In production, diversity is our worst enemy. We should be aware of this, however, we're making the same 4 mistakes, over and over again:

Mistake #1: We favor processes and tools over individuals and interaction

Hey, something that is both expensive and complicated can't be wrong, can it? Plus, it is comfortable and reassuring to use and do in projects what everybody else uses and does. Projects are as simple as having an input being transformed by a process into an output, case closed.

However, pizza, perfumes and beer share a common trait: ingredients and production are specified in painstaking detail. Customers expect the very same results having the very same level of quality, all the time. That's why processes may be a company secret, but never creative.

We're stunned and dazzled whenever we witness such frictionless operations. If this thinking works like a charm for the assembly line, it can't be wrong for our project, can it? So, lets define our processes and have our work certified according to ISO 9000 standards. It'll make our day.

Wrong. There are no work instructions that can guarantee creativity, competence and team spirit. Even a streamlined pizza factory would grind to a halt if it weren't for the human «lubricant» covering its process chain. As a matter of fact, work to rule is a guaranteed way to bring everything down.

Have you noticed how many rules and regulations are just fears that have become manifest in paper? Fears like: They won't be able to do their job well without instructions. Our results will not meet our quality standards without this. When they lack a handbook, newbies may not be able to become productive quickly enough….

Face your fears. Establish a project culture where fears can and will be discussed and made obsolete by everyday, low-tech behavior, instead of erecting monuments of regulations in their honor. Start small and «infect» others, turn team spirit into an epidemic!

You're on the right path when you feel your team is starting to morph from a partnership of convenience into The Three Musketeers. When you encounter problems, resist the impulse of raising your «defensive shields». You're not Captain Kirk on the Enterprise, offering just a meager «communication channel» to a Klingon opponent.

Mistake #2: We behave as if comprehensive documentation trumped a working, fit-for-use result

Analyze! Analyze! Analyze! Only after all requirements have been captured and fully understood we can start to implement the result. Every document is a milestone, isn't it?

Wrong. analysis.doc never crashes. A prototype may, on the other hand.

Consider the meaning of good enough in the course of your project. Documents defined as milestones can become millstones tied to your feet. It is an utter waste of money and time to give more attention to documentation than to the results that you want to achieve. Documentation exists to enable people to go ahead. Once long chapters and impressive diagrams have become more important than communication in your team, you're in trouble.

Try early what may harbor hidden risks. Learn faster by failing earlier. If your documents and diagrams look battered after their contact with reality, make that contact more often. If it hurts, do it more often.

Mistake #3: We prefer contract poker to customer collaboration

As a customer, are you familiar with the following situation? On every minor change request, the project manager starts to re-calculate costs. Better bring a lawyer to the table if you depend on any type of guarantee, you need a painstakingly precise contract for work and materials. Once you've signed it, you're sitting in a golden cage, being entitled to exactly what you needed - half a year ago. Any change request must pass the arid lands of the Change Board; in the meantime, stuff gets implemented and billed that you don't need anymore. Since you probably can't justify this in front of your boss, you start covering your a… and archive every single tiny email - you never know…

As a member of a project team, are you familiar with the following situation? Customers never know what they want. However, you can never get them to pay just for your services. Contracts for time and materials are a no-no, they want work and materials, to be able to tell you, afterwards: «Oh, by the way: you've already accounted for some minor favors when you calculated your offer, for sure.» Say NO to any request and they'll escalate it up to a level where the hourly rates of the people involved exceed what you're making in a whole month. In the end, the customer gets his will, anyway. A huge part of your day is eaten up by maintenance of the infamous Excel sheet listing all requirement changes. In any given situation, whether it's analysis.doc or changes.xls that you need to follow, well, only god knows. Of course, every little change stresses your budget and puts all deadlines at a growing risk, but the customer doesn't (want to) see it…

Why isn't the customer part of your team?

Mistake #4: We rather follow a plan than respond to change

In preparing for battle I have always found that plans are useless, but planning is indispensable.
(Dwight D. Eisenhower)

What can you do to keep a project on track? Four classical levers are time, money, quality and scope. If you want to adjust them all at your will, you're going to fail. The longer you consider the issue, the more you'll realize that talking about scope is the only way to go. Using the scope lever turns change into your friend, for customers and project teams alike.

Why, then, do people talk so obsessively about time, money and quality, instead? Because a compromise about any of these can only be achieved at the expense of one of the parties involved. That's why people like plans so much: everybody gave their best and found a so-called agreement in the shape of a plan - alas, plans, you know…

As a matter of fact, it wasn't their best when every change results in an avalanche of follow-up changes, vexing everybody and turning «change» into a synonym for «root canal treatment».

Embrace change! Embrace it. It's not about change containment, it's about welcoming it. Change isn't the problem, but ritual belief in invariable plans is.

Stay agile!

It is hard not to believe in the common wisdom about what works for project management. Especially when it's expensive, clumsy and slow (rather perverted criteria for pro work environments at the state of the art, if you ask me).

Instead, stay agile! Focus on individuals and interaction, fit-to-use results over extensive documentation, customer collaboration and on responding to change. Everything else is an optional means.

What's your opinion? Please write a comment, below!

I highly recommend these helpful books if this posting made you curious: