Slideshow 10 MDM Mistakes

  • March 13 2012, 4:54pm EDT

1. Ignoring Agile Principles

If you hear, "We cannot possibly start the design since the requirements are not 100 percent complete," run - don't walk - 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.

2. Looking Too Late at Hardware Needs

Lead times for acquiring hardware have eased, but they remain a concern in MDM projects. There should also be concern 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.

Content Continues Below

3. Waiting to Define Process and 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, encrypting data in motion and funneling all users through lightweight directory access protocol. These are among many requirements that may halt the project at the door of production if you're not careful.

5. Failing With 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.

Content Continues Below

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.

7. Being Unprepared for 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.

8. Staffing Solely With Technicians

Leadership matters more than anything else on MDM projects. Identify daily leadership opportunities to determine how to react or adjust as business requirements change. 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. Players change, and immature technology fights back at our best laid plans. In short, MDM is not all about the technology. Not even close.

Content Continues Below

9. Assuming There Will Be No Patches or Enhancements

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. 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.

10. Excluding Consultants

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.

10 MDM Mistakes

For a full article from award-winning consultant and author William McKnight, click here. For more on the MDM space from, click here.