We attended an industry event recently, and during the meet and greet portion we got to talking about what we do. The minute we mentioned "data governance," the response was something like: "you mean policies?". In this blog post we will discuss data policies and that they should take action, not to avoid taking action.
Policies. (Really?) On the bright side, that gave us an avenue to talk about our approach to data governance at IData, and how our Data Cookbook solution gives organizations meaningful and productive ways to actually practice data governance by tying it to regular activities and practices. On the darker side, it reminded us how much progress remains to be made, and how much work is yet to be done.
Let's be clear: there is nothing wrong with having policies about your organization's data. In fact, having at least some is a practical (and legal, and ethical) necessity. Policies can help guide people's thoughts and behaviors, they can set boundaries and guardrails that help minimize risk, they can help protect people and entities that need and deserve protection.
But, people violate policies all the time, sometimes intentionally, often by accident. People forget. People are busy. Policies change. And policies are generally backwards-looking: when ChatGPT was introduced to great fanfare a couple of years ago, was it obvious how your data policies applied to its use? Moreover, who is responsible for writing policy? for enforcing it? for evaluating whether it's any good?
We've observed for a long time now that one of the reasons data governance efforts fail to launch is "death by committee." When meetings drag on or must be repeated, when action items and decisions continually get pushed into the future, and/or when people are included because of their rank and not their interest or expertise, not enough gets accomplished. People lose interest. We've all seen what happens.
Another reason that data governance efforts fizzle out is that organizations spend too much of their initial energy and goodwill on issues that don’t matter to enough people. The focus invariably narrows to things important only to the loudest speakers. If your focus is on crafting policies, especially policies about data security and user roles, then you're probably going to spend a lot of time negotiating around a (virtual) conference table about topics that most people are probably only marginally interested in to begin with. Now, committees are often useful, and these negotiations are important. But even the best-intentioned policies are almost always reactive, and they almost always seem to be a list of things not to do.
How can data governance initiatives launch and reach orbit, so to speak? We've always found that new initiatives work best when they actually solve problems, when they help people and make people more successful in their jobs. This is any kind of initiative: new or migrated software, organizational restructuring, upgrading facilities, even relocating the office.
And when policies and restrictions or other bottlenecks prevent people from completing their work, they find ways to sidestep all of those. Does it take too long to get a data product from the BI team? Get a big data set from them, and maintain it yourself in a shadow system of your own devising. Can’t get official access to the data that another office has collected? Start collecting it yourself, or make friends with someone who has that access and is willing to share.
Do these techniques duplicate work someone else is doing? Sure. Does it introduce the risk of a breach or data loss? You bet. Are they unproductive? Probably. Can I generate the thing I need when I need it, instead of getting in line with everyone else and waiting who knows how long? We all know the answer to that question.
So. How does data governance enable users? We happen to think that's a long, long list. Maybe start by asking something other than what can people not do with this data, or which users should we prevent from seeing this data. For example, "What should we do with/about this data?" Or perhaps, "How can we use this data to make our tasks easier or our organization more profitable?"
What do we need to do to/with/about our data in order to answer these questions?
While that’s a somewhat rhetorical question, let’s provide some broad answers. We need to be able to provide trustworthy data in a reasonable timeframe in enough formats and outputs for our users to understand and act on that data. Those users need a framework to request data, and to ask additional questions about the data. And as with any process, there needs to be a mechanism for providing feedback in order to improve the entire operation.
What we’ve described there is the impetus for a version of data governance that will endure. Too often, data governance is envisioned and experienced as setting up barriers in order to protect...well, something. But what about conceiving data governance as the things you do when you're trying to break down the barriers that prevent its effective use.
What are some of those barriers? We’ve written in this space about how hard it can be to find out whether your organization already collects data you’re interested in. Another, not unrelated barrier, is the perception—or actuality—of poor-quality data. A third common barrier is not having a shared understanding of what data means (frequently, there’s not even a shared terminology to refer to data, much less a common understanding). Our Data Cookbook solution is designed to help you bring down these barriers, among others, but even if it’s not the tool for you—or not right now—you will still benefit from identifying how these barriers manifest at your organization, and taking steps to weaken them.
From what we’ve seen, it’s almost impossible to develop a culture of data without a strong infrastructure to govern and manage data. How do consumers improve their data fluency without knowing who’s responsible for collecting and defining data? How can leaders make data-driven decisions when data sets have not been visibly curated and data products publicly validated? How can data be taken seriously as an asset when the organization’s default position is to obscure its existence, put up roadblocks to people’s access to and use of data, and when we don’t commit to continuous quality improvement and data enrichment?
Back to policies. Too many policies—and not just about data—assume that people won’t be careful, don’t take their responsibilities seriously, and can’t be trusted to do the right thing. Overwhelmingly, we have observed that the opposite is true: people want to be scrupulous, they understand very well the consequences of risky or careless actions, and they want nothing more in their work than to fulfill requirements to the best of their ability.
More carrot, less stick. Why not favor data policies that are tied to positive, forward-thinking actions? For example, if you have an inventory of data tools and applications, perhaps the policy is that users must consult that catalog prior to purchasing new applications, so as to avoid duplicating existing functionality. The policy is to take action, not to avoid taking action.
Users are going to create a massive inventory of data products, and it might be good money after bad to spend staff time trying to prune obsolete or duplicate products. But what about a process to certify key dashboards, for example? Certified dashboards go through a rigorous review process, and are understood to represent agreed-on facts about the organization, whereas others cannot be used to source presentations or official publications or public responses. The policy is about seeking certification for published data, not about not sharing data.
Many organizations have long required some amount of User Acceptance Testing (UAT) prior to moving data products into public folders, or releasing data sets into the enterprise data warehouse; what if that UAT included not only approval but also some level of business-oriented documentation? The policy focus is on documentation and transparency, not on a de facto standard of preventing access.
Policies that grow out of data governance's best practices seem more likely to be observed, to effect positive change, and to ensure that data governance becomes central to your organization;s planning and operating. To access other resources (blog posts, videos, and recorded webinars) about data policies feel free to check out our data polices spotlight page.
IData has a solution, the Data Cookbook, that can aid the employees and the organization in its data governance and data intelligence efforts including data policies. IData also has experts that can assist with data governance, reporting, integration and other technology services on an as needed basis. Feel free to contact us and let us know how we can assist.
(Image Credit: StockSnap_5NIQZH26WY_colorjournals_datapolicies_BP #B1274)
