Technology partner for city managers and town administrators

A city manager is accountable for nearly everything the organization does and directly controls very little of it. Technology arrives at your desk in fragments: a police request for a records system, a public works ask for asset management, a utility billing platform the finance director says is failing, a vendor renewal that went up again. Each request is defensible on its own. Together they form a portfolio nobody assembled on purpose, with overlapping functions, staggered renewal dates, and a total annual cost that is hard to state from memory when a council member asks for it at the dais.

The accountability is also asymmetric. Technology that works is invisible, and nobody thanks the manager because the permit portal stayed up over the weekend. Technology that fails is a public event: the billing run misses a cycle, phones at city hall go down, an incident closes the network and residents read about it in the paper before the next meeting. Because council approves anything significant in open session, every technology decision is also a communications decision, and the decision to defer is on the record just as plainly as the decision to spend.

What makes this hard

• Technology requests arrive one department at a time, leaving the city with overlapping systems, staggered renewal dates, and no single figure for what it spends on software in a year.
• Council approval happens in public, so a cost increase, a schedule slip, or an outage in year two becomes a political event rather than a project management issue.
• The systems residents touch most often, utility billing, permits, and service requests, are the ones that generate calls to the manager's office the moment they fail.
• IT capacity is thin, and the working knowledge of how a critical system is configured often sits with one employee or one vendor.
• Cyber insurance renewals now ask specific questions about multifactor authentication, backups, and unsupported systems, and the answers can affect premiums, coverage terms, and whether a policy is offered.
• One-time funding covers implementation while the recurring license, hosting, and support costs land in the general fund in a later budget year.
• Vendor agreements carry automatic renewals, annual escalators, and data export terms that go unexamined until the city wants to leave.

How HQT helps

• Build and maintain an inventory of applications and contracts, with owner, annual cost, renewal date, integrations, and what depends on each system, so budget discussions start from one list rather than separate department memos.
• Write the technical portion of staff reports and council presentations in plain language, covering what the project does, what it costs in a steady year, and what deferring it means.
• Review vendor proposals, demonstrations, and contracts before award, including demonstration scripts built from the city's own cases, reference questions, and terms covering data ownership, export, service levels, and price escalation.
• Sequence technology work against the budget calendar, so items requiring council action are scoped and estimated before budget hearings instead of after.
• Do the integration work between platforms the city already owns, so staff stop re-entering the same information in permitting, finance, utility billing, and service request systems.
• Carry out security work sized for a small team: multifactor authentication, backups verified by restoring from them, a plan for unsupported systems, and an incident response plan that spells out the manager's and the public information officer's role.
• Document what we build and train city staff to operate it, including runbooks and administrative configuration, so routine changes do not require a vendor ticket.

How engagements with a city manager usually start

Most of these conversations begin with something already on the calendar. A permitting vendor has announced end of support. A finance system upgrade came back priced well above the placeholder in the budget. The insurance renewal questionnaire asks about multifactor authentication and the accurate answer is "on some systems." A department head has brought forward a purchase the manager cannot evaluate on technical merit alone.

The first useful step is usually smaller than a project. It is an inventory: every application the city pays for, who owns it, what it cost this year, when the contract renews, what it connects to, and what stops working if it goes away. Many cities do not have this in one place, because purchases happened department by department over a decade. Assembling it is a matter of weeks, and it changes the budget conversation, because it turns a stack of separate requests into one portfolio with a renewal calendar.

From there the work sorts into what has to happen this fiscal year, what can be staged, and what is a placeholder until there is a real estimate. Aligning that sequence to the budget calendar matters more than the technical sequence. Anything that needs council action in the spring has to be scoped, estimated, and written up in the winter.

What to ask any technology partner

• Ask who will actually do the work, and whether you meet those people before award. The names in the proposal should be the people on site.
• Ask for acceptance criteria you can verify: what will be demonstrated, on what date, using your data, with your staff in the room.
• Ask what the cost is in year three, including hosting, licenses, support, and the annual escalator. The first year price is the least useful number in the proposal.
• Ask what happens to your data if you leave: in what format, at what cost, on what timeline, and get the answer into the contract rather than the sales conversation.
• Ask which tasks your own staff will be trained and documented to perform, and which will always require the vendor. The second list is your future dependency.
• Ask for references at cities of your size, then ask those references about schedule, responsiveness, and what they would do differently.
• Ask how the partner will explain the work to your council. Someone who cannot write two clear paragraphs for a staff report will not be useful to you in the council chamber.

A partner who answers these plainly is telling you something about how the project will go. One who treats them as obstacles is telling you the same thing.

HQT does this kind of work for municipal governments: inventory and roadmap support, independent review before award, integration between systems a city already owns, practical security work, and documentation written so that city staff and the council can both follow it.

Frequently asked questions