How To Kill Doomed Projects

The challenge for managers in the “can-do” culture of business is to distinguish between belief as a key driver of success—and belief as something that can blind managers to a project’s ultimate failure – Isabelle Royer 

It’s always easier to start something new than it is to stop doing something.

Many of our organisations are prone to a form of corporate initiativitis – where people are rewarded for the creation of new activities rather than the scrutiny and hunting down of unnecessary zombie projects. Zombies are projects that, for any number of reasons, fail to fulfill their promise and yet still they keep going, with people unwilling or unable to put them out of their misery. 

These activities often make sense on paper – the benefits they bring and the development timeline sounds achievable. But somewhere along the way, something changes.

Why can’t companies kill projects that are clearly doomed?

Contrary to just poor management or bureaucratic inertia, the research of Isabelle Royer showed that many failures result, ironically, from a fervent and widespread belief among managers in the inevitability of their projects’ ultimate success. As she writes – “this sentiment typically originates with a project’s champion; it then spreads throughout the organization, often to the highest levels, reinforcing itself each step of the way. The result is what I call collective belief, and it can lead an otherwise rational organization into some very irrational behavior.”

The modern obsession with change champions – equipping armies of people to go out into organisations like evangelical missionaries proselytizing change – can reinforce this behaviour.

We can restore some rationality through transparency and effective scrutiny. Some of the most successful companies have cultures with just enough friction: with teams having regular, intense debates. Discord, rather than agreement, has to be allowed to take its proper place if we are to solve the problems that matter.

As Chris Bolton has written, not speaking truth to power contributes to very many project failures. It’s a complex problem that is cultural rather than merely the fault of managers. Organisational systems and culture often prevent people speaking truth to power, even if the ultimate boss is willing to listen.

Lessons Learned from the ‘RMS Titanic of IT disasters’

In 2011, U.K. government officials finally scrapped a massive 9-year, $16 billion project to create a unified electronic health records system for British citizens. 

The project – described as ‘doomed from the beginning’ – was criticised for being too large, too ambitious, too monolithic, and for having too many changing requirements. 

The warning signs were there from the start. The government chose the top-down,  approach. The solution was initially designed, not with actual users, but by a large central team, and intended as a complete “big-bang” replacement for the many and varied existing systems. 

A research paper summed up the main lessons learned:

  • Efforts should ideally begin with the user, before moving on to more general organizational and national requirements.
  • The initial focus should have been on making the software usable. This should be informed by users. 
  • A balance between customised approaches and standardisation is vital. 
  • An incremental roll out – with a more iterative approach, would have minimised risk

It’s not rocket science is it?

In fact the determinants of success seem to be weighted on just four factors: avoiding top down design, effective user involvement, speaking truth to power and avoiding silver bullets.

Project Flow Chart (2)

Zombie projects occur when all these factors converge and confirmation bias sets in. Even though everyone knows this isn’t really working, we carry on regardless.

As part of the work we’ve been doing at Bromford we recognise that slaying zombies is just part of good governance. Innovation is all about discipline in the creation and implementation of new ideas that create value. However it’s about stopping doing things too. As a general rule each new service or activity should lead to the decommissioning of an existing one.

It’s often harder to stop doing things that used to be valuable than start new things.  It’s that fear of stopping activity that holds real innovation back. 

Stopping a project isn’t failure. But failing to stop a project that is going bad –  that is failure.

Ultimately this is about keeping ego, ownership and politics out of the equation. We only need to be really good at a few things to have more successful outcomes:

  • Effective problem definition
  • Avoiding top down initiatives
  • Involving users in the actual design
  • Promoting local customisation and avoiding silver bullets
  • Iteration rather than mass deployment
  • Speaking truth to power and critically questioning the direction of travel

If we can get better at those – and make them foundational principles of new activities – we won’t need to kill doomed projects.

We’ll have no zombies left to slay.

  1. Great post. A really good read, and touched on lots of important ideas.
    Thanks Jon.

    Reply

    1. Thanks for reading Jon – appreciated

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: