Service Development Mapping: Two steps to identify the best approach
In this article, Joseph Badman and I, share the mapping tool we use to help leaders and teams agree on where their service should be placed on the Service Development Matrix (see previous article).
Before we get into the nuts and bolts, it’s worth explaining why the activity is worth doing in the first place.
Why selecting the correct approach is essential
Let’s imagine that Cheeseborough County Council has noticed that the needs of residents in a particularly deprived part of the borough are escalating.
People with the earliest signs of need are being referred between many services in the community and are starting to fall between the cracks in the system.
The Council wants to develop a community support hub. They believe that by providing practical and holistic support, they’ll be able to prevent needs from escalating.
Although there are examples of this kind of service elsewhere in the country, this is the first hub of its kind in Cheeseborough, and at the moment, the specific needs and challenges of residents are unclear.
As several authors, including Dave Snowden and Mary Boone have pointed out, we are in the domain of “unknown unknowns”.
We don’t fully understand the problem or how best to solve it. The project's challenge is complex.
The needs of residents are also likely to be complex, and the service will need to be sufficiently adaptive to absorb this complexity.
In our language, we’re dealing with a relational service design challenge. In this context, a more iterative project approach will be helpful. By conducting ‘safe-to-fail experiments’, the project team will learn what works in practice.
How might the service advertise itself in a way that makes citizens feel safe to ask for help?
How might the initial conversation be structured to establish trust?
How might the physical space be arranged to enable people to share personal information?
How might people from different teams draw on one another's support to help someone with multiple needs?
With some testing, answers to these questions, and many others, will emerge.
Imagine for a second that the team had taken a more linear approach. Instead of testing and learning, they pull together a team of experts, design the hub upfront and launch it with a bang.
The solution would have been full of assumptions. Many of these would have come undone as soon as they came into contact with real people. Most likely, things would have gone wonky in a hurry, and the team would have either had to pretend things were working or make changes under lots of scrutiny and pressure.
Getting the project right approach is important. But it doesn’t guarantee success.
Unlike the majority of transactional services (think registering a child for a new school or renewing your passport), staff in our community hub can’t possibly know exactly what residents will need and when.
Depending on the myriad variables at play in the person’s life, the type of service they require could change from day to day. So, too, could their willingness to talk about their needs.
If the project team fails to recognise that, at its core, the service is a relational one, many things are likely to go awry.
Transactional services should be optimised. This doesn’t mean they can’t be human, but the focus should be on getting the customer from A to B quickly with as little friction as possible.
However, relational services need a completely different design philosophy. Helpers need the time and space to build relationships and trust with the people they are there to help. They need the autonomy to exercise their judgement in response to unpredictable and unstable needs.
In this example, the project team should worry less about optimising every step in every process and more about creating the conditions needed for those closest to the work to self-organise, collaborate with their peers and be helpful.
Were our fictional team to design this service as if it were transactional, they might never get to the route cause of citizens’ issues. They might further ingrain the fragmentation between services that already exist.
Service Development Matrix - with mapped service initiatives © Basis Ltd. 2024
Two-step mapping to identify the best approach
Much to his chagrin, the Agile community has adopted and adapted Ralph Stacey’s Matrix as a means of diagnosing the complexity of a project and selecting the appropriate delivery approach, including if done in a more waterfall (a linear, step-by-step approach) or agile manner (an iterative approach).
It's worth noting that, over time, Ralph stopped using his own matrix. As we understand it, he came to believe that most activities were complex to a degree. He was also concerned that his model could be interpreted in whichever way sustained the current ways of thinking about how challenges (or change in our case) should be approached.
The model has its problems. It’s a static, simplified version of reality. However, in our experience, we’ve found it to be useful for a few reasons.
At the beginning of any new project, there is often disagreement about the complexity of the challenge. Do we know exactly what’s required? Do we know exactly how to do it? The model is a helpful tool for getting people on the same page.
Like internal service design and transformation teams, we’re often helping leaders and their teams figure out how best to ‘do change’ or run a project.
Although there has been an increase in awareness around more iterative, agile ways of working in the public sector over the last 10 years, for the most part, people leading and working in front-line services are not intimately familiar with the agile/waterfall divide.
The change approach we choose has a material impact on practical things, such as which meetings are needed to help the team make progress and how that progress will be reported to stakeholders.
The model is a helpful segway into these important discussions.
Step 1: Diagnosing the complexity of the challenge faced by the project
The first step is to map your initiatives against a version of Stacey’s matrix. We’ve adapted the language over time for our context in public services and are currently using the version below.
To do this exercise, we’ll usually hold a workshop with the person responsible for the work and various stakeholders, including people likely to be involved in the work. While you can do this in different ways (and we do!), our sessions usually follow the main flow below. We recognise that the output from the workshop will not be perfect, but it will be a good start that can be revisited later.
Example exercise
What is happening now, and why do we want to change anything? For instance, begin with a User Experience Fishbowl. We’ll usually interview a few stakeholders responsible for the work in front of the wider team. This helps everyone to understand why the work is important and and gain other people’s perspectives of the system in a safe way. Citizen journeys and other narratives collected from the residents using or needing the services can be used to aid the conversations. It also allows the group to clarify any unanswered questions.
What is the direction - the north star. Once everyone is on the same page, we’ll work as a group to agree on a purpose or a ‘north star’ for the work. Why are we doing this work? What change do we expect to see for citizens? If any research has been done with citizens, how might they frame the challenge? What is the work explicitly not trying to address? The point is not the detail a blueprint of the future, but have a common sense of the direction.
Map the initiative along the x-axis. With the goal written up on a big sticky note, we’ll stand in front of a large copy of the matrix on the wall and ask people to plot their sticky
Move to the y-axis. We’ll then repeat the process for the y-axis.
Check the consensus and discuss any outlier opinions. Understand and agree position. But not until the outliers are discussed. If anyone in the group has a completely different view of the situation, we’ll ask them to explain why. Based on this information, people can redo their sticky, and the consensus might shift.
At the end of the exercise, we’ll have a better understanding of the complexity of the challenge faced by the project.
This process doesn’t need to be perfect. It just needs to be good enough.
-
Although no project sits entirely within one of these boundaries (some elements might be simple, and others might be complex), this gives us a starting point to discuss which kind of project approach is likely to be most helpful.
For our purposes, most of our discussions centre on whether or not a project is complicated or complex. For simplicity’s sake, we’ll focus on these two domains.
When a challenge is complicated, we deal with “known unknowns”. There are often several correct answers, and it’s helpful to rely on experts to identify which of these answers are most appropriate for the context. A linear approach with a clear plan and milestones is a helpful tool for tracking and communicating progress.
When the challenge is complex, we’re in the realm of “unknown unknowns”. As mentioned previously, a more agile project approach that allows for experimentation will be helpful. The learning these experiments generate makes it possible to identify which solutions are most likely to be effective.
Step 2: Diagnosing the complexity of the citizens' needs
Having done this, the next step is to map the problems citizens are facing. Are they purely transactional challenges? Or are they multiple, complex and varying?
On the matrix below, we repeat steps 3-5, as outlined above.
It’s essential to do this exercise with people who are closest to the problem. If we’re working on a front-line challenge, people who work on the front-line need to participate in these discussions. Where possible, we also try to validate these categorisations with experts by experience.
The results of these two mapping exercises can then be transposed onto the following 2 x 2 matrix; the Service Development Matrix that we introduced in the previous article.
Service Development Matrix Basis Ltd. 2024
The model, like any model, is a simplification of reality. And just like the complexity frameworks we’ve discussed, most projects will bleed across the boundaries. Many relational services will contain transactional components. Many projects may contain parts that are simple and just need to be done by someone.
However, we think it’s a useful tool to help leaders and teams begin a conversation about the kind of project they are dealing with, which approach will likely be most helpful and, crucially, why.
The results of the exercise have significant ramifications for:
the governance arrangements of the project and meeting cadence;
the kind of leadership needed to enable the team to make quick progress;
who needs to be involved in the project, the make-up of the team and the skillsets required; and
the principles the project and service teams adhere to in the design and delivery of the service.
So what?
In our article ‘What does it take to grow Relational Services?’, we explore a specific example, namely in Children's Services, and introduce a third dimension of agile.
Written by Dennis Vergne and Joseph Badman
© Basis Ltd. 2024