Shortly after I joined NHSX, the UK was thrown into a crisis and my team was quickly put to task. Understandably, the focus was on doing — there was so much that urgently needed to get done.
I am extremely proud of the work that I was involved with in response to COVID, standing up urgent services for people who needed extra support, for example:
- I helped launch the text messaging service that notified and supported those shielding and,
- I worked to set up an end-to-end service to provide iPads to care homes to support online consultations with GPs and video calls with relatives.
While we haven’t beaten COVID yet, I have had more time to reflect on what went well and what didn’t. It may seem counterintuitive, but the biggest lesson that I learnt was the importance of slowing down in order to deliver the most positive impact at a rapid pace.
Below are some tips on when and how to hit pause before doing:
1. Before doing: collect, coordinate and collaborate
A national crisis meant that many teams and organisations were forced to refocus their efforts on the Covid response — suddenly you had many people all working towards the same goals. In this context we rushed in to support, responding wherever we saw a need. This made for a messy patch where we would start a piece of work, make some progress and then hit a wall later when we found that another organisation was already on the case.
What I learnt:
Never scrimp on scoping: Working at pace amidst rapidly moving parts can make it even harder to see the wood for the trees. Even though it can be uncomfortable to delay a project by a couple of days let alone a couple of weeks, I learnt that you should never scrimp on scoping. It is the most crucial step to make sure that you are using your resources most effectively to deliver impactful work.
To help with this, I prototyped and tested a new project scoping and briefing process to make sure that we had filled in any gaps in our knowledge prior to starting a project. This template prompted discussions with relevant organisations, stakeholders and teams who were working on similar projects and helped to identify where our team was most needed. It also crucially highlighted when we should stop — the work could be better done by another team and we should focus our resources elsewhere.
Questions to ask during scoping in a crisis (along with typical scoping questions):
- Who are the key stakeholders and existing organisations working on similar projects?
- What work has already been done in this space and what is needed now?
- What outcomes do we wish to achieve? (short term, medium term, long term)
- Are we best placed to support with this and if so how? If not, can we re-focus the brief?
Work in the open: Maintaining this coordinated approach only worked well when we shared our work across relevant teams and organisations. For example, we created a document to collect and share user needs identified across the simultaneous projects we were working on within the care sector. It became a cross-team backlog of needs to respond to. This meant that research did not need to be repeated and needs could be prioritised systematically.
Make time to collaborate: It is always important to include subject matter experts when designing services, but in this case, as the landscape was constantly shifting, it became especially crucial to maintain regular contact with key stakeholders. Not only do these stakeholders have greater expertise, local knowledge and a good understanding of user needs, they are often best placed to implement services quickly.
For example, throughout our work to support care homes, we collaborated closely with organisations such as Skills for Care and the Local Government Association to understand how we could best support them and their users, and where we could adapt or extend their existing services and channels to launch new services more quickly.
2. Before doing: gather evidence
Working at such pace meant there was no time for a traditional ‘discovery, alpha, beta, live’ process, but we still needed to make sure that the services we created supported users to address the challenges that they were facing.
To overcome this, wherever possible we worked to adapt what already existed, rather than create something new. For this to be impactful we needed to understand what existing solutions would best respond to user needs. This was not always easy, with so many great digital services out there and so many challenges to address it was hard to prioritise.
What I learnt
‘Rapid discovery, pilot, scale’ instead of ‘discovery, alpha, beta, live’ in a crisis: A rapid discovery identified that care home residents and staff needed support to communicate remotely with GPs and relatives. Instead of developing a new technology we ran pilots with small numbers of users in care homes, testing different technologies in each site. This allowed us to continue learning about our users’ needs, iterate the service and quickly scale up what worked well based on the evidence we gathered.
3. Before doing: think about why
The pressure to deliver services at such speed meant that we were sometimes too focused on what we were delivering (the output). For example, the number of text messages that we needed to send or the number of tablets that we would deliver to care homes by a certain date. However, to make sure that our work was having the required impact, it was important to keep coming back to the outcomes that we were aiming to achieve — the ‘so what’.
What I learnt
Focus on outcomes not outputs: To help make sure that we kept our focus on the impact we needed to achieve and to ensure that we were delivering the right service to do so, I ran a theory of change workshop with my team. This exercise creates a step-by-step of what is required to deliver a desired impact, as well as the assumptions that you are making along the way. It also helps to highlight what to measure to show that you are on track to achieve this goal. Running this workshop helped us to understand how our project tied into other strands of work and encouraged us to think longer-term, ensuring that the service we launched was tied into future plans.
4. Before doing: make sure you have the right team
Working at pace to deliver successful outcomes means that you need to have the right team from the start. This means a full GDS DDaT team, including a Product Manager, User Researcher, Designer and a clear lead who is able to direct the project, making strategic decisions quickly based on learning.
I was lucky to work closely with three amazing User Researchers (Hayley, Sophie and Ben) and a great Delivery Manager who made sure that the projects stayed on track, the team was well resourced and that we worked well together through regular ‘team health checks’ such as retros (shout out to Hannah Abdule!).
I hope these musings are helpful, do share your thoughts!