Digitisation Strategy for the Public Sector: What It Needs

I have sat on both sides of this. I have advised on digitisation strategy in public sector and international organisations, including consultancy work in the UN system, and I have been on the receiving end of strategy documents inside a national statistical agency, where somebody has to actually build the thing. The gap between those two chairs is where most public digitisation programmes quietly miss.

This is not a criticism of strategy. It is a criticism of strategies that describe a destination without describing the ground.

I run Mark Logic Development from Belmopan and I manage Systems Development and Data Processing at the Statistical Institute of Belize. Small teams, real constraints. That turns out to be a good place to learn what a digitisation plan actually needs, because there is nowhere to hide a bad one.

Start with the process, not the platform

The first question in any digital transformation plan should not be which system to buy. It should be: what is the process, who owns it, and does it make sense on paper before anyone writes code?

I have seen forms digitised faithfully, including the parts that existed only because a filing cabinet was three metres from a desk 20 years ago. Digitising a broken process gives you a faster broken process, with an audit trail proving it.

Before procurement, I want to see:

• A written description of the current process, including the informal steps people actually perform.
• The legal or regulatory basis for each approval, signature and retention rule.
• The exception paths, because exceptions are where systems break.
• The volume: how many records per day, per month, at peak.
• Who is accountable for the data after the project team disbands.

That last point is the one most often skipped, and the one that decides whether the system is alive in five years.

Why do public sector digitisation projects stall?

In my experience the causes repeat. The scope was written by people who will never use the system. The data was assumed to be clean. The procurement cycle took longer than the political window. The vendor delivered against a specification rather than against a process. Or the one person who understood the system transferred to another department.

None of those are technology problems. They are planning and governance problems that technology then inherits.

Data governance is the strategy, not an annex

Most strategy documents put data governance in an appendix. It belongs in chapter one.

A public institution is, functionally, a data custodian. Before you modernise anything, you need decisions on classification, retention, access, quality standards and who is permitted to change a record after it is approved. In statistical work this is bread and butter: confidentiality obligations, disclosure control, versioning of published figures. In other agencies the same discipline is often missing, and it shows up later as an audit finding.

Practical governance looks unglamorous:

• A data dictionary that is maintained, not written once for a report.
• Reference data with a single owner. Districts, villages, ministries, currency codes.
• Change logs on every table that matters, with user, timestamp and prior value.
• A documented backup and restore procedure that somebody has tested this year.
• Clear rules on who may export a full dataset, and how that export is recorded.

If you cannot answer an auditor's question about who changed a figure and when, you do not have a system. You have a database with a web page in front of it.

Procurement reality: what you can actually buy

A digitisation strategy that ignores procurement rules is fiction. Public procurement has thresholds, tender periods, evaluation committees and approval chains. Those constraints shape what is buildable more than any architecture diagram.

A few things I plan around.

Licence costs are recurring and rarely fully budgeted. A three-year licence that renews at a different exchange rate becomes a problem for a director who did not sign the original contract.

Specifications written around a single vendor's feature list produce a single bid. Write them around outcomes and data ownership instead: export formats, API access, documented schema, exit conditions.

Escrow and source access matter. If the supplier disappears, or the relationship ends, what do you hold? I have inherited systems where the answer was a compiled binary and goodwill.

Phased contracts beat big-bang delivery. Something small in production teaches more in three months than a year of requirements workshops.

Should a public institution use open source?

Where it is defensible, yes. I build a lot on PostgreSQL, Linux, pfSense and Proxmox, and I also work daily in Oracle APEX and PL/SQL, which is proprietary and entirely appropriate for certain government estates. The question is not ideology. It is total cost, available skills, support obligations and whether the institution can operate the thing without a permanent external dependency.

Open source is defensible when you have or can build the in-house capacity to run it. It is not defensible when it becomes an unfunded mandate for one overworked systems officer. Be honest about which situation you are in.

Staff capacity is the binding constraint

Every strategy assumes a team. Look at the actual team.

In small administrations one person may cover networks, servers, user support and reporting. Training budgets are thin. Salaries compete with the private sector and with emigration. A design that requires four specialists to operate is a design that will degrade.

So I build for the staff who exist, not the staff in the organogram. Fewer moving parts. Standard stacks. Configuration in the database rather than scattered across servers. Deployment steps written down as commands anyone can run, not knowledge held in someone's head.

How do you build systems that survive staff turnover?

Assume the person who built it has left. Then check:

• Is there a README that gets a new developer to a running local environment in an afternoon?
• Are credentials in a managed store rather than in someone's mailbox?
• Are business rules in one place, named clearly, rather than duplicated across triggers, application code and spreadsheets?
• Can a report be reproduced from raw data, not just from a cached output?
• Does the handover documentation include the ugly parts, the known workarounds and the reasons behind them?

Systems that pass those checks survive turnover and audits. Systems that do not become the reason for the next strategy document.

Practical takeaway

If you are drafting or reviewing a public digitisation plan, keep it short and test it against five questions.

1. Have we written down the process, exceptions included, before choosing technology?
2. Who owns each dataset, and what are the retention, access and quality rules?
3. Does the procurement approach protect data ownership and an exit path?
4. Can the staff we actually have operate this on an ordinary week?
5. Would this survive the departure of its most knowledgeable person?

A strategy that answers those honestly will be shorter than most, and considerably more useful.

If you are working through this in a ministry, agency or development programme and want a second opinion from someone who has built and inherited these systems, you are welcome to get in touch through mark-dev.com.