BeyeNETWORK - The Global Vision for BI and Beyond

I am a diligent wine drinker, and yet merely a semi-diligent exerciser, so unfortunately the two don’t cancel each other out. These are the kinds of games we play with ourselves when we’re in our forties and grasping at absolution. The longer hike for the slice of cheesecake. Working on the airplane to justify the upgrade. Enduring the cholesterol test for the new pair of fabulous crisscross high-heeled sandals. You know what I mean.

As much as we bargain with ourselves, balance is often futile. For instance, most of my clients spend way more time building applications – those units of functionality that support business processes – and far less time on information management and deployment. Application developers are rarely accountable for the data their systems generate. And forget about getting them to adhere to data standards.

Remember information? That collection of data that, when combined in a smart and deliberate way, leads to knowledge? As the now well-worn aphorism goes, it’s a corporate asset. As I’ve said before, business executives are starting to understand this point. Unfortunately, some IT departments aren’t listening closely enough and are still treating data as a by-product of the applications that use it. Old habits die hard; and from a change management perspective, this one’s a doozey.

I’ve been writing and speaking on the topic of business-IT alignment for a while now, and I’m always struck by how powerless people on both sides feel when it comes to reaching out to one another. Most of the problem involves mutual accountability – or a lack thereof. On a good day, people in IT want to protect what they’ve built. (After all, it’s working!) On a bad day, they circle the wagons, avoiding at all costs the conversation with the business wherein they must justify their vendor and technology choices or, worse, their spending.

In such cases, the root causes are predictable. There’s simply no engagement model, and the success of individual projects has no bearing on the perception of IT’s effectiveness. IT is measured in much the same way as any commodity organization: on what it costs the company. IT isn’t measured on the quality of its deliverables and, moreover, lacks the discipline of defining its “desired outcomes.” IT executives should be measuring themselves against those outcomes. There are no well-defined acceptance criteria for projects, so there are no smart answers for why projects cost what they do, or why so many resources were required, or why headcount was transferred so cavalierly from project to project. At the back end, there’s no follow through on whether the resulting system was on-budget, whether it was functional and met requirements, and whether the business was truly satisfied with the results. There are no rewards for good work, or penalties for failure.

And lest you think I’m dumping on IT, the business shares the blame. With undergraduate courses requiring advanced Excel skills and business users debating the merits of regression algorithms versus classification trees at the water cooler, the days of the nontechnical businessperson are a thing of the past. Business users are smarter than ever, and their need for information is nothing less than urgent. The proverbial “shadow IT” phenomenon widens an already gaping chasm.

Some business organizations, dreading the inevitable power struggles with IT, simply go outside to third-party providers to get things done. It’s no secret that IT budgets within line of business organizations have steadily increased over the past decade, and that money is being spent. But even the savviest businesspeople don’t have the knowledge or skills to communicate their requirements in a sustained and structured way to their IT colleagues. And so they don’t.

And we wonder why data governance is so hard.

The premise of any governance program is that the parties involved succeed together or fail together. But in today’s companies, the two organizations working effectively together toward a common set of objectives is usually a happy coincidence, not a well-planned and deliberately designed event. The business gives IT some money, and IT does what it thinks it should. If a project comes in late or a system doesn’t work, no one is authorized to hand out penalties. If something exceeds expectations, no one gives or gets the kudos.

The good news is that, notwithstanding the poor communication and lack of true alignment, data governance can work even in these cultures. The bad news is that it’s not likely to be sustainable without permanent change. I’ve seen several companies enact data governance efforts quickly in response to what I’ll call an “unpredictable external trigger” that essentially forces immediate collaboration.

Recently, the board of directors at a large manufacturing company requested a regular submission of a “Top 100” report of their most profitable clients. What would have been a simple BI query at one company became a major master data management (MDM) project at this firm. Since the manufacturer was so decentralized, with over 100 different global business units and thousands of products, a customer could do business with several or even dozens of the company’s organizations. Never mind conflicting customer definitions – the company couldn’t identify individual customers, nor could it reliably establish corporate hierarchy detail.

An effective IT organization can usually assemble the various technology solutions to address the problem – and yes, an MDM hub was part of the answer. We also launched a data governance effort to ensure that the policies and rules around customer data were sustainable and could live beyond this executive-driven project. In cases where unforeseen demands and external triggers force the issue, data governance is bottom up.

The risk here is that such collaboration is as fleeting as executives’ attention spans are short. Flash-in-the-pan data governance isn’t data governance at all, simply a happy circumstance of temporary teamwork to solve a short-term problem. When begun as a “project,” in a culture rife with ADD, data governance will fail. Would that the best of these brief efforts could be captured like a firefly in a jar, the small beam kept illuminated by a few holes strategically poked from the top.

A study by two professors at the Richard Ivey School of Business in London, Ontario, suggests that the term “organizational change management” is a misnomer, suggesting that all change must be driven at the level of the individual. The authors say:

Only in recent times have managers begun to consider the emotional content and impact of a message in communicating organizational change. Individuals have to “see” and “feel” the message in order for it to have the desired impact. When leaders deliver the message in a way that creates a visible or emotional response, the chance that individuals will change their behaviour is greater.

The fact is, with data governance, as with so many other new initiatives, change starts with people.

And to all you students of data governance, conference attendees, and white paper readers: 1) thanks, and 2) I’m not just talking about the well-worn admonishment to “Find the executive sponsor!” While helpful, edict from the C-suite only gets you so far. And if you have a culture that supports passive-aggressive behavior, it only lasts so long.

Here are four techniques I’ve seen work when it comes to establishing a truly sustainable data governance program for the long term.

1. Don’t just stop at the vision. We design quite a few data governance programs, and it always amazes me how the very people who envisioned the promise of data governance and retain us to instill the new framework nevertheless fall back on the tired email-memo-blast approach – so effective for communicating system downtime broadcasts – for announcing data governance. Moreover, they communicate the “what” but not the “how” or the “why.” A vision statement does not a lasting data governance effort make.
   
   
2. Engage people in one-on-one conversations about data governance. Ask them two questions: “What’s your take on why we’re doing this?” and “How do you think this will affect your job?” Let them talk, let them weigh in, and let them express their concerns. Only when stakeholders, willing or otherwise, feel heard will they actively participate in the changes necessary to deploy data governance. Such conversations remove data governance from an abstract concept and make it real.
   
   
3. Choose your core team carefully. Those of you who have heard me present data governance success stories have heard me tell you not to start a governance program by convening a data governance council. Rather, establish a core team of individuals from different organizations, drawing from both business and IT, and including some external experts. The core team should establish guiding principles for data governance, among other things, designing it before pitching it to a broader community of decision makers, some of whom may be members of an eventual data governance council or steering committee. Since the initial core team is essentially crafting what data governance looks like in the company, its members have to understand it and have the authority to make the case.
   
   
4. Be ready to articulate the first problem. Whether data governance starts with a bottom-up problem or a top-down vision, the ability to execute is key. There’s a short time span between the “what it is” and “how it will help” conversations, and the ability to circumscribe the initial value proposition of data governance can make all the difference.

Those of you who have read Evan’s and my book on CDI, 1) thanks, and 2) you might have noticed that one of the back-cover endorsements is from Jack Trout, the author of Differentiate or Die. This wasn’t just a happy coincidence. Jack’s book is all about change. He talks about the ability to publicize the problem you’re solving in order for a groundbreaking effort to get traction. And so it is with data governance, and with anything that requires a new way of thinking.  

If you found this article helpful and would like to receive the latest data governance insights each month from Jill Dychè, please subscribe to the BeyeNETWORK's Data Governance Newsletter.