What to do when service transformation goes wrong

When companies set out to improve a service or redesign a product, the results can sometimes be underwhelming. Instead of delivering service transformation, the team recommends only minor efficiency tweaks. If this has been happening to you, there can be many underlying causes. I’ve identified a few common problems and what you can you do about them.

In this article #

• Introduction
• 1. Wrong skill sets on team
  • Working across silos
  • Measuring progress
• 2. Wrong measures of success
• 3. Support from the top

1. Wrong skill sets on team

Often a task force is assembled to audit and improve the service and the team is given a broad remit. But what skill sets have you assigned to the service transformation team?

If they lean towards project (or programme) management, business (or process) analysis and similar, then your team is probably optimised for reducing variance and increasing efficiency through repeatability. If you’re looking for a radical redesign, a team with these skills alone will struggle to deliver the desired result.

To generalise somewhat, Six Sigma and similar approaches are about identifying incremental improvements on the assumption that the underlying service is stable — like a car assembly line. But creating a more efficient assembly process won’t help if the resulting car is still a clunker that nobody wants to buy.

Another perspective is Conway’s law, which states that a software product’s architecture will often mirror your company’s organisational structure. Users will have no insight (or interest) in the internal workings of your company – they’re irrelevant to their needs. So by definition, a product designed in this way will rarely be suited to the needs of your users.

A service redesign requires a more holistic re-evaluation of the problem you think you’re solving (has it evolved since you last looked at it?), and how well your current approach is solving that problem. Finding this out means not only examining your existing processes, but looking outside your organisation to rediscover what problem you’re solving, for which people, in which context.

Working across silos

With this clearer understanding of user needs, re-engineering the service will probably require lots of changes in concert across different departments. These changes will cause a massive initial drop in efficiency until the process stabilises again, and you’ve collectively had the chance to go through the process enough times to learn how to start optimising it again.

This means you’re going to need a cross-functional team optimised for rapid and frequent prototyping, experimentation and learning (namely: service designer, user researcher, product manager, delivery manager, business analyst, possibly a tech lead later on). To cut across the inevitable silos in your organisation, you will probably also need expert collaborators and senior buy-in from other departments to help you identify, design and roll out changes.

Measuring progress

Measure the service transformation team’s progress in terms of tangible outcomes: by the rate at which they’re surfacing new and valuable insights into user needs; by the experiments and prototypes they deliver, test and learn from; and by the actual changes they put in place for users and measurements of whether those changes solved the original user problems. Make it clear to all that this is how their progress will be measured.

Get them to work in the open, sharing what they’ve learned and delivered each week to an open audience, and posting up results where everyone can’t avoid seeing it.

2. Wrong measures of success

The service transformation team only identified incremental tweaks to the efficiency of the service. This suggests that they may have been focusing mostly on outcomes that served the needs of the business, such as cost and waste reduction.

If instead the team was measuring success by how well the service helped users to complete tasks and achieve their goals, then this might have unlocked more fundamental improvements.

There are plenty of examples of service transformation in government where the status quo is only challenged once teams start to consider the service from the user’s perspective.

The entry point to many government services is a form to gather information. But users don’t want to have to fill out a paper or online form, and in many cases the user shouldn’t have to supply the information requested — it’s a crutch to mask an inability to share information across back-office systems operated by different departments. I’m certain that many companies also suffer from similar problems.

What would need to fundamentally change in your systems, and how would different departments have to start collaborating to make the service simpler, faster and easier for users?

For future service redesigns, consider setting the goals and the success measures in terms of providing a simpler, more effective service to the user, regardless of the internal process changes that it would necessitate.

3. Support from the top

The service transformation team may have been reluctant to propose radical changes because they may have felt they lacked permission — or even felt unsafe to do so. This can point to a prevailing cultural issue, where departure from the status quo is punished, and conformity and efficiency are rewarded. In extreme cases, this can also point to a lack of psychological safety, where team members fear the recriminations that result from even suggesting a change to the status quo.

Ensure the organisation’s leadership team explicitly gives the service transformation team permission not to follow established project management process and reporting. There needs to be explicit recognition that the service redesign team is tackling a problem that necessitates a different approach that’s better suited to the task (lots of change, anticipated initial loss in efficiency until it beds in).

This in turn means the leadership team will also need to manage the inevitable grumbling from the Project Management Office or equivalent. These are organisational structures optimised for minimising change, not encouraging it.

The leadership team needs to actively (and visibly) support the service transformation team, even if their findings are uncomfortable. Change means actually doing things differently, not just rebranding what was happening before. This in turn will temporarily move people out of their respective comfort zones, until the “new way” becomes just business as usual.

This can be the most difficult piece of all. For inspiration, watch Tom Loosemore share some hard-earned wisdom on service transformation in this talk for Mind The Product.

If you’d like to chat about any of the points in this article, get in touch — I coach people at all levels from those new to product management, to experienced practitioners, to founders and CEOs / CTOs / CPOs.