An IT strategy that won't end up in a drawer: what should it actually contain?

This post is for people who commission, approve or later have to execute a strategy: secretaries and treasurers in public offices, presidents and board members of municipal companies, CEOs and CFOs of private firms, and IT managers who want the document to finally help them argue their case for budget. I wrote separately about typical mistakes in local-government strategies in the post IT strategy in JST: the most common mistakes. Here I focus on what the document itself should contain.

Why strategies end up in a drawer

From what I've seen in both public and private organisations, a strategy is rarely wrong on substance. It ends up in a drawer because it cannot be used at the moment the first concrete decision has to be made.

• It starts with a vision, not an inventory. Nobody checked what systems, contracts and dependencies already exist, so the plan diverges from reality at the first purchase.
• It describes goals, but not sequence. Everything is important, so nothing comes first.
• There's no money. Without a link to the budget, the strategy and the financial plan live separate lives.
• It doesn't change how things are bought. Successive systems keep being purchased the old way, based on vendor offers rather than the organisation's own standards.
• It has no owner. The document was adopted by resolution or board decision, and that's where its life ended.
• It's written in IT language. The board and the council don't see answers to their own questions in it: how much, what for, what happens if we do nothing.

Seven elements of a strategy that actually gets used

1. Current state. A register of systems with owner, contract, licence, cost and end of support, a map of processes and integrations, a risk register. Without this, every subsequent point is guesswork. This is a task for an inventory.
2. Target architecture. A simple picture of how registers, processes, integrations and access relate to one another. This isn't about technical diagrams, but about answering which systems are central and which merely support them, where data should originate, and which systems should inherit it.
3. Standards. A handful of rules binding on every purchase: how we assign permissions, what the interface for staff should look like, how we document requirements, what data rights we must retain, which language (standard) we use to describe processes, how we protect our ability to exit a vendor relationship.
4. A roadmap split into obligation and investment. Separate what we must do because the law or a contract requires it (in public offices, for example, an EZD-class system — electronic document and case management system, KSeF — the Polish National e-Invoicing System, e-Doręczenia — Polish e-Delivery) from what we do because it pays off. With sequence and justification. For example: once an invoice has been downloaded from KSeF, it can be saved to the case file, but by law it should also undergo substantive approval, formal and accounting verification, and conclude its journey with an automatic entry into the financial-accounting system.
5. A budget split into investment and maintenance. Maintenance costs grow with every new system and should be visible before the purchase decision is made. More on this in the post on total cost of ownership. Keep in mind that implementation is typically a one-off investment (CAPEX), but from the perspective of budgeting, continuity and security, things like servicing and updates (OPEX) recur year after year.
6. Procurement rules for systems. When an inventory or pre-purchase analysis is required, who reviews the offer, which clauses must appear in the contract. I covered some of this in the post on an SWZ without vendor lock-in.
7. Owner and review rhythm. A specific person on the management side should review the strategy and the cost of ownership, at least once a year alongside the budget process, following a clear principle of cyclical review.

A practical example

Wodociągi Miejskie, a utility company owned by a mid-sized municipality, was preparing its IT procurement plan for the following year. Initially, the IT department requested the simultaneous replacement of office computers, purchase of a new monitoring system, and modernisation of the network infrastructure. However, the board asked for evidence of which expenses were most urgent from the standpoint of continuity of water supply.

The company began with an inventory: it listed devices, software, network connections and service contracts, then mapped them to specific processes — from customer service to control of the water treatment plants. It turned out that some of the devices mediating communication with the treatment stations were close to the end of their support period, and the connection documentation didn't cover all locations. At the same time, most of the office computers could keep running without any meaningful impact on core services.

On this basis, the purchase sequence was revised. First, the plan provided for organising and securing connections to the technological facilities and replacing the devices whose failure could hinder oversight of water supply. Next, backups and monitoring were scheduled to be supplemented. Replacement of some office computers was pushed to a later stage.

In front of the board, the IT department no longer justified its budget with the general statement that "the equipment is old." It showed the chain: specific infrastructure component → process it supports → consequence of failure → proposed purchase. This allowed the board to approve spending in stages and to explain to the supervisory board why priority had gone to infrastructure tied to service continuity rather than to the office equipment most visible to staff.

When an independent advisor is needed

A strategy can be written in-house if someone in the organisation has the time and sees the whole picture. External support is useful when the current state hasn't been documented, when the strategy must serve as the basis for defending the budget before the council, the owner or a parent entity, when several regulatory obligations are approaching at once, or when the board and IT see priorities differently and someone is needed to translate one perspective into the other.

I prepare digitalisation strategies and target architectures based on an inventory: with a roadmap, standards, procurement rules and a budget that can actually be defended.