Program Management Office Implementation
Abstract
This chapter discusses the planning and structure needed for creating a Program Management Office (PMO) to oversee the Master Data Management (MDM) program, including the roles and responsibilities of the PMO in relation to resources, budgets, tools, and change management processes. It provides examples of PMO structure and process flows and the cross-functional alignment needed between program, information technology (IT), and governance functions, as well as how the MDM PMO fits into that dynamic.
This chapter discusses the planning and structure needed for creating a Program Management Office (PMO) to oversee the Master Data Management (MDM) program, including its roles and responsibilities in relation to resources, budgets, tools, and change management processes. It provides examples of PMO structure and process flows and the cross-functional alignment needed between program, information technology (IT), and governance functions, as well as how the MDM PMO fits into that dynamic.
As a company grows, it needs to expand MDM and data governance initiatives across the business model and data architecture. Implementing MDM across multiple domains naturally creates the need to examine how to best coordinate and prioritize multi-domain activities, particularly with regard to technology needs, quality improvement priorities, and the demand for budget and IT resources. An MDM plan needs to start by creating a distinct PMO and an associated core team to establish the foundation needed to move the program forward.
In Chapter 1, Figure 1.1 provided a high-level example of a cross-domain program model, showing the relationship between program office, data governance, data domains, and the key components that need to be supported. Along with the overall MDM program charter and scope, each domain will have a specific scope, objectives, responsibilities, and resources, similar to how individual projects within a program will have project-specific plans and deliverables in support of the overall program strategy and goals.
A multi-domain MDM program will not succeed if it tries to adopt too much of a cookie-cutter approach to the planning and support of each domain. The PMO needs to look at the orchestration of MDM from both an enterprisewide perspective, to ensure that there is a common program framework across the domain structure, and a domain perspective, to ensure that domain-specific objectives and priorities can be recognized and supported. A well-conceived PMO should always be cognizant of how to continually help enable the various domain objectives and avoid overmanaging where control and conformance are not necessary.
Depending on a company’s business model and MDM strategy, the role and responsibility mix between the PMO and domain charters can vary, but in general, there should be a clear separation of duties conducive to a collaborative and supportive relationship. Because many aspects of quality management, governance, and stewardship focus are unique within each domain, these aspects should not be impeded by excessive PMO control. If the PMO charter is too broad, overly controlling, and attempts to create too much of a homogeneous multi-domain model, it can start overshooting its value if it takes authority and empowerment from the domain-specific teams. A PMO needs to cultivate an environment where a maturing MDM domain team can lead by example, developing best practices that other domain teams can use to accelerate their maturity. A leading domain implementation needs extra attention so that the business foundation that it creates for data governance, stewardship, quality management, metadata management, data integration, and technology usage can create repeatable or adaptable practices to help prime the startup of other domain implementations. This is critical for driving sustainability across the overall MDM model. Using the knowledge, practices, and experience from a leading MDM practice should be a key strategy in developing a multi-domain plan.
There are many IT-oriented services and resources needed to support MDM practices. In a multi-domain model, this can cause competing demand from the domains for these elements. As a multi-domain plan is being defined and executed, the PMO needs to work closely with IT on the technical requirements, services, and resources needed to execute MDM with each domain in scope. Launching too many MDM initiatives side by side, along with poor capacity planning by IT, will quickly lead to IT overload and bottleneck scenarios, causing program deliverables to be delayed.
Here are some important IT-related considerations that the PMO should review:
• How much capacity will business and IT organizations need to support their requirements and demands with a multi-domain plan?
• How rigid is the IT engagement process and the support practices? Can these processes sufficiently adjust to provide more flexibility and collaborative support across business-driven MDM programs?
• Will new technology actually help enable or hinder MDM efficiency and return on investment (ROI)?
The MDM PMO should be careful about creating too many critical path dependencies on new technology because of the higher potential for delays and functionality issues. Chapter 3 discussed both the value points and the challenges associated with technology in an MDM program. There are many aspects of data governance, data stewardship, business analysis, process improvement, and overall program management that do not depend on technology, so be sure that these type activities and tasks are sufficiently identified in the program plan and can still move forward while other technology issues are being addressed.
Business and IT Alignment Considerations
Business and IT alignment issues can affect the ability to execute enterprise data management programs like MDM. Companies can struggle with achieving their data management and quality management objectives because of fundamental organization and process alignment issues, such as:
• MDM and data governance programs are not aligned well with IT governance, project governance, or other key decision-making bodies that can affect master data.
• Organizational changes can slow momentum or break the governance and quality management focus of a company.
• The organization fails to work collectively to correct the root causes of data issues and instead apply point fixes randomly.
• Different groups have different systems of record (SORs) or use different reporting and analytic solutions.
From the Best Practices Report “Next-Generation Master Data Management,” released by the Data Warehouse Initiative (TDWI) in 2012, among the top responses from users surveyed regarding their challenges to MDM success were:
• Lack of cross-functional cooperation
• Coordination with other disciplines (Data Integration, Data Quality)
• Poor data quality
Much of this is the result of failure to align a data governance program with other governance bodies within a company. For example, it would not be uncommon for IT governance and project governance bodies to make strategic and tactical decisions about master data without involving a data governance team. Projects are frequently launched without master data or data governance requirements and then encounter issues related to data quality management, data definition, or policies and standards that will require data governance later. This happens because data governance is not often recognized as an important component during project planning, which can cause project teams and IT functions to be unprepared to handle large-scope data quality and integrity issues when they emerge.
Alignment issues often underlie the inability to conduct sufficient root-cause analysis and implement permanent fixes to problems. For example, a data warehousing support team may identify a data quality and consistency issue across multiple source systems, but because of alignment issues between IT support and the various business process teams, a permanent fix cannot be fully implemented causing point fixes within the warehouse and notices sent to downstream user groups regarding how they will need to work around the data problem.
Another common alignment issue is where there are no cross-functional standards regarding the use of reference data, such as country codes, product codes, service codes, reason codes, language codes, or other code sets. Without enterprise standards and sufficient code set registration policies, local applications and new projects will often just find or create the reference data they need to meet their requirements without regard to other existing code sets. This will cause more duplication or overlap of reference data across the enterprise.
Building Cross-Functional Alignment
Identifying ownership and maintenance responsibilities for master data is a topic that needs to be addressed right up front between the MDM PMO and data governance. Because of the cross-functional nature of master data, identifying master data ownership and maintenance responsibilities will likely span various IT and business roles within each data domain. Reviewing the master data life cycle and completing a create-read-update-delete (CRUD) analysis, as discussed in Chapter 2, will help identify these ownership and maintenance roles. Data governance should have the authority to define or confirm these roles and responsibilities, as well as the associated policies governing the master data. The MDM PMO should have a seat on the governance team and be prepared to help support the services and alignment needs required for these roles and responsibilities. Chapter 6 will cover this in more detail from a data governance perspective, but for the MDM PMO, there are two basic questions that affect data governance:
• How does the responsibility for creating and maintaining master data need to be coordinated across IT and the line of business functions?
• What additional resources and services are needed to help support MDM as a consistent, enterprisewide program?
Each data domain may have different answers to these questions, which is why the MDM PMO office needs to be cognizant of how support needs can differ between domains. An objective examination of these questions for each domain will likely identify existing business and IT alignment issues, which will need to be mutually addressed by the MDM PMO and data governance. Figure 4.1 provides a simple illustration of a well-aligned model.
There are a number of key points to consider when building this cross-functional alignment:
• Work with data governance, IT governance, project governance, and other key steering committee bodies to define clear charters, roles, and engagement rules for how to handle issues and decisions related to master data.
• Identify how enterprisewide communications should be coordinated regarding master data issues, topics, changes, governance policies, and standards.
• Leverage cross-functional collaboration where it already exists in projects and programs.
• Bring attention to where good governance and quality management practices are occurring. Build from best practices.
• Be persistent, be opportunistic, but have patience.
Such an alignment can occur through various relationships. To best accommodate this, a data governance domain team should have members representing various projects and initiatives within that domain so that issues and data quality management needs can be reviewed and coordinated between the data governance and project teams.
Coordination of MDM Roles and Responsibilities
With each domain, the roles and responsibilities that need to support the master data need to be recognized early in the MDM strategy and program process. Spelling this out and planning how these roles coordinate with other business and IT roles will take any conflicts or jurisdictional issues out of the debate and enable MDM governance and data steward functions to be formally recognized and supported in the company’s ecosystem. Figure 4.2 illustrates how these relationships and roles become the partnerships and supporting dynamic for master data.
A well-defined and coordinated set of roles and responsibilities between the data governance and data steward roles becomes the focus point for the sponsorship and ongoing execution of the MDM process. The data stewards not only become subject matter experts who have sufficient tools, skills, and responsibilities to manage the domain’s master data across domains, but also work with specific functions to assist with many types of data analysis, standardization, or cleanup initiatives.
Another important area to coordinate roles and responsibilities with is the solution design process, such as a Software Development Life Cycle (SDLC) process, where checkpoints or gates can be put in place to ensure that there are appropriate guidelines, quality management, and data governance signoff procedures where there are proposed or required changes or impacts to master data. Figure 4.3 illustrates this concept.
Having these types of protocols in place will maintain alignment between project governance, data governance, and quality management.
Handling Organization Change
Most companies go through some fairly substantial organizational or strategic changes, which can really slow the momentum of an MDM initiative. Whether due to market shift, mergers or acquisitions, corporate restructure, or infrastructure changes, in the corporate world, change is a regular occurrence. Quite often, structural changes in the organization cause a splintering effect that can be very disruptive, requiring various program or project groundwork and plans to be revisited or recalibrated.
The MDM PMO needs to recognize this and utilize change management and impact analysis approaches such as a Strength, Weakness, Opportunity, and Threat (SWOT) analysis to help define effective strategies for identifying and managing change.
Change Impacts
The degree of business impact from organizational change will depend on how well cross-functional alignment to the changes is managed. If there are broad corporate strategies and well managed plans to transition from legacy processes and applications to enterprise solutions, then the realignment of existing programs and processes is likely to be a natural bi-product of that strategy. If good cross-functional alignment has already been established, it will be much easier to coordinate these changes across the enterprise. Keep in mind that many needed quality improvement proposals never get executed because of the failure to established task ownership or to gain commitment for just one or two extra resources needed to execute the plan. Aligned governance functions will be much better positioned to address these types of reorganization issues.
When a large organizational or operational change occurs, it is not unusual for the value, context, and need for certain data to change in light of new priorities, applications, ownership, or simply a loss of ability to maintain what may now be considered legacy data. Such changes in business practices and data requirements are a constant challenge for IT. This is particularly true with operational processes and data, but it can also be the case for master data, where there are SOR changes due to mergers and acquisitions or platform changes.
The good news is that master data can be much more adaptable, transferable, and able to retain its context and value if good MDM practices have been implemented. The ability to quickly integrate the master data into new models and environments can lead to not only a large cost savings compared to the cost of a much larger effort usually needed to align and integrate data of poor quality and integrity, but also enables the new environment or acquiring company to minimize disruption and maintain business continuity. The MDM PMO needs to recognize the potential for such changes and highlight how the good MDM practices are an asset.
Having a good MDM PMO will help keep MDM practices highly adaptive to organizational change. Because organizational change can often be very disruptive—particularly when associated with mergers and acquisitions—and is usually expected to be completed under a specific plan within a fixed time frame, the quality and execution of a data migration effort can suffer due to time constraints. Master data that have been poorly translated and mapped into new models can cause significant issues with operational processes and customer transactions later. During major organizational and system changes involving the migration or integration of master data, engaging the MDM PMO and data governance teams early during the project and change management planning phases can help define specific data-quality requirements and quality acceptance criteria during the transition of the master data.
During organizational and operational change, IT typically has the responsibility to transition the systems and the data; however, subject matter experts on the business side who are intimately familiar with the business processes and context of the data are often transitioned quickly into new organization structures and environments, or possibly even leave the company (whether voluntarily or not). This often results in poorly migrated and mapped data, which can degrade overall data quality and create many operational issues until the situation can be corrected. An existing MDM PMO and data governance team involved in the transition plans can help avoid these knowledge and resources gaps.
PMO Tools and Processes
As mentioned in Chapter 3, there are various MDM products and tools on the market that, if being considered by the MDM PMO, will need a close examination to determine their strengths and weaknesses in relation to program needs and whether they will be a good investment. With an increasing number of vendor software solutions targeted across the MDM, data governance, data quality, data integration, and enterprise data management (EDM) markets, there are many overlapping features and capabilities that can be confusing and difficult to sort out or differentiate by a PMO when trying to find complementary and cost-effective solutions to use across an MDM program. A company is likely to already have some existing solutions that support data quality, data integration, and metadata management needs. The PMO office needs to take inventory of what solutions already exist internally and evaluate the ability to leverage these internal solutions for MDM needs. Then it should determine what other vendor solutions may be needed. As also mentioned in Chapter 3, the MDM PMO should consider the value of using an experienced consulting firm to help assess tool and vendor solution needs.
Program Communication
As is typical with any program (or project), the MDM PMO will have program communications needs with the program team members as well as with stakeholders and other audiences. Assuming that the MDM PMO has established a strong alignment and partnership with the data governance program, most external communications of the MDM program can be channeled via data governance communication processes. As discussed in Chapter 2, the domain data governance team structure includes members who represent the applications, business processes, and analytic areas, and who are creators and consumers of the master data for that domain. And assuming the data governance team has established a RACI matrix (see Chapter 6, Figure 6.5) for its communication needs, the MDM program can leverage this matrix and associated process for its outward communication needs. Using the data governance RACI matrix for the MDM program’s outbound communication needs is not only good practice to avoid confusion or overlapping that can occur if these communications are not well coordinated, but it also visibly demonstrates a strong relationship between the MDM program and data governance. Chapter 6 provides more detail regarding the data governance role, as well as examples of a RACI matrix.
Program Value
There is no single recipe for fully expressing the value proposition or an ROI for MDM. Attempts to try to calculate and project a programwide ROI can be complex and highly speculative. Too much emphasis on a hard ROI can miss the central point that MDM is really a critical data management practice needed to better manage and control a company’s most important data—it does not always immediately translate to a monetary benefit. A multi-domain MDM program involves many data management disciplines that need coordination across business and IT functions. This dynamic cannot be put into fixed-time and fixed-cost outcomes that can be clearly calculated up front.
If anything, the longer-term value of MDM can be truly measured only in real time, as cohesive data management and sound governance decisions are made based on ongoing business needs and strategic plans. However, there can and should be ROIs calculated for investment decisions related to vendor solutions and incremental resources that the program needs. ROIs for these type investments may be required, so the MDM PMO needs to be prepared to address the ROI question when required. But overall, the MDM program should be recognized as a developing internal core competency and a necessary investment area for improving data management practices across the company. As such, MDM should be positioned in the company so that the program can mature and realize its long-term value.
Consider what this book has identified as the fundamentals of MDM—data governance, data stewardship, data integration, data quality management, and metadata management. These are data management and quality management process investment areas that should be justifiable based on any number of existing business problems and data issues. Companies first need to recognize their most critical business needs for MDM initiatives and build the business case around them. Next, they should estimate how much they are losing by not realizing all the benefits of a having a timely, accurate, and consistent set of master data delivered to the various business functions in the company. This is sometimes referred to as activity-based costing (ABC). Often, the best way to measure the potential benefit of MDM involves determining the amount of money that a company spends with reactive activities in place to compensate for a suboptimal set of processes and tools.
Program value should also be demonstrated continually once MDM domains are launched, by using a consistent communication and performance measurement approach that reports MDM program activity, performance against targets, and key program achievements. Performance measurement will be covered in more detail in Chapter 11.
Issue Management and Resolution
Ownership and change control of master data should have clear lines of sight, but because MDM issues can be associated with people, processes, and technology, issue and incident resolution needs to be effectively coordinated across the MDM program office, data governance, IT support, and project teams. As with any incident resolution process, there are three fundamental functions that need to be coordinated well:
• Assigning and escalating the problem
• Tracking and closing the problem
Reporting the Problem
Master data issues can be discovered virtually anywhere in the operating and analytical processes. Often, data issues in the analytic areas are not discovered until far downstream. The master data landscape is further complicated by the fact that the creation and introduction of various master data occur in many processes across lines of business (LOBs) that can have different quality management and defect management priorities. Therefore, it is extremely important that master data issues are identifiable, reported, and quickly evaluated to avoid or minimize business impacts.
If a company has implemented enterprise standard incident resolution and defect management processes, it will be much easier or the MDM PMO office to work with these process teams to establish rules, attributes, and reports that can flag significant master data issues as they are being reported and progressing through the processes. If the PMO and data governance have examined master data life cycles and CRUD dynamics, it should be easy to recognize and communicate with the business process areas and the incident resolution processes where master data related issues can emerge.
Assigning and Escalating the Problem
When a master data issue does emerge, clear guidelines for handling, prioritizing, and routing the issue are needed. Most effective help desks and call centers will have such guidelines and operating procedures, but unfortunately, they typically do not include any formal engagement practices or escalation protocols with an MDM PMO or data governance program. Similar to how an MDM PMO needs to establish engagement rules with a solution design process area (see Figure 4.3), the PMO should also build relationships with incident resolution processes that can involve master data. And as those processes assign an issue to a support area, the agents and support groups should be aware of the MDM PMO and data governance as functioning bodies that can or should become engaged based on engagement rules that have been predetermined.
Often, an issue related to a systemic data quality problem (e.g., missing data, garbage data, incorrectly formatted data, or duplicate data) is reported as a trouble ticket, incident report, or defect by an operational or analytic team. A help-desk process will not typically be able to resolve such problems and will need to escalate them to a data governance or data quality support function where more extensive root cause analysis, impact assessment, and remediation can occur. Having solid relationships between the MDM PMO, data governance, and the incident resolution processes will make it straightforward for the support teams to be able to reach out or formally escalate master data issues to the MDM PMO or data governance bodies per established engagement rules.
Tracking and Closing the Problem
With having established good relationships and engagement rules, the MDM PMO can work with the incident resolution process areas to be able to monitor and track the master data issues submitted through these processes. Tracking that data and recognizing the local user areas and processes that are submitting these issues will provide very valuable, real-time usage information and insight to augment knowledge gained from examination of the master data life cycle and CRUD dynamics. From this insight and the ongoing tracking of this, the MDM PMO will start becoming increasingly familiar with the types and nature of MDM issues, where the issues are emerging, and who is affected by the issues, and therefore it can raise visibility and support solutions to permanently fix recurring problems.
The MDM PMO should also review the closure procedures related to the incident resolution and defect management processes. It is important that master data issues are not spuriously closed or left in aging backlogs that are going nowhere. If an incident resolution and defect management process does not have resources or pathways to address certain types of master data issues, the MDM PMO should examine this problem, determine if these issues need to be addressed with data governance or reassigned, or at least assist the incident resolution and defect management processes by examining and justifying the closure of aging master data issues. Premature closure of master data issues or moving them to an inactive aging state usually results from a lack of sufficient knowledge, guidelines, and reassignment paths for how these issues should be handled. The MDM PMO and data governance can assist these incident resolution and defect management processes with creating more end-to-end guidelines and examples to help support teams triage, position, and close MDM issues.
Conclusion
This chapter discussed the planning and structure needed for creating a MDM Program Management Office, including the roles and responsibilities of the PMO in relation to program resources, budgets, tools, and alignment with other key functions and incident resolution processes.
Simply stated, a MDM PMO with a multi-domain scope can expect to encounter a lot of variables, so do the math and complete the necessary analysis to identify what program and domain execution challenges there are likely to be. A successful MDM strategy and program plan will need to be prepared to address the variances, challenges, and obstacles that will apply across the domains. Gear your PMO office to help facilitate the common and unique elements, while also driving the domain programs to stay in the scope of the overall enterprise MDM model and objectives. A PMO must ensure that there is good alignment between itself, data governance, and IT governance.