Most writing about application rationalization — including most of ours — assumes you already have permission to start. That skips a stage a lot of people are actually stuck at: you can see the problem, you are fairly sure there is money in it, and you now have to convince a CFO and a set of department heads who did not ask for this.
This is the internal sell. It has its own structure, and the thing that makes it difficult is that you are asked to quantify the saving before you have been given the budget to measure it.
Estimating Savings Before You've Done the Audit
You will be asked "how much will we save?" before you have any right to a precise answer. Do not invent one, and do not refuse to answer either — both lose the room. Give a defensible range with the method attached.
Three inputs you can usually assemble in a week without a formal project:
- Your own known software spend. Whatever finance can already report. It will be an undercount, which is useful — it makes every estimate built on it conservative.
- A published benchmark for waste. Industry estimates for unused or redundant software spend cluster around the 25–30% mark. Our breakdown of what SaaS sprawl actually costs works through where those figures come from and how far to trust them.
- Two or three specific examples from inside your organization. This is the part that does the persuading. One duplicate tool with a real name and a real annual cost is worth more than any benchmark.
Frame the output as a range with an explicit method: "our tracked software spend is $2.4M. Published benchmarks put redundant or unused spend at 25–30%. That implies $600–720K of addressable waste. I can already name $140K of it. I'm asking for six weeks to establish which end of that range we're at." That is a claim a finance director can interrogate, which is exactly what makes it credible.
Deliberately understate. The business case you are believed on is worth more than the one with the bigger number. If you promise the top of the range and deliver the middle, you have failed. Promise the bottom and deliver the middle, and you get the second phase funded without asking.
Two Audiences, Two Different Pitches
The single most common reason a business case fails is being delivered in one register to a room that contains two audiences with opposed concerns. They need separate conversations.
Finance: this is margin you already own
Finance is not resistant to this idea. Retired software is one of the cleanest cost reductions available — no headcount implications, no revenue risk, and the saving is recurring rather than one-off. Lead with:
- Recurring, not one-time. A retired $80K contract is $80K every year, and that compounds against renewal uplifts you now never pay.
- Budget predictability. A renewal calendar with usage data attached turns software from an unpredictable line into a managed one. Finance teams often value this as much as the saving.
- A modest, bounded ask. Weeks of internal effort against a six-figure estimate is an easy approval. Do not attach a tooling purchase to the first phase if you can avoid it.
Department heads: this is not about taking your tools away
Department heads hear "rationalization" as "IT is going to remove something my team relies on, and productivity will be my problem." They are not being unreasonable — that is exactly what a badly run programme does to them.
What works with this audience is a commitment about process rather than a promise about outcome:
- No application is retired without its owner seeing the usage data first and having the chance to challenge it.
- Where a tool is consolidated rather than dropped, migration support is part of the programme, not left with the team.
- Nothing is switched off with no notice — restricted access first, decommission later.
- Where a saving comes out of their area, be clear in advance about whether the budget follows it. Ambiguity here creates opposition out of nothing.
Handling the Predictable Objections
| What you'll hear | What it usually means | What actually answers it |
|---|---|---|
| "We've always used this." | Nobody has re-evaluated it since it was bought | Show current usage against current licence count. Ask what it would take to re-earn the renewal. |
| "My team needs this exact tool." | Sometimes true, sometimes preference | Ask which specific capability the alternative lacks. A real answer ends the argument in their favour; no answer ends it in yours. |
| "We don't have bandwidth right now." | Not convinced it's worth the disruption | Shrink the ask. A two-week look at one capability area is hard to refuse. |
| "IT doesn't understand what we do." | A previous change was done to them | Concede the point and hand them the challenge step. Being the reviewer changes the position. |
The objection worth taking seriously is the second one. Sometimes the answer genuinely is that the alternative cannot do a thing the team depends on — and finding that out during the business case is a good outcome, because discovering it after a migration is an expensive one.
Ask for a Pilot, Not a Mandate
The instinct is to ask for the portfolio-wide mandate, because that is what the problem deserves. It is also what makes the decision large enough to be deferred.
A bounded pilot is much harder to say no to, and it changes what you are asking people to approve: instead of endorsing a programme, they are approving a look. Scope it as one capability area or one business unit, six to eight weeks, with a named deliverable — an inventory, a scored shortlist, and a verified saving figure from at least one completed retirement.
That last item matters more than the rest combined. A pilot that produces analysis gets you another meeting. A pilot that produces a switched-off application and a number finance can confirm gets you the programme. Our walkthrough of how to conduct a software portfolio audit is a workable scope for exactly this kind of first phase.
What Goes in the One-Page Business Case
One page. If it needs a deck, the ask is too big.
- The problem, in one number. Current tracked software spend, and the benchmark range for waste against it.
- Three named examples. Real applications, real annual costs, real overlap. This is the section people actually read.
- The ask. Scope, duration, and who is needed for how long. Be specific about the time you need from other teams — hidden effort is what gets programmes resented later.
- The deliverable. What exists at the end, including at least one completed retirement with a verified saving.
- The guardrails. The commitments from the department-head section above, written down. This converts your loudest potential objectors into people who have been promised something.
- What happens next if it works. One line. Enough to show this is a first step, not enough to make anyone feel they are approving the whole programme today.
Leave out the maturity model, the tooling comparison, and the multi-year roadmap. They can all come after you have a verified saving, and every one of them gives someone a reason to postpone the decision.
Building the internal case and want a defensible number to put in it? A free portfolio assessment gives you a savings range specific to your environment, plus two or three named examples you can take straight into the conversation. Book one here →
