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

This post is for people who commission, approve or later have to implement a strategy: secretaries and treasurers (skarbnik) in public offices, presidents and board members of municipal companies (spółka komunalna), CEOs and CFOs of private companies, and IT managers who want the document to finally help them in budget conversations. I wrote separately about typical mistakes in local-government strategies in 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 the substance. It ends up in a drawer because it can't 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, not sequence. Everything is important, so nothing comes first.
• There's no money behind it. With no link to the budget, the strategy and the financial plan live separate lives.
• It doesn't change how things are bought. Systems keep being purchased the old way, based on vendor offers rather than the organisation's own standards.
• There's 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 find 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, and a risk register. Without this, every subsequent point is guesswork. This is a job 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 support them, where data should originate, and which systems should inherit that data.
3. Standards. A handful of rules that apply to every purchase: how we grant permissions, what the interface for staff should look like, how we document requirements, what data rights we must retain, what language (standard) we use to describe processes, and how we secure our exit from a vendor relationship.
4. A roadmap split between obligation and investment. Separate what we must do because the law or a contract requires it (in public offices, for instance, an EZD-class system, KSeF, e-Doręczenia) from what we do because it pays off. With sequencing and justification. For example: once an invoice has been downloaded from KSeF, we can file it in the case record, but by law it should also receive substantive approval, formal and accounting verification, and end its journey with an automatic entry into the finance and accounting system.
5. A budget split between investment and maintenance. Maintenance grows 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. Bear in mind that implementation is usually a one-off investment (CAPEX), but from the point of view of the budget, business continuity and security, it's the servicing and updates (OPEX) that matter — recurring year after year.
6. Procurement rules for systems. When an inventory or pre-purchase analysis is needed, who reviews the offer, what clauses must appear in the contract. I covered some of this in the post on SWZ without vendor lock-in.
7. An owner and a 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, following a clear principle of cyclical review.

A practical example

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

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

On this basis, the purchasing sequence was changed. First, the company planned to secure and put in order the connections to technological facilities and replace devices whose failure could hamper oversight of water supply. Next, it planned to fill gaps in backups and monitoring. Replacement of some office computers was pushed to a later stage.

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

When an independent adviser is needed

A strategy can be written in-house if someone in the organisation has the time and the overview to do it. External support helps when the current state hasn't been documented, when the strategy needs to serve as the basis for defending the budget before the council, the owner or head office, when several regulatory obligations are landing 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 be defended.