UK government has been a trailblazer in the use of discovery, one of the reasons it has become a world-leader in user-centred design. Discovery is the most critical and most challenging phase in developing a new public services, so a few of us from digital teams decided to see what’s been learned from the first few years of discoveries in government so that we can do even better over the next few years.

Background

Me, Rob Banathy, Helen Mott, Rob Stirling, Iain Gordon ran the retrospective. We spoke with 25 people from the service management, product, delivery, research and design professions, from several government departments. The things we learned have been shared in a Google Doc for the last few weeks but some government departments can’t access Google Docs and a few people outside of government said they’d like to see what was learned too, so here they are on an easily accessible blog.

You can find out more about how this retro began and the questions we asked in a previous post.

Retrospective prime directive

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. At the end of a project everyone knows so much more. Naturally we will discover decisions and actions we wish we could do over. This is wisdom to be celebrated, not judgement used to embarrass.”

Summary of themes

  1. Pre-discovery is a thing
  2. Briefs for discovery vary
  3. Teams rely on their professional experience when carrying out a discovery
  4. Teams expressed a desire for more guidance on discovery
  5. Service Manual guidance on discovery has limited use
  6. Time taken to complete a discovery varies
  7. Teams would like to learn from other discoveries
  8. Discoveries have been valuable in stopping work where there is a weak business case, or the conditions to proceed to alpha are not present
  9. Business case for a solution comes at the end of alpha
  10. Discoveries sometimes blend into alpha.

Pre-discovery is a thing

Work often happens before discovery officially begins, and this is often alled ‘pre-discovery’. We currently lack a definition of pre-discovery (it can currenrly signify any work that happens before discovery officially begins).

Things we might want to explore:

  • Is pre-discovery used to test the case for a discovery happening? In which case, is it better described as something like ‘discovery proposal’?
  • Is pre-discovery used to build the brief for a discovery team? In which case, is it better described as something like ‘discovery initiation’?

Brief for discovery varies in format, clarity, and route to team

The format for a brief can vary from conversations, to emails, to clear briefing documents. This does not necessarily matter, in itself. However, Service Managers and teams report that they can spend time (days, sometimes more than a week) clarifying the brief for discovery.

Things we might want to explore:

  • Does this match our expectation of how a discovery should begin?
  • Do we expect clearer briefs before a discovery begins?

Teams rely on their professional experience when carrying out a discovery

Teams report that they rely on their professional experience when approaching a discovery, over explicit guidance (e.g. good practice, other examples of discovery, etc).

Teams expressed a desire for more guidance on discovery

Despite relying on their professional experience, teams expressed a desire for more guidance. This is a tricky one to draw conclusions from and deserves more digging but an early assumption is that a problem with relying on professional experience when approaching discovery is that everyone’s experience is different. It seems that this can lead to a situation where a team all believe that they understand the same thing by the term ‘discovery’ . . . but don’t understand the same thing, in reality - which can lead to dysfunction.

Service Manual guidance on discovery has limited use

The majority of people are aware that it exists but few reported more than cursory use of it.

Things we might want to explore:

  • Does it need to be better?
  • Do teams need to be connected with it more consistently?

Time taken to complete a discovery varies significantly

Most of the discoveries we heard of took between 4 weeks and 3 months to complete but also heard of a discovery taking 6+ months.

Things we might want to explore:

  • Does this matter?
  • Some delivery teams and Service Managers report frustration with the time taken to complete discovery
  • Some teams think that discovery could have been completed more quickly if they could access users quicker, and if they could work more closely with stakeholders and subject matter experts
  • Scope of discovery seems to vary and it may be that there are different ‘scales’ of discovery.

Teams would like to learn from other discoveries

Teams expressed a desire to see what has been learned in previous discoveries, in order to avoid duplicating work. However, they said that they hadn’t found an easy way to find out about previous discoveries within government and that it can sometimes be difficult within their own departments.

Things we might want to explore:

  • Is the expectation that discovery insights should be shared within departments and cross-government?
  • If so, does this happen already?
  • If not, how do we make it happen?

Discoveries have been valuable in stopping work where there is a weak business case, or the conditions to proceed to alpha are not present, saving money for the tax payer

We heard of two discoveries that did not proceed to alpha.

Things we might want to explore:

  • We’d expect to hear of more discoveries don’t proceed to alpha or are paused, are there more examples out there?
  • Is there an expectation that discovery should lead to alpha?
  • Are teams empowered to pivot to such an extent that discoveries are sufficiently refined that they will tend to proceed to alpha?

Business case for a solution comes at the end of alpha

Teams reported an expectation from stakeholders that the discovery would produce a business case for a solution, however teams expect this to come at the end of alpha.

Assuming that the point of:

  • discovery is to prioritise a problem to solve (having explored several problems)
  • alpha is to prioritise a solution to the problem (having explored several solutions)

then it was felt that point of alpha is to product a business case for a solution (not discovery).

Things we might want to explore:

  • Do ‘digital’ teams and ‘the business’ mean the same thing when they use the term ‘business case’
  • Are ‘digital’ teams doing a good enough job at explaining the point of discovery and alpha?

Discoveries sometimes blend into alpha

Teams reported that discoveries sometimes blend into alpha without as much checking/approval as they would expect, given the quality checking that goes on for the other stages of the Service Manual. Most typically, a discovery is summarised in a slide deck and presented to key stakeholders, who make a go/don’t go decision.

Next post: hypotheses for improving discovery.