How to Build a GCC Business Case With Accurate Cost Modeling
Most capability centre business cases are built to be approved rather than to be true. That is not dishonesty; it is a rational response to how these decisions get made. The case competes against other uses of the same capital, the reviewer is looking for a headline saving, and a case that presents a smaller number with more caveats loses to one that presents a larger number with fewer.
The problem arrives eighteen months later. The centre is running, the actuals do not match the projection, and the centre spends its second year defending a number it did not choose rather than demonstrating what it has built. A great many capability centres that are working well are judged as failures on this basis alone.
This guide sets out how to build a case that is both approvable and survivable: what to include, how to model the parts that are usually guessed, and how to present it so that a normal variance is not read as a failure.
Key points
- Capture the baseline before the first hire; it cannot be reconstructed afterwards
- Model a productivity curve rather than assuming output from month one
- Separate fixed costs from per head costs, especially below fifty people
- Present a range with named assumptions rather than a single number
- State explicitly what the case does not claim, which protects it later
Start with the baseline, before anything else
The single most valuable action in the whole exercise takes a week and is skipped more often than any other. Record what the work costs and produces today, before anything moves.
Capture the fully loaded cost of the work as it is currently done, including benefits, overhead allocation and management time. Then capture trailing throughput over four quarters: items delivered, cycle time, defect rate, incident volume. These figures are uncontested right now, and they will never be uncontested again.
Once the work has moved, reconstructing the baseline becomes an argument between people with different interests in the answer. Every subsequent comparison then rests on a number somebody can dispute, which is how a centre ends up unable to prove a saving it genuinely delivered.
Model the fixed base separately
Entity formation and maintenance, statutory compliance and audit, legal counsel, payroll administration, core infrastructure and the minimum leadership layer do not scale with headcount. Blending them into a per head average produces a model that is wrong at both ends: it overstates the cost of the marginal hire and understates the cost of the first ten.
Keeping them separate has a second benefit. It makes the marginal economics of growth visible, which matters because it shows that a second team in the same entity costs substantially less than the first. If there is any realistic prospect of expanding, that optionality belongs in the case and is routinely left out.
Model ramp as a curve, not a switch
A business case that assumes productive output from month one will show a first year variance that looks like failure. It is not failure; it is the model being wrong in a predictable and avoidable way.
Assume a productivity curve instead. A common planning assumption has a new hire contributing a small fraction of steady state output in the first month and reaching full contribution somewhere between month four and month six, slower in complex or heavily regulated domains and faster where a senior lead is already in place to absorb the onboarding.
Model this for every cohort, not just the first. Any centre that grows has a ramp cohort in flight almost continuously, which makes ramp a running cost rather than a start up expense.
Assumed contribution of a new hire by month
Planning assumption for modelling rather than measured research. Adjust for domain complexity and for whether a senior lead is already in place.
Include the costs that are not invoiced
Four costs consistently fail to appear in business cases because they arrive as consumed time rather than as spend, or land in a different budget from the one under review. Each is real, each is foreseeable, and each surfaces between month nine and month twenty four.
| Cost | Why it is omitted | How to model it |
|---|---|---|
| Ramp cost | Feels like a one off | Productivity curve per cohort, recurring with growth |
| Knowledge transfer drag | Lands on the onshore budget | Estimate onshore output loss over the transfer period |
| Onshore management overhead | Time, not spend | Estimate leadership hours; assume it falls as authority moves local |
| Attrition and replacement | Modelled as setup only | Apply a realistic annual rate with recruitment, overlap and re-ramp |
| Travel | Treated as a separate budget | Budget explicitly for year one; do not cut as an early economy |
| Fixed cost base | Blended into per head average | Separate line, modelled independently of headcount |
Including these makes the headline saving smaller and the case far more likely to survive its own second year.
Present a range, not a point
A single savings figure invites a false precision that the underlying data does not support, and it creates a target the centre will be held to regardless of what changes around it. A range with named assumptions is more honest and, in practice, more persuasive to a reviewer who has seen a few of these.
Present three cases. The conservative case assumes slow ramp, higher attrition and full inclusion of unbilled costs. The expected case uses your central assumptions. The favourable case assumes fast ramp and low attrition. Then state which assumptions drive the difference, because that tells the reviewer where the real risk sits and gives you a defensible position when reality lands somewhere in between.
Crucially, name the conditions under which the case fails. A business case that cannot fail is not a business case, and reviewers know it.
Slow ramp, higher attrition, all unbilled costs included, no expansion optionality. This is the number you should be comfortable being held to.
Central assumptions, stated explicitly. This is the number in the summary, and every assumption behind it should be listed on the same page.
Fast ramp, strong retention, second team added in the same entity. Useful for showing upside; dangerous if presented as the plan.
What would have to happen for this to be the wrong decision. Naming these is what separates a business case from a proposal.
State what the case does not claim
This is the most underused technique available and it costs one paragraph. Most disputes in year two are not about whether the centre delivered; they are about whether it delivered something it was never asked to deliver.
Write down explicitly what the case is not claiming. It is not claiming output in the first quarter. It is not claiming that onshore delivery will be unaffected during transfer. It is not claiming attrition will be zero. It is not claiming the centre will own systems in year one if it was scoped for capacity.
This paragraph does more to protect a capability centre than any other single element of the document, because it converts a later surprise into something that was disclosed at the outset.
Build the review cadence into the case itself
A business case that is approved and then filed becomes a weapon eighteen months later, because nobody revisits the assumptions and everybody remembers the headline. Committing to a reconciliation cadence in the document itself changes that dynamic.
Publish the baseline
Circulate the pre-move cost and throughput figures with the approved case, so they are a matter of record rather than of recollection.
Report readiness, not output
Hiring against plan, compliance milestones, environment readiness. Delivery metrics in this window are noise and will be misread.
First reconciliation
Restate actuals against model. Expect variance driven by ramp; explain it in words rather than only quantifying it.
Full true-up
Reconcile every line including the unbilled costs. Revise the model for year two rather than continuing to report against a superseded projection.
Shift the headline
Move cost to the appendix and lead with ownership and outcomes. The cost case has done its job by this point and cannot do more.
Mistakes that make a case undefendable
Each of these makes approval more likely and year two considerably worse.
- Comparing fully loaded offshore cost against unloaded domestic salary
- Assuming productive output from month one
- Omitting attrition entirely, which makes year two look like a failure rather than a modelling gap
- Presenting a single savings figure with no stated assumptions
- Blending fixed and per head costs into one average
- Failing to capture the baseline, which makes every later claim arguable
- Claiming ownership and capability outcomes for a centre scoped only to provide capacity
Approvable and survivable are different targets,Optimising only for approval produces a case that wins the meeting and loses the second year. The best protection you can give a capability centre is a smaller number you can defend, with the assumptions written on the same page.
Frequently asked questions
How long does it take to build a proper business case?
Two to four weeks for the modelling, plus a week for baseline capture that should run first. The baseline week is the part most often skipped and the part that determines whether anything in the case can be proven later.
What savings figure should we expect?
Rather than adopting a benchmark, model your own fully loaded costs both sides. Published benchmark figures usually compare unloaded domestic salary against fully loaded offshore cost, which overstates the saving and sets a target you will not hit.
Should the business case include value as well as cost?
Yes, but keep them separate and do not attach invented numbers to the value side. Present the cost case quantitatively and the value case as specific, named outcomes the centre will be able to own. Quantifying strategic value with a modelled figure damages the credibility of the whole document.
How do we model attrition when we have no history?
Use a realistic rate for the local market and seniority band, state it as an assumption, and revise it after the first year with your own data. Any explicit assumption is better than the implicit assumption of zero, which is what an omitted line means.
What if the honest case is not compelling enough to be approved?
Then it is worth knowing that before committing, which is the point of the exercise. It may also indicate the scope is wrong rather than the model: a centre scoped as capacity often has a marginal case, while the same investment scoped around ownership of a specific outcome frequently does not.
Should the case include the option of a second team?
Yes, as a separate scenario rather than in the headline. Most of the fixed base is incurred once, so a second capability in the same entity is substantially cheaper. This optionality is real value and it is routinely omitted.
Who should own the model?
Finance should own the arithmetic and the data collection; the sponsor should own the assumptions and be prepared to defend them. A model owned entirely by finance drifts toward cost per head, and one owned entirely by the sponsoring function drifts toward optimism.
How often should the case be revisited?
Quarterly in year one and annually afterwards, with a full true-up at month twelve that revises the model for year two. Reporting against a superseded projection for three years is the most common reason a successful centre appears to be underperforming.
Sources & further reading
- NASSCOM — https://nasscom.in/
- Deloitte — https://www.deloitte.com/
- McKinsey & Company — https://www.mckinsey.com/
- Everest Group — https://www.everestgrp.com/
Build a case that holds up in year two
Hexominds builds the fully loaded model, the baseline capture and the ramp assumptions with you before anything is committed.