Listen to this article:
Do or do not. There is no try. – Yoda
I’ve seen dozens, no hundreds of Data Governance articles, books, classes, videos, presentations and conferences. You’d think that we’d have it right by now, but we seem to simply be perpetuating what isn’t working. Enough excuses.
It is trendy to say that “Data Governance has failed.” I’ve read and heard that sentiment many, many times over the past couple years. I even said something like that myself in an article several months ago. Actually, I said that “We must accept that Data Governance as a discipline has failed.” Similar, but with a key distinction.
The problem with the wholesale repudiation of Data Governance is that it implies that we need to throw away what we have and start over.
The foundations of Data Governance have been laid by pioneers and practitioners over the past couple of decades, and those foundations remain strong. Where we have failed is in what we do next.
I have a flat spot on my skull from banging my head against the wall for so long. I hear the drumbeat of thousands of Data Governance practitioners banging their thousands of heads against thousands of walls.
In truth, it’s not that Data Governance the way we’ve been doing it isn’t working, but rather that it’s only working just enough to make more people want to try to do it that way. You can find hundreds of success stories. Thousands of celebratory chicken lunches. A few might reach a maturity level of four or five (however those might be defined), but most don’t. It’s like playing the slot machines at the casino: you win just enough to make you want to play some more, but ultimately you lose more often than you win. We preserve the same only semi-successful approaches.
We are not advancing the art, but rather training the next generation of practitioners to pursue the next generation of underperforming projects.
Think of this like a skyscraper. The foundation supports the rest of the structure, but you don’t build the rest of the structure in the same way as the foundation.
Most all of us in this field, when invited to do some kind of Data Governance something-or-other, approach the job with a well thought out laundry list of things that we’d like to see accomplished. The DMBOK wheel? Perhaps. A roadmap from the last time you were invited to do some kind of Data Governance something-or-other? Probably. We all have a list. I have a list. If you’ve been reading my articles for any length of time you know what’s on it: definitions and expected content. And you know what? I’d be willing to bet that our lists would be right most of the time.
So what. Throw away the list.
When you come with that list in hand you have already biased your understanding of your company’s specific challenges, opportunities, and potential business benefits. You are looking at the problem through the prism of “how can I get the company to implement these things that I know the company needs to implement.” I understand that’s a useful way (sometimes the only way) to cajole a corporation into doing something for its own good that it seems bound and determined not to do. But anecdotal evidence, personal experience, and industry research suggest that’s not going to be successful.
So, before going into more detail about what to do, let’s take a minute to reorient our thinking. Here are some recommendations:
Your company is no different from any other company. You think it is, but it isn’t.
The core challenges are the same everywhere: arguments over definitions, inconsistent and/or unmeasured data quality, unmanaged and/or nonexistent metadata, debates about data decision rights (many of which amount to “I don’t want the responsibility but I don’t want you to have it either”), etc. Every company has legacy systems to deal with. Every company has culture and politics. Every company has siloes and fiefdoms. The key differentiator is execution.
Do not focus on, evaluate, or even talk about tools.
One of the biggest mistakes is to start with technology instead of culture, people, and process. So much software sitting unused or underused because it was purchased to fulfill an expected need instead of an actual need, or because the existing culture and process could not bend to the tool.
It’s easy to see how this happens. For one thing, tool shopping is fun: vendor site-visits, presentations, dinners, demos, and workshops. Everybody likes getting something new.
Another reason is more subtle. You see, projects need funding. Technology (and people) are most often the most obvious expenditures. Anticipated expenditures have to be identified not just at the beginning of the project, but before the project is even approved to proceed. The result is premature focus on technology. On tools. What do you need to get? How much of it do you need to get? How much is it going to cost? Whose cost center is paying for it? Who needs to start working on the contract?
Take a look at the tools if you must. Make a best guess. Come up with a reasonable number. And then forget about it until later.
Do not define a stand-alone Data Governance program.
Do not recruit hierarchical Data Governance councils.
These are also easy places to start. You don’t need to have funding or even an approved project. After all, the key deliverables are usually PowerPoint presentations and meetings with management. Nods all around the table. Handshakes at the conclusion. Then everyone goes their separate ways and very little actually happens.
Data Governance itself isn’t necessarily failing. Again, the foundations are strong, but the execution is lacking.
Hyperbole can draw attention to the problem, but it doesn’t solve the problem. I think that enough of us know that there is a problem. Let’s start fixing it. Stay tuned!
