MDM-CDI project implementation guidelines

MDM-CDI Project Implementation Begins

Let us assume at this point that the business drivers, objectives, and value propositions for the master data manangement (MDM) - customer data integration (CDI) project have been established and agreed upon within the organization. This agreement should result in senior management's issuing marching orders to the information technology organization to proceed with the project. Senior management wants to know how the project will be organized and planned—major milestones and releases. Senior management will also want to know how much this project would cost to develop and deploy. What should the IT organization do to translate business objectives into IT vision, strategy, actionable road map, and resource-loaded project plans, in order to successfully implement the project? Senior management will want to see the end-state vision across all business and technology domains, and will ask a number of key questions such as how the currently ongoing projects should be modified, aligned, and prioritized in the context of the MDM-CDI project. These and other critical questions are discussed in this chapter.

One of the key management challenges of MDM-CDI projects is the need to define the project's success criteria. When asked informally, IT executives may provide very different answers to the question of how to decide if the project is successful, including answers such as "Have better quality data," "Improve application functionality," "Achieve regulatory compliance faster," and "Keep the end users happy." In practice, MDM-CDI projects should follow a capabilities road map with a sound release strategy that defines what will be implemented and deployed, and when. A key component of this road map is clearly defined short-term and long-term success criteria that need to be understood and agreed upon by all stakeholders.

Of course, the tasks of defining the road map and success criteria would be so much easier to accomplish if there were a single strategy and solution architecture that works for all MDM-CDI implementations. Unfortunately, that is not the case. As we mentioned earlier, MDM-CDI projects address multiple, often diverse business requirements, involve a broad spectrum of technical disciplines, and can be extremely complex.

At a high level all MDM-CDI projects are quite similar. For example, all CDI projects have common goals of delivering an authoritative system of record for customer data that includes a complete, 360-degree view of customer data including the totality of the relationships the customer has with the organization. At this high level, project management and all key stakeholders are enthusiastic and are in "violent" agreement about the capabilities and opportunities offered by a CDI system.

The devil is in the details. And there are many details to consider. At the beginning and in the course of an MDM-CDI project, the wide variety of questions, issues, and dependencies may appear so overwhelming that the initiative's stakeholders feel like the fishermen in the movie "Perfect Storm." The characters of the film were practically helpless before the fury of the ocean. The situation may seem similarly unmanageable for the participants of some MDM-CDI projects. Many large MDM-CDI projects failed with dire consequences for the company and people who worked on the project. We will discuss risks and reasons for project failure in Chapter 18.

Key Senior Management Concerns How will the equity value and market capitalization of the company change as a result of the MDM -CDI project? What is the first set of applications and business functions that would become the early adopters and beneficiaries of the MDM -CDI project? What is the phase-by-phase and total project cost/ROI? How will the new business processes be different? What will it take to accomplish the transition to the new business processes? What additional skills, both business and technology, will the organization's staff members have to acquire and how? Will the organizational structure be affected, and to what extent? What legacy systems and functions will be affected and how? How will the project be organized and planned? What are the major milestones and releases? Does the technology organization have adequate knowledge, resources, and understanding of industry best practices in order to translate business objectives into IT vision, strategy, actionable road map, and project plans, and successfully implement the project? What are the investment and delivery risks and mitigation strategies? What is the end-state vision that would impact business and technology domains? How should the current in-flight initiatives be modified, aligned, and prioritized in light of starting a CDI project? What are the success criteria for each phase and for the project overall?

In short, due to the variety of conditions and the complexity of the MDM-CDI projects, it is difficult to define a single one-size-fits-all set of recommendations. Experience shows that an effective working approach to complex and diverse problems like the one presented by MDM-CDI is to define a comprehensive solution framework that is designed around sound problem-solving architecture principles including separation of concerns, layered architecture, federation, and service orientation (please see Part II for more details on the architecture framework and design principles). Such a framework allows us to use industry best practices for particular areas of concern, and to break down the problem domain into smaller and more manageable pieces. At a more granular level the tasks and decision-making points are much more common and manageable across MDM-CDI projects. We will follow this approach and break down the CDI problem domain into work streams and components that support and are supported by what we define as the CDI "ecosystem." The areas of concerns and key components that constitute a CDI "ecosystem" are shown in Figure 11-1. We discuss most of them throughout this book in more detail.

The CDI "ecosystem" is a layered construct that includes business processes and technical domains of change. The core CDI functional area includes:

• Customer identification, matching, correlation, hierarchies, relationships, and grouping
• Information quality
• External data providers

The layer immediately surrounding the CDI core is a key part of the CDI "ecosystem" even though it includes some components that support both CDI and non-CDI environments. We discuss various aspects of these components throughout the book.

Figure 11-1: CDI "ecosystem" -- high-level areas of the solution

As we continue to "peel" the layers of the CDI "ecosystem," we can see the components and services that do not necessarily represent "pure" CDI functionality, but are affected and/or required by the CDI solution to function. For example, the legacy layer demonstrates these dual properties—it is usually the source of CDI data and is a key consumer of new functionality enabled by the CDI platform.

Similarly, the outer layers of the CDI "ecosystem" cover Infrastructure, Project/Program Management, and Change Control. These areas of concern are vital for any successful CDI implementation. Indeed, it is hard to imagine a project of MDM-CDI magnitude that can be successful without considering infrastructure issues or providing adequate program management and change control.

CDI-related areas of the "ecosystem" contain components that have to be acquired or built. Thus, the CDI "ecosystem" also provides a framework for "buy vs. build" decisions. These decisions are not easy to make, especially considering that many vendor products in the CDI space overlap, and the resulting market focus and positioning of many CDI vendors continues to change. For example, ETL and data synchronization vendors are moving into the Information Quality space, and Information Quality vendors are extending their capabilities towards CDI Data Hubs. The discussion of the vendor landscape and their product features can be found in Chapter 17.

The complexity of the MDM-CDI problem space requires participation of multiple stakeholders. This in turn, creates a formidable socialization problem. The idea of bringing all people onto the same page on all issues can easily paralyze any initiative. While consensus building is a good strategy, we need to remember that both unlimited democracy and military-style decision making can cause large initiatives to fail. Best practices suggest to set up a small leadership group that can successfully combine principles of strong management control and decision making with principles of sharing information and keeping all participants on common ground in key areas.

Workshop Agenda State project goals and senior management concerns. Define and agree on the end-state of the solution and what it means from both business and technology points of view. Discuss the types of partners and vendors that will be required to achieve the objectives. Define and socialize the project's organizational structure and project governance. Discuss a high-level road map. Determine project success criteria. Analyze cost benefits of the project. Discuss the timeline, content, and the deliverables of the project on a phase-by-phase basis. Build consensus between business and technology teams as the decision on "What should the first release look like?" is made. Of course, every time you want diverse groups such as business and technology teams to agree, you have to overcome the challenge of each group looking at the problem from its own perspective. Using the comprehensive solution framework described throughout this book should help the reader to manage the discussions about the project and to make decisions that each project team can be comfortable with.

It is a good idea to start an MDM-CDI project with a well-structured workshop where business vision and technology approach will be discussed. Two or three days spent as a team can be very beneficial to jump-start the project by getting high-level agreement on a number of key issues.

Using a multiphased approach to a CDI project is clearly a good strategy. The outcome of the first phase (first release of the CDI solution) should be thought of as a trade-off between what the business ultimately needs and what is achievable in a single release. A practical rule of thumb is that each phase should not exceed six to eight months and should deliver tangible, business-recognizable benefits. Credibility of the project will be at stake if a year has gone by and no changes have been implemented. Enterprise-level planning should be in place to ensure successful cross-departmental delivery.

When a CDI project is initiated, IT groups should have access to a business-sponsored document that defines business case by business function and line of business. This business requirements document should include the following:

• Formulation of business problems as they relate to MDM-CDI
• Definition of the business scope including articulations of the new business processes
• Strategic business vision and objectives
• Business drivers and priorities
• ROI estimation for MDM-CDI implementation

Considering the complexity and potential breadth of the impact a CDI solution may have on the organization, defining the scope is one of the key factors that determines the actual or perceived success or failure of the CDI project.

More information

• Continue reading Chapter 11: MDM-CDI project implementation guidelines
• Go back to read Chapter 6: Data governance and data stewardship strategies and best practices
• Read more data management books in the Chapter Download Library