Over the last year or so, I’ve heard a lot of colleagues in Defra talk about 'pre-discovery'. They mean it as an additional phase of work to be done before discovery, which leads into alpha, beta and then live.
My own recent experiences make me think that while the preparation work done during 'pre-discovery' is incredibly useful, the name “pre-discovery” doesn’t help, and we should think about that work in a different way.
'Pre-discovery' is poorly defined
Despite lots of people talking about “pre-discovery”, it’s not part of the digital lifecycle as defined by the Government Digital Service’s Service Manual. Not everyone agrees that it exists. Those that do don’t have a shared definition or understanding of what it actually means.
I speak from personal experience. For the past couple of months I’ve been Delivery Manager for “pre-discovery” on something called the Asset Management Digital Transformation work stream. That’s a wide-reaching piece of work to unify our approach to managing the thousands of physical assets and pieces of equipment owned, managed or controlled by organisations in the Defra group. Everything from flood defences and sea-going vessels, down to computers and phones. The goal is to find better ways to manage and use these assets as effectively as possible.
When our small team started the pre-discovery, we were uncertain about what to do. We had a pre-defined budget to spend, but no clear goals for the pre-discovery. Different people had different ideas of what those goals should be. Speaking to other delivery managers, I found we were by no means the only team who’d reached the same conclusion.
A bit of guidance
Fortunately, around the time the team started working, the Enabling Digital Transformation team created a small amount of guidance around the preparation needed before starting discovery. This sounded like exactly what we needed.
This guidance has not been published publicly yet, but will be soon. It’s called “A guide to discovery” but some of it is specifically tailored to help Defra teams working with existing Defra processes. The section on “How to prepare for discovery” was really useful. In particular it contained table of tasks and suggested “things to bear in mind” for each one which shaped the way I approached pre-discovery:
| Prep activity | Things to bear in mind |
|---|---|
| Identifying the main business drivers | Why this service/policy area? Why now? What do we hope to achieve? How might this also contribute to wider programme or cross-Defra goals? |
| Gathering existing insight about the users of any current service and their probable pain points and needs | E.g. from customer service logs, performance data for existing online services, any recent surveys etc. You don’t need to be doing new research at this stage, just gathering what already exists. |
| Gathering existing insight about how any current service(s) in this area are delivered | Current policy, processes, technology maps, costs etc This could be expressed in As Is maps, but they don’t need to be polished at this stage. |
| Identifying subject matter experts who might get involved with discovery | Put placeholder dates in their diaries and the Service Owner’s for kick off & other likely events |
| Making the case for discovery and getting any necessary approvals | Don’t promise solutions at this stage! It’s about quantifying the problem/costs/issues that you want to look at. This will also need to include an understanding of the people and skills you are likely to need for discovery. |
Reading this guidance helped me realise that the main thing we were missing from the start was a business driver. We needed to explain why this work was needed, why now, what it hoped to achieve, and how it might contribute to the wider programme of work that it’s part of.
We realised that we’d had no engagement from anyone outside IT, we had no service owner, and had no real idea of who within Defra group actually did asset management.
Understanding what was missing gave us the clarity we needed to start work. We successfully defined our business driver, hired a service owner, and started finding (and talking to) the huge number of people involved in asset management. With that prep work done, we were able to start the process of securing a budget for formally starting discovery. We’re still awaiting a decision on that, but whatever the outcome I'm happy that our prep work was the right thing to do.
What we learned along the way
Pre-discovery is not a phase of work like the others
You’re not ready to do discovery unless you’ve pinpointed your business driver and got yourself a service owner. The other phases (discovery/alpha/beta/live) all assume a delivery team in place, working full time. Pre-discovery is different, because you probably won’t have a dedicated team, and whoever is working on it probably won’t be full-time. It’s not a phase of work like the others, it’s a task (or a series of tasks, depending on the scale of the challenge ahead).
“Pre-discovery” is not a great name
Pre-discovery is not really a phase of work, but giving it that name makes it sounds like it is. People get confused about what it means. I think we should stop calling it “pre-discovery”, and we should just say we’re “getting ready for discovery” or “preparing for discovery”. From now on, let’s call it that.
Don’t do original research
Much like Wikipedia, preparing for discovery should contain no original research. The research belongs in the discovery phase itself, not in the preparation. You should however gather as much existing research as possible.
There’s no set time limit
It should take as long as it takes, but be as short as it can be. As soon as you have got everything prepared for discovery, you should start your discovery. It took our team a couple of months to get properly prepared. Your mileage may vary, and costs may vary as well.
It really is important to ensure that costs do not run away with you, as it's easy to end up being over-prepared for discovery. It's worth repeating: once you've got everything you need for discovery you should be getting on with discovery.
Just get the team you need
You need the right people to get the job done. I think the skills and experience those people bring is more valuable than their job title. Useful skills are: pulling together people from different teams and silos, gathering existing insight, writing business cases and pushing them through approvals processes.
You don’t necessarily need a “team” at all, if you’re defining a “team” as a bunch of people working full time and exclusively on one thing. Preparing for discovery can be done effectively by a small group of people, working separately and when necessary.
Preparing for discovery means doing less
Preparing for discovery solely consists of any work that needs to be done before a team can start discovery. It should be done as quickly and cheaply as possible (if it needs to be done at all - in some cases, discovery can start without it).
Preparing for discovery is important, but it’s important not to overplay it. Do what needs to be done to get a team ready to start discovery, and no more than that. If you find yourself doing more than that, you’re probably starting the discovery too early, and ill-prepared.
4 comments
Comment by Alastair Williamson-Pound posted on
Nice article! I agree 'pre-discovery' is not an ideal name but it's been around for so long now that it might be here to stay. In the waterfall world it would be synonymous with the Project Mandate i.e. setting out the reason why the project should even begin to exist. I'm behind you on this but I have a feeling that pre-discovery will be a 'thing' until Lean accepts it as something else. I would be interested in other peoples opinions.
Comment by Rich posted on
Nice article, it was helpful!
PS. You've got a broken link in the last para: https://www.gov.uk/design-principles#second
Comment by Jon Show posted on
What's an "as is map"?
Comment by David Thomas posted on
Hiya Jon,
Sorry, I try to minimise the jargon but something always gets through. An "as is map" is a diagram describing how the existing service works. When developing a new service you want to avoid just following the "as is map", but it is important to understand it prior to starting.
Cheers,
David