It’s ok to stop

In the previous post we talked about one of the common flaws with running a discovery phase. Next up, here’s something else that’s important and easy to forget:-

It’s ok to stop a project after Discovery.

The desire to plough on past Discovery is a very human one.

There’s a great deal of research around the sunk cost heuristic  which supposes that us humans in general are quite often inclined to keep going when in fact we’d all be much better advised to give up already. We give too much weight to the progress we’ve made, and as we are also by nature inherently optimistic, we’ll often under-estimate the scale of problems and issues before us.

For Discovery teams this sometimes equates to a tendency to play down the problems and issues unearthed and instead focus on getting to the next phase where they can get on with development proper.

Coupled with this can be slightly murkier, but no less understandable imperatives. A stopped project is unlikely to be listed on somebody’s CV (although arguably it should be) and for contractors a Discovery to nowhere can mean a stopped contract.

To understand this in a broader sense it’s useful to think about Discoveries in an organisational context. One of the major benefits they’re meant to give is to foster innovation by trying things quickly and with a minimum of investment, and allowing things to “fail early” rather than later. If projects are NEVER stopped something is wrong somewhere.

If you have a large organisation with a fair number of Discoveries then it’s useful to bring together data over time about how they’ve all performed collectively. This lets you understand how many Discoveries were stopped and how projects performed after the Discovery phase.

Not ever stopping Discoveries can be down to a number of things. Perhaps there is over rigorous vetting pre-discovery that is stopping things that might fail actually before discovery has started. This is almost certainly incurring hidden time and cost by surreptitiously running two Discoveries (the second of which isn’t really a Discovery) or stopping projects that might succeed before they’ve had a chance to start.

More commonly, something is broken at the end of Discovery. Discoveries are not intended to just be a compulsory introductory pre-phase which gets rubber-stamped through to the project proper. If this happens, and serious issues aren’t exposed and addressed, the danger is that a project merely limps on to the next gate or milestone in a state of confusion.

It’s key then to be very clear on what we’re looking for at the end of Discovery, and then be certain that the outputs we’ve said should be there are ready or the project has explained along the way why they’re not. Then we need to assess these in an objective way – and that means making those outputs transparently available, and open to review and challenge. From an organisational perspective it’s usually best to try and standardise how this end of Discovery decision gets made i.e. put in place some kind of common governance across service delivery.

Another thing to bear in mind is that there are many options at the end of Discovery. You can stop. You can continue. You can re-run it. You can extend it – and for this remember a discovery team should be smallish, so spending another few weeks in discovery with a small team is likely to be cheaper than running a larger next phase (usually an alpha) team for a period of time then stopping it.

However it can often be hard to weed out a bad discovery from a bad idea. That’s why it’s important to carefully check the background work on a discovery output. Have they actually got the breadth of research done? Have they really got the user needs down? Do the user journeys actually make sense? Or is it just a great slide presentation?

Too much early prototyping also needs to be examined carefully – had the project team already decided what they wanted to do anyway and not actually run a true Discovery?

Referring back to our earlier post the best way to avoid this kind of scenario is regular engagement with the Discovery team and proactive engagement with users and stakeholders. If a couple of extra weeks would help iron out issues and provide clarity it’s probably wise to allow this.

If you’re seeing none of the above potential problems though, and the team still aren’t able to make a compelling case to proceed at all, then they must be stopped. Even in this scenario a common mistake is to lose all of the work that’s been done – and then proceed to reinvent the wheel in 12 months time. Make sure the work that the Discovery team has done is recorded somewhere for easy retrieval by whoever looks at this area next- and importantly make sure it’s stored with the reasons for stopping the Discovery attached.

Ultimately what we are trying to achieve is to change stopped Discoveries from being considered as “failed projects” to be “successful Discoveries” instead. If the aim is to prevent expensive, disastrous projects or poorly delivered solutions, then a stopped discovery has delivered a significant amount of net value. The team or resources can now be redeployed elsewhere to try and deliver something else.

In an ideal situation then, the organisational culture will change to reframe failure, and  the associated shift of the mental models of the team will mean that many of the problems we’ve talked about above will simply disappear.

%d bloggers like this: