Stork Delivery
Make next year's technology budget defendable
Build the budget around outcomes, ongoing obligations, and the assumptions that would change the decision.
The problem: technology proposals are difficult to compare without assumptions
Budget planning becomes difficult when every proposed project promises efficiency and every existing system is described as critical.
Give the discussion more structure. Separate the cost of running the current business from the investment required to improve it, then connect each proposal to a specific problem and a credible first result.
A good budget makes tradeoffs visible.
A practical approach
Account for the systems you already depend on
List hosting, licenses, support, maintenance, and recovery arrangements. Identify the owner of each significant cost and the business process it supports.
Include predictable obligations such as renewals and required upgrades. Avoid presenting all maintenance as discretionary simply because it does not create a new screen users can see.
Where a cost has grown, explain whether that reflects greater usage, a changed service, or something that needs investigation.
Describe improvement in measurable terms
A proposal to “automate operations” is difficult to evaluate. A proposal to reduce repeated order entry between two named systems can be investigated.
Establish the current work with the team doing it. Estimate potential improvement using explicit assumptions about volume, handling effort, and the work that will remain.
Treat those estimates as assumptions to test. Saved minutes do not automatically become reduced spending, and some improvements are valuable because they reduce delays or errors rather than headcount.
Include the full lifecycle
Budget for discovery, implementation, data work, testing, user handover, and ongoing operation. If a proposal replaces a tool, include migration and the period when both systems may need support.
For AI projects, account for integration, evaluation, review, and usage controls as well as model consumption.
A low initial build estimate can be misleading when the operating responsibility is left undefined.
Fund a decision point
Where uncertainty is substantial, consider a first phase that tests the key assumption and delivers a bounded result. Agree on the evidence needed before committing to the larger investment.
For example, prove that the supplier integration supports the required order changes before funding a broad rollout around it.
Keep a short list of deferred work and the conditions that would bring it forward. That helps the business respond when demand or risk changes during the year.
A defendable technology budget explains what the business is buying, why it matters, and how it will know whether the investment is working. The numbers become more useful when the assumptions behind them are equally visible.
The result: a budget tied to obligations and testable improvements
For each significant proposal, record the current problem, lifecycle cost, owner, expected improvement, and assumptions behind it. For uncertain work, specify the evidence the first phase must produce before more funding is committed. Review the proposals against those common fields. Start with the largest discretionary request so the discussion can distinguish a supported investment from an attractive but untested promise.