Search
Close this search box.
Search
Close this search box.
I’ve noticed that many of our client discussions regarding MDM roadmapping take place after deadlines are set by key initiatives dependent on master data.  The effect is to restrict the time available to plan master data strategy and tactics. The heat is on to implement the governance processes, data quality rules, and other enabling technology to address the dependency! A recent client didn’t do this.  After we completed our work and articulated for the next several years of program phasing, they admitted there was disagreement before the project about whether the time was right to start evaluating information flows, stakeholders, and other facets of their enterprise product information.  They were apologetic about having engaged us in the task without having the ability to seamlessly shift gears to the next capital project (and keep us engaged).  This raises an interesting question: when is the right time to roadmap?  Should it be part of an exploratory process, or should you begin only when the organization is committed to continued momentum?

Background

In fact, we had been quietly complimenting this client team for having the foresight to begin the roadmap at such an early time. Our recommendations pointed to the necessity to design more consistent product creation and edit processes across their organization, which consisted of diverse brand teams who had run independently of each other, and globally diverse functional teams.

The work would be critical to understanding the definition and flow of information in the present context.  It would involve a lot of data profiling, process mapping, and rationalization of data definitions and processes.  It would set the stage for understanding the change management effort, the scope and responsibilities of a data governance organization, and many of the design requirements of the upcoming data quality and MDM technologies.

Had the work be critical to an already-planned business initiative, the clock would be ticking.  The work could be accelerated with external help, but at the expense of the real engagement and ownership of functional stakeholders. The major risk is that the work soon is defined by the needs of the enabling technology rather than the needs of the business processes.

Conclusion

In our experience, many of the recommendations outlined in roadmaps are tactics to get hands-on with the data and processes to build a baseline, and quantify the changes ideal to deliver business value to the organization.  Some of this work can be outsourced, which is often necessary when there is a pressing deadline.

The question is, why not start sooner?  The work is going to give your team a major leg up in their contextual understanding of the future solution needs and benefits.  It is not necessary to have an organizational commitment for 24 months of capital project funding to begin your roadmapping journey.  However, being committed as an organization to beginning the information management journey is – you’ll want the commitment of a core group of analysts to keep the conversation going once it’s started in a roadmap.