In this three part series of articles, we’ve explored different ways you can make your service design project a success. We began by talking about shaming the organisation into action, and then choosing a line through inevitable obstacles. For this final instalment we’ll focus on legacy.

In many organisations when you hear the phrase legacy, it’s usually in relation to IT.

Legacy IT

Legacy IT are the ancient back end systems upon which the customer experience rests. Much of it can’t be configured and it’s often administered by gruff senior types who are all too aware of the risks of messing with the beast. This is without a doubt challenging terrain for the service designer. It’s a world of sunk cost and risky big investments. Tread with care. Wherever possible, don’t stir the beast. Instead this is workaround terrain. Befriend the gruff seniors. Find ways to wire the beast up to APIs, so that at the very least that bloatware interface remains hidden.

But there are two other areas of legacy that are less well known, but all the more punishing if not handled correctly.

Legacy lore

Lore is a form of ancient knowledge, passed down through generations. Our organisations, as tribal collectives, are no different. They sustain their own myths and legends, some of which can be highly destructive to your work. First there is the legacy lore of ‘what isn’t allowed’. The gates of ‘what isn’t allowed’ are often defended by the robust knights of compliance, risk and regulation. Though from experience I can vouch that applying the ‘five why’ rule often determines that much is folklore and not genuine rule. It’s your job to work out what the genuine ‘red lines’ are, which you definitely cannot cross. Then design from there.

Then there’s the legacy lore of ‘what hasn’t worked in the past’. Be very careful here. The road behind you is littered with good ideas that failed. The key is to understand why they didn’t succeed. Often it’s got nothing to do with the idea and everything to do with how it was implemented. It’s important to separate it out, as those old ideas are probably still good, and now you have a chance to implement them properly. The past is a treasure trove of ideas from which you should fish.

Legacy people

I was leading an intense service design project for a large financial service organisation. I’d spent the best part of eight weeks taking a team of 50 interdisciplinary people through an iterative process to redesign a key customer proposition. It was hard changing an established business proposition, but it was doubly hard changing the habits of a 300-plus year old business. So much of our work got stuck in endless committees, populated with people whose role was to exercise expertise and risk control, which generally meant expertise in what once worked and an aversion to change in general.

This was brought home to me one evening. I was on the train home, stabbing away at my laptop planning the next day’s governance review when. I looked up for a moment of respite and saw around me acres of people in suits comfortably reading the paper. And it struck me: I was facing another form of legacy. Legacy people.

Legacy people make up the rump of big organisations. Many are in comfortable roles at senior and mid levels. They spend a lot of time in meetings, where they’re expected to contribute – so they contribute. If you have 5 committees to get through, with 5 people on each – that’s 25 points of view you have to accept or resist. This is where customer-centred work suffers death from a thousand cuts.

And don’t get me wrong. Some of the most valuable people you’ll come across in a service design are from the past. I like to call these The Gandalfs. These are the people who have been around so long, they remember green screens and tea ladies. They know evyer nook and cranny of the organisation. They know the difference between truth and myth. Find these people and make them your friend.

So there you have it – three techniques to help your next service design project succeed. This three part series formed part of my presentation to the Service Design Network conference in London in 2016. I ended that by asking more people to ‘think like a service designer, and maneuver like a consultant’. Increasingly that’s the combination of skills required to deliver design in the organisations that need it.