In many organizations data governance sits with legal or compliance. It shows up as a policy document, a processing register and an annual training. That work matters, especially under the GDPR. But it misses the part of governance that decides whether analytics and integration projects deliver on time.
The questions that stall a BI rollout or a CRM integration are rarely technical. Which revenue figure is correct? Who decides what counts as an active customer? Who is allowed to fix a wrong record? When nobody can answer, the project waits. Or the delivery team answers on its own, and the business rejects the result.
How governance gaps show up in delivery
Teams rarely call these problems governance. They appear as:
- Definition disputes during acceptance. The dashboard is finished, and two departments say the numbers are wrong because each counts differently.
- Blocked access. Nobody knows who can approve access to a source system, so the request circulates for weeks.
- Silent data fixes. Analysts correct data inside their own pipelines because there is no route to fix it at the source. Every report then disagrees with every other.
- Scope creep through definitions. Each new stakeholder brings a variant of a metric, and the build absorbs them all.
- Late privacy reviews. A data protection question surfaces just before go-live and forces a redesign.
Each of these is a schedule risk, and each is cheaper to resolve at the start than at the end.
Where governance belongs in the roadmap
Treat governance as deliverables on the critical path, scheduled next to the technical work rather than after it.
- Before design: name the owners. For every data domain the project touches (customers, products, orders, contracts), name one business owner with the authority to settle disputes.
- Before build: agree on definitions. Write down each metric and key entity the project will deliver, with its formula, its source and the owner who signed it off. Keep it short. A dozen well-defined metrics beat a hundred vague ones.
- Before build: settle access and privacy. Agree who may see what, which personal data is processed and on what legal basis. Doing this early often simplifies the design.
- During build: set quality rules. For the fields that matter, define what valid means and what happens when data fails the check. Decide where errors get fixed, ideally at the source.
- Before go-live: define change control. Agree how a definition gets changed after launch, and who approves the change.
Keep it proportionate
Governance programs fail when they try to cover everything before delivering anything. A catalog of every table in the company, built ahead of any project that needs it, is usually out of date by the time it is finished. A more workable approach is to govern what the current project touches and extend coverage project by project. Definitions, owners and rules then accumulate where they are actually used.
The minimum useful set is small: an owner per domain, a written definition for each metric in scope, an access decision, and a route for fixing bad data. That fits on a few pages, and it is enough to stop most of the disputes listed above.
Questions to ask at project kickoff
- For each data domain, who can decide which version is correct?
- Which metrics will this project show, and is there a signed-off definition for each?
- Who approves access to every source system involved?
- Does the project process personal data, and has anyone confirmed the legal basis?
- When the project finds bad data, where will it be fixed, and by whom?
- After launch, who owns changes to definitions?
If several of these have no answer, add the missing work to the plan explicitly, with names and dates. It is real delivery work and it will happen one way or another. The only choice is whether it happens early and deliberately, or late and under pressure.
Who should own the work
Governance tasks often fall to the delivery team because nobody else picks them up. That is a mistake. The delivery team can prepare the questions, draft definitions and show the consequences of each option. The decisions belong to the business owners, and the project sponsor should make sure they are taken on schedule.