Common Custom Software Mistakes Government Agencies Make — and How to Avoid Each One
Government IT leaders often repeat the same pitfalls when commissioning bespoke systems. This guide walks through eight frequent errors — from vague requirements to skipped user testing — and shows how to sidestep them with phased delivery and real integration.
Starting without a signed, prioritised requirements document
A ministry team once asked for a case-management system "that handles everything." Three months later the vendor delivered a tool that tracked correspondence but could not route approvals to the permanent secretary's office. The gap? No one had written down which workflows were mandatory for launch and which could wait.
The mistake: Treating requirements gathering as a series of conversations instead of a documented, ranked list that both the accounting officer and the technical lead sign off.
How to avoid it: Before any code is written, produce a one-page scope sheet that lists every process the first phase must support, each labelled "must have", "should have" or "later". Attach it to the procurement file so auditors can trace every feature back to an approved need. When new requests arrive — and they will — they go through the same sign-off, not a hallway chat.
Automating a broken paper process instead of redesigning it
A district local government digitised its leave-application form field-for-field. Staff still printed the PDF, walked it to the HR officer for a wet signature, then scanned it back. The digital version added zero value because the underlying rule — "HR must physically sign" — never changed.
The mistake: Confusing digitisation with transformation. Moving a form online without questioning why each step exists simply preserves waste in a new medium.
How to avoid it: Run a two-day process-mapping workshop with the people who actually do the work. Draw the current flow on a wall, then ask "what happens if we remove this step?" for every box. Only the steps that survive that question get built. In the leave example, the rule became "HR approves in the system" and the print-scan loop disappeared.
Underestimating change management and user adoption
A health-sector agency launched a new facility-reporting portal. Nurses at 40 health centres received a one-hour Zoom demo. Two months later, 60 per cent of reports still arrived via WhatsApp because the portal required a desktop browser and most nurses only had phones.
The mistake: Assuming training is a single event and that users will adapt their habits to the software.
How to avoid it: Build adoption into the delivery plan. Phase one ships a mobile-first interface because that matches the hardware nurses already carry. Phase two adds the desktop analytics dashboard for supervisors. Assign a "champion" at each facility — a respected peer, not an IT officer — who gets early access and a small airtime allowance to help colleagues. Track weekly active users, not just logins, and pause new features if adoption drops below 70 per cent.
Ignoring integration with existing legacy systems
A revenue authority commissioned a taxpayer portal that could not pull outstanding balances from the core tax administration system. Taxpayers saw "balance: UGX 0" while officers saw arrears. The disconnect triggered thousands of complaints and a parliamentary query.
The mistake: Treating integration as an afterthought or assuming the vendor will "figure it out later."
How to avoid it: List every external system the new software must talk to — IFMS, HRIS, mobile money gateways, SMS providers — and specify the integration pattern (API, file drop, message queue) in the tender. Require a sandbox environment for each integration before the first sprint review. If a legacy system has no API, budget for a middleware layer or a scheduled extract; do not pretend the problem will solve itself.
Skipping phased delivery and trying to launch everything at once
A parliamentary service spent 18 months building a full suite: bill tracking, committee management, hansard search, and a public petition portal. The go-live date slipped twice. When it finally launched, the search function returned errors because the indexing service had never been load-tested with real hansard volumes.
The mistake: Equating "phased" with "delayed" and insisting on a big-bang release to satisfy political timelines.
How to avoid it: Define a minimum viable phase that solves one high-visibility pain point — for example, bill tracking for clerks — and ship it in eight weeks. Use the live feedback to harden the platform before adding committee management. Each phase gets its own user-acceptance test, performance benchmark, and rollback plan. The accounting officer sees progress every two months; the technical team avoids a single catastrophic launch.
Overlooking data migration quality and volume
A lands registry migrated 1.2 million title records into a new cadastre system. Duplicate parcel IDs, missing coordinate references, and inconsistent naming conventions caused 18 per cent of records to fail validation. The clean-up took six months and required a temporary manual register.
The mistake: Assuming the legacy data is clean enough and that migration is a one-week script run at the end.
How to avoid it: Start data profiling in week one. Run automated checks for duplicates, nulls in mandatory fields, and referential integrity against the source system. Build a cleansing pipeline that logs every transformation so auditors can trace a title's journey. Run at least three full dress rehearsals into a staging environment, measuring error rates each time. Only when the error rate falls below an agreed threshold — say 0.5 per cent — does the cut-over weekend proceed.
Inadequate testing with real users and real data
A procurement authority tested its e-tendering module with five power users and a synthetic dataset of 200 tenders. In production, 3,000 suppliers hit the system on day one. The evaluation committee workflow deadlocked because the test never simulated concurrent scoring by seven evaluators.
The mistake: Using happy-path scripts and small datasets that hide concurrency, permission, and performance bugs.
How to avoid it: Adopt a three-layer test strategy. Unit and contract tests run on every commit. Staging receives a nightly refresh of anonymised production data so integration tests run against realistic volumes. Finally, a two-week user-acceptance window lets actual procurement officers, evaluators, and suppliers execute end-to-end scenarios — including peak loads simulated with a load-testing tool. No phase moves to production until the UAT sign-off sheet shows zero critical defects.
No budget or plan for ongoing support and enhancement
An agency launched a grants-management system with a fixed-price build contract and zero provision for post-launch changes. Six months later a new donor reporting format required two additional fields and a revised PDF template. The vendor quoted a separate engagement; the agency had no funds and the workaround was a manual Excel merge.
The mistake: Treating software as a capital project that ends at handover, ignoring the operational expenditure needed to keep it aligned with policy changes.
How to avoid it: Include a support and enhancement retainer in the original budget — typically 15-20 per cent of the build cost per year. Define service-level targets for critical bugs (four-hour response), minor changes (two-week sprint), and regulatory updates (within 30 days of gazettement). Use the same phased delivery cadence: every six weeks a small, tested increment goes live. This turns "emergency change requests" into planned backlog items.
Putting it together: a practical checklist for your next procurement
| Area | Minimum evidence before contract award |
|---|---|
| Requirements | Signed scope sheet with MoSCoW priorities |
| Process redesign | Workshop minutes showing removed steps |
| Adoption plan | Champion list, mobile-first design, adoption KPIs |
| Integrations | API specs or middleware design for each external system |
| Phasing | Phase-one definition, eight-week target, rollback plan |
| Data migration | Profiling report, cleansing pipeline, three rehearsal results |
| Testing | UAT script library, load-test plan, anonymised data feed |
| Support | Retainer budget, SLA matrix, six-week release calendar |
Attach this table to the evaluation committee's report. When a bidder cannot tick a row, score it down — do not assume they will "sort it out during implementation."
Next step for your agency
If you are drafting terms of reference for a new system, start with the checklist above. Share it with the user department, the internal audit unit, and the procurement and disposal unit before the tender goes out. The gaps you find now are the disputes you avoid later.
Was this article helpful?
Keep reading
Office Networks & Wi-Fi Myths vs Reality for Banks and SACCOs
Separate fact from fiction about office networking. Learn which myths hold you back and how to build a reliable, secure Wi‑Fi and cabling backbone that supports banking operations and member services.
ReadSecuring Retail Operations: Risks of Custom Software and How Trusted Automation Mitigates Them
Retail and distribution leaders face data breaches, process errors and compliance gaps when adopting custom software. This guide shows concrete steps to protect your business while reaping automation benefits.
ReadHow Can Retail & Distribution Leaders Secure the Right Store Space with WetuProperty?
Retail and distribution managers often wonder how to find trustworthy premises quickly and affordably. This Q&A walks through using WetuProperty to locate, verify, and lock in the perfect location, with concrete steps and safeguards.
ReadDiscussing a similar challenge in your operation?
Our consultants reply within 24 hours.