Uganda procurement portal training: attendance is not adoption

On 8 and 9 April 2026 in Kampala, 143 officers from 59 public bodies worked with a government procurement portal that listed 395 projects at the time. Those figures record the scale of the sessions. They are not proof of independent use, organisation-wide adoption, or continuing publication quality after the room emptied.

A launch proves the portal exists. Only later use can show whether it landed. The workshop did not close that question. It made the next tests easier to name.

The problem the workshop surfaced

The sessions kept returning to one modelling problem, and it deserves more space than a launch story usually gives it: one infrastructure project can connect to several contracting processes.

A clean demonstration makes a project look like one method, one award and one contract. Actual delivery branches. A road can be procured in phases, with a separate contract for the bridge, a variation for drainage, a maintenance contract after handover. A clinic can draw equipment and works through different processes under separate awards. The demonstration shows the tidy version because the tidy version is easy to show.

That matters because a contracting record and a project record answer different questions. A contracting record can show how a supplier was selected and what was awarded. A project record has to keep those processes connected to the same public work, including what changed and what happened during delivery.

Here is the practical consequence. If a system assumes one project equals one contract, then every project page it publishes shows a single method, a single award and a single contract, while the real work branches across several. Anything built on top of that page inherits the error: a portfolio view that counts contracts will over- or under-count delivery, a delivery tracker will follow one contract and lose the others, and a citizen reading the page cannot see that more was awarded than the page shows. The modelling choice is not cosmetic. It decides whether the published record can answer the delivery question at all.

The workshop challenged that tidy assumption because real cases revealed what the demonstration had left out. The strongest defensible claim is that the edge case became visible. The checked evidence does not establish that a corresponding model change was later shipped.

Three different things to establish

Institutional responsibility. The PPDA provides an institutional home for the portal. That does not establish formal acceptance of every workflow, the operating responsibilities of every publisher, or organisation-wide adoption.

Usability with actual work. A supervised session can show whether participants complete tasks under the conditions of that session. Attendance and successful exercises do not establish independent capability or repeated use afterwards.

Publication quality over time. Records need to remain sufficiently complete, accurate, linked and timely for their intended use. A launch, a project count or a training receipt cannot establish that continuing condition. It needs a defined check, a responsible owner and evidence from later publication.

These checks can overlap and recur. They are not a universal sequence. Keeping them separate prevents one receipt from carrying more meaning than it can support.

What would count as follow-up

The defensible follow-up is narrower than an adoption claim. The modelling question can be tested with an agency's own records: can an officer connect several contracting processes to one project, complete the task without help, and publish a record that answers the intended delivery question?

That test would establish a specific improvement under stated conditions. It would still not prove that every agency adopted the system, or that the published data remained useful over time. The next evidence should come from a bounded reuse test and the resulting public record, not from the attendance sheet.

The article also avoids using historical coverage percentages as evidence of the portal's present state. Without an authoritative date and a like-for-like post-upgrade assessment, an old percentage would blur a historical diagnostic into a current finding.

Evidence boundary

One note on what can and cannot be drawn from the encounter, so it does not have to be repeated beside every sentence:

The encounter is based on Michael Cengkuru's dated first-person account of the PPDA and CoST sessions. No dialogue is quoted. The relationship between one infrastructure project and several contracting processes is described in the OC4IDS publishing guidance.