Master Data Management (MDM) is no longer the new book on the shelf. Many big ideas are competing for the focus of the modern enterprise technology leader:

• Everything as a service

• Cloud computing

• Big data

• Data lake

• Machine learning / Artificial Intelligence

(And of course, one must deliver it all using Agile, SaFE or LeSS).

You've no doubt seen this before within, and beyond, the enterprise data subject area.

For MDM, at least in the Customer Domain, which manages data for People and Organization, the technology solutions on offer have matured well.

We’ve seen consolidation and modernization: those leading the market offer deep and broad capabilities. More capabilities than most companies will ever end up implementing.

I’ve been writing recently about how the roles of the Owner and Champion are essential for MDM success and how being clear about your company’s goals is the only way to know if you’ve succeeded.

But in hindsight, perhaps I should have started this series by talking about the elephant in the room: MDM is not about IT.

Master Data Management: Beyond the Tech

You will be asked to make many decisions about many topics...

• Your infrastructure compatibility

• Maintaining customer external to your organization

• What integration skills are needed

• What is the ideal data and object model for us

• Who will operate MDM in the long-term

MDM does indeed include very technical topics and requires specialized effort, but MDM is not software that gets installed and announced by email blast to the company.

The licensed software is not itself a solution; it is data and application infrastructure. The company will find the answer to its business problem in the implementation.

The necessary MDM hardware/software are installed and operated by the tech department or hosting vendor, but it must also be defined by the business capabilities to succeed.

Think marketing, finance, service, sales. Not Technology. Not the Chief Data Officer (CDO) or Chief Information Officer (CIO).

The Business Needs to Step up and Own MDM

MDM is the capability and collection of processes used to ensure that the data provided about, in this case, the customer is trusted by the company and is the best they have. It is readily available through a variety of means suited to the company and its processes.

The company's customer data might not be perfect, but it is their definitive source. It runs on this data today.

To succeed, MDM needs to be born and lead by the business.

Declare and describe the business need or challenge to be addressed. Develop the details in conjunction with business-minded people that are data-savvy. It is not enough to say to the technology leadership that digital transformation, customer engagement or the customer journey is our focus and then put MDM on a task list.

I’m not surprised by headlines that quote surveys that find 50% to as high as 80% of all enterprise projects fail. These are not MDM specific surveys, but it is representative.

The MDM Stakes are High

I’ve been involved with a wide variety of MDM projects and witnessed the waste in investment that a poorly conceived and coordinated MDM initiative can create.

In the MDM space, companies frequently spend ten to twenty million dollars before seeing meagre results or abandoning altogether. The churn, delays and disappointments are avoidable and not the fault of the software.

Implementing enterprise systems at scale is technically and politically intricate work. There are books, courses and certifications all about how to manage them. Most of the books and courses are generic, while all of the issues are contextual and specific.

My take on why implementing MDM is particularly challenging is that it is neither an out-of-the-box business solution nor generic infrastructure. Implementing MDM must have a purpose; To be successful, it cannot lack meaning, and that purpose comes from the business.

Easy enough, right?

To illustrate, a meeting somewhere:

CEO: “Businessperson!”

VP Leader: “Yes, chef?”

CEO: “Get the IT people some purpose for our new MDM project.”

VP Leader: “Another data project? Can they handle that now? We’ve got the sales planning cutoff this quarter, and we’re still waiting for the other analytics projects.”

CEO: “I’m late for another meeting. I trust you'll make it happen.”

- End meeting -

Purpose Needed for the Needs of MDM to be Successful

If we agree, purpose is needed for MDM to be successful; the company needs to acknowledge a significant lingering barrier:

Fatigue.

I mentioned that MDM is no longer a new topic. If the company has implemented MDM before, perhaps a few times, it may be a sensitive topic. The promises made were not delivered, the money was spent yet the need remains.

Real capital and operating expense dollars have already been sunk as well as the scarcest of resources - time.

MDM projects fail when they are not driven and governed by business purpose.

If you’re new to MDM or are looking to try something different this time, here are some considerations for this business-led approach I’ve used successfully.

MDM The Right Way

Have a business person as the Champion of MDM partnered with a more technical Owner

• The Champion has ownership of a line of business and has subject matter experts assigned that live the work that will be impacted by implementing MDM

• The Owner is responsible for the implementation and the ongoing maintenance

• The Owner will work with the Champion’s SME’s and the technical team to deliver the requirements.

Know why you’re doing the project in business terms, with target numbers for outcomes.

• Be specific and document the target outcome

• Collect the details you’ll use to measure the target outcome at the outset to create a comparative baseline.

• Conduct simulations during testing to determine if you’ll be within the range of your target. You may not have hit the mark, but you'll know by how much or be able to plan the necessary adjustments.

Acknowledge that the teams required are diverse and cross-functional; they all work differently.

• Managing teams from across technology and business functions bring competing approaches and interests colliding together.

• If you invite the business to recuring calls about technical issues, they will become disengaged. They need to be working at providing requirements, testing scenarios or reviewing results.

• If you invite the technical people to lengthy scenario read-outs, they will be multi-tasking. Please don't presume that seeing their name on a call implies they understand and agree to deliver all of the requirements.

The months ahead of vendor selection, proofs, data quality issues, system access or integration challenges, contention for people will still happen. You’ll need to navigate these common challenges. By having a specific business need, you'll keep the business engaged. The entire team will have a purpose and dramatically increase your chances of success with MDM.

I can say all of this confidently because I've been on these projects and used these techniques.

The experiences are many, painful and steeped with learning.

One such example was the implementation team I was leading where I reported, seven days a week, to twelve project managers – for over a year about our development, issue resolution and the initial data load.

In another MDM project, also typical, I witnessed the executive responsible for data be replaced four times in two years.

The shared behaviour within these examples as well as others was that the requirements changed frequently, and the business was not part of the effort.

Why data executives tend to last 50 to 30% of the time in their role than a colleague in a business role is for another article. What I can help you with is avoiding or identifying where you’ve gone wrong and how to get back on track - how to get your MDM team to a meaningful business result.

When you know what the business problems are, and how MDM is to contribute to reducing them, they can have a tremendous impact on the company.

Parting Thoughts on the Realities of MDM

Here are some of the facts and questions I find useful to review frequently during the development of a strategy or review of an in-flight project:

• The company is making its decisions using the data, processes and systems they have today

• People will depend on the data from MDM to make decisions

• The current team has been working on this, at this company, for a while

• People in a modern company do not focus on one goal at a time

• Know who this work is for and do you or your colleague have the names and numbers of some of these people?

• What is the ‘day in the life’ scenario(s) for the target roles?

• Will the reliability of their decisions improve or will they get the information sooner?

• Has the work been validated, the requirements or stories before heading into development?

• Have you met with who the work is for to review your test cases and results?