Why Government Software Projects Fail — and What Actually Works

We've delivered production systems for four Czech ministries. Before each project started, we spent time understanding what the previous vendor had built — and more importantly, why it hadn't worked. The causes were remarkably consistent.

Requirements written by procurement lawyers, not the people who would use the system. Acceptance criteria focused on document compliance rather than functional quality. Vendors who priced to win the tender, not to deliver sustainably. And handovers that left no one knowing how to operate what had been built.

These are not Czech-specific problems. They're structural features of how government IT procurement works almost everywhere. The question isn't whether they'll appear on your project — it's how you design around them.

Czech public procurement law requires evaluating bids on price and quality criteria. In practice, 'quality' is often operationalized as certifications held and reference projects listed — both of which a vendor can optimize for without being genuinely capable.

The cheapest bid wins more often than not, especially in smaller contracts. And the cheapest bid is almost always cheap for a reason: stripped scope, junior teams, or a plan to recover margin through change requests once the contract is signed.

The vendors who understand this dynamic build their business model around it. They win the tender, deliver the minimum viable contract, then generate revenue through the inevitable scope changes that follow. The client gets a system that technically passes acceptance — but can't actually support the use case it was built for.

The most successful government projects we've been part of started before the formal procurement process. The authority had a genuine technical partner helping them define what they needed, structure the requirements, and understand what good delivery looks like.

This is called pre-market consultation (předběžné tržní konzultace) in Czech procurement law, and it's explicitly permitted. Vendors who participate in this phase understand the real problem. Vendors who show up only at the tender don't.

The authorities that invest in this process get better tenders, better bids, and better systems. The ones that skip it tend to get the standard result.

WCAG 2.1, NIS2, GDPR, ISO 27001 — these are minimum requirements, not differentiators. A system that meets them is doing the baseline. A system that actually works for the people using it is doing something more.

We see a lot of government systems that are technically compliant and practically unusable. The acceptance testing was done by a team that ran automated checks against a checklist. Real users were never involved. Accessibility passed the audit but failed the actual test.

The fix is not complicated. You test with real users. You include people with disabilities in your testing process. You treat the WCAG criteria as design inputs, not post-hoc filters. But it requires a vendor who thinks that way — and a procurement process that selects for it.

The handover problem is underrated. A vendor delivers a system, hands over documentation that nobody fully understands, and moves on. Eighteen months later, a security patch needs to be applied and no one knows how. A performance issue appears and there's no one to call.

We operate everything we build under long-term service contracts. Not because it's more revenue — it's often more work than we'd like — but because it's the only way to close the loop between what you built and how it performs in the real world.

The best government systems we've seen are ones where the vendor stayed. The worst are ones where the vendor was contractually required to leave.