Jack Bauer and Enforcing Data Governance Policies
Jim Harris in Blogs, Books, Data Quality, Methodology tagged Best of 2010, Communication, Data Governance Thursday, June 10, 2010 at 3:00AM In my recent blog post Red Flag or Red Herring?, I explained that the primary focus of data governance is the strategic alignment of people throughout the organization through the definition, and enforcement, of policies in relation to data access, data sharing, data quality, and effective data usage, all for the purposes of supporting critical business decisions and enabling optimal business performance.
Simply establishing these internal data governance policies is often no easy task to accomplish.
However, without enforcement, data governance policies are powerless to affect the real changes necessary.
(Pictured: Jack Bauer enforcing a data governance policy.)
Jack Bauer and Data Governance
Jill Wanless commented that “sometimes organizations have the best of intentions. They establish strategic alignment and governing policies (no small feat!) only to fail at the enforcement and compliance. I believe some of this behavior is due to the fact that they may not know how to enforce effectively, without risking the very alignment they have established. I would really like to see a follow up post on what effective enforcement looks like.”
As I began drafting this requested blog post, the first image that came to my mind for what effective enforcement looks like was Jack Bauer, the protagonist of the popular (but somewhat controversial) television series 24.
Well-known for his willingness to do whatever it takes, you can almost imagine Jack explaining to executive management:
“The difference between success and failure for your data governance program is the ability to enforce your policies. But the business processes, technology, data, and people that I deal with, don’t care about your policies. Every day I will regret looking into the eyes of men and women, knowing that at any moment, their jobs—or even their lives—may be deemed expendable, in order to protect the greater corporate good.
I will regret every decision and mistake I have to make, which results in the loss of an innocent employee. But you know what I will regret the most? I will regret that data governance even needs people like me.”
Although definitely dramatic and somewhat cathartic, I don’t think it would be the right message for this blog post. Sorry, Jack.
Enforcing Data Governance Policies
So if hiring Jack Bauer isn’t the answer, what is? I recommend the following five steps for enforcing data governance policies, which I have summarized into the following simple list and explain in slightly more detail in the corresponding sections below:
- Documentation – Use straightforward, natural language to document your policies in a way everyone can understand.
- Communication – Effective communication requires that you encourage open discussion and debate of all viewpoints.
- Metrics – Truly meaningful metrics can be effectively measured, and represent the business impact of data governance.
- Remediation – Correcting any combination of business process, technology, data, and people—and sometimes, all four.
- Refinement – You must dynamically evolve and adapt your data governance policies—as well as their associated metrics.
Documentation
The first step in enforcing data governance policies is effectively documenting the defined policies. As stated above, the definition process itself can be quite laborious. However, before you can expect anyone to comply with the new policies, you first have to make sure that they can understand exactly what they mean.
This requires documenting your polices using a straightforward and natural language. I am not just talking about avoiding the use of techno-mumbo-jumbo. Even business-speak can sound more like business-babbling—and not just to the technical folks. Perhaps most important, avoid using acronyms and other lexicons of terminology—unless you can unambiguously define them.
For additional information on aspects related to documentation, please refer to these blog posts:
- The Acronymicon
- Podcast: Business Technology and Human-Speak
- The Third Law of Data Quality
- Eternal September and Tacit Knowledge
- Not So Strange Case of Dr. Technology and Mr. Business
Communication
The second step is the effective communication of the defined and documented data governance policies. Consider using a wiki in order to facilitate easy distribution, promote open discussion, and encourage feedback—as well as track all changes.
I always emphasize the importance of communication since it’s a crucial component of the collaboration that data governance truly requires in order to be successful.
Your data governance policies reflect a shared business understanding. The enforcement of these policies has as much to do with enterprise-wide collaboration as it does with supporting critical business decisions and enabling optimal business performance.
Never underestimate the potential negative impacts that the point of view paradox can have on communication. For example, the perspectives of the business and technical stakeholders can often appear to be diametrically opposed.
At the other end of the communication spectrum, you must also watch out for what Jill Dyché calls the tyranny of consensus, where the path of least resistance is taken, and justifiable objections either remain silent or are silenced by management.
The tyranny of consensus is indeed the antithesis of the wisdom of crowds. As James Surowiecki explains in his excellent book, the best collective decisions are the product of disagreement and contest, not consensus or compromise.
Data Governance lives on the two-way Street named Communication (which, of course, intersects with Collaboration Road).
For additional information on aspects related to communication, please refer to these blog posts:
- The Point of View Paradox
- Shut Your Mouth
- Podcast: Open Your Ears
- Hailing Frequencies Open
- The Game of Darts – An Allegory
Metrics
The third step in enforcing data governance policies is the creation of metrics with tangible business relevance. These metrics must be capable of being effectively measured, and must also meaningfully represent the business impact of data governance.
The common challenge is that the easiest ones to create and monitor are low-level technical metrics, such as those provided by data profiling. However, elevating these technical metrics to a level representing business relevance can often, and far too easily, merely establish their correlation with business performance. Of course, correlation does not imply causation.
This doesn’t mean that creating metrics to track compliance with your data governance policies is impossible, it simply means you must be as careful with the definition of the metrics as you were with the definition of the policies themselves.
In his blog post Metrics, The Trap We All Fall Into, Thomas Murphy of Gartner discussed a few aspects of this challenge.
Truly meaningful metrics always align your data governance policies with your business performance. Lacking this alignment, you could provide the comforting, but false, impression that all is well, or you could raise red flags that are really red herrings.
For additional information on aspects related to metrics, please refer to these blog posts:
- DQ-Tip: “There is no point in monitoring data quality…”
- Oughtn’t you audit?
- The First Law of Data Quality
- Data Governance and Data Quality
- Adventures in Data Profiling
Remediation
Effective metrics will let you know when something has gone wrong. Francis Bacon taught us that “knowledge is power.” However, Jackson Beck also taught us that “knowing is half the battle.” Therefore, the fourth step in enforcing data governance policies is taking the necessary corrective actions when non-compliance and other problems inevitably arise.
Remediation can involve any combination of business processes, technology, data, and people—and sometimes, all four.
The most common is data remediation, which includes both reactive and proactive approaches to data quality.
Proactive defect prevention is the superior approach. Although it is impossible to truly prevent every problem before it happens, the more control that can be enforced where data originates, the better the overall quality will be for enterprise information.
However, and most often driven by a business triage for critical data problems, reactive data cleansing will be necessary.
After the root causes of the data remediation are identified—and they should always be identified—then additional remediation may involve a combination of business processes, technology, or people—and sometimes, all three.
Effective metrics also help identify business-driven priorities that determine the necessary corrective actions to be implemented.
For additional information on aspects related to remediation, please refer to these blog posts:
- Hyperactive Data Quality (Second Edition)
- A Tale of Two Q’s
- What going to the dentist taught me about data quality
- Microwavable Data Quality
- DQ-Tip: “Data quality is about more than just improving your data...”
Refinement
The fifth and final step is the ongoing refinement of your data governance policies, which, as explained above, you are enforcing for the purposes of supporting critical business decisions and enabling optimal business performance.
As such, your data governance policies—as well as their associated metrics—can never remain static, but instead, they must dynamically evolve and adapt, all in order to protect and serve the enterprise’s continuing mission to survive and thrive in today’s highly competitive and rapidly changing marketplace.
For additional information on aspects related to refinement, please refer to these blog posts:
- The HedgeFoxian Hypothesis
- The Circle of Quality
- Is DG a D-O-G?
- Data Quality and The Middle Way
- Days Without A Data Quality Issue
Conclusion
Obviously, the high-level framework I described for enforcing your data governance policies has omitted some important details, such as when you should create your data governance board, and what the responsibilities of the data stewardship function are, as well as how data governance relates to specific enterprise information initiatives, such as master data management (MDM).
However, if you are looking to follow a step-by-step, paint-by-numbers, only color inside the lines, guaranteed fool-proof plan, then you are going to fail before you even begin—because there are simply NO universal frameworks for data governance.
This is only the beginning of a more detailed discussion, the specifics of which will vary based on your particular circumstances, especially the unique corporate culture of your organization.
Most important, you must be brutally honest about where your organization currently is in terms of data governance maturity, as this, more than anything else, dictates what your realistic capabilities are during every phase of a data governance program.
Please share your thoughts about enforcing data governance policies, as well as your overall perspectives on data governance.
Follow OCDQ
If you enjoyed this blog post, then please subscribe to OCDQ via my RSS feed, my E-mail updates, or Google Reader.
You can also follow OCDQ on Twitter, fan the Facebook page for OCDQ, and connect with me on LinkedIn.
Reader Comments (11)
I heard from an industry leader that the role of a Data Governance Director has two extremes:
(1) You do a great job, and you are the least liked person in the company
(2) You do a terrible job, and you are the least liked person in the company . . . and you have the benefit of finding new "opportunities"
It does not have to be that way, but like MDM and DQ, the role of a Data Governance Director is an evolving role, and I hope in the near future, that it will be accepted and mainstream.
Thanks Jim.
Thank you Jim! This is one of your best posts I have ever read!
Data Governance enforcement is a combination of straightforward and logical activities that when implemented correctly will help you achieve compliance, and ensure the success of your program. I would emphasize that they ALL need to be part of your overall program, as doing one or a few without the others will lead to increased risk of failure.
My favorite? Tough to choose. The metrics are key, as are the documentation, remediation and refinement. But to me they all depend upon good communications. If you don't communicate your policies, metrics, risks, issues, challenges, work underway, etc etc... you will fail! I have seen instances where policies have been established, yet they weren't followed for the simple fact that people were unaware they existed.
I also like the idea of using a wiki as a means to communicate and collaborate. It can work very well! The challenge, is getting people used to the idea of using it. We've used the "If you build it they will come" strategy, which is working well now but took too long (for me anyway) to catch on. Hmmm, that's probably a subject for another day :-)
Thanks for your comments, Garnie and Jill.
As always, feedback from both of you is great appreciated.
@Garnie — Change agents, like those leading data governance programs, or perhaps more specifically those developing the internal reputation as the Enforcers of Data Governance, can definitely be viewed as a “necessary evil” in many of the same ways as Jack Bauer.
However, many organizations, especially those in the nascent phase of their data governance maturity often struggle mightily without such an unpopular change agent leading the way.
I definitely agree with you that it does not have to be this way. Communication and collaboration, although not easy to foster and sustain, can definitely make data governance less combative—but, sadly, not any easier.
I also share your hope that in the near future, the necessity of data governance will become more accepted, making its corporate cultural transformation go much smoother.
@Jill — Thanks, both for the kind words, and for your thought-provoking request, which lead me to write this blog post. I definitely agree with you that all of the aspects are important, and I would also emphasize the two you did.
The critical importance of truly effective metrics can not be overstated, but communication is the linchpin—as you said, everything depends upon good communication.
Jim,
A very good article that captures the essence of data governance enforcement in a lucid way. My experience in enforcing data governance is that "start small, finish big" tends to work. Identify pain point(s) of business where it hurts the most (Should not be very difficult to identify). Quantify the "business" pain with metrics. Too many initiatives get fascinated by the myriad capabilities of vendor data profiling tools and lose focus on what issue really hurts business the most. If a metric does not convey what it means to business discard it.
Carefully craft policies that are simple to understand, and feasible to follow. Begin enforcing the policies in a group/division/application that gives maximum benefit to business. Demonstrate quick wins supported by "before" and "after" metrics. Build on the momentum and extend the policies to a larger division. Reward people who follow and educate/train folks who are not on board. And yes refine everything with lessons learned.
Here is an example of DG that I like to keep in my back pocket. The government lays the road but also puts speed limit signs (Legislation + Policy) to ensure the safety of the general public (Business Objective). Traffic cops are designated for enforcement (Execution). Law breakers get a chance to go to court for a hearing which may end up with a warning or a ticket or a fine (Judiciary). I recall this from reading Gwen Thomas describe the different arms of DG.
Thanks,
Bhaskar
From the LinkedIn Group for MDM Experts, Sidney Gold commented:
“Data Warehousing tends to fail because of a lack of data quality and garbage in and garbage out after spending millions on transfer of data in the creation of a data warehouse.
Master Data Management tends to fail due to a lack of agreement on semantics and data content and no one with the authority for making the changes.
Data Governance tends to fail due to a lack of agreement, politics and enforcement and coffee discussion sessions which don't get results. The silo applications control the politics of the industry and anyone who opposes or threatens them is doomed to failure or extinction.
You need to send in someone like Jack Bauer.”
From the SmartData Collective, Gary Cokins commented:
I am increasingly a believer that "stages of maturity" models are of high value so that an organization may know where it resides. A problem is some "maturity models" are not sufficiently robust.
Regarding "24" and Jack Bauer, here is a "spoof" I recently wrote. If you have time for a laugh, here it is:
Jack Bauer, 24, Googly, Appel, and Analytics
Thanks Jim, this was a fascinating and clear article.
I follow and focus on Governance and have in the past delivered Best Practices in Data Quality talks - the area of enforcement often comes up in my talk sessions and my recommendations include some suggestions you probably covered elsewhere or maybe not.
I agree with every one of your points however I think the biggest reason, or at least one of the biggest reasons, for tardy or lack of enforcement is there is no one focal point from where the enforcement begins - in other words there is no Strategic Owner or Executive level assigned "Manager of Data Quality" or MDQ.
I always recommend that along with getting Executive buy-in early in the process of defining and designing a DQ project one must always look to get an MDQ reporting to the top brass who also participates in the continual process of justification for the project to the Executive Team. I usually recommend that this same person should be a part of the process for continued process improvement and advises the lower execution teams in building business driven messaging and justification reports to the Executive Team.
As part of his/her role they should be entitled with the ability to drive down from a singular "personal ownership" perspective the organization's DQ policies and enforcements - as you so well stated - as documented. The MDQ should be incentivised to own and execute all communications and enforcement of DQ policies.
What do you think? I would like to see your article expanded a bit on the concept of an MDQ.
Thanks Again,
Orpheo Iyamu
Thanks everyone for the additional (and excellent) comments!
@Bhaskar — I definitely agree that “start small, finish big” is the best approach, and for all enterprise information initiatives, not just data governance. Incremental improvements build momentum to larger success over time. Instead of focusing on the remaining unresolved problems, I always recommend focusing on continuous improvement.
Borrowing the words of Jonatan Mårtensson:
“Success will never be a big step in the future, success is a small step taken just now.”
I agree also with your excellent recommendation that if a metric does not convey what it means to the business, then discard it. The critical importance of business relevant metrics can never be overstated.
Thanks also for providing, by way of Gwen Thomas, an excellent data governance example.
@Orpheo — An Executive Sponsor, Strategic Owner, or using your excellent term, Manager of Data Quality (MDQ), is a vitally important topic, which I have covered to a certain degree elsewhere, but never as a comprehensive focal point. I will write a follow-up post about the role of the MDQ, thanks for the thought-provoking request.
Jim and fellow readers:
Great article and also valuable comments. Enforcement is all about Accountability and Ownership. It's impossible to change behavior without the person wanting to change. People need to TAKE ownership and accountability, not have it be forced (or enforced :-)) upon them.
Back in November of last year, Nancy Raulston posted a great article on her blog:
Creating Accountability
She is one of the best corporate coaches I know and her approach is very applicable to Data Governance. We have incorporated these techniques into our practice at First San Francisco Partners with very good success.
Kelle,
Thanks for your excellent comment and also for sharing the link to Nancy Raulston's great article.
Best Regards,
Jim
Implementing Data Governance – any Governance – is indeed perennially difficult. Worse still is making it stick – keeping it there season after season, as individual members of your organization change and differing ‘perspectives’, ‘strategies’ and ‘priorities’ begin to play around that which you hold sacrosanct.
This, of course misses the point of my earlier comments completely. You see, a data governance ‘program’ is totally unnecessary – though a data governance – or indeed a wider ‘governance’ initiative is essential.
The difference? The ‘Program’ is just that, a discrete undertaking that has a beginning and a middle and, sad to say, an end, at which point everyone breathes a sigh of relief and carries on as they were.
The ‘initiative’ is geared toward having the objectives of the governance program adopted and not the program itself. We do not necessarily need to adopt a ‘Director of Data Quality’ or whatever, but to have put in place processes, tools, practices and standards (and aren’t we lucky we have some nice compliance rules to follow too!) that, by their mere operation, enforce by default those very ‘governance’ means we seek.
Ok, lets pause here for an example. MegaCorp seeks to implement a data quality initiative. Certainly we can go through the whole data quality analysis process to find out what sort of crap we are dealing with and the steps we need to fix it all so it’s all nice and spiffy. The next bit is perhaps a bit (a bit??) simplistic; we can now go on to implement a ‘governance’ program that sets up data governance committees (to set standards and so on) with data stewards (to keep an eye on stuff in their domains) which would work very nicely while everyone remembered what it was it was all set up in the first place.
Trouble is, as soon as anyone takes their eye off the ball, anything that isn’t making money for the enterprise gets the chop. And that’s your ‘program’ down the toilet. Oh, come on, tell me corporations don’t think (no, I guess some really don’t…) or behave like that.
Now, perhaps by comparison we could set out to establish process and data ownership in the processes, integrating the ‘governance’ process into the business process by delineating ‘ownership’ of process or sub-process, data set, meta data or even individual elements (tax codes, anyone?) so that exclusive control is exercised by those who should be doing so in a way that reflects the enterprise’s way of doing business.
Effectively all I am suggesting is that we put the right lock on the right door and give the right people the right key. Then we leave them to decide when to go in and out, but it will be the right people through the right door in the right manner instead of ‘governing’ them. (see, I can even get Thomas Jefferson into this conversation…)
So who decides ‘right’? A number of factors, essentially focusing on the enterprise process framework (you have one, right? Oh, never mind, I have one here I got off John Noakes.) and the business model. Essential, of course is a thorough understanding of your business model to be able to identify key points of ‘delta’ in either process or data lifecycle where controls need to be exercised.
But these were all prerequisites of that ERP implementation you just dropped squillions on, right? That sorted out the implementation of processes supported by technology and structures within the context of best practice, regulation, compliance and, yes, Corporate America, the Law!
Not so fast.
However fabulous your ERP implementation might be you are still at the mercy of our original problem; your people.
A flawless ERP solution and appropriate ‘governance’ standards still have to be run on a daily basis and if you have any inkling of dissent in your ranks, you are still facing the failure of your ‘initiative’.
This, of course is where the culture of the organization has to support the structures of the process. ‘Accountability’ is the name of the game here – those charged with ‘ownership’ not only ‘own’ their fiefdom, but are accountable for the success of its function, whether in terms of operational metrics or simply maintaining standards that the business model deems necessary. Now don’t get me started on the subject of ‘leadership’ and ‘accountability’. That’s for another rant, perhaps…
Nevertheless, implementing ‘governance’ is not something you want to do as ‘governance’, at least in my eyes, either doesn’t really exist as it is a nebulous concept from the word go, or if you try to bolt it onto something else it will, as with all bolted on things, eventually work itself loose and fall off (trust me, I restore vintage British motorcycles…).
Better ‘govern’ your existing processes, technologies and practices to attain the standards of ‘governance’ you (or Sarbanes-Oxley) seek from the core by building in ‘best practice’ from inside.