Discovery: embracing the unknowns
The hardest part about discovery is, arguably, getting started
In my last blog post I talked about how valuable discovery work can be in making the case for taking a user centred iterative approach to developing services.
For teams working to the Government Digital Service Standard, or signatories of the Local Digital Declaration, discovery phases are an increasingly common part of digital service development. That’s a good thing, because it helps teams understand more about their users and the context before they start testing ideas or building things.
Getting started
The hardest part about discovery is, arguably, getting started. It means acknowledging all the things you don’t know, and will often be the very first step in any kind of digital service development for you or your organisation.
It can be tempting to suggest what solutions to the problem might be, or to try and present more certainty about what you’ll find than you really have. That’s natural, because it’s uncomfortable for us as professionals and experts in our service areas to say ‘I don’t know what we’re going to find out. I don’t know what the answer is. I’m not even sure we’re asking the right questions yet’. Avoiding that temptation will help make sure we get the most value out of a discovery.
So, how do you get lots of value out of a discovery for your team, your users, and your organisation – and avoid trying to pre-empt what you’ll find out?
The thing with working iteratively and making business cases
When we’re starting or proposing a project in government, there’s usually a business case to be written. That business case needs some expression of a problem, and some data to help support spending taxpayers’ money on it.
The challenge we often face is that before a discovery is done we don’t know the best expression of the problem, whether it really exists, or to what extent. We also don’t know how pressing it is when compared with other problems faced by an organisation, society, community, or users.
When we’re working on an alpha project, we have a much better sense of the problem we’re trying to solve and the impact we’re trying to have. But we’re still testing and iterating all the time, and might need to try several possible solutions before we find one that works well enough to take to beta. And we still might find that none of the available solutions has enough impact to justify a beta project.
This means some of the work that gets done may be discarded, but the valuable lessons that come with it are retained and built upon.
Openness can help resolve this inherent conflict
When we’re planning, scoping and delivering agile projects, we need to be honest about the limitations and expectations. These conversations aren’t always easy, but having them sooner rather than later helps to set up everyone involved for success.
If the person accountable for the budget has a better sense of what they will and won’t get out of a piece of work, they can make well informed decisions about whether that’s acceptable. Helping those decisions to be well informed from the outset makes them more stable, because it reduces the risk that an outcome of ‘things we’ve learned’ or ‘problems we think we should solve’ or ‘things we tried and stopped doing/threw away’ comes as an unpleasant surprise.
Unpleasant surprises naturally make people concerned about what else they haven’t been told, or don’t fully understand. The response to a surprise like this might be to withdraw the funding for the rest of the project, or reject a request to move it into the next phase.
Open and honest communication from the outset supports trust and enables senior decision makers to give delivery teams more autonomy, which in turn enables the delivery of better outcomes.
Think of each project as a single step on a much larger path
That path could be towards a much broader organisational change or digital transformation.
Being open about our approach to delivering agile, user-centred projects puts us in a better position to effect broader change. It makes these type of conversations progressively easier, and supports the better and more effective delivery of projects, products, and services.
We should do the hard work to make this simpler for those who come after us. The more we obscure how we work, and why it’s valuable, the harder we’ll find it to gain broad organisational support for the next project, and the one after that.
If you want to read more about discoveries, we really like this blog post.
