In my previous post, I shared some thoughts about how the absence of a formal set of processes and procedures for incorporating data governance into a master data management program actually had recognizable impacts later in the project that were manifested as more acute issues (such as performance for timely population of the master repository). The implication is that developing your governance practices first provides some boundaries for architecture design and application development that might preempt the emergence of implementation-dependent issues.

More specifically, it is worth focusing on what is really relevant to your proposed master data constituency, since socializing consumption and use of the newly created master data asset with that audience is critical to adoption and uptake. Some specific data governance tasks that can be performed early on as a prelude to architecture and development include:

• Engaging business users who meet the profile of the prospective consumer of shared master data
• Developing “marketing material” to help socialize the benefits of a master data asset
• Reviewing how business processes intersect with the master data entity lifecycle
• Considering specific business process requirements for unique identification and accessibility of shared master data
• Determining how the anticipated business benefits are quantified in relation to master data acceptance and uptake

These prerequisites help the program manager assemble a blueprint and roadmap that aligns the milestones and deliverables of the project with the trajectory of the program. At the same time it helps identify potential risks and failure points that can be avoided before they become ingrained in the system architecture.