
Key points
Zdjęcia ilustracyjne
This post is for district secretaries and district heads (starosta), as well as for treasurers (skarbnik), with whom the budget is agreed. A district office has its own specifics: many departments with their own domain-specific systems and national registers, organisational units of the district, and, under the National Cybersecurity System Act (KSC), status as a key entity. For this reason, order in IT here is not merely a matter of convenience, but also of obligation.
Why it's harder in a district office
A district office handles matters that rely on systems and registers run by various suppliers and institutions: vehicle registration, the land and property register, building matters, finance, HR and the registry office. Each department knows its own system, but rarely does anyone see the whole picture: which systems exchange data with each other, who owns which contract, when the vendor's support ends, and what happens if a supplier raises its price.
From conversations with district offices, I see several recurring causes:
- Knowledge is scattered. The IT specialist knows the infrastructure, departments know their own applications, suppliers know their own contracts. No one has the full picture.
- Obligations arrive separately but land on the same people. The KSC, KSeF, e-Doręczenia, the Central Register of Contracts and the forthcoming EZD-class system requirement are, in practice, changes to the same document workflow.
- The IT team is small. Two or three people maintain the hardware, the network and the office's day-to-day operations. They have no time to run the selection of a major system.
- Decisions are made under deadline pressure. By then there is no time left for comparing offers, and the district office negotiates from a weaker position.
Step 1. Inventory of systems and contracts
The first step is not choosing a system, but listing what the district office already has. A good inventory answers simple questions: which systems operate in each department, who owns them, who holds the contract and until when, how much maintenance costs, which systems exchange data with each other, and where the single points of failure are, meaning places where the failure of one element, or one person leaving, brings the office's work to a halt.
The inventory takes 2–6 weeks, falls below the public-procurement threshold, and requires no access to residents' data. It concludes with a one-page summary for the district head (starosta) and the District Board, plus a full set of documents used by every subsequent step. Details: IT systems inventory.
Step 2. A one-page plan of obligations
Based on the inventory, a one-page document of obligations and deadlines is drawn up. For each obligation: who is responsible, what the next step is, and by when.
- An EZD-class system. A forthcoming obligation; according to clarifications from the Ministry of Digital Affairs in October 2026, the deadline has been pushed back to 2029 at the earliest, and the regulations are still in draft. It is worth confirming, as the schedule is sometimes updated.
- KSC. The district office is a key entity under the National Cybersecurity System Act (KSC); some obligations carry their own deadlines. I describe where to start in the post The KSC Act in a district office.
- KSeF and e-Doręczenia. These change the handling of invoices and correspondence, and so touch the same processes as an EZD-class system.
- The Central Register of Contracts. This requires knowledge of contracts that the inventory gathers in any case; I describe it step by step in the post The Central Register of Contracts.
A plan of obligations works like a renovation schedule for a building still in daily use. You cannot replace the wiring in every room separately and independently. You need to know what runs behind which walls, and sequence the work so the office keeps operating throughout.
Step 3. A budget that will hold up before the District Council
An IT budget presented as a single line item is hard to defend. It is easier when split into a regulatory obligation (what must be done under the law) and an investment (what the district office does to work more effectively), with the cost of inaction set out alongside: what happens if nothing is done. The draft budget is prepared in autumn, making this the best moment to put together such a breakdown. More in the post The IT budget before the Council.
Step 4. A digitisation lead without a new post
Every major project needs a lead: someone who keeps an eye on the whole picture, the deadlines and the decisions. In a district office without an IT director, this is usually the secretary, though they rarely have the time or the experience to run the selection of major systems. Rather than creating a new post, this can be supported with a part-time external advisor: someone who sits down with the secretary and the head of IT weekly or monthly, keeps a register of projects and risks, helps with supplier negotiations, and independently assesses their proposals. The decisions remain with the district office.
In this arrangement, the head of IT is an ally, not a target of oversight. A systems register and a clear budget split are the strongest arguments for the resources the IT specialist has usually been requesting for a long time.
A case from practice
I have seen the same mechanism at work in a large local government unit (JST), where the office's partner was the head of the IT department. The office had accumulated a growing number of unconnected applications, each meant to support the work of individual departments. We began with a basic inventory of needs and existing systems. On this basis, we built a roadmap of actions leading to cost optimisation for subsequent projects, and then the foundation of an application strategy, translated into technology requirements: an optimal total cost of ownership (TCO), reduced risk of vendor lock-in, and a plan for transferring knowledge from suppliers to the in-house IT team.
The office adopted standards for process modelling, for transferring knowledge between suppliers, and for documenting requirements and system architecture, and planned its application strategy ten years ahead. One thing was most surprising: organisational units with their own budgets and authority were running parallel IT initiatives of their own. They were building silos and raising maintenance costs, even though from the outset all of this could have been carried out within a single, coherent strategy. Without the inventory, no one would have seen it.



