By the end of this piece, you’ll have a simple test: seven signals that tell you whether a public sector information system (IS) implementation will land − or leak value. Think of them as evidence gates.
Public sector IS initiatives rarely fail because the technology is “too complex”. If complexity were the culprit, outcomes would be consistent across similar platforms. They aren’t. We keep funding delivery while starving the alignment layer that turns executive intent into buildable, adoptable and auditable outcomes.
When implementations stall, the same explanations appear: procurement delays, budget constraints, weak ICT governance and change resistance. These are real, but they are usually downstream symptoms − not the structural cause.
The structural cause is the missing glue between business outcomes and ICT execution: disciplined business analysis, institutionalised through a properly configured business analysis office (BAO). Without it, projects drift, rework balloons, go-live becomes the finish line and benefits evaporate after launch.
Why this keeps repeating
This isn’t just anecdotal. McKinsey and Oxford’s analysis of 5 400+ IT projects found large initiatives average 45% over budget and 7% over time, while delivering 56% less value than predicted. A separate McKinsey review of 2 905 public sector IT projects found benefits tracking is rare − meaning even “successful” delivery can hide poor value.
In government, the cost is not only wasted spend, it is service delivery failure, audit exposure and compounding cost-of-delay. South Africa’s Auditor-General has also flagged the disconnect of ICT as a support unit rather than a strategic partner on ICT modernisation projects.
The pattern should prompt a blunt question: why are we treating all the reported problems as the root causes, when the deeper issue is that intent is not being aligned with evidence-based delivery?
What the BAO is − and what it is not
A BAO is not a project management office (PMO). It is not enterprise architecture (EA). It is not a compliance paperwork team. Those functions matter, but they do different work.
A BAO’s job is alignment with evidence. It keeps delivery anchored to operational truth and measurable outcomes. Practically, it protects seven things that failing IS implementations usually don’t protect without a BAO.
Seven-signal test: Can you prove the glue exists?
- Traceability: Linking outcomes to requirements and releases (so executives can view and interrogate what they are commissioning).
- Process-fit validation: Proving the system matches how work really happens end-to-end (not just how it was described in a workshop, but with “signed-off” process documents and not “paper sign offs”).
- Adoption readiness: Turning “people change” into named owners, training measures, cutover discipline and post-go-live support capacity.
- Integration with other internal and external systems; data exchange – all IS working as a cohesive unit; provision of a single truth.
- Key risk and audit controls embedded by design and proven through test evidence.
- Post-go-live stabilisation discipline: Defects, data quality, workarounds and performance metrics with closure plans.
- Benefits baselining and tracking: Agreed value before and measured after go-live, not merely promising it before build; tracked after launch and reported in operational dashboards.
If a BAO is functioning, you should be able to observe − and test the above seven signals at any time during an IS implementation. Treat them as evidence gates: if you cannot show them, pause the implementation before you scale it.
PMO drives delivery; EA guards coherence; BAO guards outcome integrity.
Pragmatic operating model
Most government departments don’t need a large BAO to start. They need a lean BAO with authority, a tight charter and a cadence.
A practical model is matrixed: professionally anchored in ICT (standards, methods, integration discipline) and operationally embedded in strategy/planning (outcomes, process ownership, benefits accountability).
This prevents three failure modes: ICT builds in isolation, the business requests without delivery discipline and projects go-live, but never land.
The hard part: BAO failure modes and guardrails
A BAO is not a silver bullet. Done badly, it becomes a bureaucracy factory that slows delivery. Three guardrails keep it useful:
- Lean artefacts only: Every document must earn its keep by reducing risk or rework.
- Outcome ownership: BA outputs are signed off by process owners, not only the project team.
- Evidence rhythm: Benefits and stabilisation metrics are reviewed after go-live, not abandoned.
Information systems implementation lifecycle coverage is non-negotiable without a BAO: pre-discovery (problem clarity), discovery (process and requirements truth), implementation (traceability and control), and post-launch (adoption, stabilisation, benefits realisation).
Outsourcing can help early phases, but without a permanent BAO, post-launch value tracking typically collapses.
Conclusion
Procurement delays, budget overruns and change resistance are real − but they are often symptoms. The root cause is that we attempt large-scale delivery without funding and governing alignment between business intent and IS solutions.
Until we treat business analysis as a compulsory institutional capability − as seriously as we treat technology procurement − delays and value leakage will remain predictable.
Three questions the public sector should debate openly:
- Where should the BAO sit: ICT, strategic planning, or a true matrix − and what decision rights does it need?
- Are all the seven signals required as evidence gates before go-live and after go-live?
- What is the smallest BAO we can build now that measurably reduces rework, audit risk and cost-of-delay?
Make the seven signals non-negotiable evidence gates, and public sector IS delivery stops being a lottery.
Share