Most people would agree that doing some Discovery before picking up a large new piece of work is useful. It ensures everyone knows the goals they’re trying to achieve, who needs to be involved and roughly the size and shape of work. It sets realistic expectations for interested parties and aligns the teams working together.
Where I hear many debates is around how long should a Discovery phase take? And how do you know when you’re done? How do you plan a Discovery phase?
It can be so easy to dive down rabbit holes and turn a Discovery phase into a lot of workshops with a lot of talking as various opinions and viewpoints are shared and debated. Then after a few weeks, a C-level gets frustrated and tells you to report back in 1 week with the MVP scope and timings defined so you can just get on with building. Discovery phase done.
A few years ago myself and a small team consisting of a User Researcher (Jonathan Sykes), two Business Analysts (Dharani Kumar & Caroline Milburn) and a Technical Architect (Reda Hmeid) were asked to lead the Discovery phase for Making Tax Digital, HMRC’s multi-million pound investment to transform all of the UK small businesses to a fully digital tax system. I’ll be honest, I had no idea how big of an endeavour I’d signed up for. We had 3 months to figure out an MVP and then set-up the team to deliver it.
Here are my tips from planning one of the bigger Discovery phases I’ve led in the hopes that some of it sparks inspiration for future Discovery phases you’re involved in.
Tip 1 - Discovery Assumptions
I’ve never seen another organisation produce this before but in hindsight, this was an incredibly useful exercise. Before the project team were hired, the Programme Sponsor asked all of the stakeholders to contribute to an assumptions document where they’d capture all of their assumptions of how or what the programme would deliver, how the world would function once it was done, policy changes that would be made, you name it. It wasn’t a workshop - it was a scratchpad collaborative document of everyone’s assumptions, including their names and departments so we could see who we’d need to speak to. When we arrived, it turned out to be an incredibly useful starting point. And because it had been framed as ‘assumptions’ rather than ‘requirements’, it set the expectation that this wasn’t a wish list - we would need to validate if they actually made sense.
We started to group each assumption that we thought logically went together. Once we had the groupings, we gave each grouping a name. And tada! We had an assumed high level scope. Now we could validate it in the Discovery phase.
Tip 2 - Outcomes for the Discovery phase
This step was so useful because it told us when we’d be done with Discovery.
As a team, we asked ourselves what do we think we need to have at the end of the Discovery phase in order to start building?
As a cross-functional team of Product (Rob), Delivery (me), User Research (Jon), Business Analysis (Dharani & Caroline) and Architecture (Reda), we each wrote down what we thought we’d need to create in order to start building. Here’s an example list:
A clear SMART goal of what the initiative aims to achieve
List of the customer types that would use the product or service
High level user needs for those customers
High level 1 page diagram of the as-is processes that we wanted to digitise
MVP - the first slice of value we could deliver and to which customers
High level solution of how we could deliver that MVP
High level strategy for how that MVP would evolve to meet more customers and user needs
Rough sizing and timings to deliver the MVP
Skill-sets and budget required to deliver the MVP
A list of the biggest risks and constraints that could block us
A very very gut level guess as to how long it would take to achieve the overarching goal of the programme so we could set expectations early. I.e. this is a 4-5 year programme work so be prepared to budget it for that long.
A slide deck that would summarise all of the above succinctly and could be easily presented and communicated at the end of the Discovery phase. The audience for this is your budget sponsor, your stakeholders and any other teams or people who would be interested in what you’re doing. This is also a really great artefact to help onboard new team members when they join and sign-post where they can go to find the details.
We then made clear who was the owner for each deliverable and who would collaborate with them on it. And finally we agreed where we’d capture our research in a centralised place that would be accessible to all of us and all future team members who would join us.
Tip 3 - What questions do we need to answer in Discovery?
Once we had an understanding of the deliverables for Discovery, we dove into the next level of detail by asking ourselves, what questions would we need to answer to create those deliverables? There are NO stupid questions.
Together we started writing post-its of every question we could think of and we had a lot! None of us had experience working in taxes or accounting so this included what industry knowledge we’d need to attain or where we might need to find specialists to supplement our team.
Here’s some example questions:
Who are our users / customers?
How is Self Assessment tax calculated?
How do users currently submit their Self Assessment information and make payments?
What is and isn’t working with the current submission processes?
Who makes policy changes?
What is the annual cycle of tax submissions for each tax type?
What are the existing systems and services being used to submit taxes?
What will block us or slow us down from delivering the MVP?
Once we had our pile of post-its, we grouped them according to which questions you could logically answer together and added who or how we could answer the questions.
For example, we grouped together these questions and said they could be answered through user interviews:
How do users prepare to submit their taxes?
What are the different types of users - End Users, Agents, Accounting firms
What are the different kinds of software that could be integrated for them to continue their business with minimal disruption?
How did the users find out how to submit their taxes?
What is easy vs. painful for users when they submit their taxes?
As we did our groupings, we also got brutal about which questions actually needed to be answered before we could start building. This was to constrain the Discovery phase to only what is needed right now and again try to steer away from rabbit holes. For example, we don’t need to know how users found out how to submit their taxes as part of the MVP. We’ll be targeting an engaged user group so this is something we can answer later.
This is an incredibly cathartic exercise that is also a great way to make everyone in the Discovery team feel like they’re working together in a safe space. It demonstrates that we’re all in this uncomfortable and unknown space together. It’s also a great exercise if you’re bringing together other areas of your organisation so you can assess where there are knowledge gaps versus where you already do have answers in the team. Being able to say ‘oh I can answer that - let’s chat!’ is a great start to knowledge sharing.
Tip 4 - The Discovery Plan
Now we had our assumed high level scope, deliverables, our questions to answer and a rough idea of how we might go about answering them. Now what?
I mapped out a timeline for the 3 month period we’d been given. We first added what activities might need to take place at the end of Discovery. We’d need time to summarise our findings into the playback deck, we’d need time to playback that deck to stakeholders so we could get a decision in 3 months, etc. To keep everyone focused, we actually picked the week when we would do a playback of our Discovery findings and make the decision on the MVP proposed plan. We then gave ourselves 2 weeks before it to sort through our research and prepare our deliverables for that session.
And then we looked at the time we had left. Ooof, 3 months isn’t a lot of time to discover how to digitise the nation’s taxes!
We looked at our piles of post-its and decided, what are the basics? What do we need to answer first to help us set the foundations? We dragged those activities into the first few weeks.
Now that we would have a basic understanding of how taxes work, what would we need to answer next? Then we dragged those activities into the following weeks. We did this for each wave of questions until we had mapped out what activities would need to happen week on week to address our questions.
We then built in gaps for follow-up sessions since we didn’t know how the workshops might run and if we’d be able to cover it all in one session.
This gave us insight into who we’d need to talk to and when, which meant we could start getting workshops and interviews into people’s diaries as early as possible.
In Conclusion
No, we did not stick to the waterfall plan we created. Yes, we did decide on the MVP and do our playback to Project Sponsors on the weeks that we promised. We ran the Discovery phase in sprints and used our initial plan as a guide. At the start of each sprint we’d ask ourselves, based on what we now know, does this still make sense? Or do we need to change tack? Some of it stayed the same, and in other areas we learned it was far more important to delve deeper into some spaces at the sacrifice of something less important.
I still can’t believe we did that Discovery in 3 months. Thank you to Equal Experts for the opportunity.
Comments