One Reason Why IT Should Lead on MDM, Data Governance

Loraine Lawson

Jill Dyche's recent post contains one of the most depressing statements about what won't change in 2011-what she termed an "anti-prediction"-that I've seen:

The business side won't be interested in helping to define new rules of engagement with IT. They'll simply wait for IT to tell them how to engage. And then they'll refuse to play.

It's depressing because we all know it's true, at least in most organizations.


I thought of her anti-prediction while reading Rob Karel's recent post about the necessity of coupling data governance with master data management. Karel, who specializes in MDM at Forrester, warns that all MDM practitioners and data quality/governance evangelists must take up this call to arms:

Data governance is not-and should never have been-about the data. High-quality and trustworthy data sitting in some repository somewhere does not in fact increase revenue, reduce risk, improve operational efficiencies, or strategically differentiate any organization from its competitors. It's only when this trusted data can be delivered and consumed within the most critical business processes and decisions that run your business that these business outcomes can become reality. So what is data governance all about? It's all about business process, of course.

And therein lies the rub: You'll need business engagement to drive it across the organization, to create what Forrester terms "process data management."


Dyche's words about the business refusing to play echoed back to me, along with her anti-prediction about data governance in particular:

Even if they are presented with proof of value, management will be reluctant to invest in data governance. Why? Because managers aren't rewarded on economies-of-scale, they're rewarded on revenue realization. So all the duplicate work, re-work, and skunkworks efforts don't count. What counts is how data governance will help generate revenue, which is a much more difficult pitch, and they won't invest in that either. (Ditto for data quality and MDM.)

No wonder Gartner is predicting that for the next four years, 66 percent of organizations that start an MDM program will struggle to demonstrate its business value.


A professor I knew said everybody can be divided into two groups: Lear people and Hamlet people.


Is IT doomed to play King Lear, embracing too quickly the words of vendors then railing "madness" against an unsympathetic storm as the business turns against it? And must the business always play Hamlet, bemoaning the state of affairs, but unwilling to take any decisive action?


Not necessarily. It turns out, Dyche actually highlighted a way out of this cycle back in 2008, when she wrote about Dell's successful MDM initiative where IT led the way.


Now, IT leading the way can be a disaster for any project and it is generally advised against it when it comes to MDM. In fact, John Radcliffe, research vice president at Gartner, recently warned against this approach, saying it can be hard to obtain business buy-in, which can thwart your efforts to prove MDM's value. He's quoted as saying:

It's not just an IT project. The business needs to take responsibility and be accountable for master data governance and stewardship. Unless organizations take a holistic, business-driven approach to MDM, addressing governance and metrics requirements in particular, they risk having their MDM programs fail.

So why did this approach work for Dell? Possibly it's because Dell is a tech company, and it's always a little different. But Dyche notes IT also aggressively engaged the business during the process:

The lesson here is that IT needs to emerge from the shadows and claim the conversation. In waiting for the business to define the rules of engagement, important conversations are never had, important relationships are never made, and-not to put too fine a point on it-important business applications don't get built. What Dell did was to simply ask the right people the right questions by leveraging the culture and the vocabulary of the business. Your company needs to start these conversations. And most likely, IT needs to be first to the table.

Mind you, IT wasn't acting unilaterally in this instance. Instead, IT started the discussion, even lobbied for this change. IT led, yes, but by involving the business, not dictating to it.


IT leading what should be a business initiative may not be the perfect approach; it certainly flies in the face of many expert recommendations. Yes, it could very well be a mistake that leads to problems down the road. But sometimes, you've got to make mistakes if you want to move forward.


And IT taking the lead does have one, distinct advantage: It's the path most likely to actually lead to action, and therefore, it may be the best chance we have at creating much-needed change in how organizations handle, govern and manage data.

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.


Add Comment      Leave a comment on this blog post
Jan 10, 2011 9:07 AM Marty Moseley Marty Moseley  says:

This is a great integration of a few thought leaders' discussions on this - well done, Loraine!

I've written more than several times on the fact that IT has to learn to speak to the business in their terms, using arguments and reasons for its initiatives that make sense to business leaders. Doing something b/c it improves the quality of data just doesn't cut it. But IT has to learn the mindset that they get only limited opportunities to speak to business leaders, and they have to ensure that when they do, if they blow it (talking about metadata management, data quality management, data models vs XML, etc. instead of business issues and value), their credibility is gonna take a hit. And the frequency of meaningful conversations will decrease as well. Conversely, if you talk to business leaders in terms they grok about issues that matter to them, then your cred will go up and they'll be more likely to invite you to the negotiating table.

And my friends Rob and Jill absolutely nailed their points!

If we could help data nerds get Rob's point that DG is about business process and policy management that changes the way businesses use data to get things done, we'd make significant headway.

I believe this job is one that only fairly senior business architects and enterprise architects can do. It requires a level of business acumen that most data quality practitioners, data modelers, etc. I've met don't seem to have. It's not experience or skill or ability - it's a point of view and a language that gets and holds the attention of business leaders...

Jan 10, 2011 11:20 AM Kelle O'Neal Kelle O'Neal  says:

Loraine -

Very interesting post and point of view that will surely spark some valuable discussion. The challenge of who will lead and who will own data initiatives is a bit like the Holy Grail - whoever solves the riddle will know a secret that will make them very powerful indeed.

I agree that IT is in a great position to initiate a data improvement program (aka Data Governance, Master Data Management or Data Quality). IT is a cross-functional group that sees issues that are common across lines of business, and therefore are usually the first team to identify a shared data problem. Many times they are also the group that feels the pain the most in the form of complaints by the business that "systems don't work", when in reality, it's the data in the systems that isn't working for the user.

The challenge however, is that once IT initiates a data improvement program, the best way to operationalize the changes inherently involves changes in the way the business creates and manages the data. IT cannot fundamentally change the way the business enters and updates data. Short of cutting off access to or usage rights to data, IT cannot force the business to do anything around data.

Although difficult, it is important for the business to own the responsibility and actions to improve and maintain data for the long term. Business needs to ultimately make the decisions, provide the resources and enforce the adherence to the policies and processes that will ensure that data is properly managed throughout it's lifecycle.

This is where selling data programs to the business and highlighting key business value and implications for each line of business, becomes important. So although IT can start this process, the goal is to create a sense of urgency that will enable a transfer of ownership and leadership from IT to the business.

To accomplish this we coach our clients to do the following:

Make it personal. When communicating about the value of data, understand who you are talking to and speak their language. Identify reasons why that person should actively support the data program based on their goals.

Treat it like a sales campaign. This is traditionally very difficult for IT, but getting the business on board to a data program is very similar to selling MDM software! Create a sales plan, execute it and adjust as necessary.

Show why the business should be involved and what would happen if they aren't. Provide some specific examples of why the change that is needed should come out of the business. Ask the question, "Who would you rather decide on how product information is created, IT or the product manager?"

You can never institutionalize the value of good data without business leadership, and you will always be improving data in a reactionary mode without business taking ownership.

Jan 11, 2011 5:13 PM Jill Wanless Jill Wanless  says:

Thank you Lorraine.  An excellent post and subsequent discussions. It may be that the IT led approach worked for Dell but I see that as an anomaly rather than a practice I would recommend as there are so many things that could derail the initiative:

As Marty and Kelle say, IT must learn the mindset and language of the business leaders and make it personal for them. I€™ve been in the same room as business and IT leaders, heard business specifically ask for clarity over IT's use of a technical term, and seen IT provide the clarity, only to revert back to said term in subsequent meetings, emails, and other communications including business case documentation. When Jill Dyche says the business is not interested, I think one of the reasons is because all that tech talk turns them off - heck it turns me off!

I€™ve seen business agree to do all kinds of things but because the initiative is IT led when it comes to actually making this a priority and assigning business resources to participate in development of compliance policies or processes they all seem to have little if any availability. I€™ve sat in workshops where all the IT resources are eager and engaged and 1 business resource shows up: all the business resources are busy working on other business priorities.

Unless the business is aligned and supportive their pre-dispositions and the organizational political and cultural differences will lead to failure because the business is not leading the charge and rallying the troops towards a common goal(s).

Maybe we should just work together. Forget business vs IT. Let€™s just ensure alignment around corporate objectives and common goals and the recommendations to achieve them. Then, the teams, resources and organizational leaders with the capabilities identified in the recommendations could then lead the implementation.

A person can dream can€™t they?

Jan 12, 2011 4:21 PM Lindsey Niedzielski Lindsey Niedzielski  says:

Great post Loraine. I like the idea of IT aggressively engaging the business side of things.  We have a community for IM professionals (www.openmethodology.org) and have bookmarked this post for our users.  Look forward to reading your work in the future.


Post a comment





(Maximum characters: 1200). You have 1200 characters left.




Subscribe Daily Edge Newsletters

Sign up now and get the best business technology insights direct to your inbox.

Subscribe Daily Edge Newsletters

Sign up now and get the best business technology insights direct to your inbox.