Specialist technology and software for state and local government info@hqt.orgCommunitiesGlossarySearch

Who we work with

Technology partner for county administrators and CIOs

For county executives accountable for enterprise coordination, layered compliance, and major system replacements across semi-independent departments.

A county is one legal entity and several practical organizations. In most counties the sheriff, assessor, district attorney, clerk recorder, and treasurer tax collector hold their own elected offices. Health and human services runs on categorical state and federal money with reporting obligations that have little to do with the general fund. Public works, the library, and special districts have their own revenue streams and their own vendors. Each of those departments has bought its own software, signed its own maintenance agreements, and built a relationship with an account manager who has been calling them longer than you have held your position. Your formal authority over most of that is budget, policy, and persuasion.

Accountability does not follow that structure. The board asks what the county spends on technology, whether the replacement program will be ready, and whether the county is secure, and it asks in a public meeting with the agenda already posted. The cyber insurance application wants a single enterprise answer about multi factor authentication, backups, and logging. The single audit looks across federal awards regardless of which department administers them. Meanwhile the system nobody has documented since its author retired has a data conversion problem, the vendor for a twenty year old platform has announced an end of support date, and the next agenda deadline is close enough that the item either goes forward now or waits a cycle.

What makes this hard

  • Departments purchase technology independently using their own categorical funds, so central IT often learns about a system at renewal, at an integration request, or after a security incident.

How HQT helps

  • Build an enterprise application and vendor inventory across departments: what each system does, who owns the data, hosting model, integration points, contract and renewal dates, and where two departments pay for the same capability. The output is written so it can be read by a board, not only by IT staff.

How engagements usually start

Work with a county administrator or CIO rarely starts with a product decision. It starts with a question the board has already asked in public and that no single system can answer: what the county spends on technology across all departments, why a project slipped, or how exposed the county is after an incident somewhere else made the news.

The first useful step is usually an inventory. Not a license spreadsheet, but a picture of what each department runs, who owns the data, which contract it sits under, when it renews, what it connects to, and which compliance regime governs it. That inventory is what turns an enterprise conversation from an argument about control into a discussion of duplication, risk, and renewal dates that are already approaching.

From there, work tends to branch in one of three directions. Some counties need the compliance picture first, because an audit finding, an insurance renewal, or a state reporting requirement is forcing the issue. Some need procurement support, because a replacement is coming and the requirements have not been written. Some need integration work, because the departmental systems are staying and the enterprise reporting still has to exist.

Scope the first piece of work so it produces something you can put in front of the board inside one budget cycle. An inventory, an assessment, or a working integration gives you evidence for the larger request. A multi year program with nothing visible in year one is hard to defend when the board membership changes.

What to ask any technology partner

Ask how they will work with departments that do not report to you. Elected officials run several of your largest systems. A partner who assumes central authority will stall, and you will spend your own credibility unsticking them.

Ask which compliance regimes they have actually read. The CJIS Security Policy, HIPAA, 42 CFR Part 2, IRS Publication 1075, and PCI DSS overlap on access control, logging, and encryption, but they differ on audit, disclosure, and personnel screening. A partner should be able to say which controls can be delivered once as a shared enterprise service and which have to stay inside a department boundary.

Ask what the county owns at the end. Source code, configuration, documentation, data in a documented format, and administrative credentials should be county property, written into the contract rather than left to goodwill. Ask what a clean exit looks like before you sign the entry.

Ask who will do the work and whether your staff can run it afterward. Knowledge transfer and documentation belong in the deliverables list, not in the closing meeting.

Ask for reporting in the format you already use upward. If you brief the board on a fixed cycle, project status should assemble into that briefing without a translation step.

Where HQT fits

HQT works on enterprise application inventory and assessment, integration between county systems, compliance control mapping, requirements and procurement support, and independent technical review on large replacements.

Frequently asked questions

Our departments buy their own systems, and several report to elected officials rather than to me. Can an enterprise assessment actually work here?

It can, if it is framed as information rather than control. An inventory that shows contract renewal dates, overlapping spend, shared dependencies, and where compliance obligations sit is useful to department heads too, because it answers the same questions their auditors and state program monitors ask. The assessment should record what each department runs and why it runs it, not grade departments against each other. Departments cooperate with work that gives them something they can use in their own budget request.

We have a major system replacement coming. What should happen before the solicitation goes out?

Write requirements from how the work is actually done today, including the workarounds staff have built around the current system, and inventory the data you will have to convert. Decide in advance what the contract will say about data portability, ownership of configuration and custom code, interface documentation, and what happens at termination. Build a cost model that separates one time implementation from recurring subscription, support, and integration maintenance, so the board sees the full life cycle rather than the first year.

How do we handle compliance regimes that pull in different directions?

Map them to a single control catalog and note where each regime is stricter than the baseline. CJIS, HIPAA, 42 CFR Part 2, IRS Publication 1075, and PCI DSS overlap heavily on access control, logging, encryption, and incident response, but diverge on audit, disclosure, and personnel screening. The practical result is that some controls become shared enterprise services while some data stays inside a department boundary under its own tighter rules. Verify specific requirements and effective dates against the current version of each standard, because several are revised on their own schedules.

How do we keep a multi year program defensible when the board changes?

Break it into phases that each deliver something usable and reportable within a budget cycle. Keep a written decision record with the reasoning, because a new board will reopen questions the previous board considered settled, and the answer should not depend on who is still in the building. Report the same small set of measures every time so the board sees a trend instead of a new argument.

Our IT staff are already stretched. Will this create more work for them?

Some, and it should be planned for rather than discovered halfway through. Assessment and integration work needs access, context, and review time from the people who know the systems, usually a few hours a week from a small number of staff. Knowledge transfer, runbooks, and documentation should be contract deliverables with acceptance criteria, so the county ends up less dependent on outside help rather than more.

Get in touch

Have a project or a solicitation coming up?

Talk with an HQT engineer. We respond to agency, corporate, and partner inquiries promptly.