Vodafone — John Fordham

A usable layer over systems nobody could use

Fifteen interviews, one process map, and a portal that turned routine change requests into a near zero-touch process.

The challenge

Change management inside a large telecoms operator is unglamorous and consequential. Every planned piece of work on the network passes through it, and when it goes wrong customers experience it directly — as a change that slipped, an outage nobody warned them about, or a request that disappeared into a queue.

The team responsible had ended up administering the process rather than exercising judgement on it. Requests arrived through free-text fields with no validation, producing a steady volume of rework, inconsistent records and changes rescheduled on customers. Establishing the status of anything meant opening changes one at a time. Communication with customers was manual and tended to arrive at the wrong point in the process. Internal communication had collapsed into email volume in which the genuine issues got lost.

None of that is a technology problem in the first instance. It is a process that grew around its systems rather than being designed, and the question worth answering was which parts of it needed a person at all.

My role: Service design lead through the diagnosis; delivery lead through the build, running a team of eight.
Duration: About a year, sold and delivered.
Outcomes: A 40% reduction in people costs, with routine change types automated and the remaining effort focused on genuine customer issues.

Service design

Process automation

Delivery leadership

Legacy modernisation

The rest of this case study is protected

The detail below covers client context, method and results. It is available on request — drop me a line and I will send the password, or enter it if you already have one.

The instinctive answer to a process like this is to replace the system underneath it. That was not available. The estate had grown over years, carried a large number of integrations, and was load-bearing for operations that could not be paused — so anything that began with replacement would have spent its first year on migration and delivered nothing.

The second instinct is to automate what exists. That fails differently: automating a process whose inputs are unreliable simply produces bad outcomes faster. The data quality problem had to be solved at the point of entry before any automation could be trusted.

There was a human dimension too. A programme explicitly aimed at reducing headcount has to be run in a way that keeps the remaining team engaged, and the people who understood the process best were the people most exposed by improving it. How the research was conducted mattered as much as what it found.

Understand the process properly before automating any of it

Discovery · Interviews

Fifteen people across every role touching the process — change coordinators and analysts, a technical specialist, the process owner, offshore managers, an engineer, a data authority, a process analyst, and the IT landscape experts who understood the underlying estate.

Each conversation captured the same things: what that person actually does, which systems they use, the metrics that matter to them, and where the process hurts. Talking to the offshore teams and the engineers as well as the managers is what surfaced the pain that never reaches a process document.

Discovery · Process mapping

A service design mapping of the end-to-end change request journey, from raising a request through validation, approval, customer communication, scheduling, implementation and closure — with pain points attached to the specific step that produced them.

Mapping it as a journey rather than a flowchart made the clustering obvious: friction concentrated at the points where information entered the process and where its status had to be communicated.

The brown-paper change request journey map (blurred)

The as-is journey, drawn up from it (blurred)

Discovery · Opportunity definition

Pain points were worked into opportunities, each tied to the problem it solved and the outcome it would produce, rather than a wish list of features with no line back to evidence.

Design · The solution

The answer was a digital layer over the existing systems rather than a replacement: structured forms that validate what enters the process, contextual guidance at the point of entry, a dashboard and task management view, automated customer communications, a channel for engineers to close changes properly, and reporting that made the process visible for the first time.

Underneath it sat a simple principle — eliminate, simplify, automate. Each category of routine request was assessed for how much human involvement it genuinely needed, with the aim of moving the bulk of them to minimal or zero touch.

It was worked through as a fully clickable prototype rather than a written specification — several hundred linked screens covering the create flow and its validation, the coordinator and peer review views, the approval chain, and what happens when a change is rejected. Arguing about a process is far easier when there is something to click, and it meant the team building it inherited decisions that had already been tested rather than a document to interpret.

A change request in the prototype: where it has reached, who has approved it, what is left

The prototype: several hundred linked screens

Delivery · Just in time, on a Kanban board

The build ran as Kanban rather than fixed sprints, on Jira boards, with a daily standup that had the client in the room alongside the business analyst, the designer and the dev team. One conversation a day, with everyone who could unblock something present.

Design and requirements were produced just in time — far enough ahead of the build team to keep them fed, not so far ahead that the work went stale or had to be redone when something changed. A story reached the board with the screens it referred to and its acceptance criteria already written.

Nothing was built until the client’s build PM had been through the requirements and was satisfied the designs and criteria were robust enough to build from. That gate is a large part of why the delivery ran as smoothly as it did: the arguments happened over a prototype and a written story rather than over working software.

The backlog ran to 995 items across eighteen epics, seventy-one features and a hundred and seventy-eight stories, with the rest tasks, sub-tasks and defects. Each story carried its user story and its acceptance criteria in Given, When, Then form.

Stories and acceptance criteria from the delivery backlog

Delivery · Staged releases

Delivered in releases rather than as a single programme, with the highest-volume, lowest-judgement request types automated first so the benefit arrived early and paid for what followed. I led the eight-person team through both the sale and the delivery.