# 1 Understanding the Current Service (As-Is)

## Before you start the As-Is phase

Before you start, check you have:

* [ ] **read the** [**GovStack design principles**](https://specs.govstack.global/implementation-playbook/implementation/design-service/design-principles)
* [ ] **an understanding of the service’s purpose and scope**\
  You can describe which service (or part of a service) you are focusing on, and why now. You have the finalised service prioritization to hand
* [ ] **shared expectations about the ‘As-is’ phase**\
  Participants understand that the ‘As-is’ phase is about learning and understanding
* [ ] **permission to explore end-to-end**\
  The team are able to discuss data, responsibilities, and dependencies across teams and organisations
* [ ] **access to the right people**\
  You are able to involve people who understand how the service really works, including offline steps and cross-organisation hand-offs
* [ ] **the right team**\
  You have people to take responsibility for the skills outlined in the table below

***

### Skills required for the As-Is Phase

| Area of Expertise                   |                                                                                           |
| ----------------------------------- | ----------------------------------------------------------------------------------------- |
| Product management                  | Identify assumptions related to the product’s success.                                    |
| Delivery management                 | Manage delivery risks related to timelines or dependencies.                               |
| User research                       | Validate assumptions through testing and research.                                        |
| Service design or business analysis | Research internal processes and create prototypes for the high-level, to-be user journey. |
| Technology                          | Identify technical risks and constraints, and guide technical choices.                    |

***

### Criteria for success in the As-Is Phase

This phase focuses on building a shared understanding of the problem space before moving to solutions. The criteria below describe what teams should have achieved, along with examples of evidence that indicate readiness to progress.

| Criteria                        | Evidence                                                                                                                                                                                                                                                                                                                             |
| ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Map the as-is service           | <p>End-to-end user journey maps (required)</p><p></p><p>Technical, legal, organisational, and resource constraints are identified and understood</p><p></p><p>Discovering and note down the relevant legislation in the journey map or another document.</p>                                                                         |
| Model the domain                | <p>A list or visual of key domain concepts (e.g. application, approval, status)</p><p></p><p>A simple service glossary or dictionary</p><p></p><p>A rough domain diagram</p>                                                                                                                                                         |
| Understand users and challenges | <p>User needs statements</p><p></p><p>Lightweight personas</p><p></p><p>Accessibility needs and barriers for diverse users are understood</p><p></p><p>Interview notes, observations, or summaries</p><p></p><p>Documented challenges faced by users, frontline staff and back-office teams</p>                                      |
| Analyse research data           | <p>Themed insights or findings</p><p></p><p>Problem statements or “what we learned” summaries</p>                                                                                                                                                                                                                                    |
| Prioritise next steps           | <p>Prioritised opportunities or focus areas</p><p></p><p>What to explore and not to explore next</p><p></p><p>An initial action plan, such as:</p><ul><li>quick wins</li><li>candidate pilots</li><li>areas needing further discovery or feasibility work</li></ul><p></p><p>Initial KPIs are baselined using Discovery Insights</p> |

### Moving to the next phase <a href="#moving-to-the-next-phase" id="moving-to-the-next-phase"></a>

Discovery is complete when the team has enough shared understanding to decide what to explore next. Before moving into the to-be stage, teams should take a moment to reflect on what they have learned and agree:

* which problems or opportunities are most important to explore next
* which parts of the service are understood enough to move into end-to-end journey exploration
* where confidence is lower and further discovery, research, or testing is needed

If the criteria above have been met and supporting evidence is in place, teams can make an informed decision to:

* proceed to the to-be phase to explore solutions
* continue Discovery to further explore options or reduce uncertainty
* end the work if there is no viable way forward

This decision should be based on confidence and learning, not on pressure to progress.

***

### Run an As-Is workshop <a href="#heading-title-text" id="heading-title-text"></a>

| Session                                                                                                                                                     | Activities                                                                                                                                                                                                                                                                                           | Who to involve                                                                                       |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
| <p><strong>Introduction & framing</strong></p><p><em>60 minutes</em></p>                                                                                    | <p>Set the objectives</p><p>Recap the service</p><p>Discuss the definition of end-to-end services</p><p>Emphasise why we take a user-centred approach to build empathy</p>                                                                                                                           | Service owner, delivery lead, policy or programme representatives, all participants                  |
| <p><strong>Map the As-is</strong></p><p><em>3 hours</em></p>                                                                                                | <p>Agree service scope and boundaries. Map the current service end-to-end including online and offline steps.</p><p>Break into groups to focus on multiple journeys or divide complex journeys.<br><br>Capture any known relevant legislation either as a row in the map or as another document.</p> | Frontline staff, back-office staff, delivery team, policy representatives, user advocates or proxies |
| <p><strong>Model the domain</strong></p><p><em>60 minutes</em></p>                                                                                          | Identify key domain concepts. Clarify roles and responsibilities. Create a shared glossary or service dictionary. Surface unclear ownership and differing interpretations across teams.                                                                                                              | Delivery team, subject matter experts, representatives from involved organisations                   |
| <p><strong>Understand users and challenges</strong></p><p><em>30 minutes</em></p>                                                                           | Using the journey maps to identify actors involved create simple personas to keep in mind through the rest of the design activities                                                                                                                                                                  | Frontline staff, back-office staff, delivery team, policy representatives, user advocates or proxies |
| <p><strong>Analyse findings</strong></p><p><br>(The facilitator can do this async during a break or before the next session)<br><br><em>30 minutes</em></p> | Cluster insights from mapping and user work. Identify themes and patterns. Draft problem statements or opportunity areas. Record risks, assumptions, and gaps in knowledge.                                                                                                                          | Delivery team, facilitator, service owner                                                            |
| <p><strong>Prioritise next steps</strong></p><p><br>(This can be moved to the start of the next day)<br><br><em>60 minutes</em></p>                         | Prioritise quick wins, near-term improvements, and longer-term changes. Agree what to explore next and what not to pursue yet.                                                                                                                                                                       | Service owner, delivery lead, policy or programme representatives, technical lead if available       |