Designing for complexity: Delivery Framework for the Government

As part of our work with the Medicines and Healthcare products Regulatory Agency (MHRA), Red Badger was asked to develop a Delivery Framework.

Our recommendation was a bespoke Agile Delivery Framework which recommends a Lean-Agile approach to digital and technology delivery, in line with the Technology Code of Practice set by gov.uk.

It incorporates multi-disciplined cross-functional teams, design thinking, data-driven decision making, continuous integration/deployment and continuous improvement in the development of the Products and Services being delivered by the TD³ within MHRA.  

Due to the nature of their work, the delivery model for the Agency is quite complex, the size of the projects change as well as the need for their governance. We’ll be talking about our approach to designing an adaptive and flexible solution to work in a complex environment.

Design approach

Early on in our process, when we were working on the strategy and the approach for the framework, we asked ourselves what the biggest failure would be. Almost unanimously, the answer was for the framework to be an irrelevant big document that sits in a folder, unused.

We employed a few approaches to avoid that failed outcome and to be able to create something that would be easily accessible, easy to use and useful for teams: 

• User centered approach: Mapped the process with the teams, user interviews to gather qualitative feedback
• Co-designing with MHRA: Established a working group to enable regular touchpoint with MHRA and design with a team 
• Share early and often: Regular sessions with stakeholders to show in progress work in order to get and incorporate feedback throughout
• Experimentation: Plan for testing the framework on upcoming opportunities and building feedback loops to enable iteration
• Data-driven: Established a measurement framework enabling  MHRA to track progress, pull out meaningful insights and continuously improve processes based on data

Instead of making a recommendation out of context, we treated the framework like a product, one that is based on user needs, can be measured and iterated on. Our recommendation was based on the guidelines highlighted in NHSx and GDS but customised for MHRA and how it operates as an Agency.

The Delivery Framework covers:

• The project/product life cycle of digital, data and technology projects
• The guiding steps and principles necessary to facilitate successful delivery
• The team roles and activities for each phase, with detail on why and how to run these activities 
• How to create a measurement framework for digital, data and technology projects/products
• How to govern digital, data and technology projects/products in line with the NHSx spend controls and Government Services manual 

Designing the Agile Delivery Framework was a collaborative effort, where we’ve worked with MHRA and NHSx ensuring our recommendation was aligned with existing frameworks and fit with the landscape in which the organisation operates in.

We’ve also established a working group, formed of a cross-functional team from across the MHRA to take the framework forward by implementing Proof of Concepts, and measuring the progress.

The recommended framework is based on qualitative and quantitative research conducted with MHRA employees, both Transformation Division and the business.

As part of  the discovery, we delivered a product from discovery to build which allowed the team to fully empathise with the process. Mapping the end to end experience of getting a product live allowed us to visualise the complexity of all the steps required, but also enabled us to build a shared understanding of what was happening across all the teams in the Transformation Division. 

At the end of discovery, we landed with 6 problem statements to inform the design and development of the framework.

1. Accountability: Roles, responsibilities and accountability are not clearly defined or understood
2. Process: Delivery process lacks standards and consistency and its complexity causes low levels of end-to-end understanding
3. Collaboration: Lack of collaboration between functions impedes transparency, trust, knowledge sharing and oversight of key information
4. Decision making: Hierarchical decision-making and lack of visibility of decisions stops people from feeling empowered
5. Communications: Business customers feel communications from TD³ are inconsistent and not timely
6. Capability: TD³ require additional skill sets and capabilities to deliver the transformation that the teams desire

Introducing the framework vortex

A framework that reaches across many teams, involves interactions with both the business stakeholders and the public is inevitably going to be a complex process.

We wanted the framework structure to be simple without being simplistic, which led us to exploring different models to help conceptualise the framework and best visualise it. 

We've used the vortex as an analogy to introduce the framework for a few reasons: 

1. The vortex represents various levels in an organisation that the framework considers and visualises that all levels are interlinked. 
2. The organisation is connected from the top to the bottom. Change can start at the top, from an organisational level as well as at the bottom, from a team or individual level. 
3. The vortex also demonstrates the difference in the speed of change and shows iteration cycles each would go through. For example, the speed of change, decision making and the iteration cycle could be much quicker at the team level, compared to the speed of change at the organisation level. 

The vortex informed the structure of the framework recommendation, allowing us to focus on team level activities in more detail, guiding principles and concepts for the division as a whole and aligning with other frameworks and governance standards at the organisation level. 

Guided by principles, not rules

It became clear that the framework couldn’t be all-encompassing to the vast variety of scenarios that TD³ face when delivering projects for the Agency. The duration, scope and type of projects change, requiring any framework for delivery to be flexible enough to guide each project through its different requirements. 

Instead of prescribing a strict set of guidelines, our approach to handling the variety in delivery was to lead by principles and guidelines. One of the first things we did before fleshing out the details of the framework was to define the guiding principles which would inform both the recommendation itself but also the implementation of it across TD³. 

The aim of the  principles is to guide delivery teams within TD³ using the Delivery Framework.  

1. Start with and solve for the user
2. Make it accessible and inclusive
3. Enable cross-functional accountability
4. Iterate and improve continuously
5. Apply appropriate and proportional governance
6. Decide with data
7. Share performance data openly
8. Ensure data connectivity 
9. Make it secure by design
10. Protect user and Agency privacy
11. Use open and cloud-first (use open standards)
12. Choose the right tools for the job
13. Encourage a culture of learning and building internal capability
14. Make it interoperable

We formed these principles by reviewing existing principles across different government sites, including GOV.UK, GDS, and also NHSx and by distilling them to make them relevant for MHRA. They are complementary to the Agency values and TD³ behaviours as well as existing TD³ Design and Technology Principles.

Feedback loops to allow iteration

A measurement framework was essential in enabling the framework to be implemented and iterated on with data guiding the way.

Collaborating with the Data team at MHRA we built a metrics dashboard to measure progress against the different components we’re targeting to improve.

These include Portfolio, Delivery  and People metrics. The three areas work to balance each other while maintaining a tension to allow for improvement without gaming the system.

For instance, improving the Delivery metrics, such as speed of delivery won’t be possible without considering the impact of the speed to the quality of the outcome, as well as to the team dynamics and the overall customer experience. 

The framework in practice

Just like anything in the current climate, we expect the framework and the elements of it to change and evolve with use, over time.

The recommended feedback loops, such as team retrospectives, customer satisfaction surveys as well as the metrics will enable teams to modify the framework to best suit their needs.

Parts of it that don’t resonate should be removed or modified and parts that need more detail or constraint should be defined more.

From the start, the intention of the framework has been for it to be adaptive, providing teams with a useful guide that can be adjusted within the context of their individual projects. 

The iterative nature of the framework required teams to take ownership of their process, and constantly review, either through the measurement metrics or through internal feedback loops and amend their approach.

Teams are empowered to amend these activities in line with the guiding principles to achieve the desired outcomes, if doing so is pragmatic, reduces waste and still adheres to other guidelines the Agency is committed to follow. 

Adjust course with experimentation

The next step is to put the framework into practice and refine it using the data generated through its use. The recommendation has some fundamental shifts on the operating model of TD³, so it’s important to put it into practice with an experimentation mindset and be open to certain elements of it needing refinement. 

The implementation can be through small initiatives that test a part of the framework or projects that implement the framework from conception to launch.

In either case, teams are using the measurement framework to measure the impact of the changes and share lessons learned for the next rounds of the experiments.  

Treating organisational change like an iterative product has helped us design for the complexity of the process.

By establishing the user needs from the start, aligning to existing frameworks and building feedback loops have set up MHRA with a user-centred starting point and a direction to keep improving to ensure the framework is relevant and the best to fit the context of the teams. 

References

Service Standard - Service Manual - GOV.UK
Technology Code of Practice - GOV.UK
Agile delivery - Service Manual - GOV.UK
Principles - Design principles
Government Design Principles - GOV.UK
Home - NHSX