Why do Projects Fail?

Every seasoned project delivery professional has led projects that did not turn out well. They ran late, they exceeded the budget, they delivered a disappointing outcome, or otherwise failed to meet the business goals. If you haven’t had a project fail on you yet, you’re either lucky or inexperienced. Luck does not scale.

Let’s define what we mean by project failure. There are many metrics that we can apply but there’s only one I care about. I don’t consider simply running long or delivering late to be a failure in itself. Projects that require additional funding beyond the initial forecasts may not be failures. 

A project fails when it cannot repay the investment made. We don’t run projects just to spend money and have fun. We run them to give us a return on investment. If a project reaches a state where it can’t recoup the investment, it has failed.

Early in my career my failures were contained, because nobody trusted me with enough scope to do real harm to the company. This is known as ‘limiting the blast radius.’ Early-career delivery leaders should not be given leadership of strategic or ‘Bet the Company’ initiatives. Until you learn what failure looks and feels like, you won’t know how to avoid it. 

As I gained experience and took more senior roles on major programs, I had already developed the antennae to detect when things weren’t right. This led to me being asked to perform ‘Health Checks’ on critical projects, and to consult when it was clear that an initiative was in trouble. I also learned a great deal from organisations who were courageous enough to invite me to carry out the post-mortem on moribund programs.

There are several common factors that cause project failure. All of them are easily avoidable with a little humility and a very great deal of experience. The most common factors are inexperienced leadership, over-confident commitments, and failing to respond to early signs of trouble. 

If you have leaders who have battle-scars from earlier trouble, and you are realistic about what can be done in the early days, and you put systems in place to recognise trouble, you will not fail. You might not succeed either. You may discover early that that project is simply not possible. Killing a bad project in its early days is one of the most valuable things you will do in your career, and it should be celebrated.

War Stories

I was once asked to help set up a large system replacement for a business in NZ. It was to replace a critical core capability which ran literally half the business. They had a great vendor, amazing people, and a clear goal. The leadership had the humility to realise they lacked enough large-scale systems integration experience, so they brought in external expertise.

I advised them that before leaping in to any contract with the vendor – despite the great relationship – that they should set up a small project to understand the challenge better. They took a small team, set a sensible budget and a fixed timeframe. The vendor set their system up on a cloud environment, and they started exploring the scope of the whole program. They identified the integration points, looked at impacts to business processes, and learned the scale of product changes that would be needed. 

They discovered it wasn’t a $20 million project. It was a $100 million project. That blew the business case out of the water. By investing a much smaller amount (around $200,000) they were able to avoid a $100 million disaster. Had they proceeded, it would have cost many, many millions to untangle the mess. A small amount of experience, that was heeded by leadership, saved the day.

In another case, I failed. I was part of the leadership of another large SI project in financial services. It was always going to be a big project, but the leaders were firmly wearing rose-tinted spectacles. Several team members had worked on similar projects. Those with experience could see that it was turning into a multi-year, high-risk, $300 million program. The business case needed it to come in under $50 million.

Regrettably, the leadership made some bad mistakes. First, they shared the business case with the vendor. The vendor responded that they could de-risk the program by undertaking the SI work themselves, in an offshore facility. The vendor produced a report showing they could bring it in under the budget. I can’t criticise their enthusiasm or optimism – they wanted to make the sale.

The second mistake was to listen to a vendor in ‘Sales Mode’ over their own experts. I failed not because I was wrong, but because I wasn’t convincing. The program eventually consumed several years and over $450 million, and failed to deliver a single one of its key success criteria.

Why Projects Fail

So, why do projects fail, and how can we avoid the pitfalls?

Projects fail for one of exactly three reasons. Every seasoned project manager just gasped. They’ll tell you there are hundreds of things that can go wrong. They’re right, but all those traps fall into one of three categories.

Solving the Wrong Problem

Are you absolutely sure that you are solving the right problem? Are you clear on the context? Do you know who cares about this problem? Have you clearly documented what it is they care about? Do you have objective success criteria in place?

Are you solving too much in one go? Can your project be better focused if you increase or decrease scope? If it’s the right problem, are you sure you have answered the two critical questions “Why us? Are we the right people to solve this?” and “Why now? Do we have to make this investment today, or would it be better to wait until we have more information?”

Once you are confident you are solving the right problem, it’s time to avoid the second failure mode.

Building the Wrong Solution

Are you sure your solution is the right one? What other options have you considered? What criteria did you use to select this solution? Does the solution meet your success criteria without exceeding them?

Should this be built by us, or procured off-the-shelf, or outsourced to an external supplier?

If you know that your solution is a good fit for a genuine problem, there’s only one more thing to check.

Building the Right Solution in a Stupid Way

Do your leadership have experience with this class of problem and type of solution? Do your key stakeholders have real skin in the game?

Do you have a Way of Working that is iterative and incremental? Anything with a whiff of “Big Bang” is a huge red flag.

Have you built tight feedback loops in so you can course-correct when things inevitably go wrong?

Are you clear on how information needs to flow, and where decisions will be made? You need to drive decision-making as close to the point of information as possible. On a large program centralised decision-making is a colossal drag on agility.

Have you set up the right forums to catalyse the conversations that will be needed, and have you created the artefacts that will feed into those conversations?

Have you created a ‘Culture of Done’ that requires delivery of real functionality more frequently than every 12 weeks? Monthly is better. Weekly is best, but you must have a delivery cadence of 12 weeks or less.

How Not to Screw Up

Make sure you know why this is the right problem to solve. Invest in exploring solutions until you know that your solution fits the problem. Build a way of working that drives transparency, has feedback loops, and is adaptable to change.

That’s it. If you do that, when things go wrong you will identify them early and be able to take action to keep your project on track.

The goal is not to prevent problems. The goal is to identify them early, take action, and to keep your solution delivery on track to solve your problem.

Charles Randles is a highly experienced Enterprise Delivery Professional. He has led, mentored and coached on programs up to the billion-dollar scale around the world. He believes in building a Culture of Trust that empowers people to be their best. You can contact him on 0430 0135 20 or at charles@charlesrandles.com.