How to size an offshoring or SSC transition - the FTE math nobody teaches
The short answer
Size a transition with arithmetic, not optimism. Target FTE = annual volume ÷ productivity (units per FTE per year, from the source team's actuals). Then apply a ramp-inefficiency uplift - a new team is not as fast as a mature one - and fund the higher, year-one number, not the steady state, or the team is structurally understaffed for its first six months. Choose the transition model deliberately (lift-and-shift to stabilise, then transform - not both at once). Run knowledge transfer in four steps (discovery, shadowing, reverse-shadowing, independent), advancing a process on evidence, not a calendar date. Budget the dual-running window where both teams run, with explicit decommission criteria. And declare the transition done only when each process meets its BAU exit criteria - SLA, error rate, backlog, escalation - not on the go-live date. Most failed transitions are declared finished at cutover and unravel six weeks later.
Sizing and planning a transition - six moves
- 01
Size the target team with arithmetic
Target FTE = annual volume ÷ productivity. Take the real annual volume of the work (e.g. 240,000 invoices) and the source team's mature productivity (e.g. 12,000 per FTE per year). 240,000 ÷ 12,000 = 20 FTE at maturity. That is your steady-state number and the basis for the run-cost saving - but it is not what you staff in year one.
- 02
Apply the ramp uplift - and fund it
A team three months into a new process is not as fast as one with five years on it. Apply a ramp-inefficiency uplift (commonly +15% in year one, set from your own evidence): 20 × 1.15 = 23 FTE. Budget the 23; promise the board the 20 at maturity, not on day one. Staffing the steady-state number from day one is how a new centre earns a bad reputation in its first quarter.
- 03
Choose the transition model deliberately
Four models: lift-and-shift (move as-is, improve later - lowest transfer risk); lift-transform-shift (redesign then move - double the risk); build-operate-transfer (a partner runs it, then hands over); and phased/hybrid (lift-and-shift first, transform once stable). Default to phased/hybrid. The most common self-inflicted wound is choosing lift-transform-shift by accident - changing the process and the team at the same time. Nobody writes that choice in the plan; it arrives as a handful of sensible improvements agreed during discovery, and then no failure can be traced back to a single cause.
- 04
Run knowledge transfer in four evidence-gated steps
KT runs per process in four steps: discovery (document the real process), shadowing (the learner watches), reverse-shadowing (the learner does it, the expert corrects), and independent (the learner works unsupervised, spot-checked). Advance a process on evidence - the work is right - not on a calendar date. The expensive shortcut is marking KT 'complete' on the plan date while the learner still needs the expert, who then leaves. A green KT tracker is a claim about a date, not about whether anyone can do the work on Monday.
- 05
Budget the dual-running window
While the source team ramps down and the target ramps up, you pay for both. Model that peak cost week by week, and set explicit decommission criteria - 'old system off when X, Y, Z are green for two periods' - not 'until we're comfortable.' A window with no exit criteria never closes, and the run-cost saving the business case depends on never arrives.
- 06
Define done as BAU exit criteria, not go-live
A transition is not finished at go-live; it is finished when each process meets its BAU exit criteria - SLA adherence, error rate, backlog, escalation rate, each with a numeric threshold and a sign-off. A process that has not met its criteria stays in hypercare. Declaring victory at cutover is why most transitions unravel six weeks later.
Most transitions are sized with optimism, not arithmetic
I have run shared-service and offshoring transitions, and the most common, most expensive mistake is made before a single process moves: the target team is sized to the source team’s mature productivity. It happens in a business case, in a spreadsheet, months before anyone has been hired - and by the time it hurts, the number has been signed off twice and nobody wants to reopen it. The new team is then understaffed for its first six months - exactly when quality matters most and the centre’s reputation is being set.
The fix is not more governance. The fix is arithmetic.
The FTE math, worked
Target FTE = annual volume ÷ productivity. Take a real example - accounts payable:
- Annual volume: 240,000 invoices.
- Mature productivity (from the source site’s actuals): 12,000 invoices per FTE per year.
- Base FTE = 240,000 ÷ 12,000 = 20.
- Ramp uplift, year one (+15%): 20 × 1.15 = 23.
The two numbers do different jobs. The 20 is your steady-state target - the basis for the run-cost saving you promise the board. The 23 is what you actually staff and fund in year one, because a team three months in is not as fast as one with five years on the process. Budget the 23; promise the 20 at maturity. What I have seen instead is a business case that carries only the 20, because the 20 is the number that made the saving look good in the approval meeting. Staffing the 20 from day one is how a new centre builds a backlog and a bad reputation in its first quarter.
The two traps after the maths
- Dual-running. While the source ramps down and the target ramps up, you pay for both. Model that peak week by week, and set explicit decommission criteria - not “until we’re comfortable.” A window like that can stay open for the better part of a year, because nobody wrote down what would close it, and every month the answer to “can we switch the old one off?” is another month. A window with no exit never closes.
- Declaring victory at go-live. A transition is done when each process meets its BAU exit criteria - SLA, error rate, backlog, escalation - not on the cutover date. The cutover celebration is the easiest thing in the whole programme to schedule and the least informative thing in it. Go-live is the start of stabilisation, not the end of the transition.
Get the maths honest, fund the ramp, and run knowledge transfer on evidence rather than a calendar, and the transition lands stable instead of on time and broken.
Part of The Job, Decoded - the operator’s series on what enterprise-operations roles actually are. This is the SSC / GBS transition manager, decoded.
Frequently asked
How do you calculate FTE for an offshoring or SSC transition?
Target FTE = annual volume ÷ productivity (units per FTE per year), using the source team's mature productivity. Then apply a ramp-inefficiency uplift for year one - a new team is slower than a mature one - and fund that higher number. For example, 240,000 invoices ÷ 12,000 per FTE = 20 FTE at maturity; with a 15% ramp uplift you fund 23 for the first year. The 20 is the business-case saving; the 23 is what you actually staff.
What is the ramp uplift and why does it matter?
It is the extra headcount a new team needs before it reaches the source team's productivity. A team in its first months produces fewer units per person, so sizing to mature productivity leaves you structurally understaffed exactly when quality matters most - the first month-end, when the new centre's reputation is set. The uplift is not padding; it is the arithmetic of a new team. Make it explicit so finance funds the ramp instead of discovering it as an overrun.
What are the four transition models?
Lift-and-shift (move the process as-is, improve later - lowest transfer risk); lift-transform-shift (redesign the process, then move it - much higher risk because you change the what and the who at once); build-operate-transfer (a partner builds and runs it, then hands it to you later); and phased/hybrid (lift-and-shift first to stabilise, transform once BAU is solid). Most real transitions should be phased/hybrid; the default mistake is attempting lift-transform-shift without meaning to.
When is a transition actually 'done'?
When each in-scope process meets its BAU exit criteria - SLA adherence, error rate, backlog, and escalation rate, each at an agreed numeric threshold, signed off - not on the go-live date. Go-live is the start of stabilisation, not the end of the transition. The most common failure is declaring a transition finished at cutover; it then unravels in the weeks after, in front of the customer, because the exit criteria were never the definition of done.
The done-for-you version: an 18-tab Excel workbook that runs the whole transition - scope, process discovery, the FTE and ramp-curve maths, knowledge transfer, UAT, parallel run, go-live readiness, hypercare and BAU exit - plus a 15-page, 12-phase delivery handbook and SOP + engagement templates.
Get the Transition Management Operator's Workbook - $179Written by Petko Petkov - 15 years inside enterprise IT operations. Vihren Labs publishes operator-grade templates and playbooks for the enterprise IT stack.