Data governance has a bad rap. Rightly or wrongly, people think that it’s just too much to take on, that it introduces additional – and unnecessary – layers of bureaucracy, that its procedures are onerous, confusing, and restrictive. In practice, unfortunately, this is frequently the case.
It doesn’t have to be.
Successful data governance has to do with how and where you begin. In Greek mythology, the goddess Athena emerged, fully grown, from Zeus’ head. Many organizations expect to pull off the same trick with data governance. They start big, with a top-down push to bring governance to all relevant domains. Initiatives of this kind can work, although – owing to their cost, complexity, and enterprise-wide scope – they’re more likely to drag on for years and run significantly over budget. Ultimately, they’re what gives data governance a bad name.
I like to think that there is a better, more pragmatic alternative. Instead of starting with a complete, multi-domain data governance program – i.e., a top-down-first approach – consider taking a cue from the agile project management world and start small. Look for projects, processes, or business domains that are good candidates for data governance. Start with the users or business areas that are experiencing the most pain. At the same time, cultivate a grassroots effort by emphasizing outreach to the lines of business and, crucially, tapping line-of-business experts for data stewardship and data ownership roles. The idea is that you’re bootstrapping your data governance program by growing it, iteratively, from the bottom-up. As your program grows, you’re codifying repeatable procedures that you will formalize as part of your organization’s core data governance policies. Once your bootstrapped data governance program has attained a sufficient degree of critical mass, it’s time to take it to the C-suite. Many enterprise-wide data governance programs started out just like this.
Here are a few practical guidelines for bootstrapping your data governance program.
Think globally, act locally. The impetus for data governance often begins at the grassroots level – i.e., with the people closest to the data. Think of the business users who work with and consume the reports, scorecards, dashboards, and analytic insights generated by the data warehouse as akin to canaries in the proverbial coal mine: they provide a kind of early-warning system for governance-related issues. A grassroots data governance effort usually begins with them. Reach out to managers and other important stakeholders on the business side. Ask them to identify the people in their functional or organizational areas who know the data best. Bingo: these are your grassroots data stewards. They can identify common pain points and pinpoint the types of errors they see on a daily, weekly or monthly basis, as well as ferret out hidden areas of risk. Bear in mind, too, that some on the business side -- the business subject matter experts (SME) and business analysts who know the data inside and out – should also be involved in any governance effort. SMEs and analysts are familiar with the data structures that are (supposed to be) instantiated in the data warehouse: they helped to codify them! On top of this, they have detailed knowledge about the nitty gritty of the business, from the source transaction points used as grist for the data warehouse’s fact tables to the manual processes by which data is entered into upstream systems. Rely on their expertise.
Line-of-business involvement is crucial for several reasons. First, it’s the best way to identify and redress common data governance problems. Second, it gives the (often frustrated) lines of business a voice. And not just a voice, either, but a kind of agency, too. Because data stewards occupy leadership roles in the data governance program, they’re empowered to actually do something about the governance issues that are at the root of their frustration.
Write it down: document and formalize your grassroots effort. Document the procedures you created when you bootstrapped your organization’s data governance program, starting with the criteria you used to identify and nominate data stewards and data owners. Your purpose is two-fold: in the first place, your organization can use this information to define the repeatable procedures it will instantiate as part of its core data governance policies. These policies will, in turn, form the foundation of its formal data governance program. Because the procedures your organization captures are, in a sense, empirical – i.e., they were reverse-engineered from the ground-up – the formal policies and procedures it creates from them will tend to be more robust. Second, package what you have into a presentation that you can use to build support among business leaders. Present what you have as a kind of “governance blueprint:”, a foundation for a formal, business-driven data governance structure.
Remember, people often think of governance as a four-letter word. This is true even when the lack of data governance standards is a source of undeniable pain for the business: people are fearful, not without reason, that a formal governance program will, in practice, prove invasive, restrictive, or onerous. Another, related problem is that business leaders tend to view governance as a technology-centric problem. Data governance, they think, is defined and enforced via technological controls – e.g., in the data layer. Demonstrate that the business itself must play an active, leading role in creating and enforcing data governance standards – as data owners and data stewards – and you’ll have an easier time securing buy-in.
Iterate. Iterate. Iterate. Data governance isn’t a monolith. Here as elsewhere, a pragmatic, iterative approach is in order: instead of trying to take on everything at once, focus on manageable, high-value projects, at least at first. (Wherever there’s governance-related pain, there’s potential value.) Look for quick wins, and build on your early successes.
Above all, continue with your grassroots approach. Map your core processes one at a time, starting, again, with the people who are closest to the data. Enlist the relevant business and IT stakeholders to determine what controls, if any, you’re using to govern how data is sourced, persisted, used, changed, and retained. Keep in mind, as well, that relatively routine business events – such as the launch of a new product – can provide both an impetus and an opportunity for remedying otherwise neglected governance issues. Here’s a thought experiment: A financial services firm makes a chilling discovery as it’s preparing to bring a new mutual-fund product to market. The firm had mapped out all of the data points in its existing portfolio of mutual-funds, but it had neglected to map out the core process of creating a new fund. What’s more, as it reverse-engineered this process, the firm discovered that each and every participant in the process flow has his or her own checklist, and that these checklists are specific to each individual participant’s domain. As a result, the organization has almost no insight into what’s going on across different domains. By reverse-engineering this process flow, the organization was able to identify data entry and touch points, map out potential bottlenecks, and, most important, pinpoint issues that it would not have known about had it been following a traditional (i.e., primarily top-down) approach to data governance.
Don’t boil the ocean. Every organization wants a data governance program that emanates from the C-level. This entails CEO- and CIO- level backing, along with the creation of completely new C-level positions, such as a Chief Data Officer or Chief Data Steward.
That’s the goal. Realizing that goal is another matter. By starting at the grassroots level and working iteratively, it’s possible to build out a robust bottom-up framework that addresses many of the key people, process, and procedural aspects of data governance.
As anyone who’s ever been involved in a master data management (MDM) effort will attest, however, getting key stakeholders in different domains to agree on reference definitions – not just about the terms themselves, but about what they mean – can be a herculean task. This is why an enterprise data governance policy must emanate from the C-level. C-suite executives have the power to reign in recalcitrant stakeholders and mandate consensus. Strong C-level backing can make the difference between an organization that’s riven by competing (and sometimes irreconcilable) data governance standards and one in which data governance is consistently practiced across all domains. The danger is that a CEO or CIO might be tempted to go big – i.e., to boil the proverbial ocean – by pushing a governance initiative that simultaneously targets all domains. This is a mistake. Here, again, an iterative approach is best. Work with executives to identify specific tasks in specific areas that it’s worthwhile to focus on. (Most efforts start with customer or product data, each of which is a minefield of competing definitions, priorities, interests, and egos.) Take it one day – or, rather, one project – at a time, and don’t be afraid to market your successes. Success, after all, is contagious.
There are two strategic assumptions here. The first is that data governance will become an organic, integral part of every process – not something that’s added to, separate from, or somehow imposed on the process. The thing about data governance is that it has to be at least a little burdensome. There are plenty of examples, however, of governance-like requirements that are experienced as more or less routine. For example, a professional pilot must complete a preflight checklist before her plane can be cleared for takeoff. To an outsider, going through a checklist might seem onerous or burdensome; to the pilot, it’s standard operating procedure. So it is with data governance: when it’s practiced by everybody in the organization, sooner or later, governance becomes standard operating procedure.
The second assumption is that data governance is not a one-and-done type thing: you aren’t “finished” with data governance once a particular project goes live. In fact, you’ve got to maintain your data governance assets (people and process components, procedures, and policies, along with their enabling technology bits) just as you do your other business assets. This requires updating them to address new or revamped regulatory requirements, changing business conditions, and/or the vicissitudes of everyday life. In a sense, good governance is a function of aligning the practices and standards of the business with those of IT. This alignment itself is prone to drift, or change, over time. It, too, must be maintained.