Top 10 Ways to Fail at MDM

Register now

One of the sessions at our MDM & Data Governance Summit in New York last week came from Sally Gerber, the team lead for enterprise data management at Amway Corporation.

Sally has been through the process at her company, observed some preconceptions and caught a few falling knives in her pursuit of MDM and a project that had to push the reset button (as I've seen most of them do).

I meet a lot of practitioners who are fond of checklists to show how on top of MDM their project managers are. Sally points out that the reverse -- what not to do -- can be even more illuminating, and I agree.

So here are Ms. Gerber's Top 10 Ways to Fail at MDM:

10. Execute MDM exclusively as an IT project. Don't identify likely business owners and partners and don't give them ownership in the challenge as well as the solution.

9. Boil the Ocean. Let's go for all of our data or the parts that are easiest to get to and decide later what objects and master types are really needed in our solution.

8. Hire developers inexperienced in MDM to create your solution. Off the shelf software uses use familiar code, so MDM developers ought to be able to know how to move whole records across source and target systems.

7. Make your MDM effort part of a bigger project. Some observers have found that MDM can be delivered on the coattails of another project, so it's no big deal that this is also our first ERP implementation. We can just bolt MDM on when we build it.

6. Don't establish governance. I don't have time for data quality when there is real back end work to do. And we already have a librarian somewhere, don't we?

5. Don't model the data topic. We don't have time to model the customer when there are so many other details to cover.

4. Build your MDM hub between two critical enterprise applications. Here's an idea. Let's get in between the communication and integration of our most important applications and not worry about high performance or data quality. 

3. Don't pick an architectural style. You can have design discussions but who needs to test models ahead of time? We can fix it later.

2. Don't build requirements. I'm not sure what problem we're solving so let's just go with what the most people seem to want.

And the number one way to fail at MDM.....

1. Buy the tool first. C'mon, technology is what's going to handle all the work anyway, right?

The stories are familiar irony to many of you, and oh so true. We see the flaws of human frailty, a lack of communication, missions that are undefined and misaligned culture all the time. The point is, when you do tackle MDM, remember that the problems you do prepare for might be less dangerous to your success than the ones you don't.

For reprint and licensing requests for this article, click here.