How a council member reads your IT budget request

February 18, 2026 · 5 min read · HQT

A council member opens the meeting packet with limited time, no technical background, and several other departments to get through. Somewhere in it is a request from IT: a short narrative, a list of line items, and a total. The vote depends on whether a non-specialist can tell what the money buys, what happens if it waits, and what it costs every year after.

This is written for the staff who prepare those requests, read from the other side of the dais. We apply the same one-time-versus-recurring test to our own internal systems. The requests that get funded are not the ones with the best technology behind them. They are the ones a reader can follow.

What the line items mean

Each category behaves differently over time.

Software licenses or subscriptions. A recurring right to use software, usually priced per user, per device, or per transaction. The line grows as the agency grows. Ask whether the contract caps the renewal increase.
Maintenance and support. Vendor support for software or hardware the agency already owns, often priced as a share of the purchase price. It buys patches and a phone number, not new capability.
Professional services or implementation. One-time labor to configure, migrate data, integrate systems, and train staff. This is the most uncertain line, because it depends on conditions nobody has measured: data quality, undocumented workflows, and how much staff time is actually available.
Hardware and refresh. Devices, network equipment, and servers on a replacement cycle. A refresh line that disappears for a few years means the cycle slipped, not that the need went away.
Hosting and cloud consumption. Metered charges that vary with storage, traffic, and compute. This is an estimate, not a price, and should be labeled as one.
Contract labor. People, priced by hour or month. This buys capacity, not a finished product, and it ends when the money does.
Contingency. A reserve against scope nobody can see yet. An honest request includes one and says how it was set.

One-time and recurring costs are two different decisions

The most common failure in a technology budget is approving a project on its implementation number and meeting its operating cost for the first time two budgets later. Software purchased once still carries support. A system moved to a cloud provider trades a capital purchase for a monthly charge that does not stop. Many jurisdictions separate capital and operating budgets, which makes this easy to miss: the large number moves through one process and the durable number lands in another.

Governments reporting under GASB standards are subject to GASB Statement No. 96 on subscription-based information technology arrangements, which can require a multi-year subscription to be recorded as a right-to-use asset and a liability rather than only as an annual expense. Applicability depends on the arrangement, so ask the finance office how it will treat each recurring line before the request is written.

If a request cannot show year three, it is not finished.

The questions worth asking

What happens if this waits a year? A good answer is specific: vendor support ends, an audit finding stands, a system cannot be patched, staff keep rekeying data.
What is the recurring cost after implementation, and which budget absorbs it?
Is this replacing something? What gets retired, and when does its cost stop?
Who does the implementation work, and which agency staff are involved? What do those people stop doing?
Where is the funding from, and does it expire? Federal awards run under the Uniform Guidance, which sets a period of performance and permits cost-sharing requirements; federal spending above the threshold there triggers a single audit. The recurring cost usually outlives the award.
What makes this line grow? Users, devices, transactions, or storage. Name the driver.
How will we know it worked, and when will you come back and report?

What a strong request contains

It opens with one plain paragraph naming the problem and the people affected. Every line item is labeled one-time or recurring. The multi-year total is visible. It names what is being retired, what the agency gives up by deferring, the funding source and any restriction attached to it, and one measure with a date to report against it.

It also names its own risk. A sentence such as "this estimate assumes the existing records are usable without cleanup" is more credible than a confident number, and it protects staff when the assumption proves wrong.

Signals that a request needs another round

A single line called modernization, transformation, or upgrade with a large number and no components.
Implementation priced with no assumption about agency staff time.
A recurring cost shown only for a partial first year.
"Required for compliance" with no citation to the rule, contract term, or audit finding behind it.
Savings claimed without naming the line item that goes down, and the year.
A total that matches a vendor quote exactly, with no contingency and no scope note.

Before you submit

Write the request for the person who will read it once. Answering the deferral, year-three, and retirement questions before submission tends to improve the project itself, because each forces a decision that would otherwise surface during implementation.