Phase 1 - Discover

The discovery phase enables you to form a team around a clear understanding of a problem. We always start with a discovery exercise, even if a service has already identified a particular software solution. The end of a discovery phase helps us understand whether we can reuse an existing piece of software, buy something or need to build some, or all, of the solution. This is important because work often starts because someone believes they’ve found a potential solution and just wants it to be implemented. Sometimes that solution turns out to partially solve the problem, particularly when that problem is complex. If the implementation takes time or costs money the work may have made that problem worse.

Team and skills

You may not be able to assemble a large team at the start of the project. However, you should try to build a core group that can take you through the whole project lifecycle. Even if your team is one or two people, they will need to play the following roles:
  • A project sponsor
  • A Product Owner
  • A developer
  • A user researcher
It won't always be possible to identify a Product Owner before the Discovery phase begins, but you can use the workshops and show and tells to identify people who might have the skills and interest to be a Product Owner. It is not essential to have a developer working full-time during Discovery, but it is important to have input so that:
  • They can understand the user needs
  • They can advise on the achievability of the solution
    • You may also find it useful to include:
    • A business analyst
    • A delivery manager
    • A subject matter expert
    • Frontline staff (someone who deals with customers on a daily basis)
    Discovery projects work best when everyone has clear areas of responsibility but the team talks regularly to share what they learn. It's important that team members don't simply read what others have produced but are responsible for ensuring they've understood it and probed it from their own perspective and professional skillset.

    See: Roles in an Agile team

    Governance

    Our manifesto says it’s better to take small, quick steps than to embark on long journeys. So you can spend up to two weeks working to develop a project without any formal governance, provided this isn’t at the expense of other work. The Relationship Manager will usually take responsibility for setting up a Discovery phase. To formally initiate a project you will need the agreement of the ICT steering group (or equivalent) of the relevant directorate. We use the template provided by the Digital Outcomes framework to explain the vision and intended scope of hte work. This means that if you need to procure an agency to support the project, you don't have to produce multiple documents saying similar things. At the end of the phase, should you wish to continue with the project, you will need to book an assessment of the work against the Local Government Digital Service Standard. You should look to ask two assessors to hear a presentation capturing what you’ve learnt and how you will move to the next stage. These may be colleagues within ICT but should not be associated with the project. For larger projects (eg over £100,000 or affecting more than 5,000 residents) you should seek the input of an external assessor. Contact LocalGovDigital to identify a digital/ICT leader in another local authority that could volunteer their time to conduct the assessment. Assessments are published on our microsite HackIT.org.uk.

    Tools

    There are a number of research techniques and workshop-based tools that can help you during Discovery:

    Timing

    A discovery phase will usually last 6-8 weeks. If you're exploring a single service (rather than a whole area) it will be between 15 and 30 days in total.

    The things that can take most time to put in place are:

    • Interviews with users
    • Exploring the business process and understanding any regulatory or legislative constraints

    Outcomes

    A successful discovery phase will:

    • Identify all of the types of user, including those who may not be able to use a digital service
    • Understand the strengths and weaknesses of their experience today and develop hypotheses about what an ideal service would do
    • Identify the key business challenges and the type of improvements that are possible (cost savings, customer satisfaction improvements)
    • Identify key areas of focus for the next phase of work (eg a part of the customer journey that is causing particular pain, or a part of the business process that could be easily automated)
    • Align the stakeholders around the definition of the problem and get agreement to take the next step

    For inspiration

    End of phase checklist

    We have:
    • A team that has a shared understanding of the problem and how we might solve it
    • Identified all of the types of users and stakeholders associated with the project
    • Interviewed at least 10 users to learn about their experience, skills and needs from an ideal solution
    • Mapped the customer journey and understood the key pain points
    • Mapped the business process and identified key constraints
    • Demonstrated our work to a wider group of stakeholders
    • Hypotheses for the types of improvement we may be able to deliver
    • A business case to justify the next phase of investment required
    • An assessment of the software you need to buy against the Technology Code of Practice (where necessary)
Team and skills
Governance
Tools
Timing
Outcomes
End of phase




Last updated on 25/06/2018