There is a meaningful difference between a system that holds all your data in one place and a system in which that data is structurally connected. The first is an improvement on scattered spreadsheets. The second is what makes coherent programming and full traceability achievable.
That difference is worth examining carefully, because it explains why most general-purpose project tools — even ones used by organisations that care about rigour — produce reporting problems that feel like process failures but are actually structural ones.
What co-located means in practice
A system is co-located when the relevant records exist within the same application. Requests, action plans, activities, expert assignments, documents: all in one place, accessible without switching tools.
That is genuinely useful. It eliminates the obvious coordination failures — the request logged in one system, the assignment tracked in another, the document filed in a third. Co-location is necessary but not sufficient.
The failure mode of a co-located but not interconnected system appears at reporting time. You want to know, for a given programme, the total budget committed across all activities, the working days contracted and the working days actually delivered, and the indicator values tied to the results that were achieved. In a co-located system, all the components of that picture exist somewhere. Assembling them still requires someone to pull figures from each record, reconcile totals, and manage the discrepancies that emerge when activity-level data does not match what the programme record shows.
That reconciliation is a data-integrity task, not a reporting one. And it recurs every reporting cycle because the data structure was never designed to eliminate it.
What interconnection adds
An interconnected system is different in one specific way: the operational levels are formally related to each other, not merely available within the same interface.
In ZeePMT's data model, a request triggers a structured intervention. That intervention is decomposed into an action plan of work packages, each broken into activities. Each activity carries its own status, budget, responsible officer and indicator data. The activity links forward to the call for expertise that staffed it, the expert assigned, the documents produced, and the budget consumed.
The structural consequence is bottom-up aggregation. When an activity's status changes, that change is visible at action plan level without anyone updating the action plan separately. When working days are recorded at activity level, the totals roll up to the programme level automatically. When an indicator value is entered against an activity, it feeds the results picture at programme level without a separate consolidation pass.
This is what coherent programming actually requires: a change or a delay at any level in the hierarchy is immediately visible at all levels above it, without manual reconciliation.
Two things this makes possible
Coherent programming
A facility managing a multi-country portfolio can see throughout the delivery period whether activities delivering against any given indicator have collectively consumed budget from multiple work packages, and which of those are at risk of overrunning. That picture is visible because the activity-level data is aggregating continuously rather than being consolidated periodically.
Full traceability
Any operational, financial or results figure in a report can be traced back to the specific unit, role and date that produced it. Not because someone kept careful notes, but because the data model made that connection at the point of entry. Audit queries do not require reconstruction — they require navigation.
The practical test
The test of whether a system is interconnected or merely co-located is simple: can a programme-level figure be traced to the activity that produced it, and does a change at activity level propagate upward without manual entry?
If both answers are yes, the system is interconnected. If either requires a manual step — updating the programme record separately, reconciling totals at reporting time, notifying a programme manager that an activity has changed — the system is co-located but not interconnected, and the reconciliation overhead will be a permanent feature of running the programme.
The bottom line
When operational levels are interconnected rather than merely co-located, the programme view is always current, the audit trail is always complete, and the reporting burden shrinks from a consolidation exercise to a quality check: verifying that what the system reflects is what actually happened, rather than assembling what happened from records that were never designed to talk to each other.