Covid-19: we designed and built something in 7 days!

So, why does it normally take months?

This was a question I was asking myself. I’ve been involved in a myriad of projects throughout design and development and they take time…so what was different now?

The SHIELD system

The work involved creating a new system for the Cambridgeshire and Peterborough Covid-19 Coordination Hub. The users are 150 redeployed staff who are checking in with 15,000 shielded people across the county. The system was designed to track actions taken following the chat, for example flagging if someone needed support with shopping or collecting prescriptions.

Prior to using the new system, staff had been storing this information in Excel sheets. As you can imagine, tracking each person’s support needs was a pain and, while ok for the first few weeks, the team needed a sustainable solution.

We needed to build a system ASAP! …Avengers Assemble!

How did we tackle it?

Two of the days were spent in design: understanding the needs, drawing journeys and creating wireframes. The remaining days were spent tweaking designs, building the thing, iterating over the changing needs and giving it a good old test!

We were working in a space of enormous ambiguity, with needs often changing by the hour – it’s not ideal, but we like a challenge!

If we were able to design and build something in 7 days, why does it normally take months?

People were resourced solely to this project

This piece of work was prioritised and diaries were cleared in order to truly focus on the task at hand
We don’t normally have this luxury on other projects as we are often balancing our stakeholder’s competing demands as well as our own. It can often take weeks to get something booked in the diary because of other priorities

Minimum. Viable. Product

We focused on the absolute essentials that staff in the Hub needed to do their job
You might argue that this is how an agile project should “normally” be run, but we’ve all encountered those “nice to haves” and “it would be great if you could just…” requests and honoured them in the past
We weren’t starting from scratch at the start of 7 days because Kat, our Product Owner, knew what she needed and ruthlessly prioritised the work. As Kat lives and breathes this way of working, we didn’t need to spend time introducing agile and coaching the stakeholders

We reused a lot of components

This service has only existed for a month. It’s brand new and as such there was no “…we’ve always done it this way!” or mountains of legislation and paperwork to trawl through (which is a very, very different thing to encounter!)
However, the Hub’s needs were similar to other services we had worked with in the past and so we had lots of reusable components! For example the login page, user management function and search/filter pages were reused from other digital products

We operated in lots of ambiguity

The service is new and as such there was lots of ambiguity around what’s needed from the system in the wider context
Our first iteration concentrated purely on the biggest problems to solve and the needs we that wouldn’t change
This isn’t normally the case as we spend time researching with the service, understanding their needs and discovering the opportunities
We normally try to remove as much ambiguity as possible to ensure that we’re designing the right thing

We didn’t really look after ourselves…

We were working in a time of crisis and crisis isn’t “normal”
Working in such an intense way isn’t healthy and it’s not sustainable in the long run
We were so lucky to have a team that mucked in, with no ego involved and just got on with it. Yes, we spent a good few hours inputting data on Friday night. Rock and roll! 🙂

It has given me such a great opportunity to reflect on the “normal” way of working and the things that can be refined, removed or introduced going forwards.

I will take away from this the value of releasing something early to users, getting feedback and then iterating on it. It won’t be perfect and that’s fine, but it’s something to test and learn about.

I also feel that this piece of work can be used as an example of what can be achieved when other things don’t get in the way.

This is just a tiny example of some of the AMAZING work going on in local government; often having to respond to things at pace and without all of the information. We’ll get things right, we’ll get things wrong and as long as we keep learning, sharpening those tools and refining the way we work then it’s all incredibly valuable. For me, it really does show the power of clearing your calendar and focusing 100% on the problem to solve when the stakes are high.