.svg){kind=small}
I often become involved in an organization’s MDM program when they’ve reached out to InfoTrellis for help with cleaning up after a failed project or initiating attempt number X at achieving what, to some, is a real struggle. There can be a lot of reasons for a failing, and none of them are due to the litany of blame game reasons that can be used in these scenarios. Most failures arise from common problems that people just were not prepared for.
Let’s examine some of the top reasons MDM implementations fail. In the end they probably won’t surprise you, but if you haven’t experienced it yet you will be better prepared to face them if they happen.
Underestimating the work
I am starting with this one because it leads to many of the others, and is a complex topic. It seems like a simple thing to estimate the work but there are a lot of aspects to an MDM project that aren’t obvious that can severely impact timelines and your success.
“It’s just a project like any other”
Let me start by saying MDM is not a project, it’s a journey, or at the very least a program.
Most organizations thinking about implementing MDM are large to global companies. Even medium sized companies that started small and experience growth over time have the same problems as their global sized piers. While the size of the chaos in a global company may seem much larger, they also have far more resources to throw at the problem than their smaller brethren.
If we stick to the MDM party domain as a point of reference (most organizations start here with MDM), the number of sources or points of contact with party information can be staggering. You may have systems that:
- Manage the selling of products or services to customers
- Manage vendors you deal with or contract to
- Extract data to data warehouse for customer analytics and vendor performance
- HR systems to manage employees who may also be customers
- Self-service customer portals
- Marketing campaign management systems
- Customer notification systems
Many others
A lot of large organizations will have all of these systems, each having multiple applications, and often multiple systems responsible for the same business function. So by now you are probably saying, yes I know this, and...? Well your MDM “project” will need to sit in the middle of all of this, and in many cases since many of these systems will be legacy mainframe based systems, you will need to be transparent as these systems won’t be allowed to be changed.
MDM can be on the scale of many of the transformation programmes your organization may be undertaking to replace aging legacy systems and moving to modern distributed Service Oriented Architecture based solutions.
Big Bang Never Works
Now that we have seen the potential size of your MDM problem, let me just remind you that you can’t do it all at once. Sure you can plan your massive transformation programme and execute it - but if you have ever really done one of these, you know it’s a lot harder than it seems and that the outcome is usually not as satisfying as you expected it to be.You end up cutting corners, blowing the budget, missing the timelines, and de-scoping the work just trying to deliver.
What is one of the typical reasons this happens on your MDM transformation project?
You Don’t Know What You Don’t Know
You have all these systems you are going to integrate with and in many cases you are going to need to be transparent in that those systems may not know they are going to be interacting with your new MDM solution. You are going to need to know things like:
- What data do they use?
- How often?
- How much?
- When?
- Do they update the data?
- How often?
- How?
- What?
- Do they need to know about changes made by others?
- How often is the change notice required?
- Do they need to know it’s changed, or what the change was?
This type of information seems pretty straight forward. I haven’t told you anything you probably didn’t know, but, when you go to ask these questions, the answer you will mostly likely often get is:
“I don’t know.”
Ok, so the documentation isn’t quite up to date, (I am being kind), but you are just going to go out and find the answer. Which leads to the next problem.
Not Enough Resources
So this is an easy problem to solve. I’ll hire some more business analysts, get some more developers to look at the code, get some more project managers to keep them on track.Seems like a plan, and on the surface it looks like the obvious answer, (ignoring how hard it is to locate available quality IT people these days), but these aren’t the resources that are the problem.
You don’t have enough SMEs.
The BA’s, developers and others are all going to need time from your subject matter experts. The subject matter experts are already busy because they are subject matter experts.There typically aren’t enough of them to go around, and if you have a lot of systems to deal with, you are facing a lot of IT and business SME’s.
What your SMEs bring to the table is intellectual property. Intellectual property is critical to the success of your implementation. You will need the knowledge your SMEs bring on your various systems, but there is another kind of intellectual property that you are going to need and can be tied to a very lengthy process.
Data Management through Governance
In order to be able to master your information, you will need to amalgamate data from multiple sources and both the meaning and the use of that information will need to be clearly defined. What may appear to be the same information from one source may have a different meaning. Data governance is a key requirement to be able to establish the enterprise data definitions that are crucial for your master data. Even in mature environments this can be a challenging task and can consume significant time and resources.
Data governance may seem like a problematic and time consuming exercise but it is an effective tool to use against one of the other major hurdles you will face in trying to establish a common set of master data.
That’s My Data
Many organizations are organized into silos. The silos are designed to look after their own interests, funded to maintain their business goals and competitive for resources and funding.While the end goal of any organization is the success of the organization,the silo measures its success in terms of itself.
An MDM implementation is by nature at odds with the silo based organization as master data is data that is of value to a cross section of the business and thus spans silos. The danger in many organizations is that a particular silo has significantly more influence than another, often laying with the revenue generating lines of business.This over balance of power can easily lead to undue influence on your master data implementation, making it just another project for division X, instead of an enterprise resource to be shared by all.
Data governance is one of the key factors to help keep this situation in check. Your data governance board will be comprised of representatives from all stake holders, giving equal representation to all. The cross organizational nature of data governance is also the reason that decisions can be a difficult and lengthy process as it requires consensus across all the silos.
Aside from enterprise data definitions, another important aspect of master data management is the establishment of business rules.
Too Many Rules
The business and data governance will need to be involved to establish business rules for:
- ETL processes to loading data into your MDM application
- Updates to information from multiple sources
- Matching rules
- Survivorship rules
The establishment of rules is designed to address one of the big problems MDM is meant to solve: data quality. Organizations will want to manage both data quality on load and ongoing data quality. One of the big mistakes often made is to try and introduce too many rules right away.
The use of too many rules early on can have a significant impact on the initial data loads into your MDM solution. You are ready for production and most likely getting your first crack at live data to only find out vast numbers of records are being rejected due to your business rules.Your data loads have now failed and you need to go back and rethink your rules, revise your ETL process and try again.
You finally get your data loaded and your consumers have arrived to start to use the data and your legacy transactions are failing. Why are they failing? Because the application isn't validating the input according to your business rules, or collecting enough information to satisfy the rules.
Of course there is one way you could reduce this risk, but it often isn't done well enough and sometimes isn’t done at all.
What Profiling?
Data profiling is the one task that is critical to understanding what your data looks like and what you need to plan for. There are often many barriers to profiling because your party master data will likely contain personally identifiable information (PII) and access will be restricted for security reasons.You have to overcome these barriers because data profiling is the only way to foresee the gotchas that are going to put you far off track down the road.
Data profiling can be a significant task as each source system needs to be profiled. As you learn more about your data you will have more questions that need to get answered. All this profiling takes time and most likely needs the time of specific resources as they are the only ones that have access to the information you require.(There's that resource problem again.)
Project Management is my Problem?
So far you haven’t heard any magical reasons as to why your MDM implementation should fail. In fact many of the problems seem to be tied to the typical reasons any IT project can fail:
- Underestimating the work
- Not enough resources
- Trying to do too much at once (including scope creep)
- Time required for discovery
An aspect of an MDM implementation that may be a little non typical includes the need for data governance. Data governance not only gives you the enterprise view of the information you are trying to master, but can also be an effective way of dealing with competing agendas between silos.
Data governance is also one of the key success actors for the ongoing success of your implementation. Since MDM is a journey not a project, longevity is a characteristic of a successful implementation.Once you have delivered your foundation, the succeeding phases will build upon the base and provide more coverage of your master data. To ensure the ongoing success of your implementation you will need the support of data governance, to ensure that new systems and upgrades to existing systems use the master data and don’t just create islands of their own.
In the past we tried to achieve what master data management promises today, but with a lack of controls and governance, we ended up with the data sprawl we are trying to correct with MDM. Once the project is over, the role of master data management does not end. It is important to recognize that you must establish the processes and rules to not only create the master data store, but also to maintain it and integrate it into your systems. Master data management is not about the installation and configuration of a shiny new software product. The product is an enabler making the job easier. The establishment of rules, governance processes and enforcement are what will bring you success.
One final thing that every master data management implementation requires, and you are pretty much doomed to failure without, is strong executive sponsorship. Your MDM implementation is going to take years.You will require consistent funding and support to be able to take the journey and only an executive can bring that level of support.Organizations that are organized into silos often don’t play well together, and while data governance can help in this situation, the time may come when a little intervention is required to ensure things keep moving in the proper direction on the expected timelines.
Your executive is a key resource in and out of the board room.In the board room you will need t champion that has the vision of what your MDM implementation is going to bring to the organization, and keep the journey progressing over time. Out of the board room you will be faced with competing agendas, data hoarding, shifting priorities, and silos trying to work together.The executive influence here can be used to make sure that everyone continues to work towards the common goal, and provides the resources required to achieve the gaols in a reasonable time line.
