Building a Transformation Function From Zero

Sometimes none of that exists.

There may already be plenty of improvement happening across the business, but it tends to happen locally. Managers fix the problems they can see, employees create workarounds to keep things moving, customer issues are dealt with as they arise and projects are launched when something becomes important enough to demand attention.

The organisation may already know that things could work better. What it often lacks is a way of bringing all of that information together, understanding what matters most and making sure something happens as a result.

That is where I think a transformation function has to start.

Before building frameworks, dashboards or improvement programmes, I would spend time understanding what is actually happening across the business, and I would start with the people closest to the work.

One of my favourite questions when looking at a service is simply: what isn't working?

It sounds basic, but it can open up some incredibly useful conversations.

The people delivering the service every day usually know where the difficulties are. They know which processes take far longer than they should, where customers repeatedly get stuck, which transitions regularly fail and which systems create more work than they remove.

They also know about the workarounds that may never appear in a process document or management report.

If five people have created their own way around the same process, I want to understand why. There is usually something underneath that behaviour worth looking at.

This is also where transformation can begin to have an impact on the employee experience.

People can spend years working around the same frustrations. They mention them to colleagues, raise them in meetings or find their own way of managing them because they assume nothing is going to change.

Giving employees a genuine route to raise those issues matters.

But asking for feedback is only the beginning. If somebody takes the time to explain what is making their job harder, they need to know that somebody has listened, considered the issue and will tell them what happens next.

That does not mean every suggestion will become a project. Sometimes there will be good reasons why something cannot be changed immediately. People can understand that when there is transparency around the decision.

What makes the difference is knowing their experience has been taken seriously.

When employees start to see issues they have raised being investigated and improved, they begin to understand that their knowledge of the service has value. They feel more involved in how the organisation develops, and they are far more likely to keep sharing what they see.

That creates a much stronger improvement culture.

One of the first challenges when there is no transformation function is that information tends to be scattered across the organisation.

Operations knows about one set of issues. Customer-facing teams know about another. Managers may be dealing with recurring escalations. Account teams hear concerns directly from customers, while frontline employees are quietly working around inefficient processes.

Individually, each team may already be doing something about the problems it can see.

The wider picture becomes much clearer when those issues are brought together.

A recurring customer complaint may connect with a process problem another team has already identified. Increased contact volumes may link back to unclear customer communication. An employee workaround may explain why a particular service is taking much longer to deliver than expected.

This is one of the areas where a transformation function can add real value because somebody starts to develop a bird's-eye view of what is happening across the service.

Instead of looking at each issue in isolation, you begin to see patterns.

And those patterns can tell you where the biggest opportunities are.

I think this part is particularly important.

There is nothing more discouraging than being asked for ideas or feedback and then never hearing about them again.

If employees are going to contribute to transformation, communication needs to work both ways.

If somebody raises a problem that becomes an improvement project, tell them. If their insight helped identify the root cause, acknowledge it. If the change is implemented, show them what happened and what difference it made.

Where possible, involve the people who raised the issue in designing the solution.

They already understand the problem because they live with it.

They can often tell you whether a proposed solution will work in reality, spot consequences that may not be obvious from a process map and help test whether the improvement has actually made their job easier.

That involvement creates something valuable beyond the individual improvement.

Employees begin to feel that change is happening with them rather than around them.

They can see that their experience matters to the organisation and that they have a role in making things better.

For me, that is a very important part of transformation. A function should not just improve processes and customer journeys. It should give people across the business a way to be seen, heard and valued for the knowledge they bring.

Once people realise there is somewhere to bring improvement ideas, you will probably find there is no shortage of them.

There will nearly always be more things that could be improved than there is capacity to improve them, which is why prioritisation matters.

I would want to understand the impact of each issue before deciding where to focus. How many customers are affected? How frequently does the problem happen? How much employee time is being consumed? Is there a financial impact? Does it create complaints or escalations? Could it affect customer retention?

A small frustration that happens hundreds of times every month may have a much greater impact than a larger problem that happens once a year.

Employee effort should be considered as part of that impact too.

If a process takes ten unnecessary minutes and dozens of employees complete it several times a week, there is a meaningful operational cost sitting inside something that may initially sound quite minor.

There is also frustration attached to that wasted effort.

When transformation starts removing those barriers, employees feel the improvement themselves. Something that used to make their working day unnecessarily difficult suddenly becomes easier.

That is often one of the quickest ways for people to understand the value of transformation.

Once an issue has been identified, there is always a temptation to move quickly into solution mode.

A team is struggling, so perhaps it needs another person. Customers are asking the same question, so perhaps a chatbot would help. A process is slow, so maybe it should be automated.

Sometimes those will be the right answers, but I would want to understand the cause first.

Why is the team struggling? Why are customers contacting us? Why does the process take so long? Where does the delay actually happen?

This is another reason the people doing the work need to stay involved.

A process may look straightforward when you review it from a distance, while somebody completing it every day can immediately tell you about the exceptions, missing information and additional steps that have gradually become part of the job.

A customer contact that appears to create demand in one team may have been caused much earlier in the journey. A transfer may be creating rework because important information is missing. A capacity problem may actually be an avoidable-demand problem.

Taking the time to understand those connections gives you a much better chance of solving the right problem.

Identifying problems is relatively easy. Making sure something happens as a result is much harder.

Once improvement activity starts crossing departments, ownership can become unclear very quickly. Everyone may agree that something needs fixing, but each team also has its normal responsibilities. Meetings happen, actions are discussed and then day-to-day priorities take over.

A transformation function needs to provide enough structure to keep the work moving.

That does not mean transformation owns every solution. The people closest to the process will often need to design and implement the improvement, particularly when specialist knowledge is involved.

The transformation role helps keep the wider piece together by making sure ownership is clear, dependencies are understood, actions are followed through and the change is reviewed afterwards.

It also keeps communication open with the people affected by the improvement.

If employees have helped identify a problem, they should not have to wonder whether anything ever happened with it.

Closing that loop builds trust in the transformation function itself.

An improvement is only useful if something improves.

It is very easy for transformation activity to become focused on what has been delivered. A new process goes live, a dashboard is built, training is completed or an automation is introduced, and the project is marked as finished.

I would still want to know what happened afterwards.

Did customer effort reduce? Did employees save time? Did repeat contact fall? Did the process become quicker? Did complaints reduce? Did the service become more consistent?

The measure should connect directly to the problem that triggered the work in the first place.

If employees were spending hours every week working around a manual process, how much time did the new process release? If customers repeatedly chased for updates, did those contacts reduce after the change?

And I would go back to the people who originally raised the issue.

Does this actually work better now?

That question can be just as important as the data because an improvement can look successful on paper while employees have quietly created another workaround behind it.

As improvement activity grows, the organisation starts building useful knowledge about what works and where recurring problems tend to appear.

Several projects may reveal similar ownership problems. Poor transitions may appear in different customer journeys. Unclear communication may be creating avoidable contact across several services.

Those lessons should not disappear when the individual project closes.

I think there is real value in keeping a central record of improvement activity, outcomes and lessons learned so future work can build on what the organisation has already discovered.

It also gives people across the business visibility of what transformation is achieving.

Employees can see that issues are being raised and addressed. Leaders can see recurring themes and where investment is having an impact. Teams beginning a new piece of work can learn from what has already happened elsewhere.

Over time, transformation starts creating organisational memory rather than a series of disconnected projects.

A transformation function begins to mature when improvement stops feeling like something that happens occasionally.

Teams start bringing issues forward because they know there is a route for dealing with them. Frontline feedback becomes useful input rather than something mentioned in passing. Customer feedback is connected with operational information, and leadership has better visibility of where service problems are concentrated and what is being done about them.

People also start to see improvement as something they can contribute to.

That matters.

Some of the best ideas will never come from the transformation function itself. They will come from the person who speaks to customers every day, the employee who completes the same awkward process twenty times a week or the team that has found a workaround because the official route stopped working months ago.

A mature transformation function gives those people somewhere to bring that knowledge and makes sure they hear what happens afterwards.

That is how you create an organisation where people feel they have a voice in improving the way work gets done.

When people hear the word transformation, it can sound as though the starting point needs to be a large team, a major programme and a substantial budget.

You can start much more simply.

Talk to customers and employees. Ask what is not working. Bring the issues into one place and start looking for patterns. Understand the impact before deciding what to tackle first. Give improvements clear ownership, involve the people who understand the problem and measure whether the change genuinely made things better.

Most importantly, keep communicating.

Tell people what you are looking at. Explain why something has been prioritised. Go back to the employees who raised issues and show them what changed.

As the business begins to see the value, the transformation capability can become more structured. Governance becomes clearer, data becomes stronger and the improvement pipeline becomes easier to manage.

The function grows because people can see what it is achieving.

For me, that is what building transformation from zero is really about. You are creating a way for the organisation to recognise problems earlier, understand them properly and make sure improvement actually happens, while giving the people closest to the service a genuine voice in shaping how it develops.

When people can see that their knowledge is listened to and acted on, they become part of the transformation rather than simply experiencing the changes that come out of it.

If you asked your employees what is making their job harder today, would they believe something would actually happen with the answer?