A manager at a heavy vehicle workshop approached us in March to quote for five industrial PC systems for installation onto mobile trolleys. The manager had already purchased two identical systems from us previously, was happy with them, and knew exactly what was needed for the new ones. The specification was proven, the application was understood, and the quote was straightforward. Yet four months later, the project still hasn’t proceeded.
The quote has been updated multiple times as prices have changed, the quantity has been reduced from five to two as a consequence, and and the decision keeps on being deferred. The workshop manager knows how badly the equipment is needed. But somewhere between the workshop floor and the finance approval, the urgency has evaporated.
This isn’t an isolated case. We have seen the same pattern repeatedly this year. Another customer requested a quote for 15 industrial PCs in January, asked for price updates over several months, then reduced the order to five.
Projects ready to proceed in Q1 are still sitting in approval queues in Q3. The need hasn’t changed. The decision environment has.
Why projects stall
The technical justification is usually clear to the engineer, manager or whoever works with the equipment daily. The PC is old, unsupported or showing early signs of failure. The risk is obvious to anyone close to it.
But the people who approve capital expenditure aren’t close to the equipment. They are managing budgets across dozens of competing priorities, and a PC that is still technically running doesn’t feel urgent.
This year, economic uncertainty and the global RAM and component shortages have pushed prices up and made organisations more cautious. A project that looked like an easy approval six months ago now competes against tighter budgets and higher costs.
The result? Even proven projects get deferred, until something fails or the engineer finds a way to frame the project in terms that the finance department can’t ignore.
The language gap
Engineers think in terms of risk and reliability. Finance departments think in terms of cost and exposure. Operations thinks in terms of uptime and throughput. These aren’t conflicting priorities, but they use different language.
“The industrial PC is running Windows 7 and is out of support” is an engineering statement. It describes a condition but doesn’t communicate consequence.
“If this PC fails, we lose the production line for two to three weeks while we source a replacement, at a cost of $X per day in lost output” is a business statement. Finance can evaluate that against other risks.
Same facts. Different framing. The framing can determine whether the project gets approved or deferred.
Framing the business case
Here are some of the factors engineers who need to get essential hardware out of the approval process and onto the operational frontline need to consider.
Present the cost of inaction, not just the cost of action. The project cost is visible. The cost of deferral is invisible until something breaks. Make it visible.
Quantify the downtime exposure. What does the system control? How long to source, configure and commission a replacement? Multiply the daily cost of lost production by the realistic recovery time. That number usually makes the proactive replacement cost look modest.
Highlight increasing replacement difficulty. Hardware that could be replaced in two weeks today might take months next year if components are discontinued or supply is constrained. The current RAM, SSD and CPU shortages are a real example. Deferring does not freeze the situation. It often makes the eventual replacement harder and more expensive.
Identify compliance or safety exposure. Unsupported operating systems and unpatched vulnerabilities can create liability that extends beyond the engineering team. If a failure occurs on equipment known to be unsupported, the organisation’s position is different from a failure on maintained equipment. This matters to risk managers in ways that technical obsolescence alone may not.
Propose a staged approach. If the full project is too large, address the highest-risk systems first. Two replacements now is better than five replacements that never get approved.
Document the current state. Record hardware specs, software versions, backup locations and dependencies. This reduces recovery cost regardless of whether the replacement is approved now or later.
Get a current quote and keep it updated. A concrete proposal is easier to approve than a vague budget request. If prices are moving, a current quote also shows that deferral is not cost-neutral.
How ESIS can help
We provide detailed quotes and technical specifications that engineers can use directly in business cases and capital requests. We can advise on current lead times, component availability and pricing trends that affect procurement timing.
If you have a hardware replacement project that needs to move forward, or want to document your current systems to support future planning, we’re happy to help.
Contact us to discuss your requirements and get a detailed quote.
