Help with the governance problem in front of you

Most governance help fails the same way, and it's a boring way. You get a framework document, an ambitious target operating model and a three-year roadmap. All of it correct. None of it anybody's job on Monday. Eighteen months later the framework is a file somewhere, the roadmap has been superseded twice, and the organization has quietly decided that data governance doesn't work here.

I try to do the opposite. Half an hour or three months, the work ends the same way: named people holding named decisions, written down, with the first few already made.

There are two sizes of help below. Pick the one that answers the question you actually have, not the one that sounds more serious.

Start with thirty minutes on one problem

Not every governance problem needs a project. Most of what reaches me in writing is half an hour's worth of talking to somebody who has already watched that same problem fail somewhere else.

You describe it, we talk it through once, and you leave with a position you can act on. Or with a clear reason why the thing you were about to do wasn't going to work, which is often worth more. It's a paid conversation and not a sales call, and that's exactly what makes it useful: I have no reason to steer you toward something bigger.

A session is usually the right size when:

• The initiative has stalled and you can't name why. There's a council that meets, there's a policy that exists, and there's no change in behavior anyone can point to. Half an hour is usually enough to find the accountability that's missing.
• You're about to choose an operating model and want a second opinion. Federated, centralized, hub-and-spoke: the words are cheap and the consequences are not. Bring the org chart.
• A definition dispute has escalated. Two functions, two numbers, one meeting next week. There's a standard way out of this and it isn't a data model.
• You took the maturity assessment and disagree with the result, or agree with it and can't decide which gap to open first.
• You've been asked to justify governance to a finance function. Bring the calculator output and we'll turn it into an argument that survives a CFO.
• You run governance internally and have nobody to think out loud with. This is the most common reason people come back.

How it works. Send me the problem in writing first. A few sentences is plenty, and the contact form opens with the framing already in place. I read it before we speak, so the thirty minutes go on the answer instead of the background. I reply with times that work across your time zone and mine, usually within two working days. You're asking for a session rather than picking a slot from a calendar: I hold a few open each week, and I'd rather confirm one that suits you than publish a grid that's out of date by Tuesday.

Afterward you get a short written follow-up: what we concluded, what I'd do first, and anything worth reading. That note is yours to forward, which matters when the person who needs convincing wasn't in the room.

What a session is not. It isn't a discovery call. If the honest answer is a multi-week piece of work I'll say so, but the session stands on its own and most of them end there. It isn't a document review service either: send one artifact ahead and I'll read it properly, but send an operating model, a policy set and a quality report and we'll spend the half hour reading. And it isn't training. Getting a whole group to the same starting line is a workshop, a different shape at a different price.

When the problem is bigger than a conversation

These are the four shapes of longer work I actually deliver, and not a menu of hours. Scope, duration and output are agreed in writing before we start, and each one ends with something you own and can keep using without me.

• Governance diagnostic: two to three weeks. Interviews across the domains that matter, profiling of the data behind the disputed reports, and an assessment against the DAMA capability areas. You get a written diagnosis, a ranked list of what's actually blocking you, three costed quick wins, and a maturity read you can put in front of an executive committee. This is where to start when everyone knows something is wrong and nobody agrees what.
• Operating model design: six to ten weeks. Domains, owners, stewards, forums, decision rights and the routes between them, designed for the organization you have rather than the one the org chart implies. You get the operating model document, a populated decision-rights grid, role descriptions with the hours they honestly demand, terms of reference for the governance council, and the first council meeting facilitated with a real agenda.
• Data catalog practice: eight to twelve weeks, one domain. Quality profiling first, so the rules come from what the data actually contains and not from what the schema claims. Then quality rules with thresholds and a named owner each; metadata carrying business context, meaning what a critical field means in business language, who owns it and which reports depend on it; a business glossary written by the domain itself and wired down to the physical columns; and a security pass covering sensitivity classification, who is allowed to see what, and masking where it's needed. You get all of it configured and running inside a tool, a cost-of-poor-quality baseline, and a pattern the next domain can copy without me.
• A monthly block of hours, ongoing. For organizations that already have somebody running governance internally and need a second opinion more than a delivery team. A fixed block each month: reading artifacts before they go to a committee, preparing the difficult conversations, and being the outside voice when an internal recommendation needs weight behind it.

A word on the third one, because it's the piece most often bought and least often used. A catalog is not a documentation project. All of it has to end up inside the tool you already have or are about to sign for — Collibra, Purview, DataHub, OpenMetadata, the pattern travels — with connections and scans configured, profiling on a schedule, rules running against real thresholds, and a breach raising a ticket for the owner of the process behind it instead of landing in a shared inbox. If the glossary lives in a spreadsheet and the rules live in somebody's SQL, you have notes, not a practice.

The other half of the job is deciding who it belongs to. The domain writes its own definitions and approves them; I facilitate and edit, and I refuse to be the author, because a glossary written by the data team is a glossary the business will contradict in the first meeting that matters. Terms get linked to the reports people already argue about, so looking a number up in the catalog is faster than emailing whoever built it. Quality results go to the business owner with the process behind each breach named, and the same numbers turn up in the domain's monthly meeting rather than on a data-team dashboard nobody outside the team opens. That is the whole difference between a catalog people use and an expensive inventory of column names.

The three things every piece of this work holds on to

They're the same three the framework on the homepage describes, and they're why the work above ends in decisions rather than documents.

Governance foundations: the compass. Decision rights, the domains and their owners, policies short enough to be enforced and standards specific enough to be tested. This is the part of the DMBOK that genuinely gets reused, and also the part most often over-produced.

A use case: the engine. Governance that changes nothing in the business has no sponsor and doesn't survive a budget cycle. So the work is always anchored to something the business already wants: a regulatory finding to close, a report nobody trusts, a launch blocked by a data dependency, an AI initiative that can't say what it trained on.

Change management: the heart. This is where most of it falls over. The new behavior has to be easier than the old one, it has to be visibly backed by someone senior, and it has to be rewarded at least once in public. If that isn't designed in from the start, everything else is documentation.

What I will not take on

I don't sell tool selection as governance work. I'll gladly tell you which capability you're missing and what class of tool covers it, but if the definitions don't exist, buying a catalog won't create them. I'd rather say that before the invoice than after.

I also don't take work where the sponsor won't commit an owner. Governance without a business owner who can approve a definition and say no to another function is an exercise, and the ending is visible far enough ahead that it isn't worth either of our time.

Where else this work has been published

I write about data governance for the blog of NowVertical Group, the firm I do this work for as a data governance specialist out of Brazil. Same subject as the articles here, a different editor, and an audience of clients rather than readers of my own pages.

What it costs

A single session is a fixed fee, confirmed in my reply before anything is scheduled. If you decide afterward that you want continuing help, that fee comes off the first invoice of whatever we agree.

Diagnostics and fixed-scope design work are quoted as a fixed fee against a written scope, so you're not buying an open-ended day rate. The monthly option is a block of hours. Workshops are priced per session, and the workshops page covers what's included, down to the private branded simulator space and the facilitator report.

Everything is delivered remotely, in English, Spanish or Portuguese, and I work shoulder to shoulder with whoever runs governance inside the organization, whenever there is one.

Two doors, and you can take either

Ask for a session →: the contact form opens with the first line already written and the request tagged as a session. Add the problem underneath, plus what you've already tried. That second part saves us both the first ten minutes.

Write to me about a longer piece of work →: tell me what's broken and what you've tried, and I'll come back with the shape I think fits and what it would cost. If a session is genuinely the better first step, I'll say that instead.

Not sure yet? Then start with something free. The maturity assessment takes about fifteen minutes and produces a read you can act on with or without me, and the cost of bad data calculator puts a number on the current state, which is usually the shortest route to a funded conversation. And if you'd rather read first and decide later, that's a legitimate choice, and most of this site exists for it. The FAQ covers what comes up in every first conversation, the blog has the long arguments, and the simulators are there if you'd rather make the decisions yourself and watch what happens.