ten mistakes to avoid when launching a data governance programdownload.· ten mistakes to avoid when
Post on 06-Jul-2018
Embed Size (px)
By Jill Dych and Kimberly Nevala
ten mistakes to avoid
When Launching a Data Governance Program
first quarter 2008
10ten mistakes to avoidWhen Launching a Data Governance Program
FOREWORDIn their recent book, Judgment: How Winning Leaders Make Great Calls, management guru Warren Bennis and his co-author, Noel M. Tichy, explain that judgment is a process and not a single event. Good judgment and sound decision making are at the heart of data governance.
Many managers, however, speed down the data governance trajectory in their enthusiasm to support customer relationship management, compliance, data integration, business intelligence, and other high-profile business initiatives, only to collide with the realities of politics, ownership confusion, shaky stakeholdership, and organizational ADD. Even when its necessary and viable, change is hard, and data governance involves change. Moreover, as we discuss here, most companies that fail at data governance wont get a second chance. In this Ten Mistakes booklet, we outline the mistakes weve seen companies make and have helped our clients avoid, in the hope of ensuring that you steer clear of those data governance potholes.
ABOUT THE AUTHORSJill Dych and Kimberly Nevala are consultants at Baseline Consulting (www.baseline-consulting.com), a technology and management consulting firm specializing in data integration and business analytics. A partner in the firm, Jill leads Baselines business consulting practice and is the author of three acclaimed business books; the most recent is Customer Data Integration: Reaching a Single Version of the Truth, co-authored with Evan Levy. Kimberly is a senior consultant specializing in MDM and CDI program planning, design, and governance.
2 TDWI rese arch
1Data governance has become a veritable rubric for all things data. Google the term and youll come up with references to data quality, metadata, data warehousing, data ownership, and data security, to name just a few. We define data governance as the organizing framework for aligning strategy, defining objectives, and establishing policies for enterprise information. What is really important is how you define data governance and how your organization understands it. As nascent as it is, data governance has failed in more than one well-meaning company because people misinterpreted its meaning, its value, and what shape it would eventually take in their companies.
The most common definitional mistake companies make is using data governance synonymously with data management. Data governance is the decision-rights and policy-making for corporate data, while data management is the tactical execution of those policies. Both require executive commitment, and both require investment, but data governance is business-driven by definition, while data management is a diverse and skills-rich IT function that ideally reports to the CIO.
Unlike CRM, whichafter an initial failed attemptwould simply be rebranded The Voice of the Customer and relaunched, once data governance becomes a dirty word, an organization rarely gets a second chance. You cant use the word governance here, one brokerage company executive confided recently. Well have to call it something else. Attempts at euphemistic substitutes dont hide the fact that definitional clarity and a firm vision for data governance do matter.
MISTAKE ONE: FAILING TO DEFINE DATA GOVERNANCE
2As with any strategic initiative that enlists both business and IT and is process-centric and highly visible, data governance must be designed. Designing data governance means tailoring it to your companys specific culture, organizational structure, incumbent ownership environment, and current decision-making processes. It means articulating the value proposition for cross-functional and formal decisions about corporate informationwhether by minimizing compliance exposure or security breaches, over- or under-communicating to customers, consolidating product catalogs, or supporting dozens of other potential business drivers. No two companies treat these issues in exactly the same way, and data governance is never exactly the same across companies.
Consider two of our clients. One client, a multinational bank, is hierarchical and formal. Decision making is top-down. Budget sign-off goes high up in the organization for relatively meager expenses. Executives are big on town hall meetings and roundtable discussions. Consensus reigns.
The other client is a high-tech firm where even business execs are tech-savvy. People come to work at 10 p.m. with a six-pack, the dog, and some really good ideas, and start coding until 10 the next morning, when theyll toss the empty beer cans in the recycling bin, load the dog in the back of the Subaru, and head over to the trailhead. These guys fix their own problems and make their own decisions. Anarchy is the rule.
Data governance looks very different at these two companies. At the bank, three different governing bodies are involved in the data governance process, each with its own checks and balances. The high-tech company relies on established yet grassroots effort. The stewards use an online knowledge base to submit decisions for review, subject to occasional tie-breaking by executives. These stewardship units are endorsed by divisional managers, who want to see measurements for data quality, integration, and deployment velocity improve.
MISTAKE TWO: READY, SHOOT, AIM: FAILING TO DESIGN DATA GOVERNANCE
4 TDWI rese arch
If we had arrived at either of these companies with a best practice template for data governance, we would have been met with rolled eyes and the requisite explanations of why were different here. The high-tech company would have laughed us out of the espresso lounge, had we recommended a single business sponsor. Conversely, the bank requested a formal mission statement with formal hand-off points across different committees for its governance council. In both cases, deliberate data governance design ensured that governance supports the companys culture, organizational structure, implicit hierarchies, and way of doing business, while making sure its value is well understood and ultimately measurable.
3We see it all the time: An earnest visionary perceives the need for data governance. She decides that its time for formal consensus and enlists an executive to support her effort to convene a council of data stakeholders.An e-mail invitation goes out for the council meeting. Its a lunchtime eventPlease make your selection from the attached menuand nearly every invitee shows up. The visionary begins discussing how data is an asset and that the company needs to begin managing it as such. Heads nod. The visionary goes on to explain that the newly formed council should meet regularly and discuss the companys prevailing data issues and address any open problems. The follow-up meeting is scheduled.
Fewer people show up to the next meeting. Someone complains that the company has never really defined the term customer. Someone else pipes up about bad data on the billing system. A sidebar conversation starts on CRM consolidation. The next meeting never happens.
In this all-too-common example, data governance isnt overtly cancelled. It simply fizzles like a damp firecracker. The problem? See Mistake Number Two. Well-meaning people who see the need will gravitate toward the who conversation (Who should be on the council? Who will sponsor it?) before understanding the what and the how. Until a core team of stakeholders deliberately designs a data governance framework (including guiding principles, decision rights, and the appropriate governing bodies), no sanctioned, cross-functional council will have either the clarity or the mission to affect change. There is no free lunch.
MISTAKE THREE: PREMATURELY LAUNCHING A COUNCIL
6 TDWI rese arch
4In a well-intended effort to fix whats broken, many companies will announce data governance with much flourish and fanfare. An executive might assemble a cross-functional team, extracting its members from existing projects, creating an ersatz data governance SWAT team. Others will hang the Center of Excellence shingle and treat data governance as an isolated organization of data-savvy individuals. Still others will inaugurate a data quality task force and call it data governance. In each example, data governance is formed as a discrete effort, when in fact it should be baked in to existing development and decision-making processes.
As those of us in the data warehousing world know all too well, when an initiative is deemed a project, it is, by definition, finite. One data governance project we know was positioned as an 18-month effort to get our data house in order, as if, once finished, the companys data would be perfect and everyone could return to their day jobs.
The reality of data governance is that it should be continuous and systemic. As information needs change, data volumes increase, and new data enters the organization via new systems or third parties, decisions about how to treat, access, clean, and enforce rules about data will not only continue, but theyll likely also proliferate. A structured, formal, and permanent process for making these policies and decisions should be retrofitted into the way a company develops its data and conducts its business.
MISTAKE FOUR: TREATING DATA GOVERNANCE AS A PROJECT
5A key indicator of data governance success is an environment that encourages decision-making bodies. Call them councils, steering committees, management roundtables, or advisory teams. These bodies are usually composed