Do you need to gather business requirements for MDM projects?

Are there particular business requirements that we need to gather for a master data management (MDM) project, like with business intelligence and analytics deployments? Or is it too complex for that?

    Requires Free Membership to View

    Login

    When you register, you'll begin receiving targeted emails from my team of award-winning writers. Our goal is to keep you informed on the hottest data and information management trends today.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchDataManagement.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchDataManagement.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

This is a GREAT question! Not that all of the others aren’t great, too. It’s just that yours is really timely and a lot of people were thinking of asking it. But you did, you rock star.

Yes, you need to gather business requirements for MDM, just like you would with any strategic IT initiative. The difference is that requirements for MDM are different. You’ll do business requirements, and you’ll gather some data requirements as well. Then you’ll make yourself a hot chocolate and ponder your success. Then you’ll embark on functional requirements.

Yes, I said functional requirements. Where business intelligence (BI) and MDM really diverge is in MDM’s need for functional requirements. That’s right: use cases. If you’re in BI, you might not know how to build them now. But you’ll learn – and it will be really helpful, not only in terms of delivering an MDM system but also for pitching it to stakeholders.

This is all due to the fact that with most MDM software and tools, there will be operational processing needs to take into account. For instance, perhaps you need to manage hierarchies between and across different companies and their subsidiaries? Or maybe you need to bolt address cleansing capabilities onto your MDM hub? The combination of your functional requirements will inform your choice of an MDM vendor and product. Or it should, anyway. Don’t get me started on that.

One of the most prevalent problems on MDM projects these days is the tendency of companies to lump MDM in with BI. But MDM has a totally different set of outcomes and solves a totally different set of business problems. That mandates a totally different requirements approach. Trust me, I’ve seen the war wounds.

This was first published in November 2010

Back to top