On the first floor of the Imperial War Museum, William Orpen gazes out of his 1917 self-portrait, ‘Ready to Start’, into the Orpen Boardroom. On 16 July 2019, the First World War artist’s gaze fell upon a group of senior leaders gathered to discuss the delivery of public services in uncertain times.
Dominic Carter, VP and Head of Public Sector at Mastek, kicked off proceedings, welcoming those gathered to share their expertise. These included representatives from the Home Office, the Institute for Government, the Ministry of Defence, and the Departure for Digital, Culture, Media & Sport.
The discussion would centre around lessons learned from development of the EU Settlement Scheme (EUSS) service in the context of Brexit uncertainties.
The case study was jointly presented by members of the Home Office’s Digital, Data and Technology (DDaT) team: Natalie Jones, EU exit lead, and Ann Walker, Head of Operations.
The EU Settlement Scheme story
In October 2017, the Government announced its plan to create an EUSS service so that resident EU citizens could easily apply for settled status. Its announcement followed earlier proposals designed to safeguard, after Brexit, the 3.6 million resident EU citizens and their families.
Natalie described how, tasked with delivering this project from a standing start that Autumn, she began to put together a team, design, requirements and plan.
She didn’t even have an agreed budget to begin with. To get up and running quickly, she simply had to – as the saying goes – act first, then seek forgiveness after.
The project would require collaboration across multiple Government departments including Border Force, UK Visas and Immigration, the Department for Work & Pensions, HM Passport Office and HM Revenue & Customs.
Yet just 18 months later, at 7am on the morning of 30 March 2019, the EU Settlement Scheme went live.
What was involved in delivery?
A large-scale integration project
The EUSS service aimed to make applying for settled status smooth and seamless. Natalie highlighted the scale of the challenge this posed.
14 different technical services had to be integrated. Of these, 12 had to be created from scratch. In total, the project would involve over 230 people working in 16 dedicated teams across 7 different locations in 5 countries.
The service centres around an app that scans the applicant’s passport or national ID card, uses near-field communication (NFC) technology to read the document’s chip, and captures a photo of the applicant for identification. Behind the app, APIs and back-end web services connect to central databases to check data while supporting handoff to a web browser. This handoff enables completion of the application on a different device – e.g. on a desktop or laptop web browser, for ease.
Available in the Google Play store since launch, the app is coming to Apple iOS devices this Autumn.
Using a word cloud and quotes from user reviews, Natalie illustrated the positive feedback received from users of the service. Applicants note the speed of the application process, which takes, on average, just 8 minutes, with decisions provided within 1–4 days.
To date, almost 1 million applications have been processed by the service.
Agile principles: in the DDaT’s DNA
Natalie outlined how the Home Office’s DDaT team developed its own approach to Agile.
Some of its key aspects are:
- Fully automated testing
- Early integration
- Test and learn
- Prove things early
- A DevOps culture
- Hands-free deployment pipelines – with no manual steps
- Making sure it’s ‘done, done’ – i.e. actually deployed to production
At the same time, in delivering a complex project like this, both Natalie and Ann emphasised the importance of team culture.
Team culture and relationships
What was the key thing on this project? How to mobilise people. How to keep people motivated, while looking after them. To keep them focused, but not burnt out.
To do this, Natalie described how they paired shared objectives and a compelling vision with robust big-picture planning and careful dependency management. Within this, she then fostered a culture in which:
- Teams had to work with their nearest neighbour
- People talked to each other
- Desired behaviours were protected and encouraged
- Teams focused on finding solutions – together
Above all, Natalie underlined the importance of nurturing awareness across project teams that no one team could succeed without the others.
Preparing for the unknown
Ann then offered a closer look at how the DDaT team handled uncertainty.
She began by quoting American mathematics professor John Allen Paulos:
“Uncertainty is the only certainty there is, and knowing how to live with insecurity is the only security”
As Head of Operations, Ann noted that she simply has to deal with uncertainty. It’s just a fact of life.
But she argued that it’s actually better to embrace uncertainty and create a process that works within it. Then you can focus on applying your process.
She outlined four key principles that underpin this:
- Behaviours – in the face of potentially disruptive external inputs, work out how you can encourage behaviours such as adaptability, flexibility and dynamism and combat those such as rigidity, blockage and resistance.
- Be curious – look for single points of failure. What are your risk points? What can you change and adapt? What about your wider environment? Most important, don’t be a silo: find out how you can work with nearby teams.
- Take small steps – look for small wins and bank them. For example, on this project they checked for when certificates ran out and then brought forward their renewal to avoid the risk of certificate expiry being a problem.
- Learn mastery – for example, if a project requires cross-departmental working, work out how to do that, even if your department doesn’t usually work that way.
How can other teams apply this?
As the roundtable discussion began, Dominic asked Natalie and Ann what underpinned their approach.
Two key themes stood out.
- Work lean – if your planning groups are too big, you can easily end up generating too many options. Many of these can be impractical and there’s no point wasting time in exploring them. To avoid this, have small teams focused on working out what they can deliver and collaborating with other small teams doing the same. Don’t use scarce resources working up 5 options if only 2 of these ever have a chance of seeing the light of day.
- Be pragmatic – there are always common sense, uncontroversial things that you can do. Identify these by breaking projects down into small steps. Then, focus on delivering the no-brainer, generic capabilities you know you’ll need. These give you a foundation. And this approach helps you move forward with work even when there are major uncertainties with other project elements.
The discussion then turned to managing ministerial relationships.
Pragmatism and personal courage
One attendee wondered what pragmatism looked like when working with ministers? In particular, when there was agreement around the table of the importance of stating clearly when something can’t be delivered. Of saying ‘no’, even if this involves an act of personal courage. No-one is served by overpromising and underdelivering, whether that’s due to impossible development timescales, uncontrollable external factors or simply hitting up against the laws of physics.
But it’s also important not to show Eeyore-like gloom and pessimism in response to every request. Instead, far better to be flexible. Be in the habit of saying ‘yes’ when requests are deliverable. Then, when something isn’t, your ‘no’ will be more clearly heard.
In this context, Natalie emphasised how vital it is to build strong relationships with sponsors. This is good practice in general as it’s good for getting things done. But it is also incredibly helpful in ensuring you have allies to support you in the times when you do need to say ‘no’.
A thousand flowers blooming
As the roundtable discussion moved into its final stages, participants voted on which questions to end the discussion.
The top pick?
How to avoid having multiple instances of the same project being developed independently across departments – a thousand flowers blooming!
This was an area of concern for all participants, with agreement that there was no easy fix. Co-ordinating development across departments is a huge challenge.
Dominic noted that Mastek, as a supplier to multiple branches of the UK public sector, sometimes sees such duplicate requests. It always takes care to flag where functionality can be re-used.
One attendee then talked about having a central repository, a shop window of functionality that other departments could access. Another wondered who would be responsible for actively developing and supporting the things in such a repository.
A concern was that by uploading to somewhere central a team might lose control of something it’d developed and in future it wouldn’t be developed the way that team needed it to. This kind of worry would need to be allayed.
What if using shared services turned out to be more expensive? If you’ve developed something yourself, you wouldn’t want to make it a shared service and then be charged more to use it.
Despite these concerns, participants all agreed that the principle of not duplicating effort was vital.
Organisational change
What about the challenge of developing new ways of working and then pushing those out into the organisation?
One participant noted how the adoption of DevOps, say, could be a challenge for an ITIL-based organisational culture that expect things to be done in a certain way.
Take ITIL change freezes as an example.
On the EUSS project, Natalie needed to keep moving fast and making changes right up to launch. Implementing a 6-week change freeze, as had been done in the run up to the Olympics, would have been a disaster for hitting the EUSS project’s deadlines. Especially given deal/no-deal uncertainties persisting right up to (and beyond) the 30 March service launch date.
So, she negotiated an exemption for this project. (Another example of the importance of building strong relationships with key project sponsors to get stuff done.)
But having developed a new approach, as the DDaT team has done in the EUSS project, how can that be adopted more widely? How can departments avoid creating silos and keep learning and evolving?
Ann noted that the key first step is to demonstrate the success of a new approach in one project – as they have done. Then, you can much more easily persuade people that this new approach works and might be worth wider adoption.
As the roundtable drew to a close, Dominic thanked everyone for contributing their considerable expertise to the discussion and these conversations continued over the buffet.
If you would like to attend future Mastek events, make sure you’re receiving our event alerts. Sign up here.
