Intro
This page is a post mortem to my dissertation project, the Master Construction Plan (MCP) @ Volkswagen AG. It provides a brief overview of the project, teasers and links to paper and online versions, und a summary of key findings.
As you can further explore on my About and Blog pages, my professional interest has shifted back from consulting to software development. However, I am always interested in discussing the MCP-Method from a scientific - and even more - from a practical perspective. Just contact me directly.
Please also feel free to utilize the materials you find on this site as well as the download version of the dissertation which I am providing on CC-BY licenseopen in new window. If you need any of the original sources such as graphics I am happy to provide them on request.
Please note that the actual dissertation is published in German for various practical reasons. If there is substantial interest (i.e. willingness to fund) I would be happy to get the thesis translated (whole or parts).
The text on this site is rather casual and does only scratch the surface. It is not meant to replace the detailed reasoning provided in the thesis itself!
What is the MCP-Method about?
In many large organizations individual business units use different IT-business applications for the same business purpose. By standardizing on business applications, organizations aim to harmonize business processes across the board and to save expenditures on customizing and operating the applications.
The Master Construction Plan (MCP)-Method describes a systematic IT-Governance process developed at Volkswagen AG to drive business application standardization. During my thesis project I accompanied Volkswagen AG in the initial development, deployment and continuous improvement of the method during the years 2005-2011. In this time the method was applied in twelve independent cycles each reaching across the complete organization.
The MCP-Method supports the organization to spell out standardization decisions, to coordinate the decision making process across geographic and departmental boundaries and to ensure enactment over long time periods. This focus on catalysing standardization decisions is a rather unique approach. It is based on the observation, that many standardization issues and viable solution alternatives are already known to the organization. However, decisions are not being made due reasons embedded into the organization's structure in general, embedded into the IT-organizaton's structure in specifc and related to IT-idiosyncracies. What is not needed is another data collection and analysis to identify overlaps and standardization potentials! It is rather to unblock the analysis paralysis related to standardization decisions for business applications and following-up on them.
What does the execution of the MCP-Method look like?
The MCP-Method describes a yearly process in which the Organization reviews the progress made with standardization. The process is separated into three phases outlined in the figure below (German Version only) and explained in the following sections.
Phase 1: Corporate decision making
In the first phase of the process, standardization decisions are reviewed in the central units of the organization and negotiated with all stakeholders. This is organized by segmenting the application portfolio according to the already established departmental structures. All segment owners organize the identification of standardization issues and the negotiation process by themselves, supported by regular senior management meetings for escalations as well as conferences with easy access to relevant stakeholder. The results are captured in the so called MCP-Portfolios, a very condensed graphical format. Decisions are described in more detail and combined with business and IT-Strategy updates in the MCP-Document. The combination of "senior-management-style" portfolios, company wide publication of the MCP-Document and clearly assigned personal responsibilities, create a momentum that facilitates the actual decision making without prescribing and controlling the detailed processes steps.
A detailed process diagram (German only) can be found here.
Phase 2: Regional decision making
In the second phase, regional organizations are systematically approached. They need to review the proposed standards and integrate them with their local business application portfolio. This also includes to identify local consequences of certain moves such as decisions to phase out redundant local solutions. These strategic decisions are then systematically followed-up to make sure they eventually lead to projects and implementation steps.
Detailed process diagrams (German only) can be found here for regions and here for individual organizations .
Phase 3: Review regional decision making
As to be expected, some standardization decisions are rejected by local organizations - often based on valid reasoning. The third phase focusses on resolving critical issues and making sure that joined agreements on the further proceedings are being made.
A detailed process diagram (German only) can be found here.
What are the main results of the thesis
The thesis provides three core results:
- A grounded theory of standardization antagonists - an analysis of factors that inhibit business application standardization in large organizations
- The detailed formal description of the MCP-Method as such
- A series of design principles that reason why and how the the MCP-Method is working
From a research point of view, these results may be used to validate, discard and improve the MCP-Method in whole or in parts. They also point to some discrepancies with documented findings in scientific and practitioner's literature.
From a practitioners point of the view the result allow senior IT-decission makers to reason, whether their organization is facing similar challenges and to adept and implement the MCP-Method if appropriate. While I cannot provide a scientifically proven method to solve their problems, I have put great effort into explicating the reasoning behind various method details to allow to assess the relevance and allow for customization.
Factors inhibiting business application standardization (Grounded Theory of standardization antagonists)
The figure below summarizes why large organizations with federated IT-decission making are challenged with business application standardization.
(original German version can be found here)
On the business side, these companies implement a broad array of business processes with different dynamics and philosophies. A car manufacturer for example deals with processes as diverse as early prototype construction, just-in-time assembly line management or workshop service management. Each of these processes faces individual challenges and demands individual strategic adjustments. This is further complicated by providing services for a multitude of brands, markets and other divergent application contexts. As as result, large organization often implement a multi layered, matrix style organization structure with overlapping responsibilities and areas of concern. There is a continuous discourse between leveraging local opportunities on the one hand and corporate synergies on the other hand. There is no either-or decision, but constant adjustments in individual business areas. As a result, strategic decision making in regards to business application standardization is costly and always involves many stakeholders.
The IT-organization of such organizations reflects this complexity. IT-deparments in central and decentral units continuously negotiate over local vs. global gains. Seemingly technical discussions about the efficiencies of individual business applications are often rooted in underlying conflicts about whether to support local or central needs. As an additional factor individual employees often build their career on developing and maintaining "their" business application adding a personal dimension to what seems to be a rational decision making process. As a result, the operative decision making in regards the business application portfolio is also costly.
Finally, the business application portfolio is actually very complex from a technical perspective. Business applications are connected via information flows, share components such as databases or use shared resources in the data center. To handle this complexity, large organizations have implemented a highly diverse division of labor. The IT-Operation department runs applications, the Architects focus on long-term viability and the business-IT caters the requirements and support needs of the business users. The different segments within the IT are so specialized, that they have developed different methods, terminology and tools. They also have partially conflicting goals in regards to the business application portfolio such as minimizing changes from an Operations point of view, implementing long-term solutions from an Architecture perspective vs. rapid response to business needs on the Business-IT side. This creates another ongoing discourse. As a result the implementation of changes to the business application portfolio often takes several years providing many opportunities for blocking and watering down initiatives.
The result of is Analysis Paralysis - decision making in regards to the business application portfolio is inhibited. Due to the effort involved of standardizing on corporate business applications the easier way out is to focus on local solutions, preserve the status quo or deliver partial solutions.
It is important to point out that these are not deficiencies of the organization that need to be eradicated. The ongoing discourses are vital to maintain an inner balance and be successful in a complex business environment.
Design-Principles of MCP-Method
The design principles of the MCP-Method are based on the analysis outlined above. They are structured according to a generic Enterprise Architecture Management (EAM) reference frame based on other EAM approaches. The figure below summarizes the core principles which are described in detail in the thesis and are outlined below.
(original German version can be found here)
One challenge how to divide the business application portfolio into manageable segments (Define segments). As the challenge is to ease decision making, the MCP-Process relies on using the already established departmental structures. While this seems to be obvious, many EAM-Methods recommend to partition the portfolio according to functional and optimal criteria to minimize overlaps. While this is great for external consultants to grasp the complexity of the portfolio, it only creates more tension. To ease decision making it seems to be vital empower the existing "owners" of certain application areas rather then implement another matrix decision structure on top.
Many (but not all) application portfolio decisions require some strategic alignment on priorities and direction of the supported business lines. While most EAM-methods simply assume, that such strategies are available, in reality they are rareley so. To develop actionable strategies with business lines requires a lot of effort. It will only happen, if there is a strong senior management pull and support for such strategies (not to mention time budgets and funds). This includes the management option to explicitly work without such strategies for certain application areas and focus on IT-operation benefits and more technical standardization options.
Many decisions require at least basic information about which unit uses what business application for which purpose. In large organizations this is a major challenge as the responsibilities of these applications are spread across the enterprise. The MCP-Method proposes means of decentral data collection which has many operational challenges that need to be addressed.
So how to find on the Target-Portfolio, i.e. the long-term vision which business applications should serve the organization in the future? The MCP-Method does explicitly not provide a selection or analysis strategy. It rather assumes, that the respective segment owners already know the issues within "their share" of the business application portfolio. They also already know different alternative and pros and cons of each decision. However, they haven't come to an agreement on how to proceed due the organizational challenges outlined above. The MCP-Method fosters decision making by guiding senior management attention and support to the decision making progress. The progress of individual segment owners and their stakeholders is made transparent and easy to follow-up. The MCP-Method also aims to bring up conflicts as early as possible and to address them openly. An example is that not only standards are decided, but also - at the same time - which other business applications will be phased out in the mid-term as result (which usually leads into to intense discussions with IT and and business lines).
With all the progress on deciding on business application standards, it is important to also ensure their implementation. Implementing such a standard usually means to roll out a business application to many (somtines hundreds) of organizations spread around the world. This requires to solve various, technical challenges such as interfacing with local applications, observing local legal restrictions, data transfer from superseded applications, hiring local project teams -to name just a few- all while keeping the business processes up and running. Given this complexity, it is vital to monitor the implementation systematically and to support distributed decision making on various implementation issues.
MCP-Method description
The actual MCP-Method comprises detailed descriptions of the process and its activities and roles. It also describes the artifacts such as diagrams, documents or maturity measures as well as techniques for creating them. They are described in detail in the thesis.
One of the central artifacts is the MCP-Portfolio:
(original German version can be found here)
It is used describe the status of individual business applications. If such applications are placed in the right quadrants they are part of the Target-Portfolio. If they are placed in the left quadrants they will be phased out in the mid term. If they are placed in the top quadrants, they are or will be used across the organization, if they are placed in the lower quadrants they are only used locally by individual units. Q1, the top right quadrant, therefore contains the standard business applications. It is further subdivided into applications that are standards, but are already available or functionally stable as opposed to applications that are still in rollout or are being extended functionally and therefore receive a high share of the available IT-budget. Applications in Q4 (lower right) fulfill vital local needs and will continue to be funded by local units only. Q2 (upper left) contains group-wide applications that are to be phased-out. They are further distinguished into ones, that are already being replaced and others, that cannot yet be replaced, but receive no funding for further development. Q4 (lower left) is the equivalent for Q2, but for applications only used by individual business units. The lower quadrants are further subdivided, to indicate whether the applications are managed by IT-departments or owned by the business units directly.
The MCP-Portfolio is applied in several variations for individual portfolio segments as well as for reviewing the applications in use in a single business unit. While the master data is maintained in an Enterprise Architecture tool, it is often used in Flipchart size to capture the results of management discussions.
Notes on my research approach
My research philosophic groundings, the research methods used and the quality criteria applied are described in the thesis in detail. On this level it is important to note, that I am combining qualitative research with design science. I cannot provide "proof" that the MCP-Method works for other organizations from my research at Volkswagen AG. Instead I focus on explicating why the MCP-Method is designed the way it is designed and describe the experiences gained when applying it over a period of six years.
Where to buy the book or download the CC-Version
There are several options:
You can buy the book at your local bookstore: ISBN: 978-3-7375-3867-1
You can buy the book online at amazon or where ever you prefer. buy from epubliopen in new window
You can download the Creative Commons Version for free. No frills attached. download (18 MB)