Shared Services Strategy & Business Case

IT Shared Services is the operating model in which common IT capabilities — infrastructure, service desk, application management, finance-IT, HR-IT — are consolidated into a dedicated organisation that serves multiple business units under service agreements. The premise is that common work, done once well, is cheaper, more consistent, and more automatable than the same work done many times across business units.

The strategy and business case are what separate shared services that deliver from those that disappoint. A shared services programme launched without a clear target operating model, a defensible business case, and a value-lever sequence tends to consolidate cost without improving service — the failure mode that gives shared services a mixed reputation. Done with rigour, IT shared services reliably reduces run cost by 20-40% while raising service quality, freeing business-embedded IT to focus on differentiating work.

This page covers the case for shared services, the target operating model, the value levers and their sequence, the business case method, governance, and the common failure modes to avoid.

The case rests on three observations. First, a large share of IT work is common across business units — every unit needs service desk, identity, patching, backups, application support — and doing it many times is wasteful. Second, common work, once consolidated, can be standardised and then automated, unlocking cost and quality gains distributed work cannot. Third, business-embedded IT talent, freed from run work, can focus on differentiating change work that grows the business.

The economic logic is compounding. Consolidation removes duplicated effort; standardisation removes process variance (which is where most cost and error hide); automation removes the remaining manual effort. Each lever enables the next — you cannot automate what is not standardised, and you cannot standardise what is not consolidated. Sequencing matters more than scope.

The strategic case is equally important. A shared services model gives the enterprise a single, accountable owner for run IT, clear service agreements, and a platform from which to scale AI and automation. Without it, AI and automation are adopted inconsistently across business units, producing the same fragmentation in a more modern form. Shared services is the organisational substrate on which enterprise-scale AI adoption rests.

The target operating model (TOM) is the design of the shared services organisation: what services it provides, how it is structured (by service tower, by customer, by geography), where it sits in the organisation, how it is governed, and how it is funded. The TOM is the anchor for the business case and the design for delivery; without it, the programme has no destination.

The TOM spans four dimensions. People: the roles, skills, and structure of the shared services organisation, and what happens to the business-unit IT staff it absorbs. Process: the standardised processes and SOPs the organisation runs (covered in its own topic). Technology: the platforms — service management, automation, knowledge — the organisation operates. Location: the onshore/nearshore/offshore mix that balances cost, skills, and service hours.

The TOM must be concrete enough to guide design and defensible enough to survive scrutiny. A TOM that says only 'we will be efficient and customer-focused' cannot guide decisions; one that specifies the service towers, the location mix, the service agreements, and the staffing model is actionable. The discipline is the same as any architecture: a directional target with enough specificity to sequence the journey.

Shared services value is delivered through three levers, in a fixed sequence: consolidate, standardise, automate. Consolidate brings the work into one organisation, removing duplication. Standardise removes process variance, which is where the real cost and quality gains hide. Automate the now-standard processes, removing the remaining manual effort.

The sequence is non-negotiable. Automating before standardising automates the variance — you build bots that replicate every team's different way of working, at high cost and low return. Standardising before consolidating is theoretical — there is no single owner to hold the standard. Each lever enables and amplifies the next, and skipping one collapses the value of the others.

A fourth lever, optimise, runs continuously once the first three are in place — improving the standard, extending the automation, refining the service. The mature shared services organisation runs optimise as a steady-state discipline, not a one-off project. The programme that stops at consolidate, declaring victory on the move, captures perhaps a third of the available value.

The business case quantifies the value of the shared services programme and secures funding. A defensible case has five elements: the baseline (current cost and service, honestly measured), the target (the TOM and its expected cost and service), the benefits (the value levers, quantified), the costs (transition and run, including often-underestimated change-management cost), and the financials (NPV, payback, IRR, with sensitivity).

The benefits must be sequenced to the value levers and tied to specific actions. '20% cost reduction from standardisation' is not a benefit; '12 FTE reduction from standardising the access-management process across 4 business units' is. Benefits tied to specific, trackable actions are credible and realisable; benefits asserted at a percentage of run cost are neither.

Sensitivity analysis is where the case is stress-tested. What if attrition is higher than expected? What if automation delivers less? What if the transition takes six months longer? A case that survives plausible downside is fundable; one that only works in the base case is not. The discipline is to present the case with its sensitivities, not to hide them — boards trust cases that are honest about risk more than cases that ignore it.

Shared services governance has two parts: the steering (a joint business-IT body that sets direction, approves the TOM, and resolves escalations) and the service management (the SLAs, XLAs, and reviews that govern day-to-day delivery). The steering ensures shared services serves the business; the service management ensures it is accountable for delivery.

The funding model shapes behaviour. Chargeback (business units pay for what they consume) drives consumption discipline but can discourage use of shared services; allocation (cost spread by formula) is simpler but weakens the demand signal; showback (business units see their consumption without paying) informs without constraining. The choice depends on the enterprise's maturity and goals; many start with showback and move to chargeback as services mature.

Governance fails when the steering is absent or advisory. Without a joint steering body with real authority, shared services drifts toward what is easiest to deliver rather than what the business needs, and business units circumvent it with shadow IT. The steering is not optional infrastructure; it is the mechanism that keeps shared services aligned to the business over time.

Several failure modes recur in IT shared services programmes. Consolidation without standardisation moves cost without removing it — the work is in one place but still done many ways, and the expected savings do not appear. Automating before standardising burns budget on bots that replicate variance. Over-ambitious scope — trying to share everything at once — overwhelms the organisation and stalls the programme.

Underestimating change management is the most common failure. Absorbing business-unit IT staff, changing how business units request services, and building a shared services culture are each significant change efforts. Programmes that budget the transition but not the change produce a new organisation the business does not adopt, and shadow IT returns.

Finally, declaring victory at consolidation — 'we moved the work, we are done' — leaves the majority of value on the table. Consolidation is the first lever, not the last. Programmes that stop at consolidation, without sequencing standardise and automate, capture perhaps a third of the available value and often revert as variance re-enters the model. The value is in the sequence, not the move.