Why problems tend to repeat
Shared services functions often face the same set of difficulties, whatever the industry. This is partly because the model asks one team to serve many customers with different needs, and partly because the original case for the team is often written around savings, which are easy to promise and hard to verify. The list below covers the problems that come up most often and general ways of dealing with them. Which ones matter in practice depends on the organization, and none of the remedies is guaranteed to work.
Scope creep
What happens. Requests accumulate that were never part of the original design. A unit asks for a favor, the team agrees, and soon it is an expectation. Over time the team does more work than it was staffed for, and quality or turnaround suffers.
General remedies
- Write down what is in scope and what is not, in plain language.
- Route out-of-scope requests through a simple approval step rather than handling them informally.
- Where extra work is legitimate, treat it as a new or changed service with its own resourcing.
- Review the scope on a regular schedule and remove items that are no longer needed.
The opposite problem also exists: a scope that is too rigid, so that sensible requests are turned away. The aim is a deliberate boundary, not a wall.
Loss of local knowledge
What happens. Staff who used to support one unit now support many. They no longer know the unit’s habits, its special customers or its unwritten rules. Errors increase and customers feel they must explain everything repeatedly.
General remedies
- Capture knowledge in standard operating procedures and notes before work moves, not after.
- Keep a named contact or small group for each major customer, so there is a familiar face.
- Retain a few experienced people from the original units in the new team where possible.
- Maintain a record of customer-specific instructions that new staff can find.
Customer dissatisfaction and distrust
What happens. Business units feel the central team is slow, remote or unresponsive. They begin to work around it, hire their own people, or buy tools independently, which creates the very duplication the service was meant to remove.
General remedies
- Agree expectations in writing and report against them openly.
- Create regular opportunities for customers to give feedback and see what changes as a result.
- Provide clear escalation routes for urgent or unresolved matters.
- Acknowledge failures quickly and explain what is being done.
Trust usually returns slowly and through consistent behavior, rather than through announcements.
Unclear ownership and decision rights
What happens. It is not clear who decides when a standard should change, when an exception is justified, or who is accountable for an outcome. Issues bounce between the central team and the units.
General remedies
- Name an owner for each service and each process.
- Record who decides what, ideally using a RACI matrix or a similar simple tool.
- Set up a forum where disputes about standards and priorities can be settled.
- Define how exceptions are requested and recorded.
Weak or misleading measurement
What happens. Either nothing is measured, so debates rest on opinion, or the wrong things are measured. A team judged only on cost per transaction may rush work. A team judged only on speed may let quality slip. Targets can also produce unintended behavior, such as closing requests prematurely to meet a deadline.
General remedies
- Use a small set of measures that cover cost, speed, quality and customer view together.
- Define each measure precisely so that everyone calculates it the same way.
- Record where things stood before the change, so progress can be judged fairly.
- Look at what the numbers cannot show, and ask customers directly.
Savings that do not appear
What happens. The case was built on expected savings, but costs remain. Some are fixed, some move elsewhere, and new coordination costs appear. Leaders become disappointed and the team is pressed to cut further.
General remedies
- Be modest about expected savings in the original case, and say which are uncertain.
- Track all costs, including those that moved to other parts of the business and the cost of managing the shared team.
- Consider benefits that are harder to measure, such as consistency and reduced risk, but do not rely on them to excuse poor performance.
- Revisit the design if the numbers are not working, rather than defending it by default.
Overload, queues and key person dependence
What happens. Demand rises without matching capacity, queues form, and a few experienced people become bottlenecks. If one of them is away, work stops. This is a form of single points of failure that applies to people as much as to systems.
General remedies
- Cross-train staff and document the work.
- Monitor demand and backlog, and raise capacity concerns early.
- Prioritize requests using clear, agreed rules.
- Plan for absences and have a backup for critical activities.
Resistance and morale in the team itself
What happens. Staff who were moved into the shared team may feel disconnected from their former colleagues and uncertain about their careers. The team can become demoralized if it only hears complaints.
General remedies
- Be open about roles, development paths and the purpose of the team.
- Share positive feedback as well as complaints.
- Involve team members in improving processes, since they often see problems first.
- Pay attention to change resistance as a normal part of any restructuring, not a personal failing.
Knowing when to change course
Sometimes the underlying issue is that the work was a poor fit for a shared model from the start. If problems persist despite honest efforts, it may be reasonable to return some activities to the business units or to adopt a hybrid design. Treating that as a legitimate outcome, rather than a failure, makes it easier to act on evidence. Suitable review points include a regular look at the overall scope, the service levels and the customer feedback together, rather than any one in isolation.