IT projects fail because we don't like to face reality.

IT WAS a miserably cold and damp Sunday, typical of a day when we had something outdoorsy planned. So instead our family was inside, and my daughters were competing to see who could build the tallest tower of dominos. Sabotage was banned, but that wasn’t doing much to ease tempers. Each girl carefully arranged one domino on top of another, and then they built. This worked well for a few layers, but the little tower soon became unstable and inevitably fell down leading to all manner tears and screams, the like of which the world had never seen outside a project review meeting. But again they tried, and tried, never varying the method, nor of course the result.

Then the eldest decided to try something a little different. She stacked three dominos as a base, and quickly found her tower was stronger so the little shakes that would have toppled her creation before now just wobbled it, and she was able to build her tower a few layers higher. She had avoided insanity, which is defined as doing exactly the same thing again and again, but expecting a different result. And by that definition, the IT industry is certifiable.

If success is defined as delivery of the originally envisaged solution on time, and to budget then it is well known that few IT projects are successful, and of course even the allegedly successful projects aren’t always truly successful, just claimed as such.

The "project cost" generally doesn't include all the effort required for justification, BAU impact, or post-live activities - and that's if it's measured at all.

Yet despite the dismal results, the same basic project delivery models are used year after year, every project starting full of optimism and assurances of success. Human nature being what it is, we tend to think that this time, things will be different, despite the plethora of statistics which only ever apply to other, dumber people. No newly-weds think they’ll be divorced, we’re all above average drivers, it’s always others who fall for a scam and nobody thinks their project will be one of the 50, 60, 70% - choose your number – that will fail.

So the first step in breaking any repeating pattern of failure is to acknowledge your approach is wrong, just as my daughter did. Then you need to understand why it’s wrong, and finally do something about it.

If you can handle the heresy, read on, because We're Doing It Wrong.

The accepted wisdom on project failures revolves around poor budget control, lack of scope management, resistance to change, technology issues and unrealistic expectations, estimating or planning, all of which seem to be someone else's fault, usually someone else that has departed the scene.

All those are indeed failure factors, but not root causes - they're simply a lack of ability to deal with change and unexpected events that always happen on projects, even when they're protected against by magic risk-killing phrases called assumptions. 

In fact, most projects set themselves up for failure even before the first hour is charged by failing to properly resolve, or even acknowledge the fundamental contradiction at the heart of a typical IT project - the need for a certain knowledge of the outcome, versus the inherent uncertainty of an project.

At the start of a project, nobody knows how much a project will cost, how long it'll take, or what it'll deliver. If anyone claims different, ask them for their original estimates vs audited project completion costs.  

The definition of a project is a unique endeavour to create an outcome, with defined start and finish criteria such as dates and budget. A “unique” endeavour means it hasn’t been done before, or at least not in the circumstances presented. And that means the project is unpredictable, or at least nowhere near as predictable as everyone would like to pretend, from sponsors to customers to vendors.

Ah, say the experts, but we’re good at giving you certainty in the face of this unpredictability, because we can estimate accurately, look at all our experience and credentials!

Well, the harsh reality of project results over the decades says otherwise. That’s in part due to the goldfish effect; the IT industry doesn’t remember what it did in any detail, so estimates are really optimistic guesses discovered using torches with dead batteries, and projects learn most things anew. How many projects do the post-live step of proper knowledge and metric harvesting, comparing the reality against the original estimate? Very few, because you don’t have time, and you have a sneaking suspicion you wouldn’t really like the answer so you dare not look, leaving reputations intact.

Next time someone says they're sure about a project estimate, ask to see their metrics based on other projects, their algorithms, and their model.

The dirty little secret is that even if a vendor or other expert has a halfway decent estimating method, the chances of the staff on the job knowing it exists or using it appropriately are about equal to the chances of a politician adhering to a code of ethics.

So projects are, by definition, unpredictable. However, unpredictable is not what gets projects signed off; certainty is what gets the tick of approval. That means the project’s objectives and high-level requirements are set, and the client issues an RFP, asking for a fixed price to deliver the outcome.   Vendors read the RFP, work out a solution (or rather, their part of it, not the same thing at all), do their estimates, decide that price won’t win, so come up with something else and submit their proposal. The proposals are read by the client, a selection criteria is created (and sometimes used), a vendor is chosen and the project begins. Often the non-vendor side of things is forgotten.

And here we have the problem. The project’s unpredictability has apparently been managed to some level of certainty, and the emphasis is on apparently. Merely saying something does not make it so.

The usual method to manage unpredictability from the client’s perspective is to use a fixed-price contract that moves the risk to the supplier, who being an expert in the field is able to accurately estimate and deliver the job successfully. But:

Large-scale fixed-price contracts are very much like communism, ideal in a theoretical sort of way but ignoring reality and the way humans work.

And:

Project risk is like matter. It can be shifted from vendor to client, but it doesn't get any smaller without real hours of work, and if the vendor takes it on the client pays, directly or indirectly.

So let’s look at the reality of project experience, and then we can stop pretending this fixed-price method is effective.

Firstly, it is not possible to define all the requirements, scope and objectives for a project at the initial stages. It is human nature to think you can, mostly on the basis that you can’t think of any more at the time, mixed with a bit of just-want-to-believe, but anyone who has been on a project knows the reality is requirements change, they never get easier, and they increase in number and complexity. Kind of like rabbits really, requirements seem to get together and make more, littler requirements.

Rationally, you’d expect that as projects are unique endeavours, but rational thinking goes out the window and is replaced by a rosy cocktail of groupthink, hope, unwillingness to change minds in the face of new data because of egos, and sales targets.

However, the vendors are responding to a contract with a fixed price, budget and scope. They know full well that requirements change, and that puts them at risk of being responsible for project failure. Therefore, they manage that risk by lots of assumptions that things won’t change – which may as well be assuming the sun won’t rise - or by boxing activities to take a fixed time as opposed to deliver a certain outcome, simply not including critical chunks of work, or worst of all, writing assumptions they know the client cannot keep.

Yes, there’s a change request mechanism built in to each project delivery method, but it’s not designed to fix fundamental chasms between expectations and outcomes.

But it gets worse.

Even if the vendor has estimated accurately, there’s a difference between the real price (never known even after the project finishes), the estimated price (can’t win) and the quoted price (win price, yay!). Simply, vendors go in with the price needed to win, not to deliver. And to be fair, some of them actually believe their estimates.

At this point the vendors are sounding like the bad guy, but who drives their behaviour? The client. Just so I manage to upset everyone, clients have a lot to answer for too. The two primary sins are driving costs unrealistically low, and forcing vendors into situations where they need to deliver to fixed criteria of cost, schedule and solution. Some might add a client sin is changing requirements, but that’s simply an inherent function of any project and the sooner the IT world accepts that reality the better off we’ll all be, instead of trying to stamp out change like it is a venereal disease.

Accept this fact – projects have changing requirements, otherwise they aren’t projects. Design your project for change, otherwise it is designed for failure.

Then we come to the question of risk. Ultimately, the risk is borne by the client, regardless of the contract, and that includes fixed-price. If a client starts a project which ends in abject failure, suing the vendor successfully is never going to compensate for the loss incurred by the project failure. Money cannot make up for wasted time, effort, reputation damage, incorrect solutions partially delivered and more.

Simply, if a project fails the client has much more to lose than the vendor, therefore regardless of legal liability the client needs to manage their own risk.

For a client to win a legal battle over a project failure is a little bit like seeing a pedestrian's tombstone embossed with the words “I had right of way”.

But of course few projects end up in the courts, although that doesn’t mean to say they are successful. As the project deadline and budget approaches the project team is under pressure to deliver, and games like Schedule Chicken begin. It’s easy to play, you just need one project director and several project managers or team leads. Each of the leads knows their area needs more time and effort to complete their job, but they don’t want to call it out because it’ll make it look they can’t manage their tasks. So everyone waits for someone else to make the call. Eventually someone cries enough, the project’s budget and timeframe are extended, and the other leads breathe a massive sigh of relief as they can now get their work done too. There’s plenty of other undesirable, non-outcome driven behaviour driven by fixing date, budget and solution as anyone with project experience will attest.

The unstoppable force of inevitable, inherent project change hits the immovable rock of  under-estimated, fixed completion criteria and so something has to give - project success.

But what about the change request mechanism, surely that could and should be used to manage the inevitable change?   In theory yes, but most projects aren’t designed for change, which is sadly ironic given their inherent unpredictability. Let’s take an example – you hire a guy to clean your car, for a fixed price of $30. He jumps in the car and starts to drive off.

“Where are you going? You’re meant to wash the car!”

“I am, I’m taking it to the mechanical carwash.”

“But I don’t want it put through a carwash!”

“Well, you paid me $30 for a clean car. You’ll get a clean car. How I do it is up to me. I can’t do the job for $30 by hand.”

And so the argument begins. If you think about it, even a simple carwash could be unpredictable – how dirty is the car to begin with, did you agree a polish and if so to what standard, would the wheels be cleaned, where should the job be done, or maybe you don’t like the smell of the interior cleaning agent and want it changed.

Then from the cleaner’s point of view what happens if there’s complicating factors like roofracks, bullbars and spotlights which take extra time to clean, or the client is late with the car, or they can’t provide water, or if there’s an extra-difficult bit of bird poo to remove, did the clean include a polish. And again, lots of energy in an argument about who assumed what, during which the car remains dirty.

You could spend hours working out all the possible permutations of car cleaning scenarios so you manage your cleaner to a fixed price and scope, or you could pay him to start making things cleaner.

A valuable commodity like time is of course be better spent on delivering the job, and the same is true of a change request on an IT project but the effect is magnified. Any change request distracts key resources to “estimate” it, prepare the contract, consider the effect on the schedule, cost and budget, then it goes before the client who considers it, before all concerned begin arguing about scope with the vendor and internally about whether it is needed. A huge amount of energy has been largely wasted and no change has been made. There are Dilbert-eqse change requests to estimate change requests too.

Let’s jump back in time to the car cleaner, but this time we’re paying him $10 an hour instead of a fixed price of $30 and he’s about to drive off.

“Where are you going? You’re meant to wash the car!”

“I am, I’m taking it to the mechanical carwash.”

“But I don’t want it put through a carwash!”

“OK, what do you want?”

“I want the car cleaned by hand, and polished.”

“No drama mate. I’ll get started. You’re paying me by the hour so I’ll do whatever you want, how you want it”.

Less grief, less cost, better outcome, an immediate change. It’s not feasible, cost-effective or even possible to work out everything in advance, so both client and vendor adapt, and do so without "nah nah but you said..." games.

However….anyone who is paying for a project has already spotted a problem, and large one at that.

What’s to stop the cleaner just relaxing and turning a one-hour job into a three-hour job? And this is why fixed-price contracts were invented.

Unfortunately, fixed-price contracts in the IT world tend to estimate a three-hour job as two hours, price it as one hour, in reality it costs the client four hours, who then accounts for it as half an hour.

The simple solution is to measure progress by quality and rate of completion, not by time or budget. The problem is the difficulty in doing so.

Humans naturally use easy metrics to measure the worth of things, regardless of whether those measures are appropriate.

For example, there’s a fixation with kilowatts in the world of cars, which has very little to do with overall performance and isn’t even as much of a factor in straight-line speed as you may imagine. Fuel consumption figures are similarly pored over by potential buyers, who don’t think to ask about lifecycle costs such as servicing, tyre wear, depreciation and much more. Cameras are measured by megapixels, which has nothing to do with picture quality and very little to do with effectiveness as an image-taking device. And because it’s easier, IT projects are measured by time and budget more than outcome or quality. You know it's true, what do steercos look for? Budget and time first, outcome third.

So what can be done? Prepare for some heresy.

Firstly, let’s ditch fixed-price contracts. It is madness to fix all of time, schedule and outcome when a project is inherently unpredictable.

We all sagely whiteboard those little triangles, label the sides Time, Cost and Scope, then solemnly intone that you can’t fix all three, yet the industry continues to do so on daily basis.

I think I mentioned the definition of insanity.

Instead, use a time and materials approach, and as you want an outcome, fix that and leave the other two as variables, or maybe you want to get as far as you can within constraints of time or money. When you get project change, and it is a when not an if, then you don’t need to wrangle about it or play schedule chicken, everyone just gets on with the job. The project team will be much happier and more effective as they’ll spend their time delivering your outcome, not protecting scope or running back to the contract. Only lawyers will lose.

In the world of occupational safety, we encourage everyone to speak up about risks, their fault or not. Yet in projects, those who want to change the originally accepted scope or plan as things evolve are pariahs. That's not safe.

Of course, the problem with not fixing time, scope and money is simple – aren’t you signing a blank cheque? And any business needs to know what will be delivered, when, and not all changes are sensible or cost-effective. How will the risk of the project spiralling out of control be managed? Isn’t this going to be an anarchy, never ending?

The answer is that you do of course need a measure of control and estimating. Specifically, you need a robust roadmap for change with more objectives and outcomes, less precision about time and money. That's the bit that's very often missing.

Then, project still needs a sub-objective, and must be managed to that outcome. It must also be justified with a business case. The trick there is aiming for accuracy, which for projects by definition means a lack of precision – the two words are not synonyms.

Unfortunately, most business cases are precise, but not accurate - think about the difference. 

If the project can still stand up without a massive effort of justification then it must be a good one, and sometimes it’s better just to put that justification effort to making a start, easier if the project is small - we'll come to that shortly. Actually, in a way the current method of unrealistic expectations is no bad idea, as if everyone assessed the true risks vs benefit of an endeavour very little would get done.

Making sure a one-hour job doesn’t become a three-hour job isn’t as hard as it sounds either. If we go back to observing our car cleaner and we see he’s taking breaks, not fully using buckets of water and spending a long time polishing the bonnet which doesn’t seem to be getting any cleaner….you know he’s slacking.   The same is true of projects, it’s easy to tell whether a vendor is putting effort in or not and whether progress is being made. But a client can only do that if they’ve not made the mistake of entirely outsourcing the project with nobody involved who is directly loyal to your company, and not hiring any people with deep expertise in the domain and technology.

Always have your own people closely enough involved to notice if bonnets are being polished and not getting any cleaner.

One more problem is quantifying progress. You can’t really march out to the cleaner and demand he moves quicker with the bucket, or ask why he seems to be working a bit slow. That’s micro-management which never works, and is usually counter-productive because it incents people to provide the appearance of being productive rather than actually being productive, and we all know some world-class experts in the field. Micro-management also removes a major job satisfaction motivator, and makes you more responsible than you should be for the outcome.

What you can do is incent your cleaner to deliver an outcome that makes you happy. Perhaps you say that you’ll first get him to clean the bodywork, and if that goes well then you’ll pay extra for him to do the interior too.   You don’t precisely need to define quality, as that’s difficult, but you might say you want it basically clean but not sparkling. The cleaner will come back to you and say “is that enough on the body?” and you get to decide. The cleaner is incented to do a good job by the promise of extra work - plus a focus on the job, not the contract - and you’re working together to an outcome.

Unfortunately, this approach requires two things:

1. A mature give-and-take partnership model rather the adversarial model that has both sides running back to check over contracts before every conversation.  It requires the client to trust the vendor to do the job without 20 pages of specification, that half a hour's work may turn in an hour or fifteen minutes, and requires the vendor to accept the fact the client may decide that they do want the wheels polished after all, or the interior doesn’t need a vacuum as they first thought. Scope change is a reality, not a disease.

2. Small chunks. Like the car-cleaning example, clients can also split IT projects into smaller ones, and award sections piece-by-piece. There’s no project that cannot be split into smaller, less risky pieces, moving towards an overall objective. It just takes a different way of thinking, and it’s better to do that and have some rework than try and do it all in one big, messy, complex effort…and do the rework twice over anyway or accept what turned out to be a sub-optimal solution. We’ve all seen the project which says “this is what we’ve built, now you just have to accept it”. Those would be the big projects, not the small ones.

If projects are split into smaller chunks vendors will complain. They will offer sweet deals for long-term commitments. They will moan they cannot or will not commit resources to a Stage 1 if they are not also promised Stage 2.   Honeyed words will whispered, assurances will flow, discounts will be dangled. And boards will say, well the end state is not achieved in this one project, do more. The client's CV-polishers will want the big programmes. But this is folly. 

Whatever you lose by shortening projects and keeping vendor-change gates open you will surely reap by less effort to start the project, better agility and keeping the vendor hungry for more. You need not actually go to market at the end of each smaller project, and indeed you wouldn’t want to swap, but you should ensure you have the option – that point earlier about having your own loyalists deep in the project is also important.

It also helps to treat the vendor right. Pay their bills ahead of time. Don’t quibble about cents. Be a good reference. Make your staff available. Even if you’re in the right, give a little. Then you, the client, becomes a rarity, someone the vendor really wants to do business with rather than they have to do business with, yet the vendor knows you’re well prepared and able to switch elsewhere at a moment’s notice.

If a vendor is treated professionally, and each project is broken into small parts, that's a far more powerful incentive to perform than any clause in a contract or macho table-thumping blood-on-walls meetings. It’s not being soft, it’s being intelligent.

Another benefit of small projects on a time and materials basis is a fast start. Ever tried negotiating a fixed-price contract worth several million dollars over several years? It takes months, and that's just the first meeting with the lawyers. Lots of cost on both sides, lots of time lost. Why not select the vendor based on approach and attitude, let them start quickly but scope their contract in such a way if they’ve not delivered after a short while you can swap them out.

If you think all this sounds rather like an Agile approach to IT development then you’d be right, and Agile has a lot going for it, not least a recognition that projects are unpredictable. 

Unfortunately, Agile is mostly used in the industry as a superficial sales gimmick or a sexy-sounding smokescreen to excuse a lack of planning, and ironically most allegedly Agile projects are managed to fixed time, scope and cost.

So if we look back at why projects fail, perhaps the biggest mental shift has to come from the project approvers.   Boards and CxOs are used to being presented with a plan that promises a fixed scope, cost, time and budget then driving the latter three down.... but in reality, some harried project manager just goes away, grits teeth, does something against their better judgement before coming back with figures that are more palatable, never mind the reality.

Project governing boards would do well to remember that torture victims tell their interrogators what they want to know, not what they need to know.

Instead, boards need to look at projects differently. They should authorise funds for small projects, and worry more about alignment to their roadmap than a project changing how it achieves its outcome or even which part of the roadmap it achieves.

There’s so much more to write on this subject, but ultimately the summary has to be the same as the introduction – the way we price and manage IT projects very clearly isn’t working.

Either we fundamentally change our approach to IT delivery and get a better result, or we just continue stacking those dominos just like we did before hoping that this time, it won’t end in tears.

Summary

1. Most IT projects fail, even those reported as "successful".
2. This is because projects are inherently unpredictable, yet flawed models based on incorrect data are used to fix time, cost and scope before any are truly understood. Nobody mentions this because humans like to be overly optimistic, and most involved are incented to close the deal, and start the project. Also, groupthink.
3. Project risk ultimately lies with the client, regardless of the contract, as if the project fails the client is the one with most to lose. Any matter that goes as far as a dispute is a loss to the client, regardless of any legal victory
4. Therefore, fixed-price contracts do not mitigate the risk to the client. Risk shifted to the vendor is paid for by the client, directly or indirectly.
5. The solution is:
1. Accept the fact projects are uncertain and will not be accurately estimated at inception.
2. Define a detailed roadmap for the programme aligned to your business strategy, based on prioritised outcomes. The detail needs to be in what you want to achieve and the order, not so much the how or the when.
3. Use contracts that have scope for natural change; eg "far as you can within this budget"
4. Approve only short-term, smaller projects, even if there are apparent benefits in much larger programmes. Ensure the smaller projects align with a longer roadmap from an achievement perspective.
5. Embed client staff in the project at all levels so you can monitor the vendor, and reduce dependence.
6. Always be in a position to stop or change vendors at the next break point; their incentive is the next piece of work.
7. Encourage an attitude of change is good, but keep everybody oriented to the long-term goal as per the roadmap.

Did you like this article? Here's some more:

• Forget the federal debt, start worrying about technical debt
• How to specify useful response time NFRs