I have led more savings projects than I can count. I have also seen enough of them quietly miss their number to know what is going wrong, and it is rarely the work itself. The work usually performs about as well as the spreadsheet predicted. The number underperforms because the spreadsheet only had one column.
I run distributed IT across roughly 250 vessels and 100-plus offices. Years of acquisitions have left a long catalog of consolidation and standardization projects in my wake. Some of them saved real money. Some of them booked a savings on paper and gave it back somewhere else. The difference between the two has almost nothing to do with the technical decision and almost everything to do with which costs got counted.
There are three. Most savings stories count one of them.
The three-cost frame
Every IT cost lives in one of three categories. A complete savings story has to account for all three. Most savings stories live entirely in the first one.
Direct cost is a line item on a vendor invoice or a budget. ISP circuits. Software licenses. Headcount. Cloud spend. Direct cost has a name, a number, and an owner. It is the easiest cost to reduce because it is the easiest cost to see. It is also the only cost that shows up in a typical savings memo.
Indirect cost is visible but unbudgeted, or budgeted somewhere other than the project that creates it. The integration tax. Training. Escalation overhead. Cutover windows. End-user time. PM work redistributed onto engineers when the PM role gets cut. Indirect cost is real, but it lives on a different line than the savings. The arrow points out of one P&L into another, and nobody connects the two.
Hidden cost is invisible and uncounted. Decision quality after the team is over capacity. Audit-trail integrity when the named owner of a vendor relationship changes and nobody picks up the work. Technical debt that compounds because the next project has to be built on top of the shortcuts the last one took. Senior engineers consumed by tier-1 work that should have been someone else's. Contracts that auto-renew because nobody owned the disconnect. Hidden cost surfaces months or years after the savings has been booked, and by then no one is doing the subtraction.
Direct savings minus indirect cost minus hidden cost equals the actual number. That is the formula every savings claim should be checked against. Almost none of them are.
The indirect cost most savings stories don't count
The pattern I see most often is the cutover-overlap miss.
Take a typical ISP consolidation. Twenty-five sites. The new ISP comes in at roughly two hundred dollars per site per month under the incumbent. That is sixty thousand dollars a year in direct savings. The memo writes itself. The board approves. The work begins.
Then operating reality shows up. There are actually two teams in this story. The project team owns the consolidation. They schedule the installs, manage the vendor relationship, track milestones, and report progress to whoever is asking. The local team at each site does the physical cutover. They escort the technician, validate the circuit, update the documentation, and fix what does not come up clean. The savings model accounts for the project team's labor, if it accounts for anyone's. It rarely accounts for the local team at all.
The local team is already running three other projects and day-to-day operations. The savings project is, on a good week, their fourth priority. Installations go fast because the project team and the vendor want the business and both control the schedule. Cutovers go slow because the local team controls the cutover schedule and the cutover sits behind everything else they own, plus the business-hour windows and site-specific dependencies only they can see. The new circuit is live. The old circuit is still live. Both are billing while the cutover waits in the local team's queue.
A four-month average overlap across twenty-five sites at the full second-circuit rate is real cash. Add the thirty-to-ninety-day termination notification period that almost every commercial circuit contract requires after you finally pull the trigger.
Then add the team labor question, which is where most savings stories quietly cheat. The local team is already on payroll, so the cutover uses people who are already paid. Therefore, the reasoning goes, the labor is free. It is not. Their time was already committed. The savings project displaces work that was already in flight. Every hour the local team spends cutting over a circuit is an hour not spent on the security review, the standardization rollout, or whatever project was scheduled to use that capacity. The cost does not show up on a vendor invoice. It shows up as the other three projects sliding to the right and the day-to-day backlog growing. At the team-capacity level it shows up as stress, slipped deadlines, and eventually attrition. A team running over capacity is not a team that can absorb a savings project for free. It is a team that will give back the savings in the other three projects you are not watching as closely.
The first year of savings does not look like sixty thousand dollars. It looks closer to break-even, sometimes worse.
The indirect cost was real. It was visible. It was on a line item, just not the one the savings memo was reading. By year two the math improves. By year three the project actually saves money. But year one, the year the savings was booked and the project was declared a win, the org-level total barely moved.
If the savings story does not include the cutover overlap, the termination tail, and the labor pressure on the team doing the work, the story is not finished.
The hidden cost most savings stories will never see
The pattern that is harder to spot is the missed disconnect.
Growth by acquisition compounds this. Every acquired company comes with its own vendor catalog. Its own ISP contracts. Its own dedicated lines. Its own auto-renewing service agreements at sites the parent company is about to consolidate, replace, or close. The acquisition closes. The new connectivity standard rolls in. The new sites get cut over. The acquisition team moves on to the next deal.
Months later, sometimes years later, the inventory work reveals what the consolidation missed. Circuits at sites that no longer exist on the operational map. Backup lines at offices that were closed during the integration. Maintenance contracts on equipment that has not been in service since the acquisition. The disconnect notices were never sent. The contracts kept renewing. The bills kept landing in accounts payable, and because they were within the noise floor of a multi-million-dollar telecommunications spend, nobody flagged them.
This is hidden cost. There is no line in the savings memo for it because at the time of the savings claim, nobody knew it existed. It surfaces during a careful inventory pass, the same pass that produced the original consolidation savings in the first place. I have personally been part of recovery efforts that returned tens of thousands of dollars in unreturned equipment and unused circuits that had been billing for years.
The savings was real. So was the hidden cost. The two never met on the same page.
The pattern is not unique to ISPs. The same thing happens with software licenses, hardware support contracts, lease equipment, and SaaS subscriptions. Whenever the acquisition pace exceeds the speed of vendor-rationalization work, hidden costs accumulate in the gap.
How to read a savings claim
Three questions land on every savings proposal before I sign off.
Where did the work go? If the work disappeared, the answer is suspicious. Work rarely disappears. It moves.
Whose budget is it landing in? If the answer is "the business" or "operations" or "the local team," the savings is at least partially a transfer. Maybe a good transfer, maybe not, but the org-level number is smaller than the IT-line-item number.
What is the indirect and hidden cost we have not named? If the proposal cannot articulate any indirect cost, the proposal is incomplete. If it cannot articulate any hidden cost, the proposal owner has not done the inventory work yet, which means the work is still ahead, not behind.
Three questions. Five minutes. Most savings claims do not survive them intact. The ones that do are the ones worth approving.
What I'd tell another IT leader
Read the savings, then read the other two. Direct savings is the easiest number to produce and the easiest number to defend in a meeting. It is also the least informative one. The number that actually matters is direct minus indirect minus hidden. If your savings memo only has one column, your savings number only has one column of accuracy.
Your team is not free labor. The people who actually do the cutover are already paid and already loaded with other work. That is what makes their time look free, and it is the most common mistake in a savings model. Internal labor has opportunity cost. If your savings model does not include the local team's time as a real, contested resource, the model is hiding its most important cost.
Make someone own the disconnect. Every cancellation, every reduction, every contract that ends has to be assigned to a person with a date. If you cannot answer who is going to send the termination notice on this circuit, you do not have a savings yet. You have an intent.
Stage the savings in your model. Year one is rarely the saving year. Year one is the integration year. Build the cutover overlap, the termination tail, and the team-capacity tax into the financial model so the year-one number is honest. If the project still pencils at year two and year three, it is real. If it only pencils at year three on paper that ignored year one, it was never real.
Do the inventory before you book the next savings. The hidden costs from the last three years of acquisitions and consolidations are still on your bill. They are also still recoverable, but only by someone who is doing the careful, slow, unglamorous work of comparing what is being billed against what is being used. Inventory is the cheapest savings project in the catalog. It also tends to be the one nobody is staffed to do.
The job is not to find more savings. The job is to make sure the savings you have already booked are real. If the column you live in is direct cost, you are living in the smallest column. The other two are larger, harder to see, and where most of the work actually goes.
Adam Cooper is a Technical Director writing about distributed IT operations, maritime technology, and AI in production environments. Connect on LinkedIn or get in touch.