Why IT leaders need to learn to 'fail fast'

In the long history of bad IT projects, one of the common characteristics has been the willingness – perhaps even determination – of IT teams to see things through to fruition even when it’s obvious that things have gone wrong.

This has been highlighted numerous times in various official reports about some of the high-profile government IT projects that have gone off the rails – even now, it looks like the increasingly troubled Universal Credit programme is going the same way.

Elaborate quality assurance processes have been put in place to flag up failing projects at an early stage – but in many cases civil servants have ploughed on regardless.

It’s not exclusive to Whitehall though – there are plenty of private sector projects that have made the same blinkered mistakes.

So it’s refreshing – even if on a small scale – to see retailer John Lewis talking publicly about its intent to “fail fast” at technology innovation.

The department store canned a “virtual mirror” initiative that had been launched with great fanfare last year, because it was making no money. “The key is, when you find it’s a dud, stop,” said one of the John Lewis IT executives.

It’s a principle that all IT leaders would do well to adopt.

“Fail fast” is a phrase that has come out of the online and start-up worlds, where the emphasis is on prototyping and piloting new initiatives, which inevitably makes it easier to stop. When there have been thousands of pounds sunk into a major development programme, there is clearly more at stake for project leaders.

But if “fail fast” has an antonym, it’s “pride comes before a fall”. It would take a culture change in many organisations to make a fail-fast strategy accepted, and not simply seen as failure. Risk-averse British business culture can be a hindrance.

But failing fast doesn’t just encourage honesty and prevent problem projects. It enables a culture of innovation – think how much more confident employees would feel about suggesting new ideas if they knew there would be no stigma attached to their subsequent failure.

“Right first time, every time” was the mantra of the quality brigade, and it’s a nice objective to have – but it doesn’t always reflect reality. Fail fast is good for IT departments, and good for innovation.