Transformation, Operating Model & Value Creation

A new department carries no expectation yet and nothing to unwind; replacing one that already runs means holding its service up — however poor — while taking it apart underneath. One client was buying nearly all of its IT from a managed service provider, paying above the market and not getting the quality, and that job was both at once: the service had to keep running every day, and the department that would take it over had never existed. We priced the alternative, hired the people, stood it up, kept the provider for the part it was genuinely better at, and handed the department to its own new leader. Run cost came down about 15%.

In-house, outsourced, or split changes what the business can do without asking permission, how fast it can change direction, and what it costs to stop. Fully outsourced buys capacity and gives up control over how the function changes; fully in-house buys control and carries the fixed cost. Most of the work is deciding which parts belong on which side.

When a business asks for a restructure, what it usually wants is for the work to run better. The chart is one lever on that — it sets who reports to whom. The rest is how the work moves: what gets produced, who does which part, what gets handed over and when, how long something sits before anyone picks it up, and how anyone knows it went out the door. People, process, the systems underneath them, and the governance that holds all of it together. Define those elements and the restructure has something concrete to improve.

A function has two ends. What comes in, who sends it, and why it's sent that way. What goes out, who depends on it, and what they do with it. Get those and the middle largely draws itself — and the departments on either side get asked before anything changes for them, which is most of why the new way sticks. It's where we've seen builds and rebuilds go wrong, and it's what we hold onto from the first conversation to the last.

You only find out whether a change worked long after the program is over. So every benefit in the business case starts with a baseline measured before anything changes, and one person inside the business owns it and reports on it. Set that up at the start and the business can show what the investment returned, in its own numbers, long after we've gone.

Some changes touch every department and every person in them. Before the build starts, the future process gets walked end to end — real people in their real jobs, role-playing their own work through it. The order they'd take. The exception they'd actually hit. The handoff to the person two desks over. What surfaces gets designed in, and the build starts on a design the business helped write.

Once it's configured, the people who'll use it run their own work through it with their managers in the room — real orders, real exceptions, real handoffs, on the configured system rather than a deck of it. Whatever they find gets fixed while it's still a change to something nobody depends on. Go-live is then the second time the business has used it, not the first.

Every company has a few who know the day-to-day, think past it, and carry influence regardless of their title. Their own leaders name them, and putting them on the program early — with real latitude, design input, and keeping the business informed as part of what they're there to do — brings the rest of the business along for the ride. By the time it lands, the people who were never on the program arrive ready to work rather than ready to fight.