What belongs in a technology strategic plan, and how to keep it current

Reference article · 5 min read

A technology strategic plan earns its keep when people outside the IT department read it and make decisions from it. Plans that run to hundreds of pages or inventory every server sit unopened until the next rewrite. A plan short enough to read in one sitting, with a few clear goals and initiatives tied to the budget years in which they would be funded, gives department heads, finance staff, and the governing body something they can use.

The plan is a decision document, not an asset register. Some states ask agencies to file a technology plan with a central technology office, and some grant programs ask applicants to show that a project fits a broader strategy. Those expectations vary and change, so confirm them with the office that collects the plan or with the grant terms.

Current state, written honestly and briefly

The current state section establishes shared facts. Keep it short and push detail into the systems that already hold it: the asset inventory, the data catalog, the contract file.

• Systems by function, not by vendor. Group what you run by the service it supports: permitting, payroll, dispatch, case management.
• Contract and lifecycle horizon. Which major agreements come up for renewal in the planning period, and which products are approaching end of support.
• Known constraints. Integration gaps, unsupported versions, manual workarounds, and places where one person holds all the knowledge.
• What people experience today. A plain description of the friction residents and staff encounter, without blaming a team.

Guiding principles and a small set of goals

A principle that never rules anything out is decoration. Useful principles settle arguments: prefer configuration over custom code, look for an existing shared or statewide service before standing up a new one, meet accessibility requirements before launch rather than after.

Keep goals to a handful, each stated in one sentence, each about a service outcome rather than a technology. "Residents can complete common permit applications without coming to the counter" is a goal. "Migrate to a modern platform" is an initiative wearing a goal's clothing. Name an owner for each goal by role, so the plan survives turnover.

The initiative roadmap, mapped to budget years

For each initiative, state the problem, what changes and for whom, the dependencies, and the budget year in which funding would be requested. Separate one-time from recurring costs, and operating from capital requests, since they travel different approval paths.

Resist precise cost figures; they age badly and get quoted back years later. Give an order of magnitude, say what the estimate rests on, and note when a real number will exist, such as after market research. Mark which initiatives depend on a grant award or on a prior one finishing. Add a short list of what the agency considered and is not doing this period, with a sentence on why, so the same proposals stop returning as surprises.

Staffing and skills implications

Every initiative creates work after go-live that someone absorbs. For each roadmap item, say who will operate the result: existing staff, a new position, a managed service, or the vendor under support. If the plan assumes a position that is not funded, say so plainly, because that belongs in the budget conversation.

List the skills the roadmap requires and name the gaps: integration work, data engineering, security operations, product ownership, contract administration. Note which you will close by hiring, by training staff, or by sourcing the work. Recruiting and classification timelines in public agencies are often long, so treat a hiring dependency as a schedule risk.

Measures that someone actually reports

Choose few measures, tied to the goals, and favor data the agency already collects. State the baseline where one exists, and say plainly when it does not. Name the office that reports each measure and where it appears, such as a quarterly report to the governing body. A measure with no named reporter and no publication venue will not be maintained.

The annual refresh

A full rewrite every few years, with a light refresh in between, keeps the document current without consuming a quarter of the year. Anchor the refresh to the budget calendar so its output arrives before departmental requests are due.

1. Mark every initiative complete, underway, deferred, or dropped, and record the reason for each deferral.
2. Update only the current state passages that changed, including contract expirations and staffing.
3. Re-check the assumptions: grant availability, vendor product direction, leadership priorities, and regulatory changes.
4. Add new initiatives, retire finished ones, and re-sequence what moved.
5. Republish with a version date and a one page summary of what changed.

Keep the plan in a format staff can edit, and if you post it publicly, confirm the posted version meets your accessibility obligations.

How to start, and what to ask if you bring in help

Start by collecting what exists: recent budget requests, audit findings, risk registers, prior plans, and service tickets grouped by theme. Interview department heads about their service problems rather than their system preferences. Draft the goals before the initiative list, or the list becomes the plan.

If you engage outside help, ask who will write the document and conduct the interviews, ask for a sample plan of similar scope, and ask how the firm avoids steering agencies toward products it also sells or implements. In the contract, require editable source files rather than a locked document, confirm the agency owns the work product, require an accessible version if the plan will be published, and require that the deliverable include the refresh procedure staff will run between engagements.

HQT is a technology and software company whose advisory and systems engineering work includes technology planning and roadmap development for public agencies.

Frequently asked questions