Engineering finished with time to spare. The launch was still at risk.
Not because anything was broken — because a citizen-facing service is a container for content, and the content was owned by a dozen people across several units who had their own jobs, their own approval chains, and no particular reason to treat our sprint boundary as meaningful.
This is the least technical article in the series and it describes the constraint that most often decides whether these projects land on time.
The shape of the problem
A delivery team can build screens quickly. It cannot write the authoritative description of how a public service works, what it costs, who qualifies, what documents are needed, and what happens next — because it does not know, and because being wrong about it in public is a serious matter.
That knowledge sits with the people who run the service. Getting it out of them and through an approval gate is a workstream with its own dependencies, and it is almost never planned as one. It gets treated as something that will happen alongside the build, which is another way of saying it gets treated as nobody's job.
Then engineering runs out of work, and the remaining path to launch runs entirely through people outside the delivery team.
Content quality is AI quality
There is a second consequence that matters more once an AI assistant is in scope, and it is worth stating plainly because it reframes content from a publishing concern into an engineering one.
The same approved content feeds the assistant's knowledge base. Which means:
- Content that is out of date produces an assistant that is confidently out of date.
- Content with gaps produces an assistant that either says nothing useful or fills the gap itself.
- Content that has not been through approval produces an assistant answering on unapproved material, in public, on behalf of a government department.
The quality ceiling of the AI is set by the content, not by the model. Teams spend a great deal of effort on retrieval configuration and comparatively little on whether the corpus is any good, and the second one dominates the outcome. Given the residency work that goes into deciding where the model may run, it is worth noticing that what it runs on has a larger effect on whether citizens get correct answers.
Four routes in, mixed by content type
There is no single right way to collect content. What worked was matching the route to the type.
Fill-in templates are the fastest way to get structured content out of many owners at once. A spreadsheet or form with the exact fields, sent to the person who knows the answers. Unglamorous and extremely effective, because it converts "write us your service description" into a set of small, obvious questions.
Admin screens are for content that will keep changing after launch. Build these for the things that genuinely move — fees, contact details, operating hours — and do not build them for content that changes once a year.
Curated document upload is the route for the material the assistant will ground its answers on. This one carries the tightest gate, because it is the content the AI is licensed to speak from.
System pulls come later, once there is a stable system to pull from. Attempting integration-based content ingestion before launch usually means two hard problems instead of one.
Everything passes an approval gate. For the assistant's corpus especially, unapproved content is not a content problem — it is a public-statement problem.
Fix the date, flex the scope
The most useful rule we applied: when a service's content slips, launch fewer services rather than moving the date.
This is easier to agree in principle than in the room, because every service owner reasonably believes theirs should be in the first release. But the alternative is worse in every direction. A moved launch date affects everyone, including the services that were ready. A reduced first release affects only the services that were not, and it creates a visible, fair incentive that does more for the second wave of content than any amount of chasing.
It also protects the thing that actually matters, which is that the service exists and citizens can use it. Six services live is a launch. Twelve services in draft is a project status.
Plan it as a workstream
Concretely, what we would do from the start:
Name an owner per content area. A person, not a unit. Units do not return drafts.
Put dates on content, in the same plan as the engineering. Not a separate document that only the delivery lead reads.
Send templates, not requests. "Please provide content for the licensing service" produces nothing for three weeks. A form with eight specific fields produces a draft in two days.
Track it visibly. Content status per service, in the same place the build status lives, so slippage is obvious early to everyone rather than late to the delivery lead.
Get the approval chain agreed up front. Knowing who signs off before you need a signature removes a surprising amount of the delay.
The honest summary
On a citizen-facing service, engineering is rarely the constraint any more — and with AI-assisted delivery it is less of one every year. The constraint is the organisational work of getting accurate, approved information out of the people who hold it.
Plan it like a workstream with owners and dates, because that is what it is, and it is on the critical path whether or not anyone has drawn it there.
How CloudNala can help
We now plan content collection as a named workstream from day one on citizen-facing deliveries, with owners, templates, dates and an approval chain agreed before the build starts. On engagements with an AI assistant in scope we treat the corpus as an engineering input rather than a publishing task, because it sets the quality ceiling for everything the assistant will say.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Readiness Workshop or write to us at consult@cloudnala.co.za