Data Governance Consultant: Owned Definitions, One Source of Truth, No More Reconciliation Wars

Assigns ownership of definitions, declares a system of record for each one, sets up change control so definitions cannot drift silently, and fixes the capture points producing most of the bad data. In practice that means sitting in the meetings where numbers get contested, tracing disputed figures back to their sources, and getting named business owners to rule on the edge cases in writing. It is largely an operating and authority exercise rather than a technical one. The tooling matters far less than whether a specific person is accountable for what each contested term means.

The definitions are a business responsibility; the implementation is a technical one. The questions that cause reconciliation disputes — whether a paused client is churned, whether an internal correction counts as a defect, whether a client delay stops the clock — are operating judgements with commercial consequences, and a data team has neither the authority nor the context to settle them durably. Governance initiatives led purely by IT tend to produce a catalogue and a policy document while the Monday meeting continues as before. Give definitional ownership to named operating leaders and ask the technical function to implement their rulings.

Stop resolving it in the meeting. Log the discrepancy against the relevant term, route it to that term's named owner, and require a written ruling within a fixed period that updates the definition with a dated note. Apply the ruling to a restated baseline so nobody benefits from having been wrong. Publish every definition change with its effective date, so a metric jumping prompts the right first question — did the business change, or the definition. Where this is followed, disputes stop arriving at leadership and get settled by the person who owns the term.

Not one system holding everything. It means that for each defined term, exactly one system is the system of record, and any report either derives from it or says plainly that it does not. The practical artefact is a short table: term, system of record, owner. Where two systems disagree today, someone decides which wins and the other is retired, made read-only, or labelled an estimate. Where operations and finance genuinely measure different things, do not force them to match — document the difference in one line so it is understood rather than rediscovered.

The diagnostic takes a few weeks. Writing the dictionary for the genuinely contested terms — usually a couple of dozen in a company of a few hundred people — takes a few more, and most of that time is getting owners to rule on edge cases rather than writing prose. The part that takes a full quarter is behaviour: change control being followed, disputes routed instead of argued, capture steps corrected at the teams that own them. I plan for that quarter explicitly, because governance handed over at documentation stage reverts almost immediately.

Not to begin with, and often not at all at this size. Four artefacts do the work: a data dictionary with one page per contested term, an ownership map of systems of record, a change-control rule, and a quarterly review. All of that can live in whatever documentation tool the company already uses. Buy a platform when the manual version has proved itself and the volume of terms genuinely exceeds what people can maintain by hand. Buying first tends to produce an impressive catalogue of definitions nobody rules on.

Because bad data is created at capture, not in the pipeline. Someone rushes a form at the end of a shift, picks an approximate dropdown because the accurate option does not exist, or enters a workaround because the process does not cover their case. Trace the worst fields backwards to the human moment that produced them and the remedies turn out to be operational — remove the free-text field generating nine spellings of one client name, reduce mandatory fields to the ones you actually use, validate at the point of error rather than cleaning up downstream, and measure completeness where capture happens.

They are the same problem at different altitudes. A dashboard is only trusted if its numbers reconcile with what the business already believes, and a KPI framework only holds if every metric has a written definition someone owns. In sequence I usually settle the contested definitions first, then choose the five-to-nine metrics that matter, then build the screen that runs the weekly review. Done in the reverse order, the dashboard launches, loses its first argument about a number nobody owns, and is quietly abandoned within a quarter.