Contrary to popular belief, the majority of big projects fail.

Yes, something gets delivered at the end, but that’s not necessarily a mark of success. If projects run over time and over budget – which is often the case – then they have failed. The history of civic and business planning is littered with examples, from the infamous DeLorean Motor Company and the NHS central IT system, to the San Francisco Bay bridge rebuild.

Why big projects fail

Many business books and articles have been written on this subject. One of the most succinct summaries was by Matthew Syed, who cited three main reasons why big projects fail.

The grand vision

You could also call this “survival of the worst plan”. It’s based on the principle that we naturally seek to make significant and lasting change as humans, and particularly as business people. We have a grand plan, one that will leave our mark on the world and our organisation. It’s often too big to be realisable on time and to budget, but our ego won’t let us let go. We persevere to deliver our big vision at any and all cost.

Everything goes according to plan (EGAP)

This was a phrase coined by the World Bank during research into big capital projects. It refers to a common route of failure driven by over-optimism. According to EGAP, humans have a tendency to expect things to go mostly to plan, and to think we have covered all bases in terms of contingency planning. In reality it’s impossible to predict everything that might go wrong—the Covid-19 pandemic highlighted this—and so big projects inevitably fail without contingency for all possible eventualities.

Haste over speed

As humans we have a completion bias, meaning if we’ve publicly committed to doing something, we like to see it through. Not doing so would count as failure. Business people especially hate to fail. If we’ve committed to a project, however unrealistic, we do everything in our power to make it happen. Timelines tighten, corners are cut, budgets get out of control and mistakes creep in—all in the name of delivering.

Silos as an additional lens

These points, all based on human nature and modern corporate culture, go a long way to explaining why projects fail. However, at Zebra, we think there is an additional lens that can be applied to Syed’s theory—that of business silos.

Businesses and ventures naturally organise themselves into groups of specialists. Engineers, accountants, marketers and operations managers all have an important role to play in business and tend to be grouped together in teams.

Often, when we organise these people into groups by specialism, that discipline becomes too deep with hard edges and a silo forms. This has the potential to disrupt projects in a number of ways.

The grand siloed vision

If a big plan comes from a particular silo, often the team will feel so much ownership over it that it’s difficult to challenge or halt no matter how poorly it’s going. Since nobody from above or outside the silo has any influence over proceedings, the project continues on unchallenged.

Trust in specialists

We tend to trust specialists. We rightly respect their experience and defer to that when we plan. If they say we need two months, we put that in the plan with 10% contingency if we’re smart project managers.

However, remember EGAP? The specialists may know their subject but they are not all-knowing and infallible. It’s likely a problem may arise they have no experience of, and therefore couldn’t predict. This could throw timelines off by more than the 10% contingency allowance and lead to the project spiralling out of control.

Saving face

Similar to the grand vision theory, the perceived risk of not delivering a project might be so great that a silo pushes on to deliver a project at all costs. Ignoring the fact they have already failed because timelines and budgets are out of control.

On the other hand, if a project from another silo is perceived as failing or likely to fail, a team may be unwilling to step in and help because they don’t want their name attached to it. Protecting the reputation of the silo becomes the top priority, adding further disruption to any plan.

The solution is to test early and often

These scenarios might seem extreme, but we do come across them in our work. And while it’s true that silos don’t necessarily cause failure, their existence—along with human nature and corporate culture—create conditions where this is more likely.

We’d like to suggest a way to avoid the disaster scenarios we’ve looked at here. It’s an alternative approach to running projects based on experimentation, iteration and continuous development.

The basic principle is similar to a scientific approach—you start with a hypothesis about something and you test it. Rather than spending time and money going after the big vision, you start with small steps.

This approach is not always popular because it goes against corporate culture where a big, bold plan is expected. There are no flashy slide decks or grand visions.

However, we believe building hypotheses and testing them out in a digitally driven commercial world is often the best (and most efficient) way to approach projects. It’s how Amazon built a business after all… In the next post of this series, we’ll look at how you can put this iterative approach into practice for your business.