Why don’t MDM Implementations Stick?

puzzleFormer Gartner (the analyst firm) MDM guru John Radcliffe has established his own business and blog and started off revealing some dirty secrets about how sticky MDM implementations are.  Quote:

“Another interesting thing was something that we found during Magic Quadrant reference checking. Increasingly the initial MDM champion, who made the business case, chose the software and led the MDM program had now moved on. The new guy (or gal) in the role often didn’t have the same enthusiasm (putting it politely) for MDM generally, for the MDM software that was installed or for the incumbent MDM software supplier.”

You may read John Radcliffe’s blog here.

A pretty bad review of MDM vendors merits indeed. But, as I have experienced during several decades in the IT business, this is an observation that probably could be made not only in the MDM realm.

However it could be good to learn how MDM implementations could be stickier. What are MDM implementations missing? Is it:

  • The functionality in MDM solutions that needs improvement?
  • The often massive consultancy that comes with a MDM tool that doesn’t meet expectations?
  • Enterprises not actually being ready for MDM?

My take is: All of above in mentioned order. Your take is?

Bookmark and Share

5 thoughts on “Why don’t MDM Implementations Stick?

    • Henrik Liliendahl Sørensen 1st October 2013 / 10:53

      Maybe Gary. However the business case for the MDM vendor is selling the product 🙂

    • Bernie LeCuyer (@bernard_lecuyer) 1st October 2013 / 13:03

      I agree Gary (and thanks for the link to your original post) but I also agree with Henrik’s reply below. The important aspect is to focus on the data with a MDM implementation and back into the technology requirements (and let’s not forget about the importance of stakeholder ownership and adoption). Many times the organization attempts to find technology to solve a business problem without thorough consideration of the data requirements to support the new reality they are attempting to create. To Henrik’s reply and points 2 and 3 in his list, perhaps the vendor community, to a degree, inadvertently influencing failure of MDM.

  1. Shiva 3rd October 2013 / 09:36

    I agree with Gary’s point that MDM being often sold as a technology or a SW product could result in less enthusiasm amongst business, resulting in poor alignment with key business performance goals that MDM is supposed to support the achievement of. In my personal experience, I sat in many MDM pre-Sales discussions, often greeted by teams comprising Solution Architects, Analysts, Managers of the IT domain, with a token presence of a business guy or two, who is low down the hierarchy and not in a decision-making role either. True, there were documents describing the business problems that MDM should solve in their organizations; however, the driving force behind the creation of these also seemed to be the IT, with support from the business side.
    A well-documented business case, incorporating the right business data / facts to highlight the current business pain points, together with an association to the correct business stakeholder(s) facing those challenges, would go a long way in avoiding the pitfall of linking the MDM project to a single champion who is likely to move on during the course of the project implementation, risking the loss of energy on the project.
    This, coupled with poor project execution – especially, lacking a crystal-clear, agreed-upon definition of “project success” – driven by the inputs from the business case, not enough emphasis on delivering “valuable” results to the most important stakeholders iteratively & in short intervals (prioritized for business impact), leading to poor requirements understanding seriously hampers the chances of the MDM implementation project success.
    In my view, Product functionality, by itself, has a low impact on the outcome of the MDM project (in other words, it is necessary, but not sufficient). Many companies select their MDM product after enough due diligence (through multiple demos & POCs simulating their current context, talking around with analysts, partners etc) and would have taken care to see that the product has enough out-of-the-box features to address their concerns (though, that may involve some expensive configuration, customization, work-arounds etc to get the desired results)

  2. Henrik Liliendahl Sørensen 4th October 2013 / 13:25

    Thanks a lot for commenting Shiva. Many good points. Still, when looking back I have seen many cases of a wide gap between what business users (including IT staff) thought the MDM solution would do for the business and what the MDM solution could do for the business.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s