I inherited an $8.5 million infrastructure proposal that was already being treated as the answer.
It was seven slides long and covered a single year of spending. The technology itself wasn’t obviously unreasonable. The problem was that there was no defensible way to explain why the company needed that particular infrastructure, in that sequence, at that cost.
There was no requirements baseline behind the number. No current-to-future-state view. No useful total cost model. Business demand, resilience requirements, lifecycle obligations and existing capacity had not been brought together into one decision.
So I rejected the proposal and restarted the work.
The failure wasn’t that the infrastructure team couldn’t identify equipment to buy. The proposal gave leadership no defensible basis for deciding whether this was the right plan.
A purchase list is not an IT infrastructure roadmap
Technology teams are usually quite capable of identifying equipment that is old, approaching capacity or difficult to support. Those facts can justify action, but they don’t necessarily tell leadership what to buy next.
That distinction becomes expensive when several legitimate needs arrive at the same time. Storage is aging. Compute needs replacement. Recovery capability needs work. Network equipment is approaching end of support. Security has requirements of its own. Application teams expect growth. Each request can be valid independently while the combined investment plan is still indefensible.
That was the condition behind the $8.5 million proposal. The number represented a collection of technical answers, but leadership had no common model for deciding whether those answers formed the right plan.
The annual budgeting process had the same defect. Asset data, depreciation, licensing, support, lifecycle, recovery needs and capacity requests lived in different places. Technical teams could ask for more capacity without seeing the full production cost behind it, while finance could see transactions without seeing the technical dependencies and consequences behind those transactions.
The predictable result was that the same questions came back every budget cycle. Why now? Why this much? What happens if we wait? Why this platform? What does this replace? Which business requirement actually drives it?
Adding more detail to the purchase request wouldn’t have solved that. The decision model underneath it was missing.
The rebuild started with the current estate, not the desired purchase
I went back to the infrastructure baseline.
That meant rebuilding the datacenter inventory well enough to understand what was actually running, then working outward from there. What did the business expect the environment to support? What resilience and recovery requirements mattered? Where was capacity genuinely constrained? Which assets were nearing replacement? What dependencies changed the order in which work could happen?
Only after those questions were tied together did the future-state technology become useful to discuss.
That changed the shape of the work. Instead of asking leadership to approve one large year of infrastructure purchases, I could show the transition from the current environment to the required future state and explain why each step existed.
The financial model changed with it. Capital purchases, operating costs, support, licensing, lifecycle and other recurring costs were brought into a three-year TCO view. The infrastructure roadmap extended across 36 to 48 months rather than pretending everything belonged in one budget year.
The difference is more than presentation. A multi-year infrastructure roadmap makes sequencing visible. Leadership can see which investment is prerequisite to another, which work can wait, where delaying replacement creates an operating consequence, and where technical teams are asking for capacity ahead of demonstrated demand.
That is a much better conversation than debating individual line items.
TCO matters because purchase price is only one part of the decision
Infrastructure discussions can become strangely narrow around acquisition cost. That makes sense because the purchase is visible and easy to compare. Operating consequences are scattered across different budgets and different years.
A cheaper technical decision can increase support effort. A delayed replacement can preserve capital this year while increasing maintenance cost and operational risk. A platform that costs more upfront may eliminate another renewal or allow several fragmented environments to be consolidated.
None of those conclusions should be assumed. They need to be modeled.
In this case, the rebuilt three-year plan projected roughly $3 million less spending than the prior trajectory. That was a planning comparison, not realized savings, and I wouldn’t present it as anything else. Its real value was that the difference could be explained. The revised plan connected cost to requirements and sequence instead of simply producing a smaller number.
The CFO endorsed the roadmap. It redirected already approved 2023 spending, became the basis for 2024 and 2025 planning, and the approach was later extended across Infrastructure, End-user Technologies, Information Security and Application Development.
What had changed was not our ability to price technology. We had changed what leadership was being asked to approve.
An infrastructure assessment should produce decisions, not inventory
This is where I think a lot of IT infrastructure assessments stop too early.
An accurate inventory is useful. Lifecycle status is useful. Capacity utilization, support status, technical debt and architecture diagrams are useful. None of them are the final product if the business still can’t decide what to fund, what to defer and what sequence the work belongs in.
The assessment has to connect the technical estate to the decisions that maintain it.
That means enough current-state evidence to establish what exists, enough business direction to establish what the environment must support, and enough financial structure to expose the cost and tradeoffs of getting from one to the other.
It also means being willing to discover that the apparent answer is premature.
If a modernization proposal begins with products and ends with a total, the hard work may not have happened yet. The organization may know what it would like to buy without knowing which problem it is solving first.
That is how technically reasonable infrastructure plans become expensive arguments.
The roadmap should survive the person who built it
The strongest evidence that the rebuilt plan was useful came later. It continued to shape planning and was extended into other IT functions after I had left.
That is an important test for any IT infrastructure roadmap. If the logic only works while the architect or executive who built it is in the room, it isn’t much of an operating asset. Leadership should be able to see the baseline, requirements, dependencies, economics and sequence clearly enough to make the next decision without reconstructing the argument from scratch.
The original $8.5 million proposal wasn’t wrong because $8.5 million was necessarily too much. It failed because the organization had been given an answer before it had been given a defensible way to make the decision.