Experience has revealed key actions to avoid when working with master data management. Heed this list of 10 red flag behaviors.

1. Ignoring agile development principles.

If you hear, "We cannot possibly start the design since the requirements are not 100 percent complete," don't walk, run away. That project is tracking to be multiyear in scope and will likely be stopped before it gets anywhere productive. Additionally, if there are no parallel efforts and components within the project, project leadership needs to be examined. A multitasking leader is essential to agility, and agile principles are essential to MDM success.

2. Waiting until the last minute to look at your hardware needs.

Lead times for acquiring hardware have eased, but they remain a concern in MDM projects. I'm equally concerned about the time it takes to collaborate with hardware and procurement teams to specify the hardware, including the disk. This applies to all environments you intend to use, including development, testing and production.

3. Waiting until it's time to start user acceptance testing to define the process and the participants.

Trying to book an important stakeholder's calendar on short notice can be impossible. This is especially true when you consider the time demands of the stakeholders in an MDM user acceptance test. Such booking should be staggered over time, given the need to react to feedback in the process.

4. Neglecting to involve security.

Security requirements may include putting the MDM software on secure hypertext transfer protocol (https), encrypting data in motion (and at rest) and funneling all users through lightweight directory access protocol (LDAP). These are among many requirements that may halt the project at the door of production if you're not careful. Get security involved early to surface those requirements and address them well in advance.

5. Failing to build and execute test plans.

Test plans put the fine point on requirements; it's exactly what you need to see the system do. Plans include the workflows, the valid values entered, the integration of data to support the workflows, the order of the tab usage in the developed processes, the reports, the passing of comments, delegation, security requirements, access security and the integration of the MDM data with other systems.

Test plans may be for development (unit test), quality assurance testing, user acceptance testing, end-to-end testing (especially if MDM has publishers and subscribers) and myriad other preproduction environments. Determine early in the project who will build the plans and who will execute the plans.

6. Keeping business governance out of the program.

MDM needs business governance as a forum for supporting the program among all the business units. It needs governance to advocate, and it needs governance to govern the program from a business perspective. There will be many important decisions to be made in the MDM program, and it is essential that governance members are already on board with the program and up-to-date. This puts their insight and their support a quick phone call away when needed.

7. Being unprepared for organizational change.

Tactical organizational changes occur with MDM, such as the roles participants will play in the governance processes that originate the master data. In these processes, people will enter, edit and approve a variety of fields related to the subject area. They will need to respond to new forms of messages, and the process will have expectations of timeliness in the responses. Strategically, the added efficiency should do more than speed up existing processes. It should enable other possibilities for the company as well.

8. Staffing the team solely with technicians.

It is a common fallacy to look at any project that is supported by technology and overemphasize the technology aspects in the staffing plan. Leadership matters more than anything else on MDM projects. Identify daily leadership opportunities to determine how to react or adjust as business requirements change. For instance:

  • Does this change expand the scope of the project?
  • Does the change need to be addressed now or in a future release?
  • Does it counter another stakeholder's preferences?
  • Will this require the team to resort to code or use product's native capabilities?

As changes occur and requirements are adjusted, the perception of the project's success hinges on communication. Communication demands are met only by up-to-date documentation including project plans, status reports, issues logs, requirements lists, mapping documents and business rules documents.
Timelines are usually not the focus of technicians. If you staff the project solely with technicians, you may find an imbalance of focus (and dollars) on fringe, "insignificant," internal requirements.

Players change, and immature technology fights back at our best laid plans. In short, MDM is not all about the technology. Not even close.

9. Assuming that once MDM is placed in production, it will not need patches, fixes or enhancements.

You can complete MDM projects, but I don't know of any MDM program that is complete - and I may never. There's always the next subject area to master, the next set of requirements to incorporate and environmental vicissitudes that necessitate MDM change and continued - and growing - value to the business.

Change will come in the form of vendor software patches that need to be applied. There are practical aspects of bug fixes. Production fixes are inevitable, so all dependent systems must expect them and be prepared to deal with them. While most fixes occur in development and trickle through the preproduction environments, potentially including regression testing, there is a threshold of fix that may extend all the way to production for retrofit. This threshold, and all associated processes, should be determined ahead of the moment of failure.

MDM will provide long-lasting organizational value, but only if it is continually supported.

 

10. Not including consultants that have led other organizations to MDM success.

Because MDM is just like data warehousing or ERP or CRM, you can staff the project with people experienced in the other disciplines, right? Wrong. MDM is its own discipline, and a "been there, done that" MDM leader is essential to keep you out of the pitfalls and roadblocks that lie ahead.

Find someone who knows to avoid these 10 (and the other 46) ways to screw up an MDM implementation and keep them happily employed.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access