All too often, projects fail big — major issues arise too late to do anything about them, and time and costs balloon. It doesn't have to be this way.
When starting out on something new, in virtually any arena, the urge to get on and do stuff is incredibly strong.
It feels important to be seen to be doing something — to be a person who acts! Being effective and dynamic, leading with authority, means to be active and to be seen to be so, it’s assumed.
That’s pretty much the biggest error that can be made, especially with large projects.
To be truly effective, you need to slow things right down.
Instead, you need to be guided by a vital principle:
Fail fast and learn quickly.
This heuristic (a fast and frugal rule of thumb) is so important for a Chief Delivery Officer or other delivery principal that it should almost be said as the opening statement for any new project, and repeated and repeated all the way through the opening stages.
This heuristic — fail fast and learn quickly — is strongly related to the previous one, the most important principle — discover stuff first of all.
There’s two parts to this statement — fail fast and learn quickly. And neither is complete without the other.
So what do they each mean?
What does ‘fail fast’ actually mean? #
It’s easy to have ideas — interesting and novel ways to approach a particular problem or achieve a desirable outcome.
Some will be good. Some even very good. Others will be bad, and maybe even disastrous.
So crucially, those ideas need to be put to the test. You need to know the difference before you come to rely on something specific that is novel or innovative and only then discover which is which.
Experiments that fail are good experiments #
That means every project needs to build in a robust period of testing, trialing and experimenting.
Whether its a new digital technology, a novel toolkit, an innovative building method — test it.
Experiment in multiple ways, scaling up as you go:
- try it small — the quickest and easiest method you can find, a pen-and-paper design first by preference
- try building a quick mock-up — a non-functional thing that kind operates as you’d like it to do without actually doing much
- try building a model — build something with some actual functionality, something that can bear some weight
- try building a prototype — build something that kinda works, even if not at much scale or pace
With each of your experiments, get real users to use them, i.e. not yourself — you know how they work, you know how to get the ‘right’ outcome.
A desirable outcome from each of these experiments is failure.
You need to know when and where and how and why each of these things break. The earlier you achieve that failure, the better.
Each time you find a place of failure in a cheap or early trial, that’s a time you haven’t failed in the real thing.
As a Chief Delivery Officer, then, it’s important that you create a culture that is comfortable with failure. In fact, more than just comfortable, you should actually welcome failure.
Leaders must unequivocally give their teams permission to lean forward and take risks.
With one vital proviso — that you learn from it, and learn quickly.
What does ‘learn quickly’ actually mean? #
Each failed experiment is a way not to do what you’re aiming to achieve.
That means learning, and where possible, learn quickly.
Analyse what went wrong and why, and work out what you can do about it.
Is it a fundamental problem? Does it indicate an essential issue with the given approach that introduces a fatal vulnerability? Or is it something that needs just some adjustments and/or minor tweaks to make it successful.
Learn those lessons, and bake them into a new set of experiments.
Fail while it’s cheap, learn while it's quick #
It’s vital that you do all this at the earliest stages of a project.
Before you even start putting ‘spades in the ground’, you need to understand all that you can about the ways that the thing can go wrong to avoid discovering those by accident later on when failure becomes expensive.
That becomes incrementally more important as the project price tag increases.
If you spend 5%, 10%, 20% (or more!) of the whole budget on lots and lots of early experiments that unearth hidden problems and stop you from discovering those when you’re in the middle of building, you will potentially save 40%, 50%, 75%, 100% (or more!) increases to the overall spend that are necessary to accommodate these issues.
Make experiments that fail a requirement #
No project should be given a green light if you don’t know in detail how if could go wrong and you have taken steps to avoid those problems.
Only when you have done that can you be confident that you will start out on the right track and stay there.