Data Quality as a Side Effect

Government-funded programs exist to achieve a public purpose. They may be intended to improve health, support vulnerable people, strengthen communities or address some other identified need. Funding agreements, reporting frameworks and data standards exist to provide accountability for that investment and to help determine whether the program is working.

But over time, something can go wrong.

The requirements intended to support the program can begin to dominate it. Success becomes defined by whether every mandatory field has been completed, every record passes validation and every submission is delivered on time. Staff spend increasing amounts of time correcting data, interpreting specifications and resolving reporting exceptions. Systems are designed around what must be reported rather than around the work people need to perform.

Compliance gradually stops being a supporting function and starts to feel like the core business.

This is an inversion of purpose. The organisation becomes highly focused on proving that the program is being delivered, while potentially losing focus on what the program was funded to achieve.

Compliance is necessary, but it is not the outcome

Government funding rightly comes with obligations. Public money must be used responsibly. Funders need confidence that services are being delivered to the intended people, that program rules are being followed and that the reported results are credible. Providers must be able to demonstrate their performance, and poor practice must be identifiable.

The problem is not compliance itself. The problem arises when compliance becomes disconnected from purpose.

A healthy program should have a clear hierarchy. The intended public outcome comes first. Services are designed to contribute to that outcome. Information is captured to support the delivery, management and improvement of those services. Reporting and compliance obligations then draw upon that information to provide accountability.

When the hierarchy is reversed, the reporting specification becomes the de facto operating model. The question shifts from “What does this person need, and is our service helping?” to “What information do we need to submit?”

Those questions are not mutually exclusive, but they are not equivalent. One is concerned with purpose. The other is concerned with evidence. Evidence matters, but producing evidence cannot become a substitute for producing the result.

Compliant data is not necessarily good data

Compliance and data quality are often treated as though they mean the same thing. They do not.

Compliance generally means that information conforms to a defined set of rules. A required field contains a value. A date is in an accepted format. A code appears in the permitted list. A record has been submitted within the required period.

Data quality is broader. Good data is accurate, timely, consistent, meaningful and fit for its intended use.

A record can pass every technical validation rule and still be poor-quality data. A field may contain an accepted value that does not accurately describe what occurred. Information may have been entered weeks after the event by someone relying on incomplete notes. Staff may select the closest available option simply to get past a mandatory field. A completed record may satisfy the reporting system while contributing very little to service delivery or program evaluation.

Validation can confirm that a value is present and structurally acceptable. It cannot, by itself, confirm that the value is true, meaningful or useful.

This distinction matters because a compliance-first response to poor data is usually to add more rules: more mandatory fields, more validation, more exception reports and more oversight. These controls may identify some problems, but they also increase the administrative burden. If the information remains disconnected from the work, the underlying reason for poor data has not been addressed.

The compliance cycle

When data is collected primarily because a funder requires it, frontline staff can understandably see the task as administration added to their real work. Information is then more likely to be entered retrospectively, copied from another source or completed with the minimum detail necessary to satisfy the system.

The resulting data is incomplete or unreliable, so managers introduce additional checking and remediation. Staff are asked to correct old records. New validations are added to prevent the same issues. More guidance is written. More time is spent explaining definitions and clearing errors.

The organisation can end up investing heavily in the quality of its submissions without materially improving the quality of its information.

This creates a self-reinforcing cycle:

1. Reporting requirements drive data collection.
2. Data collection is experienced as separate from service delivery.
3. Information is entered late or with limited care.
4. Data quality deteriorates.
5. Additional controls and remediation are introduced.
6. The administrative burden increases further.

Eventually, substantial effort is devoted to making the data appear complete at the point of submission. Yet the same data may still be of limited use to the people delivering or managing the program.

The effect is not limited to workload or data quality. Repeated over time, the controls used to enforce compliance also influence how people think about their responsibilities. Staff learn which activities attract attention, which exceptions require explanation and which results the organisation values. A process introduced to improve reporting can therefore begin to reshape the organisation’s culture.

Data quality should be a side effect of doing the work well

The most reliable information is usually information that people need in order to do their jobs.

When a practitioner relies on current information to make a decision, accuracy has immediate value. When a team uses information to coordinate services, missing data becomes visible. When managers use it to identify demand, allocate resources and monitor progress, inconsistencies have operational consequences. When an organisation reviews outcomes and adjusts its approach, the meaning of the information matters; not merely whether a field is populated.

In these circumstances, data quality is not a separate activity applied at the end of the process. It becomes a side effect of effective service delivery and management.

This does not mean that all reporting data will be naturally produced without any additional effort. Government programs often require consistent information across many providers, and some data will exist primarily for system-wide accountability or evaluation. However, the closer data collection is connected to a meaningful operational purpose, the more likely it is to be accurate and timely.

The aim should therefore be to make the information required for accountability part of the natural evidence produced by the program; not a parallel administrative record constructed for the funder.

Design the work around outcomes

An outcome-focused approach begins with the purpose of the program and works backwards.

What change is the program intended to produce? What services or interventions are expected to contribute to that change? What decisions must practitioners, teams and managers make along the way? What information do they need to make those decisions well? Only then should we determine how that information can also meet the needs of funders, auditors and evaluators.

This approach changes how processes and systems are designed.

Information should be captured when it becomes known, by the person best placed to know it. It should be incorporated into the normal workflow and reused wherever possible. Systems should not ask people to re-enter information that is already available. Validation should occur while correction is practical and should explain the problem in terms the user can understand. Mandatory fields should have a clear purpose, not simply accumulate over successive versions of a reporting specification.

Most importantly, the people entering information should be able to see how it is used. If data disappears into a submission process and provides no benefit to the service provider, it will continue to feel like an external burden. If it informs care, highlights risk, supports coordination or helps a team understand its performance, its value becomes tangible.

Technology can assist, but technology alone cannot resolve a poorly designed model. Digitising an administrative burden does not remove it. A system can make validation faster while still reinforcing the wrong priorities. Good technology makes the correct action the easiest action and allows evidence to emerge from the delivery of the service itself.

Measurement does not merely observe performance; it changes culture

Compliance usually takes the form of measurement. Activities are counted, timeframes are monitored, records are validated and performance is compared against targets. These measures are intended to make service delivery visible and accountable, but measurement is not neutral.

What an organisation chooses to measure; and what it attaches consequences to; influences how people behave. Over time, those behaviours shape culture.

People learn which results attract attention, which failures require explanation and which activities are rewarded. Work that is measured becomes prioritised. Work that is difficult to quantify can gradually be treated as less important, even when it contributes more directly to the intended outcome.

If a program emphasises activity volumes, providers will naturally focus on activity. If it rewards completed records, completion can become more important than the quality of engagement. If timeliness is measured without considering accuracy, speed may improve while confidence in the data declines.

This does not require deliberate manipulation. People adapt to the environment in which they work. When time and resources are constrained, they will prioritise the things that are visible, measured and enforced.

The effects can extend well beyond the data being collected. A culture built around compliance measurement can become cautious and defensive. Staff focus on avoiding exceptions rather than exercising judgement. Managers become concerned with demonstrating control rather than examining whether the process remains effective. Problems may be concealed, minimised or reclassified because reporting them creates additional scrutiny.

In human services, this can be particularly damaging. Effective work often depends on trust, professional judgement, responsiveness and an understanding of individual circumstances. These qualities are difficult to capture through standardised measures. If the compliance framework dominates, staff can receive an implicit message that completing the record matters more than the quality of the interaction.

The organisation may become highly compliant while also becoming less curious, less adaptable and less connected to its purpose.

Program designers therefore need to distinguish between what is easy to count and what is important to understand. Activity, compliance and outputs may all be necessary measures, but they should not be allowed to stand in for outcomes merely because outcomes are harder to define or attribute.

A sophisticated accountability framework accepts that not everything important can be reduced to a mandatory field. Quantitative data may need to be considered alongside professional judgement, client experience and other forms of evidence. The objective is not to collect the greatest possible amount of data. It is to collect enough trustworthy information to deliver the program well, understand its effect and account for the funding provided.

Measures are still necessary, but every measure is also a cultural signal. The question is not simply, “What will this measure tell us?” It is also, “What kind of organisation will this measure help create?”

Put compliance back in its proper place

An outcome-first model does not weaken accountability. Done well, it strengthens it.

Data produced through meaningful operational use is more likely to reflect what actually happened. Reporting derived from that data is more credible. Problems become visible earlier because the information matters within the service, not only when a submission is due. Providers are better able to explain their performance because reporting is connected to the way they manage the program.

Before adding any data item, reporting rule or validation requirement, it is worth asking:

• What decision will this information support?
• Who will use it, and how?
• How does it relate to the outcome the program is intended to achieve?
• Can it be captured naturally as part of delivering the service?
• Is the person entering it able to provide an accurate answer?
• Could the requirement create unintended behaviour?
• What does the requirement communicate about what the program values?
• What would be lost if the information were not collected?
• Are we measuring an outcome, or merely confirming that a process occurred?

These questions will not eliminate every administrative obligation. They will, however, help distinguish necessary evidence from reporting that has become detached from purpose.

Government-funded programs do not need to choose between outcomes, data quality and compliance. The three should reinforce one another. But their order matters.

Start with the outcome. Design services around achieving it. Capture information that helps people deliver and improve those services. Use that information to demonstrate accountability.

When the program is designed this way, good data is no longer something that must be forced into existence at reporting time. It becomes a side effect of doing the work well.