Building stronger data systems for programme delivery

Programme data systems are commonly judged by what they can display to the centre or to a financier: a coverage figure, a completeness rate, a dashboard, a quarterly report. Those products have a place. They are a poor test of whether the system serves delivery. Delivery is a set of operating decisions taken at different levels, on different clocks. An officer in charge of a facility, deciding how to use this week’s staff and commodities, a state programme manager deciding where supervision should go this month, and a national team preparing what to tell a financier this quarter are not looking for the same cut of the same facts. A system designed only for the last of these will be completed for the report. It will then be distrusted for the first two, because the people closest to the work know which fields were filled to satisfy a return rather than to describe the service.

The design question is therefore the operating decision, stated before the indicator. What does this person need to see, by when, in order to act? What would they do differently if the figure moved: redeploy a team, place an order, escalate a stock-out, open a supervision visit? If nothing in their authority would change, the indicator is a reporting burden. It may still be required by a financier or a statute. It should not be described as a management tool, and it should not be allowed to crowd out the few measures that would change an action. A long list of indicators is often the residue of questions that were never tied to a decision someone could take.

A single national view is not a substitute for the views beneath it. Aggregation hides the exception on which a manager can act. A state average can be acceptable while a local government area, or a facility, is failing in a way that would justify a response. The system has to make that exception visible to the person who has the authority to respond, at a frequency matched to the decision. A quarterly national report cannot run a weekly commodity decision. Treating it as though it could produces a careful picture of a problem that has already moved on.

Most delivery institutions are not short of data. They are short of data that has been made usable for a stated question, and they often become shorter of trustworthy data when a new system asks staff to record the same fact again. Registers, logistics records, budget-execution reports, payroll and supervision notes already describe a large part of what is happening. A platform that ignores them imposes a second entry. The two versions drift, staff learn which one is checked, and the unchecked one becomes fiction. The first design choice is what to leave alone: which source is closest to the work, who already maintains it, and what would be lost by replacing it rather than reading it.

That choice has to be explicit about what the source cannot say. Routine service data can support statements about volume and, where identifiers and visit dates are reliable, about continuity. It cannot by itself support a statement about population coverage, because it has no reliable denominator of the population at risk. It cannot certify quality of care, and it cannot show that a household was reached if the household is not the unit being observed. Logistics data can show that a commodity left a store. They do not show that it was used appropriately. Financial data can show that a budget line was released or spent. They do not show that the output occurred. A facility assessment describes readiness at a point in time. It is not a monitoring system. Asking a source to carry a conclusion it cannot identify produces a number that is precise and wrong, and it teaches managers to distrust the next number from the same place.

Where the gap is real, because the decision requires a fact that no existing source contains, the addition should be the smallest collection that can identify it. A long new tool is often a sign that the question was not narrowed, or that several decisions were collapsed into one form. Each extra field has a cost at the point of capture, and that cost is paid by the same staff whose service the system is meant to describe. A data system that degrades the service in order to report on it has failed before any screen is built.

If sources are to be read together, events and facilities have to be identifiable across them. Without a maintained list of facilities, and without a disciplined way of referring to the same site in the service statistics, the logistics records and the financial system, the institution cannot move from three partial pictures to one account of delivery. Joining systems is not a software feature added at the end. It is an agreement about identity, about which system is authoritative for which fact, and about the definitions that make a join meaningful rather than merely technical.

Delivery, supervision, finance and verification do not need the same report. They do need to draw on an agreed set of definitions. When each unit keeps its own workbook, the management meeting is spent reconciling figures that differ because the numerator, the period or the facility list differed, not because performance differed. That reconciliation consumes the time in which a decision could have been taken, and it leaves every party free to prefer the version that suits them. The cost is invisible in a system review, because each workbook looks complete on its own.

A workable architecture specifies, for each measure that matters, a small set of properties, and writes them where they can be maintained. The definition. The numerator and the denominator, including who is excluded. The disaggregation the decision actually requires, rather than every disaggregation that might one day be asked for. The source system and the field the figure comes from. The frequency. The check applied before the figure is released. And the decisions the figure is allowed to support. The last of these is the property most often skipped, and it is the one that protects both the decision and the people who produce the data.

A figure fit for monthly management is often unfit for a payment, an audit finding or a public claim. Management can tolerate a timely estimate with a known bias, because the cost of waiting may exceed the cost of a correction next month. A payment triggered by the same figure changes the incentive to report it. An audit or a published claim will be read as a statement of fact, not as an operational signal. Using one number for all of these purposes, without saying so, is how a data system becomes a dispute. The specification should say in advance which uses are permitted, and which would require a different source or a separate verification step. Verification, where money or a public commitment depends on the figure, is its own process, with its own sample, its own standard and its own independence. It is not a second screen built on the same unchecked return.

A system fails quietly when the only people who understand its definitions are no longer in the room. Specifications sit in a contractor’s files. An indicator changes in a slide and not in the register that staff complete. Fields that no one uses remain on the form because removing them would require a decision. Staff learn which fields are decorative, complete those mechanically, and keep the operational truth in a book or a message the system never sees. From the centre the return looks complete. At the point of delivery the system has already been bypassed, and the bypass has become the real record.

That day has to be designed for at the start, not handled as a handover in the final month. Definitions need to live where the team that will run the system can find them and change them: a data dictionary and an indicator reference, owned by a named unit, versioned when a definition changes, and used as the source for any report or screen. The tools need to be ones the institution can host, staff and pay for after project financing ends. A platform whose operating cost, licence or specialist skills sit entirely outside the institution is a temporary exhibition. Training should include the people who will alter a form, retire an indicator and explain a definition to a new officer, not only the people who will fill the form in.

There also has to be a routine for retirement. Indicators accumulate because each had a sponsor and none has an owner with authority to remove them. A system that only adds questions will, within a few cycles, ask more than anyone answers carefully, and the quality of the fields that matter will fall with the rest. Digital tools belong inside this design. They do not replace it. A current platform that does not match the way teams already record, check and act will be worked around. The technical choices — what is configured, what is joined, what is left as a source to be read rather than re-entered — matter only if they follow the operating decisions, the authoritative sources and the maintenance the institution can sustain.

Strength is not the number of indicators, the completeness of a monthly return, or the finish of a screen. Completeness, timeliness, internal consistency and accuracy are different properties. A return can be complete and on time while the figures in it are wrong, and a sophisticated screen can display that return without making the error visible. Reporting performance and the performance of the programme are not the same object, and a review that treats them as the same will certify the system that is easiest to complete.

A stronger system is one a delivery team can use when no visitor is in the room. The team can see the exception that should change an action. They can trace the definition behind the figure, including what the source cannot support. They can tell a management signal from a figure that would be used for payment or for a public claim. And someone, by role rather than by goodwill, is accountable for acting when the figure moves. That is a management system which uses data. It has a short list of measures tied to decisions, sources that can bear those measures, and a distinction between uses that has been written down before a dispute arises.

The practical test is local. Take one decision that a facility or a programme office actually takes, and see whether the system shows the fact they need, in time, from a source they have reason to believe. If it does not, the gap is in the design: the decision was never specified, the source cannot carry the inference, or the figure is aimed at a report no one at that level can act on. Treated only as a reporting product, the same system will look finished in a review and will leave the week’s work unchanged.