Executives who bring in agile service design teams don’t always know what’s needed to support these teams to deliver outcomes at scale.

It’s not realistic to expect to change the culture of an organisation while requiring new teams to work within existing IT portfolio management, target architecture or operating models and red-amber-green project control.

In this post I’ll explain tactics for executives to help tackle key problems with organisational structures and practices that get in the way of creating good products and services. Try these and there is more chance you’ll avoid well intentioned but ultimately wasted effort.

Here are six things you can work on this week:

• the target operating model is continuous improvement of services
• govern with real life performance data
• the goal is outcomes and performance, not revenue and cost
• portfolio management is service improvement, at scale
• set goals that everyone works on together
• change the language to change the organisation

Someone brand new to your domain should be able to read a list of the services your organisation provides and fully understand what people outside your organisation are trying to do.

People inside the organisation should be able to see how well these services perform, which teams provide which parts, as well as how they’re being improved. This is not another list of all the internal activity or a diagram of your IT systems. It means gathering evidence on service performance through user research and cost analysis. Then providing the means and designing the work to radically improve them over time.

Traditional target operating models often remain fiction when so much can change or be discovered before you get there. Improving how you operate persistent services for your customers while occasionally adding new ones, is a target that’s more closely linked to useful outcomes. See also ‘the last target operating model you’ll ever need’ by Matt Edgar.

Rather than review red-amber-green (RAG) project statuses, executives should challenge why it is they don’t have access to dashboards of real life service performance. You need this to be able to challenge investment decisions.

You don’t necessarily need a new design authority to drive digital transformation. It can be more revealing to bring in digital practitioner skills to the main boards. You need people in the room representing specialisms like product development and management, modern technology, design and research. This will bring appropriate and different intervention. And from now on, only make key hires if they’re used to working in digital ways.

Some key governance questions for boards should be:

• Why don’t you have a plain english list of services your organisation provides for customers?
• Why can’t you tell how much it costs to run these services?
• Why are you presented with internal views of projects without knowing whether they tackle the biggest customer problems and opportunities?
• How does work in your current portfolio relate to reducing costs or increasing revenue?
• Which teams work on which cross cutting services? Do they know the pain points that matter most, that result in greatest cost?
• Are teams talking about outcomes or only delivery of predetermined solutions?

A good start is to have someone prototype an actual service dashboard — something indicating success and error rates, time and effort, even if through best guesses and proxies for now. Present it at the next board to provoke discussion. Is any current work set up to be able to improve performance in these ways or is it merely to ‘control’ delivery? Ask the PMO, operations and finance leads to pair up with people with experience of digital ways of working. Make it their joint responsibility to adjust practice to support service improvement and ask them to present this at a key conference or internal leadership session.

Money is a lag indicator. It’s not instructive to brief teams to go at cost or revenue directly. Teams need to be able to tackle changes in behaviour, rather than revenue or cost. Make a template for all current and future business cases that identify clearer outcomes to achieve. For example, in a coronavirus pandemic, improve the rate at which contact tracers can track down contacts. Or reduce the proportion of transactions that aren’t solved first time. The goal is to figure out what’s really needed and how to deliver it sustainably or profitably, by the best means possible.

One public organisation I worked with successfully reduced the cost of transportation in a service by outsourcing to the lowest bidder, only to find their own costs increase because more cases needed intervention. John Seddon’s work with service organisations challenges this traditional cost-cutting practice. Successful organisations study actual demand in a service, focusing on what’s valuable for customers and measuring performance in terms of what works for the people outside your organisation. Efficiency follows.

What’s needed is differently skilled and knowledgeable people working together, contentedly, to improve services for people outside the organisation. To encourage this you need the often missing view of what your organisation does, as well as what it fails to do, for people outside it. This has to be presented in a way that allows everyone to figure out how to do it better from within.

Rather than pick an architecture model or management practice to follow, you need a diagram of what people outside your organisation are actually trying to get done. Find out what goes wrong with this and what good outcomes look like for your customer and your organisation. Don’t worry about how it currently works.

Identify one big, important service and set a hefty ambition for radical improvement. Say, ‘reduce the time it takes us to deliver X outcome for users from 10 days to 10 minutes’. Say, open a bank account or transfer ownership of a freehold. But don’t predetermine how to do it.

Invite the relevant, experienced teams to figure out what it means for each of their areas and support them to work together to achieve it over time. This includes operations, fraud, back office, front line, technology, design, security. Improve and consolidate ideas with input from experts with internet era skills and knowledge — assuming that’s not yet default in all teams. Iterate ideas as you learn more over time and use this picture as the overall direction to design the individual work. This means starting, stopping, and changing existing projects. Set up regular forums to get all teams continuing to work together to improve and redesign it by default.

Write blog posts of improvements along the way, authored by colleagues across teams who don’t normally do this. Champion the collective effort to improve services, not just the ‘digital’ effort.

If yours is a service organisation, your portfolios are mostly service improvement projects. Large organisations typically have hundreds of projects at any one time, rightly or wrongly. Pull out the ones that directly relate to services that people outside your organisation use, including any common products and platforms.

Map each of these against steps in your end to end services to see where the work fits and where there are gaps. Compare this with what are the biggest pain points for customers, as well as the biggest areas of cost for your organisation and general service performance. Have teams write down how their work aims to improve the service it’s a part of. Stop the less obviously impactful projects and initiate new work to address the gaps.

Work to remove the barriers that stop your organisation providing great services. For example:

• rather than updates on commitment to a shipping date, ask teams to show what they’ve done to increase the chance their work will improve an overall service and achieve better outcomes
• instead of budgets that lock teams in to predefined features, invest in ongoing teams focused on agreed outcomes, with regular reviews over spend and progress
• give experienced people the oversight and data that reveals demand across a whole service. Empower them to shape the work to improve it, not merely a centralised committee or IT department in isolation

Reporting, budgets and governance are hard for an individual practitioner or team to change, but will thwart the efforts of all teams if you don’t address them.

Set the direction by developing new, shared language for services and their constituent parts. This establishes relationships and hierarchy, so that all work is given an outside-in context. Here’s an example of words to describe services from the UK government’s Home Office.

Label and describe projects by what they intend to improve and who for, in plain english. Talk about work internally and externally in terms of how it improves overall services, outcomes and performance. Show examples of what’s actually happening in your organisation. Communicate about the new reality often, to embed specific behaviour among teams.

Much of the work to improve services is communication. But few organisations support it to work well between roles and teams and across tasks. This is particularly important for those all working on the same service. Hire a specialist who can specifically help communicate and facilitate collaboration on services across your organisation.

Hopefully I’ve shown, or at least reminded you of, a few practical ways you can support all teams working on products and services. Don’t leave incoming agile service design teams to cope alone. Trying these will help you build better service organisations over time and avoid investing in effort that’s prevented from having real impact.

This post was first published on Kate’s own blog.