Why digital projects fail: rarely because of technology

Technology is rarely the reason

A project I worked on stood still for eleven days. No bug, no interface, no server. It stood still because a design approval was missing and nobody on the project could say who was allowed to give it.

The person we had asked did not want to decide without the head of marketing. The head of marketing did not want to decide without the managing director. The managing director did not know she had been asked. All three meant well, all three answered quickly, and eleven days passed anyway.

This is not an exception and it is not a client problem. It is the normal case. Digital projects rarely fail because of technology. They fail because the wrong people were in the room, because the concept did not hold, and because in the end nobody was allowed to decide.

What the numbers actually say

For the Pulse of the Profession 2018, the Project Management Institute asked 5,402 project leads what caused the projects they had seen fail over the previous twelve months. Multiple answers allowed, up to three per person.

At the top: a change of organisational priorities, at 39 percent. Then inadequate vision or goals at 37 percent, and inaccurate cost estimates at 35 percent. Further down come changed project goals, poor communication and weak change management, all around 28 percent.

Not one technical cause shows up anywhere in that list. Technology failure is absent, so are integration problems, so is performance. What is on the list are goals, priorities, communication and responsibilities.

The Standish Group, publisher of the CHAOS Report since 1994, names the root of the problem in two words: “decision latency”. Not the wrong decision. The late one.

McKinsey, together with the University of Oxford, analysed more than 5,400 IT projects. 45 percent run over budget, 56 percent deliver less value than planned. The study traces around 40 percent of cost overruns to team, incentive and project management practice, meaning factors with no technical component at all.

The German-speaking region has the same observation on a smaller scale. The German Project Management Association asked 151 project leads across Austria, Germany and Switzerland about failure factors. The highest rated one: roles and interfaces between the parent organisation and the project side are not clearly defined. Not the tools. Not the method. The question of who is responsible for what.

I wrote a while back about why a good concept at the start is worth so much. The data says the same thing, just with a bigger sample.

When it really is the technology

It happens. An ERP interface that behaves differently from its documentation. A legacy system that only exports part of its data. A payment method that needs different certification in the target market than assumed. Those are real technical delays, and we have had them.

The difference is how they end. Technical problems have an end. They can be named, they can be estimated, and at some point they are solved. A project where nobody decides has no end. It only has a new date.

How far off the gut feeling is shows up in a number from an entirely different corner. The Content Marketing Institute asked 1,015 B2B marketers about their biggest barriers. Technology came last, at 8 percent. Lack of resources came in at 39 percent, cross-departmental collaboration at 21. Even where people work with systems all day, the system is rarely the problem.

Well studied before the signature, ignored after it

Before the signature, there are numbers. For The JOLT Effect, Matthew Dixon and Ted McKenna analysed 2.5 million sales conversations. The finding: 40 to 60 percent of deals are lost not to a competitor but to indecision on the buyer's side. 56 percent of that comes from fear of choosing wrong, 44 percent from being content with what is already there.

For the time after the signature there is no comparable study. Nobody has measured how many approval rounds a website project usually needs, or how often a go-live moves. I went looking. It does not exist.

In our experience the same pattern repeats. Indecision does not disappear when the quote is signed. It just moves from the question of whether to build to the question of how.

How to spot it before the project starts

The usual question sets for a project kickoff ask about goals, audience, content, budget and technology. They are good, and they all ask about the what. None of them asks about the who.

The questions that are missing from most kickoffs sound more awkward than they are. They take twenty minutes and save weeks.

• Who approves the design, and is that person allowed to sign off alone?
• Who needs to have seen what we are building, so that it does not turn into a fundamental debate later?
• What happens when that person is on holiday for two weeks?
• Who writes the copy, and is it in that person's calendar?
• Who has access to the domain, analytics and payment provider, and do we know that now or in go-live week?
• Which three things should the new website explicitly not do?

The last question matters most, and it is the only one that reliably produces silence. A project without a no does not have a concept, it has a scope that is still open. That is exactly what we settle in the concept phase, before the first line of code exists.

What you can settle on your own side

What helps most on the client side costs no budget at all.

First, name one person who may approve, and say that name out loud inside your own company. Not to the agency, but to your own colleagues. The sentence “Miriam decides that for us” saves several rounds later on.

Second, bring in the people early who will have an opinion anyway. Sales in the kickoff costs an hour. Sales in the first review costs a week.

Third, write down what the website is not supposed to do. It is the most uncomfortable exercise in the whole project and the only one that keeps the scope stable.

What we changed because of it

For a long time we treated delays as something that happens on the other side. Approval does not come, copy is missing, access is not there: noted, chased, carried on. That was not wrong, but it was not enough. When an approval sits untouched for two weeks, usually nobody has clarified who is allowed to give it. Clarifying that is our job, not the client's.

So we changed three things.

In the kickoff we ask for names, not roles. Not “Who approves the design?” but “What is the name of the person who approves the design, and is she in this room?” It is briefly uncomfortable and takes five minutes.

We put approvals into the plan with a date, the same way we do with development packages. An approval without a date is not a task, it is a hope.

And we work in short cycles, so an open question holds up one strand instead of the whole project. Whether that is agile or waterfall matters less than how fast a decision travels through the organisation.

None of this makes projects automatically faster. It makes visible what they are hanging on, in week two instead of week twelve.

The difference is clearest with clients who have been through the other version before. Anyone who says in the kickoff, unprompted, who approves and who needs to have seen the work first, rarely moves their go-live. That has little to do with budget and nothing to do with company size. It has to do with someone having decided, in advance, who decides.