"What happens when our agency uses three procurement methods in one project?"
The officer asking was an hour into the second day of training. The portal we were running her through assumed each project would behave like a textbook example: one method, one contract pathway, one clean lifecycle. Her actual project did not. Her question landed in the room, and within twenty minutes I was taking notes faster than I was teaching. That single edge case exposed a design assumption I had carried for over a year, and it did so in the room where it was supposed to be defended.
The 8th and 9th of April, Kampala. 143 procurement officers from 59 Ugandan public bodies sat through two days of training on the Government Procurement Portal. The portal had been live since February. The training was not the launch. It was the test of whether the launch had landed.
1. The room where the assumption broke
I had assumed training is a knowledge transfer event. Walk officers through the portal, show them the workflows, hand over documentation, validate that they can complete the core tasks. Done.
The ownership distinction matters for how I write about this. The Government Procurement Portal is not mine. It belongs to the Public Procurement and Disposal of Public Assets Authority and, through it, to the Government of Uganda. I was contracted through CoST, the Infrastructure Transparency Initiative, to help build it. The transfer the training tested is not from me to PPDA; it is from the build team (CoST plus our technical partners) to PPDA's officers, the agencies that publish through them, and the public the disclosure is meant to serve.
Ownership transfer moves accountability outward, from the people who built the portal to the institutions and users who must keep it alive.
- Build team CoST and technical partners harden workflow assumptions.
- PPDA The regulator accepts institutional responsibility for adoption.
- Agencies Officers test the portal against actual procurement work.
- Public use Disclosure becomes useful when trusted data can be reused.
2. Cohort design: train the people the system was not designed for
The design rule: do not staff training cohorts from the audience the launch event was performed for. A roomful of senior officers from a single agency is a closed loop. A roomful of working-level officers across many agencies is a stress test. The cohort that finds the system's flaws is not the cohort that sat through the launch ribbon-cutting.
What the April cohort looked like: 143 officers from 59 organisations including the Office of the Prime Minister, Kampala Capital City Authority, the Ministry of Finance, the Uganda Electricity Transmission Company, the Uganda Revenue Authority, and the National Environment Management Authority. Every workflow assumption the build team had baked in over the previous year got challenged within the first morning, by people who would actually have to use the portal.
Officers closer to daily data entry asked questions that the senior decision-makers in the same agency had stopped noticing. They flagged friction in field validation, audit-trail visibility for junior staff, workflow problems that only show up when you do not have political cover to skip steps.
Of the 143, 51% were women. That number is the headline donors and oversight bodies look at first. It is also the easiest number to misread. What I observed in the room was that role and seniority almost certainly correlate with gender in Ugandan public-sector procurement, which is its own well-documented pattern. A controlled comparison would isolate which variable drives the question-quality difference. I do not have one. So the honest claim is that diversity of role and agency is the variable I can defend from this cohort. Gender plausibly tracks with it; I cannot claim a direct causal link from a single training. The practical consequence is the same in both readings: optimise the mix, however you build it, away from the audience the launch was performed for.
3. The boring questions are the survival questions
The interesting training questions, the ones that demo well, are about novel features. Reporting, analytics, cross-project search, the things that distinguish a modern disclosure portal from a 2010s PDF dump. The questions that predict survival are the boring ones.
What happens when a contract gets cancelled mid-procurement and a new one replaces it. How do I correct a typo three months after publication. What happens when an officer leaves and their drafts need to transfer. Who can see this before I publish, who can see it after, and how do I tell the difference.
None of these are exciting. None of them get into a launch press release. All of them are the questions an officer asks when they are imagining themselves using the system on a Tuesday afternoon when nothing is going right. If you cannot answer them on day one of training, you have built a system for the launch event, not for the work.
The 395 projects that were live in the portal as of training day were not the test. The test was whether an officer in a regional office could correct one of those projects three weeks later without phoning Kampala. We had built that capability. We had not built the documentation that explained how to use it. By the end of the second day, the documentation existed because the officers had written it. Not metaphorically. Two officers from Kampala Capital City Authority started a shared draft mid-session, capturing the steps for a workflow we had not formally documented because we had assumed it would be obvious. By lunchtime on day two, four other agency representatives had added their variants, and one had photographed the resulting whiteboard sketches. We took that whiteboard back to the office on the second night and rebuilt three pages of the official portal handbook around it. The pages now in the live training pack come from those two days. The author credit on those pages is not mine.
That is what ownership transfer looks like, on the day it actually happens.
And the three-procurement-methods question that opened this article? It became a backlog item, not a fix. The portal does not yet model a project with multiple concurrent procurement methods cleanly. The interim guidance the handbook now carries is a workaround: publish each method as a linked sub-record under a parent project. The schema change that would model it natively is open in the design backlog and has not shipped. The honest version of "ownership transfer" includes admitting which questions the room exposed that the build team has not yet closed.
4. Three validations, or you have shipped a draft
Most teams I have worked with treat regulator sign-off as launch. It is not. Regulator sign-off is one of three validations a transparency portal needs, and conflating them is what turns a working system into a digital monument.
The Public Procurement and Disposal of Public Assets Authority validated the portal on the 13th of February. That cleared the political path for adoption. PPDA validation says the system meets the standards it was meant to meet. It does not say anyone will use it.
The 143 officers in April performed the second validation. User validation says officers can operate the system under real workflow pressure, including pressure from edge cases the design did not anticipate. This is the validation that determines adoption, and it cannot be done by the team that built the system, because the team that built it has internalised what the system is meant to do.
The OC4IDS quality assurance round that closed on the 21st and 22nd of April was the third validation. Data validation says the data inside the portal can be trusted to comparison standards across CoST member countries. This is the validation that determines whether the disclosed data is interoperable, which determines whether downstream tools and oversight bodies can use it.
The portal cleared that round. The data was checked against the OC4IDS schema and the CoST data-quality framework that comparable member implementations are held against, and passed without conditions. That is the validation that travels: it lets downstream researchers, oversight bodies, and partner programmes pull from the portal knowing the records will line up against records from elsewhere on the standard.
Three different validations. Three different audiences. None of them substitutes for the others. The temptation in every rollout I have worked on is to declare victory after the first validation and let the other two slide. That is how systems become monuments. If you ship a transparency portal and only one of the three has happened, you have shipped a draft. If only two have happened, you have shipped beta. Three validations, in any order, is what shipping looks like.
| Validation | When | What It Proves | What It Cannot Prove |
|---|---|---|---|
| PPDA sign-off | 13 February 2026 | The portal meets the institutional standard. | Whether officers will use it under pressure. |
| Officer training | 8-9 April 2026 | Real workflows and edge cases can be operated. | Whether adoption holds after the room empties. |
| OC4IDS QA | 21-22 April 2026 | The data can survive comparison and reuse. | Whether agencies keep feeding the portal. |
| Validation | When | What it proves | What it cannot prove |
|---|---|---|---|
| PPDA sign-off | 13 February 2026 | The portal meets the institutional standard. | Whether officers will use it under pressure. |
| Officer training | 8 to 9 April 2026 | Real workflows and edge cases can be operated. | Whether adoption holds after the room empties. |
| OC4IDS QA | 21 to 22 April 2026 | The data can survive comparison and reuse. | Whether agencies keep feeding the portal. |
The shape of this argument travels even if the institutional shape does not. Uganda's 59-agency rollout is one kind of user base, fragmented across many publishers with no single anchor. A single-anchor implementation, where one institution publishes most of the projects, runs through workflow-integration sprints instead of cross-agency cohorts. A sector-specific portal, built from a roads or water utility outward, trains sector-deep rather than wide. The format follows the shape. The shape is a fact about the country, not a choice the donor or the build team gets to make.
5. The July test
The 143 officers I worked with in April are now back in their agencies. Some are uploading regularly. Some have not logged in since. The next reporting cycle will tell me which is which.
active is impossible
you must log in to publish
For this test to be a test, the metric has to be defined before the result. Active means an officer logged in to the portal at least once during the July reporting cycle. Producing means an officer published at least one new project record to OC4IDS schema during the cycle. Active without producing is presence; producing without active is impossible (you must log in to publish). Both together is what survives.
That is the metric I trust most. Data quality, correction rates, completeness, audit use, and reporting timeliness all matter, but each one collapses to nothing if the officers stop coming back. The July metric tells me whether ownership transferred, or whether it only looked like it did.
The training was the bet that the chain would hold without me in the room. The next three months are the result. I will publish what I find.
Found this useful?
I write about open data systems, transparency, and implementation.
Read more articles →