More on this book
Kindle Notes & Highlights
A service helps someone to do or to achieve something, while delivering an outcome for the organization providing that service.
A few of the most common service types help people to start something; request or claim something; do something with permission; stop something;
move people, things or goods; learn something; become something; get or buy something; make an agreement about something; store something; or gain entry or access to something.
Whether ‘products’ is useful as a concept to describe what a service is made from varies between organizations, teams and sectors, so I don’t separate it out as its own category here.) Figure 4.
users knowing what to do; users choosing the right option for their situation; having the right data to make a decision that’s right first time; users being confident they’ve done the right thing or that the right thing is now happening; a decision being made and communicated, and users understanding it; a token of permission or the right payment being issued securely to the right person; being able to accurately tell who has permission to do something and who hasn’t.
This kind of insight is often the key to understanding patterns and bottlenecks in operations. When we don’t help users successfully do what they need to do, it shows up as additional work in our operations. When people aren’t confident, the contact centre will handle more contact.
understand what leads to ‘satisfaction’ for a particular type of service or segment of users, and then measure that instead.
The concept of customer satisfaction doesn’t always sit comfortably in public services. There are services we don’t want to have to use, like paying a parking penalty or appealing a court decision. Being shocked by a larger than expected tax bill will not feel satisfying. For this kind of service it can be more practical to assess people’s confidence instead: confidence as a user that I’m doing the right thing; confidence that the right thing is now happening.
One well-known problem is spending too much time optimizing processes that wouldn’t need to exist if we rethought how parts of a service worked or joined them up, or modelled the risks of something not happening at all.
In many organizations services aren’t seen as a whole, which makes it difficult to get performance data. But the very act of setting out what you’re aiming to improve puts you in a much stronger position to assess what’s needed, whether you have the numbers or not.
What helps move everyone forward together is real skill and clarity in communication and translation of complex issues so that everyone can properly understand the constraints, the reality of any trade-offs, and the implications. This entails a culture that respects different perspectives and nuance – with enough support from the top for a faster ‘good enough’ decision to be taken, protecting the time and space to take action if that decision proves to be wrong.
If there are already multiple existing strategies for design, customer experience, product, architecture, digital, data and technology, it can make things unclear or even confusing.
It’s much more effective to embed individuals from these enabling functions within the core service team(s) if the nature of the work in a service or depth team heavily involves one of these areas.
As we’ve seen during the pandemic, services with permanent service teams in place were in a much stronger position to handle the sudden change in priorities.
what we can, should – and therefore are – doing or achieving now; what’s likely to be next; and what’s possible in future, the priority of which we can determine later.
It’s wise to include a fourth category of ‘what we won’t be doing’ to reduce ambiguity.
Some professions work across the organization to seek to reduce duplication of capabilities and effort across services. But sometimes it just sounds like duplication until you understand the context.
Rather than talk about operating models, I now think about specifics such as the flow of work, what ‘success’ looks like, the activities needed, what else is needed, who and where. This might include the capabilities, the people and teams, the processes and ways of working, and the supporting infrastructure.
Being able to learn about and iterate services based on outside-in performance is, in the words of Matt Edgar (service transformation director in NHS England), ‘the last target operating model you’ll ever need’.
The biggest change is often encouraging leaders to care about what other leaders care about.
Service leadership is not the same as ‘customer journey’ or ‘customer experience’ leadership The idea of organizing leadership horizontally around customer journeys has existed for many years.1 But this often results in leadership only for the parts of services that are exposed to customers – the websites, apps, outgoing communications or customer accounts – and not for the supporting capabilities, technology and processes underneath, all of which are fundamental to how well a service works inside and out.
The UK government recognizes a professional role of ‘service owner’.2 This has helped establish the need for people to look across all the teams delivering work. There are now some brilliant individual service owners who work on genuine end-to-end services across the UK government as a result.
Governance is less about going to the right boards and more about supporting flow of (the right) work and decision making.
If a brand new team undertakes this work without situational context, there’s a greater risk of discovering ‘things we already know’ or of making recommendations that don’t ‘fit’ – or don’t challenge – what else is already underway. Blend new teams with those who understand the context and landscape, or make them available on the periphery to a ‘core’ team.
Some people would be concerned that a process like this would work against the principle of having empowered teams that make their own decisions. They would want to shape and scope work to remove or reduce any dependencies, so that teams aren’t ‘held up’. It is possible to isolate some kinds of work in this way, but it isn’t realistic for every type of work or team in a large organization or for a large service.
In some cases it pushes back the start of what looks like delivery, but only to avoid the problem of having a large team in place to then find out we’re not doing the right thing. It’s a way to protect investment and make sure the higher-performing pieces of work are prioritized.
Who has budget and who influences spend? Who sets strategy? Who works closely with those who influence spend or set strategy, but who may be more available to you? Who is currently initiating projects in ways that are contrary to this approach? Who else is already concerned about the shape of work (even if for different reasons)? Who tracks current portfolios and work that impacts services? Whose priorities and issues are related to the same underlying conditions that a greater focus on services would help address? Who struggles with underfunded and overworked operations and is already
...more
Make the case for ongoing funding of permanent teams and outcomes, with ways of working that mean the work can be (re)prioritized as needed.
we’ve made ongoing funding available for the teams that adopt iterative ways of working to improve the products and other parts of services they’ve developed continuously.
making the case that the traditional model of ‘change programme’ versus ‘BAU’ isn’t in line with contemporary standards for delivery of modern services that are supported by digital and technology capability. In fact, the whole organization would benefit from having a much closer relationship to the performance of services, products, technology and processes that operationalize its policies.
