Why government IT projects struggle, and how to improve delivery
Six recurring delivery risks in public-sector software: ambiguous scope, procurement trade-offs, ownership, handover, user acceptance and maintenance.
By UNIXDEV Team · 3 min read
Original published · English edition
A public-sector IT project can meet its document checklist and still disappoint the people who use it. The important question is whether the procurement and delivery process gives the team a way to resolve uncertainty before launch.
Investment is not the same as a usable service
Digital-government indicators describe broad national progress; they do not measure the success of a particular software contract. Evaluate a project through its intended users, service outcomes and operational readiness. Avoid using a national ranking as proof that an individual delivery approach works.
Six risks to address early
1. Requirements that remain open to interpretation
A long specification is not necessarily a testable one. Map the workflow, roles, exceptions and expected results. Record open questions, assumptions and acceptance criteria. When a requirement changes, show the impact on scope, cost and timing.
2. Comparing price without comparing scope
Procurement has to follow the applicable rules. Within those rules, make testing, migration, documentation and support requirements visible so proposals can be compared on the same basis. A low initial amount says little about lifetime cost if essential work is excluded.
3. No technical owner on the customer side
The supplier needs someone who can coordinate stakeholders, resolve conflicting requirements and approve technical decisions. A committee can provide oversight, but day-to-day ownership must still be clear.
4. An incomplete exit or handover plan
Agree source-code rights, repository access, build instructions, licenses and data-export arrangements before signing. Ownership in a contract does not guarantee that the receiving team can build or operate the application.
5. User acceptance without representative users
Invite the people who do the work to test realistic cases. Include difficult records, permission boundaries, integration failures and recovery. A successful demonstration is not a substitute for agreed acceptance evidence.
6. No budget for operation after launch
Hosting, updates, monitoring, incident response, backups and future changes need responsibilities and funding. Make the distinction between warranty fixes, maintenance and new scope explicit.
An illustrative permit-service project
Imagine an agency replacing a paper permit process. A broad instruction to “move applications online” leaves questions about identity, attachments, review stages, fees, exceptions and status notifications. If those are discovered only during acceptance, the delivery team has little room to respond.
A better starting point is one complete application journey, with roles, sample records and acceptance checks. Deliver and review that journey before expanding. This is a hypothetical scenario, not a named customer case or a measured outcome.
Make delivery reviewable
Break the scope into increments that can be demonstrated and accepted under the agreed procurement arrangement. Keep decision records and trace requirements through implementation and tests. Agree how changes are authorized; agile practices do not remove contractual responsibilities.
Specify service coverage, escalation, recovery expectations and maintenance boundaries from the start. Review the operating plan with the team that will support the system, not only with the procurement team.
Questions before signing
- Who decides when requirements conflict?
- What evidence makes a deliverable acceptable?
- How are changes estimated and approved?
- What code, data, documentation and access are handed over?
- Who owns deployment, backup testing and incidents after launch?
- What is included in support, and what is additional work?
UNIXDEV’s custom software service starts with the workflow and delivery boundaries. For national context, see the UN e-Government Knowledgebase; use project-specific evidence for project decisions.