The Top 3 Causes of Project Failure

Over the past 25 years, I've been invited to take on more than 30 failed projects in the web and mobile space as turnarounds or rescues. These have ranged from small projects with start-ups to a £70m point-of-sale (POS) redevelopment at 1,100 stores for one of the UK’s largest retailers, with a team of 150 people.

As with anything we do repetitively, patterns start to emerge. It didn’t take long for me to notice common issues across these failing projects. These patterns quickly distilled into a set of activities I would conduct upon arrival. Alongside these activities was a short list of authorities I required as a project/program manager in order to fix the problems I found. I negotiated these authorities as part of my interview process, as I realised that without them, my hands were tied, and I could not transform a failure into a success.

I’d like to share the three most common failure patterns because they are easy to spot and surprisingly easy to fix—provided someone in the team has the authority to change what needs changing. I summarise these as:

1. Why are we here? (Unknown outcome)

2. Who’s done this before? (No previous experience)

3. How do we know when we’re done? (Governing to scope or plan instead of outcomes)

#1 – Unknown Outcome

Before my first day on a new project, I would ask the sponsor to prearrange a four-hour workshop with my direct reports on the second day following my arrival. Day two, because the first day was typically taken up with "meet and greets." These sessions would always start with a simple question:

“Why are we here?”

I was never given a simple answer that spoke to the business benefit we were trying to deliver. Almost all of these projects had a business case, yet none of the team could articulate in simple terms the commercial benefit we had been tasked to achieve.

Think about this for a minute. We have 150 people on a program with its own building, and yet no one can clearly state what we’re trying to accomplish? This is a glitch in our traditional governance model and process. As the Cheshire Cat says in Alice’s Adventures in Wonderland:

Now, don’t get me wrong—everyone I’ve ever asked the “why are we here?” question has given me an answer. In most cases, they could speak for hours on the topic. The problem? Their answer rarely had anything to do with the business benefits that justified the project’s funding in the first place.

Here are some examples that don’t count as a valid answer to "why are we here?":

• We are doing a like-for-like replacement of the POS system.

• We need to ensure the in-store server stays up 99% of the time.

• Our old till has a whole bunch of issues; we need a new one.

• There are 2,713 outstanding change requests for the old system.

• We need to be able to take the new "chip and PIN" cards.

• Total cost of ownership.

None of these pass the “so what?” test.

Fixing this is as simple as asking “so what?” repeatedly until we get an answer that could be explained to the CEO or CFO. Sometimes, we’ll hit a dead end and have to brainstorm again. Sometimes, the team doesn’t know, so we have to go back to the executives who approved the project. Sometimes, they’ve forgotten, so we need to start over and re-agree on the commercial outcome we’re striving for.

In this case, the real answer was:

“We want to operate 90% of our stores with one less person.”

#2 – No Previous Experience

Now that we know what we’re doing and why, the next question is:

“Who here has done this before?”

In this case, we were building a new POS system from the ground up—including hardware, communications, and software. The best way to de-risk projects, in my experience, is to ensure that someone on the team has “been there and done that.” It doesn’t have to be the project manager, but someone in a key role—ideally one of the developers—should have prior experience.

If I’m building a POS system, I want someone on my team who has experience doing something similar. The same goes for building a web or mobile application—if no one on the team has built something of this scale before, then you're immediately in a high-risk scenario because all of your learnings are happening on this job. And there will always be mistakes made the first time you do something technical.

In this case, no one on the team had built a POS system before. As a retailer, we had plenty of people who knew how to install, maintain, and change a POS system, but no one had actually built one.

A ray of hope came from one of the leads, who pointed out that we’d chosen a consulting partner with experience building POS systems. However, in our first meeting, it became clear that no one on their team had experience building a POS from scratch either.

This explained why they hadn’t delivered a single working system in over 48 months, despite repeated commitments to release something “next month” for over a year.

So we fired the prime contractor. This sounds harsh, but doing anything else would have been negligent.

What did we do next? We looked for individuals who had actually built a POS system before. Given the budget we had, this wasn’t difficult. A few weeks later, we had a new, smaller team in place.

Within two months, we had a working POS system in one small store, which almost doubled productivity (more sales per hour).

#3 – Governing to Scope or Plan Instead of Outcomes

This one is contentious because almost all projects today are managed to scope or plan—including agile projects.

The problem? If you focus solely on scope, you will deliver something, but without focusing on outcomes, there’s no way to know if you’re delivering the right thing.

The only way to ensure progress toward an outcome is to deliver that outcome incrementally.

It’s no longer good enough to say, “We’re 20% of the way through the project because we’ve spent 20% of the budget.” The only real measure is:

“How much benefit have we delivered (in the real world)?”

On this project, we asked: What’s the simplest store we can deploy to, and how can we deliver a partial solution there to prove we’re on the right track?

Within two weeks, this pilot store was outperforming its peers by almost 100% in sales per staff member.

Epilogue

This project paid for itself before it was finished 18 months later.

It delivered over double the expected business benefits while costing half the original budget, including the wasted spend on failed attempts.

I attribute this turnaround (and most that I’ve done since) to addressing these three simple factors.

Have you ever worked on a project where no one could articulate the business benefit? What happened?

Andrew Walker
Technology consulting for charities
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.