Technology Strategy & Roadmaps

What this covers

A technology roadmap sets out what an agency will replace, modernize, or build over the next several years, in what order, and at what cost. HQT develops roadmaps grounded in the agency's strategic plan, its current systems, and its realistic capacity to change.

Typical activities

• Current-state assessment of applications, infrastructure, staff, and spending
• Interviews with department leaders about service goals and pain points
• Prioritization of initiatives by value, risk, and dependency
• Cost and staffing estimates by fiscal year
• Governance model for reviewing and updating the roadmap
• Presentation materials for executives and governing bodies

What you receive

A roadmap document with prioritized initiatives, multi-year cost projections, a governance process, and briefing materials.

Considerations for public agencies

Roadmaps must survive budget cycles and leadership changes. We structure them so that each year's initiatives stand on their own and the plan can be revised without starting over.

When a roadmap is the right next step

Roadmap work is worth its cost when a decision is waiting on it. Agencies usually reach that point when:

• Finance asks for a multi-year technology number and no one can produce one with a defensible basis.
• A core system is approaching vendor end of support, or the vendor has announced a successor on a different platform.
• Departments buy their own subscriptions and the agency cannot say what it pays for or when terms renew.
• Several projects compete for the same few integration and data staff, so sequencing goes to whoever asks most persistently.
• An audit finding, an after-action review, or a grant condition asks for a documented technology or cybersecurity plan.

The opposite case matters too. If the agency already knows which system it is replacing and has funding identified, the next step is requirements and a solicitation rather than a roadmap.

Where roadmaps fail

Weak roadmaps tend to fail in predictable ways:

• A maturity assessment scored against a model, with no decisions attached to the scores.
• Initiatives that track a single vendor's product catalog.
• Everything rated high priority, which leaves the real sequencing to someone else later.
• Cost figures with no stated basis, which travel into budget documents as though they were estimates.
• Staffing assumptions the agency cannot meet and has no approved position to hire against.

Two habits prevent most of that. Write the estimating basis next to every number, whether it is a vendor quote, a comparable award, a published price list, or a stated parametric method. And let precision fall off by year: year one specific enough to build a budget request from, later years deliberately coarser, since false precision in a distant year gets read as a commitment. A plan that names what the agency will retire or stop doing also holds up better than one that only adds, because staff capacity binds more often than money.

Fitting the roadmap to plans, vendors, and the budget office

Few agencies start from nothing. There is usually a strategic plan, a capital improvement plan, vendor product roadmaps, an incumbent integrator, and sometimes a cybersecurity plan written for a grant program. The roadmap should reconcile with those rather than replace them, so each initiative names the strategic plan goal it serves and each cost line reaches the budget office in the form that office already uses.

Vendor roadmaps are an input with a caveat, since announced dates move. Separate what a contract or written support commitment guarantees from what a vendor has only announced, and plan against the former. Purchasing lead time belongs in the sequence too, because an item the agency can buy through an existing statewide or cooperative agreement lands differently on the calendar than one needing a full solicitation.

Bring finance in early. Moving from purchased licenses to subscriptions can change which fund pays and whether the cost is treated as capital or operating, and governmental accounting standards address subscription arrangements for information technology separately from purchased software. Your finance office can say how that applies to the years the roadmap covers.

What to require in the scope, and how to judge the result

Terms worth writing into a solicitation for roadmap work:

• Editable native source files for the roadmap, the cost model, and the underlying system inventory, with ownership to the agency. A PDF alone is not something staff can maintain.
• The estimating basis documented for each initiative, so a reviewer can test a number rather than accept it.
• Coverage stated as departments interviewed, systems inventoried, on-site days, and briefings to the governing body, so level of effort is not left to interpretation.
• A decision, made before the solicitation is released, on whether the firm writing the plan may bid the implementations it recommends.

Judge the result about a year later. Did the budget request cite the plan, and did funded work match the sequence? Can someone other than the author update the cost model? Did year one estimates hold when real prices arrived? If departments still buy around the plan, the governance section was written but never adopted.

Working with HQT on this

HQT scopes this kind of work as a fixed-price or time-and-materials engagement with a written statement of work, named staff, and a defined acceptance process. We are candid about what we can take on and prefer a well-run project to an oversized one. Contact us to discuss a requirement, a draft scope, or an upcoming solicitation.

Frequently asked questions