We’ve said previously that the newly-established Central Digital and Data Office (CDDO) will provide professional leadership to the Digital, Data and Technology (DDaT) function, and collectively shape strategy and assure delivery for digital. In this blog we hope to illustrate how.
I wanted to continue to highlight how this service team is doing great things in UKEF (UK Export Finance) and with the support of GDS and CDDO have really been able to identify and start to build DDaT capability to help shape the organisation going forward. With a one-team approach of GDS, CDDO and UKEF people, we see the work and team as an exemplar of user-centred design and taking the organisation on the transformation journey.
—Chad Bond, CDDO
Picking up from where we left off
In our last blog post, we covered building capability as a fundamental cornerstone in enabling change within UK Export Finance’s Digital Trade Finance Service. This, along with a slowly shifting cultural change, allowed the team to focus on reaching their next milestone: Alpha assessment.
To cut to the chase: they met all points of the Service Standard. But how did they do that? What does it mean? What comes next? All things many service teams ask on the same journey. So let’s jump right in and demystify how the team accomplished it.
Preparing for an Alpha assessment
A service assessment is often seen as a daunting challenge, but it shouldn’t be. It’s a point in a journey like building a plane. The hard work itself has already been done over the course of Alpha. The assessment is the chance to showcase the journey you’ve been on to a team of peers. The real challenge here is collating all the evidence you’ve gathered and fitting it into a single peer review.
On this, flying is a great metaphor for the journey of software development, as you never stop learning. Demonstrating this journey was key. They interacted with user groups internally and at various banks to ensure they solved the problem for their users. This was done as the team searched for the best technological approach in an environment and culture unfamiliar with agile delivery. At the pinnacle of building that plane was the service assessment, which some of the internal team had never done before.
With a supplier well-versed in agile delivery and close collaboration with CDDO the team had sure footing. At the heart of this was the ambition to deliver a service steeped in user-centric design.
Crucially, the service needed to be accessible to all its users, both external and internal, while adhering to government service standards. The team also wanted a service that was easy to change and improve at pace.
Tackling established user needs in Alpha
In the Discovery phase, the team identified 279 user needs, some of which included:
- finding financial support
- processing an application
- applying for UKEF cover
It was from these user needs, and the core needs they surfaced to tackle during Alpha, that certain choices were explored. Key areas of focus in Alpha included topics such as:
- user research with business colleagues and banks, research plans going forward into beta
- interoperability with internal systems
- user profiles, personas and accessibility needs
One particular choice, and challenge, involved what shape the application and processing of cases would take. This highlighted the need for good evidence and why the Alpha phase was so important.
The team knew they wanted to ensure all their users, external and internal, were treated no differently when it came to ensuring their needs were met, which was a break from more traditional ways of thinking about internal users.
How to approach the application and processing of cases
The team had 2 approaches they wanted to explore. One was a popular off-the-shelf tool used by the department. The other was an extension of their current work, creating a fresh, simplified interface in node.js using the GOV.UK Design System.
The team did not want to recreate the user pains from the old backend service, an old workflow system built on a low-code platform that became a slow and cumbersome monolith that users despised. So, with CDDO support, the team embarked on an extended trial phase prototyping both options to find out which was the best fit for user needs.
Smart planning ensured that the team’s delivery supplier had a solutions architect product expert to dive deep into the suitability of the product. This expert also had the experience of working across government, meaning they could point out and explore what other departments had done and open-sourced. In fact, open source patterns from the Ministry of Justice (MoJ) were ultimately used.
The work was not easy, finding the right fit against user needs whilst adhering to technology principles; yet it prepared the team for challenges not only at assessment, but from their change boards, their colleagues and leadership.
Refining the evidence, and avoiding losing the plot
Afterwards, to help the team prepare, they did several dry runs before the assessment: one in the form of a show and tell ‘mock assessment’ with cross-government service standard assessors, and a sanity check to help further refine the evidence they’d be showing.
Show and tells were already part of the team’s ceremonies. It was as simple as inviting the right folks to one and turning it into a condensed mock review. This gave the team insight into what the assessment panel would look for, and how to present their evidence. It was also an opportunity to refine it into manageable, logical chunks reducing burden on the team and the panel.
For the final sanity check, they brought in their CDDO Consulting Technical Architect to do one final dry run. Like an editor with a red pen, it was a whirlwind run-through with a critical friend, leaving reams of slides on the cutting room floor (or at least, in the annex.)
Then, they were ready. And they nailed it, as the report confirms.
Navigating through Alpha into Beta
Thanks to many hours of preparation and continuous hard work from the Digital Trade Finance Service (DTFS) team, they passed their Alpha service assessment.
The team was in a great place. It had the external validation from CDDO. They were doing the right thing, working, building and thinking in a way that put users at the heart of their ambitions. This, combined with internal governance in place, meant they were good to move into Beta.
DTFS is the first project in UKEF that aligns to the Service Standard and the Technology Code of Practice. The team has taken the whole organisation on their journey, creating the right environment for effective delivery. This has laid the foundations to make it easier for service teams to be user-led, rather than tech-led in the future.
Taking a different approach that challenges the status quo is hard - the key is to make evidence-based decisions, create networks that can advise and support you, and keep focused on the personal resilience of those under constant challenge.
Using the recommendations from the Alpha assessment, the team were able to factor these into their backlog which helped build out the roadmap for beta.
In the third blog post, we’ll discuss further work on organisational change, designing with data and creating a sustainable future for the service. Subscribe to the blog to get notified about it.