There are two ways to start a data governance program. You can start from a framework, work out which capabilities you lack, and build a roadmap toward a target state. Or you can start from the things that are visibly costing the organization money and time, fix a few of them with governance, and let the framework fill in behind you.
The first approach produces better documents. The second produces programs that survive their first budget review.
This is not an argument against frameworks — I use DAMA DMBOK constantly, and a capability model is the right tool for planning year two. But a governance program has to earn its credibility before it can spend it, and the only currency anyone outside the data team recognizes is a problem they already complained about, now gone.
So start with the pain. Here is how to find it, and what governance can actually do about each variety.
The six pain points that justify a governance program
Across engagements, almost everything organizations describe as a "data problem" resolves into one of six patterns.
Data silos
Departments hold their own copy of shared information, because at some point getting it centrally was harder than rebuilding it locally. The visible symptom is duplicated effort; the expensive symptom is that the copies diverge, and nobody can say which is right.
The governance response is not "consolidate everything" — that is a multi-year platform program, not a governance act. It is to name the authoritative source per shared entity, declare the others derived, and publish that decision somewhere findable. A data catalog helps, but the decision matters more than the tool.
Data quality problems
Records are incomplete, stale, duplicated, or wrong. Everyone knows about it, and the knowledge lives in workarounds: the analyst who always filters out test accounts, the ops team that re-keys addresses before shipping.
Governance contributes the part that engineering cannot supply: which attributes matter enough to measure, what tolerance is acceptable, who accepts the risk when it is breached, and who is accountable for the fix. Without those four answers, data quality tooling produces dashboards that measure everything and change nothing.
No clear ownership
Nobody is accountable, so issues get discussed and not resolved. This is the pain point that most reliably indicates a genuine governance gap rather than a technical one, and it is also the cheapest to address: naming a data owner per data domain costs a decision, not a budget.
The test I use in a first workshop: name the accountable person for your top five domains. If it takes longer than a minute, or produces a team name rather than a person, that is your finding.
Inconsistent definitions
Two teams report "active customers" and the numbers differ by eleven percent, because one counts a login in the last 90 days and the other counts any account without a cancellation. Both are defensible. Neither is authoritative.
This is what a business glossary exists for, though the glossary is the artifact rather than the fix. The fix is that someone has the authority to approve one definition and the reports get changed to match it.
Data that is hard to get to
Access takes three weeks and two escalations, so people build shadow copies. Restrictive access controls with no workflow around them do not reduce risk; they relocate it into spreadsheets nobody can audit.
Governance's job here is a classification scheme, a standing approval rule per tier, and a service level on the decision. Most access friction is not a security requirement — it is the absence of anyone empowered to say yes.
Compliance and security exposure
Sensitive data is in places nobody has mapped, retained longer than any policy allows, and copied into environments with weaker controls. This is usually discovered by an audit rather than an incident, which is the good outcome.
Governance supplies data classification, retention rules with a trigger, and a named owner for each PII domain. The engineering work follows from those decisions and cannot precede them.
| Pain point | What it costs you | The governance remedy |
|---|---|---|
| Data silos | Duplicated effort, divergent copies, unresolvable disputes | Authoritative source per entity, published and enforced |
| Quality problems | Rework, manual reconciliation, distrust of reporting | Critical element list, tolerances, accountable owner |
| No ownership | Issues discussed and never closed | One accountable individual per domain |
| Inconsistent definitions | Conflicting numbers in the same meeting | Approved definitions with an arbiter |
| Poor accessibility | Shadow data, slow analysis, unauditable copies | Classification tiers with standing approval rules |
| Compliance exposure | Audit findings, fines, remediation projects | Classification, retention, named PII ownership |
Why pain-first beats framework-first
Two things make the difference in practice.
The first is that a pain point comes with a sponsor attached. Somebody already cares, has already escalated it, and will already vouch for you if it gets fixed. Capability gaps identified from a framework have no such constituency — you have to manufacture the interest, which is most of the reason governance programs spend their first six months on internal communications.
The second is that the remedy is testable. "Reduce time to resolve a definitional dispute from three weeks to three days" either happened or it did not. "Reach level 3 in metadata management" is a claim only the data team can evaluate, which means it is a claim only the data team believes.
Finding yours in two weeks
You do not need a maturity assessment to locate pain. You need four inputs and two weeks.
Interview the people who complain. Ten to fifteen conversations, thirty minutes each, spread across business and technical roles. The question that produces the most useful answers is not "what are your data problems?" — it is "what did you do last week that you shouldn't have had to do?" People describe workarounds vividly and problems abstractly.
Read the escalations. Whatever your organization uses for incidents, tickets, or audit findings, pull the last twelve months and code them. Most organizations find that four or five root causes account for the majority, and that at least one has recurred quarterly for years without anyone owning it.
Sample the data itself. Pick your three most-used datasets and run basic data profiling: completeness per attribute, duplicate rate on the natural key, value distributions against expectation, freshness against the stated schedule. Two days of this converts "quality is bad" into a number, and a number is what gets funded.
Survey the consumers. Short and quantitative: how much do you trust this report, how long does it take to get data you need, how often do you rebuild something that exists elsewhere. Ten questions, whole-team distribution. The value is the spread — a department that trusts nothing is a different problem from an organization that trusts everything equally poorly.
Turning findings into a backlog
Fifteen problems will come out of that exercise, and the temptation is to write a roadmap that addresses all of them. Score them instead, on three axes:
- Frequency — how often it bites. Weekly beats annually.
- Cost — what it consumes in hours, rework, or risk. If you cannot estimate it, the cost of bad data calculator will get you to a defensible order of magnitude.
- Addressability by governance — whether a decision can fix it, or whether it needs a platform migration. Be honest here. Pain that requires eighteen months of engineering is real, but it will not demonstrate anything this quarter.
Take the two or three that score high on all three axes and do those first. Publish the before-and-after number. Then use that result to ask for the structural work.
What this looks like when it works
A retailer with inconsistent product data. Regional systems and the e-commerce platform disagreed on descriptions, pricing, and stock. Customers saw wrong prices; orders were canceled after purchase. The remedy was master data management for product — but the governance act that made it possible was deciding which system was authoritative for each attribute, and getting the merchandising director to own that decision. The MDM project had been proposed twice before and failed both times on exactly that question.
A financial institution with unmapped sensitive data. An internal audit found customer data in systems outside the scope of any control, with no accountable owner. The remedy was classification, lineage capture, and named ownership of the customer domain. What made it stick was that the audit finding gave the ownership question a deadline, which is the one thing that reliably converts a governance recommendation into a governance decision.
The trap to avoid
There is a failure mode in pain-first governance, and it is worth naming: the vanity pain point. Someone senior has a particular complaint — usually about a report they personally use — and it becomes the program's first initiative because it has sponsorship.
Sometimes that is fine. Often it is a narrow problem affecting one person, and solving it teaches the organization nothing and proves nothing about governance's value. If a senior stakeholder's pet issue does not score well on frequency and cost, fix it quietly as a favor and choose something else as your demonstration case.
Where to go from here
Diagnose, score, fix two things, publish the result. That is a first quarter that earns you a second one.
Once you know what hurts and why, the structural questions become answerable: which domains need owners, which decisions need a home, and how much governance your organization can actually staff. Building a Data Governance Operating Model covers that next step, and Introduction to the Basics of a Data Governance Program sets out the foundations in order. If you would rather start with a structured read on where you stand across all four dimensions, the maturity assessment takes about ten minutes.