A DG consultant works across three areas simultaneously: strategic (defining program goals, aligning stakeholders, building the governance framework), operational (designing workflows, data quality rules, stewardship processes), and technical (configuring the governance platform, building source system integrations, enforcing metadata standards). The balance between these shifts as the engagement matures – early phases are heavier on strategy and stakeholder work, later phases on technical delivery and adoption support.
The Collibra environment has been live for nine months. The data stewards have accounts. There is a roadmap in a slide deck somewhere. And almost nobody is using the platform in a meaningful way.
This is not an unusual situation. We see it regularly across many industries like banking, pharma, retail, and manufacturing. And it almost always traces back to the same root cause: the wrong consulting engagement at the wrong moment, or the right engagement executed with the wrong partner.
Key takeaways
- Data governance consulting covers business problem definition, framework design, tool implementation, and adoption – not just the technology configuration
- The most expensive mistakes happen at the problem definition stage, not during implementation
- “Too much, too fast” is the single most common pattern behind failed DG programs – we have seen it across dozens of projects
- A good consultant challenges the client’s assumptions; a bad one implements them without question
- Champions on the client side – data domain managers with clear business goals – are a precondition, not a nice-to-have
- Whether a firm can put you in front of the consultant who would actually work on your project, within a week, tells you a great deal about how they operate
What data governance consulting actually covers
Data governance consulting is the strategic and operational work of helping organizations design, implement, and adopt a governance program – from initial assessment through tool configuration and organizational change management.
That definition is broader than most firms describe. The tool side – Collibra configuration, integrations with source systems, workflow setup – is only part of it. Just as important is the business side: identifying what you are actually trying to solve, building a data governance framework that reflects how your organization works, defining accountability, and then making the program stick through adoption.
Data governance, as defined by DAMA DMBOK2, exists to enable organizations to manage data as an asset, and to build the internal culture where people actually care about data . That function demands a scope that goes beyond platform configuration.
Paulina [Solution Architect, Murdio] puts it directly: “It is end-to-end – business consulting, adoption, and technical implementation. Anyone who sells you just one of those three is not selling you data governance consulting.”
The practical implication: when you hire a data governance consulting firm, you are not hiring someone to configure software. You are hiring someone to help you figure out what you need from your data – and then build the infrastructure to deliver it.
Why organizations bring in external data governance consultants
There are three distinct situations that lead organizations to external consulting. Understanding which one applies to you changes what you actually need from a partner.
- The expertise simply does not exist internally. For many enterprises – particularly in markets like Luxembourg, Switzerland, or the Nordics – there are almost no Collibra specialists available locally. Even in larger markets, practitioners who understand both the platform and governance framework design at an enterprise level are scarce. You can hire generalists and train them, or you can bring in someone who has done this twenty times.
- The expertise exists but the scale is too large. Some organizations have capable internal teams who could manage a small DG program. But the scope of what they need – multiple data domains, dozens of business stakeholders, complex source system integrations – is simply larger than any internal team can absorb while running the business at the same time. This is not a skills problem. It is a capacity problem.
- Building internal capability over time. A third model – and one we see more frequently – is hiring an external firm to act as a temporary data governance office while simultaneously training internal staff. The consultants implement, but they also teach. After one or two years, the client has the knowledge to continue independently. Łukasz [Partner, Murdio] describes what clients are actually buying in this model: “They are buying peace of mind – someone who knows how this implementation needs to go and takes ownership of getting it there.”
The most common reasons data governance programs fail – and what a consultant should catch
The main driver forcing Data Governance investment is regulatory pressure – BCBS 239 and DORA in banking, but also similar requirements in pharma and insurance. A good consultant does not treat this as box-ticking. They use the regulatory driver to build something that delivers business value beyond the minimum required. After working across 70+ projects – in banking, pharma, retail, and manufacturing – we have a clear picture of where engagements go wrong. The patterns repeat often enough that they have names.
After working across 70+ projects in banking, pharma, retail, and manufacturing, we have a clear picture of where engagements go wrong. The patterns repeat often enough that they have names.
Wrong assumptions at the starting line
The most expensive failure mode is not bad implementation. It is a bad problem definition. In one retail project, two use cases had been defined at a high level of generality before any consultant was engaged. The implementation proceeded. A source system integration was delivered on time. And the client started using it – five months after it became available. The delay was not technical. The underlying business questions the use cases were supposed to answer had never been validated with the people who actually needed the data. Three months into the project, the scope required a full renegotiation.
The right consulting partner catches this before it becomes a sunk cost. Stan [Senior Consultant, Murdio] puts it directly: “With dozens of projects behind you, you develop pattern recognition. You can ask: where is your real bottleneck? Start there – not with the use case someone in HQ invented six months ago.”
The Ferrari Problem
We have a name for the most common setup we walk into. The client has bought a Ferrari but is either using it as a horse wagon – loaded with every possible task except the one it was built for or does not really know how to drive it (jerking every time it starts moving or changes gears). Enterprise-grade governance platform – Collibra, Informatica, or similar – configured to store descriptions they could have kept in a shared spreadsheet. No real metamodel. No source system integrations. No accountability for metadata quality. Workflows that exist in the system but that nobody follows.
The Ferrari Problem does not come from buying the wrong tool. It comes from never answering the fundamental question: what specific business need or regulatory requirement are you enabling with this platform? A consultant who does not force that question in week one is not doing governance consulting. They are doing configuration work.
Too much, too fast
This pattern shows up in every large enterprise that decides to “do governance properly.” Multiple domains activated simultaneously. New teams onboarded before earlier ones are stable. Parallel workstreams generating contradictory naming conventions. We have seen environments become so cluttered this way that the only viable option was to clear the Collibra environment and restart from a clean state.
The right data governance roadmap for a large organization is sequential, not parallel. One domain needs to be stabilized before the next one can start. Small projects that demonstrate value, not large programs that demonstrate ambition (low hanging fruit / quick win).
Garbage metadata loaded at speed
Metadata quality in Collibra reflects the quality of the inputs. Entering asset descriptions quickly, without enforced standards, produces a catalog that nobody trusts – and therefore nobody uses. A consultant who accepts whatever the client provides, rather than enforcing standards from the beginning, is setting up an adoption failure months before it becomes visible.
What to prepare before bringing in data governance consultants
You do not need a perfect plan before engaging a data governance consulting firm. But there are a few things that determine whether the first three months produce value or produce an expensive set of discovery interviews.
- Name a champion for each use case – not just a sponsor. Without a data domain manager who has a specific business problem, and can say “I need to answer these questions with trusted data, and here is how I will measure success” there is no real use case. Without champions, consultants spend their first months chasing stakeholders who never agreed to be involved.
- Have your current architecture documented – not perfectly, just accurately. Which systems produce your critical data? Where does it flow? Which source systems are you expecting to integrate with Collibra, and which ones have no native connector and will require custom development? As Paulina [Solution Architect, Murdio] puts it: “If we don’t understand your data landscape in week one, we’re spending your budget figuring out what you already know internally.”
- Know what you want the platform to do – not how to configure it. The technical decisions come from the consulting engagement. The business decisions have to come from you. Whether you want to prioritize lineage, data quality governance, stewardship workflows, or regulatory reporting – those priorities shape the entire engagement and the team composition you need. Arriving without them means the first phase is spent extracting them from scattered stakeholders.
Engagement models: single expert, boutique team, or a large generalist firm?
The right model depends on what you are missing internally – not on the size of your organization.
| What you have internally | What you need externally | Model that fits |
| No Collibra expertise, no DG program experience | Full team: Solution Architect, developer, business analyst, adoption lead | Boutique firm with dedicated cross-functional team |
| Strong IT team, weak business-side engagement | Business-focused consultants for stakeholder work and framework design | 1-2 SMEs from boutique firm |
| DG strategy defined, implementation required | Technical delivery team | Technical-focused engagement |
| Want to build internal capability over 1-2 years | External DG office model: implement and train simultaneously | Boutique firm with formal knowledge transfer |
The Murdio model: Subject Matter Experts – including Collibra Rangers, the platform’s highest certification level – anchor every engagement as the competency body. Supporting roles – admins, testers, business analysts – can be client-side or supplemented as needed. After one to two years, clients typically have the internal competence to continue independently. No lock-in by design.
On a large generalist firm engagements.
A staffing pattern worth understanding before you sign: large engagements are sometimes won by senior practitioners and delivered by less experienced team members who have been onboarded to the platform. This is not universal, but it is common enough to warrant a direct question. Ask to meet the consultant who will actually work on your project before the contract is signed. If that request takes weeks to fulfill, you have learned something useful about how the firm operates.
Red flags: signs the firm you are evaluating won’t deliver
These are observable behaviors, not hypothetical risks.
- They show slides but cannot demo the tool. Any Collibra consultant with real implementation experience can open the platform and walk through a live example in thirty minutes. If a firm responds to a demo request with a PowerPoint presentation or a recorded walkthrough, you have your answer.
- They answer questions you did not ask. Łukasz [Partner, Murdio] puts it directly: “When I ask a consultant what they need to know about your situation, the right answer is more questions – not a prepared speech.” A consultant who leads with a pitch is optimizing for their framework, not your problem.
- Their answers sound like the Collibra documentation. There is a version of DG knowledge that anyone can acquire in two weeks from public sources. It covers definitions, platform capabilities, general best practices. It does not cover what happens when two enterprise systems use the same column name to mean different things across tables – and resolving it takes three months of stakeholder interviews. Ask for a specific, uncomfortable example from a past project. If you get a general principle in response, you have your information.
- No case studies with operational substance. Any firm can produce a case study that says “we implemented a data catalog for a global bank and improved data quality.” Ask for the specific use case, the specific integration challenges, how long adoption took, and what went wrong. Absence of operational detail is a reliable signal of absence of operational experience.
- They hire consultants after the contract is signed. Some firms – including established names in the Collibra ecosystem – sell engagements before they have the people to staff them. The engagement starts. There is a two to three month period while the actual consultant is recruited and onboarded. You are paying for that ramp-up time.
- No proactive accountability. If you are chasing a consulting team for status updates two weeks after a milestone, that is a structural problem, not a busy week. Accountability for results – not for meetings held and emails sent – should be visible and agreed from day one.
How to verify a data governance consultant before you sign
Do not ask “what experience do you have with data governance?” The answer will always be impressive and tell you very little.
Ask instead:
- “We have [X] source systems, [Y] data domains, and [Z] business stakeholders who have never been part of a governance program. Where would you start, and what do you see as the biggest early risks?”
- “Walk me through a project where the initial scope turned out to be wrong. What happened, and how did you handle it?”
- “Can we speak with the specific consultant who would work on our project? Next week?”
- “How do you handle a situation where a key stakeholder refuses to engage with the governance program after sign-off?”
- “What would you tell us not to do in the first six months?”
The quality of the answers tells you more than any reference call. A consultant who starts with “that depends on your situation – tell me more” is operating in your world. One who starts with a prepared answer is operating on their own.
One additional test: ask for a short live demo in Collibra – not a recorded video, not a slide showing the interface. Thirty minutes is enough to understand whether someone knows the tool or has learned to talk about it.
Frequently Asked Questions (FAQ)
For organizations starting from scratch, expect 12 to 18 months to reach a stable, adopted program across two or three data domains. Organizations with existing infrastructure and some internal maturity can move faster, but “fast” in governance still means quarters, not weeks. Engagements that promise a complete DG program in 90 days are describing an assessment – not an implementation.
Implementation typically refers to the technical configuration of a governance platform: data model setup, integrations, workflow design, user management. Consulting is broader – it includes defining what to implement, why, and how to make it adopted and maintained. An implementation without consulting often produces a technically functional system that nobody uses. This is, incidentally, where most rescue projects start.
The honest answer is: both, sequentially. Start with external consulting to establish the foundation – framework design, tooling, initial use cases. As the program stabilizes, use the consulting engagement to transfer knowledge to internal staff. Most of our clients reach a point where external support is no longer needed for day-to-day operations, though they typically retain access to specialized expertise for complex integrations or new use case development.
Three things matter most: named champions for each data domain with clear business goals, a documented current-state data architecture, and clarity on what business decisions or regulatory requirements the governance program should enable. For a breakdown of which internal roles need to be involved from the start, see our article on data governance roles and responsibilities.
Costs vary significantly depending on scope, team composition, and engagement length. A single SME for strategic guidance and adoption support costs substantially less than a full cross-functional delivery team. The more useful framing is cost relative to the risk of doing it wrong. The “too much, too fast” pattern described above typically produces a program reset that costs more than a well-scoped initial engagement would have.
The practical difference is who works on your project after the contract is signed. Boutique firms with deep specialization in a single platform typically have their most experienced practitioners doing delivery work. Large firms carry broader capabilities and often more experienced people in the sales process, with varying depth at the delivery level. Neither is universally better – but the risk profile differs. Ask to meet the delivery team before you sign.
The leading indicators are adoption-based: are data stewards using the workflows, are business users querying the catalog, is metadata coverage growing on the defined asset set? The lagging indicators are business-outcome-based: faster audit responses, fewer data incidents, more confident regulatory reporting. For a structured approach to building a measurement framework, see our article on data governance metrics.
Conclusions
Data governance consulting is not a product you buy and deploy. It is a working relationship with a firm that needs to understand your organization, challenge your assumptions about what you need, and deliver measurable results in the platform – not in slide decks.
If you want to discuss your specific situation with the consultant who would actually work on your project, the Murdio team is available – typically within a week.
