Setting Up a Shared Services Function Step by Step

Treat it as a staged change

Setting up a shared services function is an organizational change, not only a reorganization chart. People change reporting lines, processes are rewritten, systems may be replaced, and customers must learn a new way to ask for help. Doing it in stages allows learning along the way and gives points at which to stop or adjust. The stages below are a general pattern; the exact order and length will vary with the size of the organization and the work involved.

Stage 1: Clarify purpose and scope

Begin by deciding why the function is being created. Typical reasons include consistency, better visibility of cost, access to specialist skills or relief for local managers. A vague purpose leads to arguments later about what success means. It is also worth being honest about what the change is not for, since a case built on over-promised savings tends to disappoint.

Then identify candidate activities. Useful questions include:

Is the work repeatable and rule-based?
Is the volume high enough to benefit from pooling?
Do business units do it in broadly similar ways?
Does it depend heavily on local knowledge?

Work that is uniform and transactional is typically easier to move first. Judgment-heavy or relationship-driven work is often better left local, or handled later. Decisions about which functions to centralize first deserve care, since early results shape confidence in the whole approach.

Stage 2: Understand the current state

Before designing anything, find out how the work is done today. This is a form of current state assessment and usually covers:

Who does the work, in which units, and how much of their time it takes.
The volumes, peaks and seasonal patterns.
The steps followed, the systems used and the variations between units.
Known problems, delays and errors.
The cost, as best it can be established.

The result is a performance baseline. It matters because without it, no one can later say whether the change improved anything. Be careful with the figures: time estimates from staff are often rough, and partial roles are hard to count. Record the assumptions made, and treat the numbers as approximate.

Stage 3: Design the service

With a clear picture of the present, design the target arrangement. Elements to settle include:

Structure and location. One team or several, and where they sit.
Services offered. A defined list, described in an internal service catalog.
Processes. Common ways of working, documented as standard operating procedures.
Service levels. What customers can expect, set out in internal service levels that are realistic given the baseline.
Governance. Who owns the function, who decides what, and where customers can raise issues.
Funding. Whether costs are allocated, shown or charged, as in chargeback and showback.
Technology. The tools for requests, tracking and reporting, selected through a fair evaluation rather than assumed.
Roles and staffing. Skills needed, numbers, and how people will be selected or moved.

Consult the business units during design. They know where the exceptions lie, and involving them early reduces resistance. A stakeholder mapping exercise can show who is affected and how.

Stage 4: Build the case and prepare people

Prepare a case for the change that states benefits, costs and risks plainly. Avoid precise savings figures unless they rest on solid analysis, and be open about what is uncertain. A realistic case is easier to defend later than an inflated one.

Plan communication for everyone affected: staff whose jobs change, managers who lose or gain responsibility, and customers who will use the service. People are usually more concerned about what changes for them than about the overall rationale, so be specific where you can. Training and support for new ways of working should be planned before the transition, not afterwards.

Stage 5: Pilot

If possible, start with a limited pilot: one process, one region or a few friendly business units. A pilot tests the design with real work and exposes problems at low cost. Set measures in advance and compare them with the baseline. Be ready to change the design, delay the next step or stop.

Pilots are not perfect predictors. Volumes are low and the team is often especially attentive, so results may look better than they will at full scale. Treat early success with some caution.

Stage 6: Transition

Move work in waves rather than all at once where practical. For each wave:

Capture knowledge from the people currently doing the work, including exceptions and informal rules.
Train the receiving team and let them shadow existing staff.
Run in parallel for a period, if feasible, so that the old and new arrangements overlap and errors can be caught.
Define the cutover point and who is responsible after it.
Prepare a way back in case the transition fails, and agree the conditions under which it would be used.
Support customers with extra help during the first weeks.

Expect a temporary dip in service. Being open about this with customers, and planning for extra capacity, limits the damage.

Stage 7: Stabilize

After the move, the focus shifts to making the service dependable:

Track performance against agreed targets and the baseline.
Collect and act on customer feedback.
Fix recurring problems at their cause.
Hold regular governance meetings with customers.
Check whether staff are coping, and address workload and morale.
Adjust staffing and scope as real demand becomes clear.

Stabilization often takes longer than planned. Declaring it finished too early, and moving people on, is a common reason problems persist.

Stage 8: Review and improve

Some months after stabilization, review results honestly against the original purpose. Questions to ask include whether the expected benefits appeared, what costs were underestimated, whether customers are better or worse served, and whether any work should return to the units. Treat the function as something to adjust over time. Revisit the scope regularly, and keep a willingness to change course, since the right design today may not be right in a few years.

Risks across the stages

Weak sponsorship. Without a senior person who will back the change, disputes between units are hard to resolve.
Underestimating variation. Units often do the same task in more ways than anyone expected.
Rushing. Compressing the timeline tends to move problems into the transition.
Neglecting people. Staff reactions and morale affect quality as much as process design.
Over-centralizing. Pulling in work that depends on local knowledge may cost more than it saves.

None of these can be eliminated, but planning, honest measurement and staged steps make them easier to manage.