In every infrastructure transparency programme I have worked on across Africa and South Asia, portals that launched to press releases went dark within three years. The failures follow predictable patterns: they rely on manual data entry, they treat the contract award as the finish line, and they build for politicians instead of practitioners. Portals survive when they automate data extraction directly from government systems and use OC4IDS (Open Contracting for Infrastructure Data Standard) to connect procurement data to physical project delivery. If you want your infrastructure transparency portal to outlast its launch funding, you must hardwire it into existing administrative workflows.
1. Manual Entry Guarantees Failure
APIs
Application Programming Interfaces, which allow different software systems to communicate
Every manual-entry portal we observed was abandoned. When governments build platforms that require procurement officers to log in and upload spreadsheets, compliance drops to zero the moment project funding ends. In Uganda, after five implementations, we found a stark divide. Portals that relied on human memory and goodwill died. Portals that pulled data automatically via APIs (Application Programming Interfaces, which allow different software systems to communicate) survived.
5
transparency portal implementations across East Africa, all revealed the same divide: portals that automate data extraction survive, portals that rely on manual entry fail.
Why this matters: when transparency requires extra administrative effort, stressed civil servants skip it. Automation removes the human bottleneck, ensuring data flows even when political will fades.
IFMIS
Integrated Financial Management Information System, the software governments use to manage budgets
The logic is absolute: transparency cannot be a separate, additional task. It must be a byproduct of doing the work. You extract data from the e-GP (electronic Government Procurement) system and the IFMIS (Integrated Financial Management Information System, the software governments use to manage budgets). When a procurement officer issues a tender in the e-GP system, that action must automatically populate the public portal. In our fieldwork across East Africa, we saw donor-funded projects hire teams of data entry clerks to backfill portal data. The day the grant closed, the portal died. Survivors eliminate the data entry clerk entirely.
2. Procurement Is Not the Project
Portals die when they answer the wrong questions. Citizens do not care who won a contract; they care whether the hospital has a roof. Many failed portals use OCDS (Open Contracting Data Standard) as their only framework. OCDS is excellent for the procurement data layer. It tracks the tender, the award, and the contract execution. But infrastructure requires tracking the physical asset, the site location, and the engineering milestones.
track variation orders
formal changes to the scope, cost, or schedule of a contract
This is why you must use OC4IDS. OC4IDS takes the procurement data from OCDS and connects it to project preparation, physical progress, and final completion. In our CoST (Construction Sector Transparency Initiative) implementations across Africa and South Asia, portals that stop at the contract award lose their audience immediately. Portals that track variation orders (formal changes to the scope, cost, or schedule of a contract) and physical completion milestones retain active users.
When you rely solely on procurement data, a project looks successful the day the contract is signed. OC4IDS forces the system to track reality. It links the financial disbursements in the IFMIS to the physical site inspections. If the government pays 80% of the contract value but the physical progress sits at 20%, OC4IDS exposes the gap. OCDS tells you who got the money; OC4IDS tells you if the bridge stands up.
3. Building for Oversight, Not Optics
Every portal I watched die shared the same design philosophy: built to look good in a press release. They featured massive dashboards, aggregate spending charts, and zero project-level detail. Survivors do the opposite. They provide granular data for specific oversight actors.
3 years
, median lifespan of a disclosure portal launched via press release before going dark. Portals hardwired into government systems outlast their launch funding indefinitely.
A beautiful dashboard hides broken projects. Aggregate charts make politicians feel safe, but oversight requires project-level friction. If your portal does not expose delayed projects, it is a PR tool.
In our PPDA (Public Procurement and Disposal of Public Assets Authority) dataset in Uganda, we observed that journalists and civil society groups ignore aggregate dashboards. They search for specific contractors, specific districts, and specific delays. They want to know why the road in their district remains unpaved three years after the contract award.
When we structured the OC4IDS pipeline to flag time overruns and cost overruns automatically, usage spiked. The portal became a daily tool for auditors and reporters. We stopped building charts that showed total infrastructure spend and started building lists that showed projects twelve months behind schedule. If you build for everyone, you build for no one. Build for the auditor. Give them the exact data points they need to launch an investigation.
Counterargument: The "Low Capacity" Objection
Critics correctly note that low-capacity agencies lack the IT staff to build and maintain automated data pipelines. They argue that manual spreadsheet uploads are the only realistic starting point for rural districts or underfunded ministries. They claim that waiting for API integration delays transparency by years.
This objection miscalculates the true cost of manual entry. Manual uploads require permanent, recurring human capacity every single month. In every integration we built that bypassed manual entry, the initial technical hurdle was high, but the system sustained compliance. Automation is a one-time capital expenditure; manual entry is an infinite operational tax.
When you accept manual uploads because of low capacity, you guarantee the portal's death. The same underfunded district that lacks an IT developer also lacks a dedicated data entry clerk. You hire a consultant once to map the OCDS procurement data into the OC4IDS infrastructure schema and build the API. After that, the system runs itself. The initial delay is worth the permanent survival of the platform.
What to Do Next
Stop funding standalone portals that require manual data entry. If you manage an infrastructure transparency project, take three steps this week.
- Audit your data pipeline. If a human being has to click "upload" for the public to see a new contract, halt development. Redirect your budget to build an API integration with your e-GP system.
- Map your data to reality. Align your existing systems to the OC4IDS schema. Ensure you track physical progress, not just the contract award. Use OCDS strictly as the procurement feed, but structure your public display around the full infrastructure lifecycle.
- Test for friction. Locate your primary oversight user, an auditor, a journalist, or a civil society monitor, and ask them to find a delayed project on your current platform. If they cannot find it in three clicks, redesign your interface.
Build systems that expose failure quickly. Build systems that work without you.
Playbook
Decision Table
| Option | When to Use | Tradeoff |
|---|---|---|
| Adopt immediately | Low-risk process and clear team ownership | Fast progress, limited validation runway |
| Pilot first | Uncertain data quality or mixed institutional capacity | Slower scale-up, higher confidence |
| Defer pending controls | Missing governance, QA, or monitoring guardrails | Lower short-term output, better long-term durability |
Execution Checklist
Failure Modes
- Skipping the section "1. Manual Entry Guarantees Failure" during implementation.
- Skipping the section "2. Procurement Is Not the Project" during implementation.
- Skipping the section "3. Building for Oversight, Not Optics" during implementation.
Found this useful?
I write about open data systems, transparency, and implementation.
Read more articles →