Data Governance
The rules determining who may change what, how changes are reviewed, and how they are recorded. The control that stops a designed system from drifting back to whatever it was before.
What it assigns
Decision rights and accountabilities. Who may create a field, who may change a definition, who is answerable when a definition proves unfit. Describing it as a data quality project misidentifies both the work and its output — quality is a consequence of governance, not a substitute for it.
Quality means fitness for use
The data quality literature establishes that quality is multidimensional and defined by the consumer's use, not by accuracy alone. An owner field can be accurate and useless if it populates after routing has already fired. An industry value can be complete and useless if two teams read it differently.
| Dimension | A concrete failure | How to test it |
|---|---|---|
| Accuracy | Stale employee counts | Sample against an external source |
| Timeliness | Enrichment lands after routing | Compare populate time to consume time |
| Completeness | Routing fields empty on inbound | Null rate on fields rules read |
| Interpretability | Two teams read a stage differently | Ask three people to define it |
| Accessibility | Data sales cannot query | Trace the consumer's actual path |
Source: Dimension framing per the data quality literature
Fitting a configuration
Identify consumers and uses first. For each data domain, list who consumes it and for what decision. Governance without an identified consumer has no fitness criterion and defaults to accuracy.
Write down the contingency factors that apply: size, how centralised decisions are, how standardised processes are, regulatory exposure, diversity of business models. This is the step a template skips.
Assign decision rights domain by domain rather than uniformly. Account data and pipeline data often warrant different configurations in the same company.
Govern the flow before the stock. Entry controls, ownership at creation and definitional change control set the steady state; cleanup only sets the initial condition.
Re-examine when a contingency factor changes — an acquisition, a new segment, a move to self-serve invalidates a configuration fitted to the previous state.
The failure mode to watch
RELATED TERMS
Data Hygiene
The continuous practice of keeping records accurate, complete and current — as distinct from data quality, which is the state that practice produces.
Single Source of Truth (SSOT)
The declared authority for a given piece of data — the system whose value wins when two systems disagree. Correctly applied it is decided per field, not per system.
Systems of Record
The set of systems that each hold authoritative data for part of the business, and the map of which owns what. The architectural decision underneath every reporting question.
COMMON QUESTIONS
- What is data governance in revenue operations?
- The assignment of decision rights and accountabilities over data: who may create or define a field, who may change it, and who is answerable for whether it is fit for use. It is an authority structure, not a cleanup project.
- Is there a standard data governance model?
- No. Research on governance design finds configuration is contingent on organisational factors — size, centralisation, process standardisation, regulatory exposure — rather than universal. A model imported wholesale from another company is fitted to that company's contingencies.
- Why do data cleanup projects not stick?
- Because cleanup addresses the stock while the process keeps producing the flow. Without decision rights over what enters the system, the corrected state decays at the rate defects are generated.
- Do we need a data governance council?
- A council is a coordination mechanism, appropriate where decision rights genuinely span functions. Where a single owner would be faster, standing one up produces meetings instead of authority.
WHERE THIS HAS BEEN APPLIED
Client work and research from RevOps HQ, our consulting practice.
FURTHER READING
Design Factors in CRM Adoption: Applying Technology Acceptance Research to Revenue Systems
Adoption research identifies perceived usefulness as the principal determinant of system acceptance. This paper applies that finding to CRM implementations and sets out a diagnostic distinguishing design causes from user discipline.
Process Ownership and Revenue Leakage: A Taxonomy and Measurement Protocol
A four-state taxonomy of process ownership, an account of why unowned work is invisible to event-driven reporting, and a four-step protocol for quantifying the exposure against an organisation's own data.
Contingency Factors in Data Governance Design for Revenue Systems
Governance research finds that no single governance configuration fits all firms — the appropriate design depends on identifiable contingency factors. That finding contradicts most of what is sold as governance best practice.
Why Two Dashboards Show Different Numbers
When two reports answer the same question differently, the cause is almost never a broken report. It is an undeclared owner for a field, and it is fixable in an afternoon once you know where to look.
Learn how to apply this: CRM Admin 101
Definitions are the vocabulary. The courses are where you learn to operate it, with the interactive audit tools.
See the course