Total cost of ownership is the dated cost of obtaining, operating, changing and eventually leaving a software capability over a defined period. It is not the subscription total plus a rough implementation percentage.
A useful TCO model states volumes, timing, responsibilities and uncertainty. It separates cash from internal effort, committed cost from risk allowance and baseline use from growth. The worked example below uses illustrative units—not market prices—to show the method.
Write the decision boundary first
State which options, business capability, population, regions and time horizon the model supports. Define the starting point: replacing an existing service, introducing a new one or consolidating several. Record whether tax, inflation, financing and internal labour are included and which currency and price date apply.
Use the same boundary for every option. One proposal may include migration and premium support while another excludes them. Normalise the scope before comparing totals.
Build the cost model in six layers
| Layer | Typical components | Primary evidence |
|---|---|---|
| Acquire | subscription or licence, environments, minimum commitments, procurement | proposal, price schedule, usage definition |
| Implement | design, configuration, migration, integration, testing, training, cutover | statement of work, buyer resource plan |
| Operate | administration, support, monitoring, data quality, security review, recovery tests | operating model, service boundary |
| Change | releases, new workflows, integrations, reporting, retraining | roadmap and change scenarios |
| Risk | contingency for evidenced uncertainty, not a hidden padding percentage | risk register and ranges |
| Exit | export, transition help, replacement overlap, archive, deletion evidence | contract, tested exit plan |
Separate cost drivers from quoted prices
For every recurring line, record the unit and formula. A user price requires a definition of user, role mix, minimum count, inactive account treatment and growth. Usage pricing requires the measured event, included allowance, tiers, overage and data source used for billing.
Keep a driver sheet beside the cash flow: employees, active users, transactions, storage, integrations, environments, support hours and growth. Changing a driver should recalculate every affected option transparently.
Place every cost in time
A three-year total can hide a difficult first year or a large renewal step. Build monthly or quarterly cash flows during implementation and annual flows afterward. Show contract prepayment, implementation milestones, parallel operation and decommissioning.
If the organisation uses discounting, apply one approved method consistently. The UK government's Green Book emphasises appraisal across costs, benefits, risks and time. Private organisations may use different approved rates, but the logic remains: timing and uncertainty should be visible rather than collapsed into one unsupported total.
Worked illustrative model
Assume two options support the same capability for three years. Values are illustrative cost units.
| Cost group | Option A | Option B | Evidence note |
|---|---|---|---|
| Acquire | 24 | 36 | A varies with use; B has higher committed subscription |
| Implement | 14 | 9 | A needs two integrations; B includes one suite connector |
| Operate | 19 | 14 | A has higher reconciliation and monitoring effort |
| Change and growth | 15 | 18 | B's next module increases licence count |
| Risk allowance | 11 | 7 | ranges trace to open assumptions |
| Exit | 7 | 9 | B needs longer dual-running period |
| Baseline total | 90 | 93 | difference is smaller than uncertainty |
A three-unit difference does not justify declaring A cheaper when several lines remain ranges. The decision should inspect which assumptions can reverse the result.
Run growth and stress cases
Change the drivers, not arbitrary totals. A growth case might add 30% active users, a region and two integrations. A stress case might increase migration remediation, delay cutover and require six months of parallel service.
Report each option as a range with the assumptions that create it. Identify the break-even driver: the user count, transaction volume or change frequency at which the cost order reverses. This is more useful for negotiation and planning than one precise-looking number.
Calculate sensitivity before negotiating
Rank the assumptions by their effect on the three-year result. Change one at a time to a plausible low and high value, then combine the most credible adverse values into the stress case. Typical sensitive drivers include adoption pace, migration remediation, integration count, premium support, usage growth and the length of parallel operation.
Suppose Option A's 90-unit baseline assumes two integrations at four units each. If discovery reveals five integrations at six units, the difference is eighteen units—not a minor implementation adjustment. The decision team can then simplify scope, request a fixed deliverable or reconsider architecture. Sensitivity turns uncertainty into a targeted question.
Treat internal effort honestly
Internal labour may not create a supplier invoice, but it consumes scarce capacity. Estimate roles, time and period for process owners, users, data teams, security, technology operations, procurement and finance. Keep hours visible even if financial policy does not convert them into cash cost.
A product that needs 400 internal hours during the busiest operating period may be less feasible than a more expensive proposal. Capacity timing belongs in the decision record.
Prevent double counting
Map each cost to one work package and owner. Common duplicates include contingency embedded in both supplier estimates and risk allowance; support counted in subscription and again in operations; or migration resources included in a statement of work and internal plan.
The reverse error is more common: each party assumes the other owns data cleansing, testing, training, reporting or cutover. A responsibility matrix should reconcile to the cost model.
Govern estimates and actuals after approval
Assign an owner and confidence level to each line. Baseline the approved model, then record committed contract values, approved changes and actual internal effort against the same structure. Do not overwrite the original assumptions; version them so decision quality can be reviewed.
Set review triggers for material scope change, volume movement, delayed cutover, new integration or supplier price notice. TCO is most valuable when it becomes an operating forecast rather than a spreadsheet opened only during procurement.
Connect cost with evidence and value
TCO does not rank product fit. Apply mandatory requirements and a transparent evaluation scorecard separately, then compare the cost of viable options. If a capability changes revenue, control or service outcomes, model those benefits in a distinct evidence-based business case rather than subtracting optimistic claims from cost.
Keep a versioned assumptions log, source, owner and review date for every material line. A TCO model is ready when another person can reproduce the total, challenge the uncertain drivers and see what the organisation must fund after signature.