Surviving Turbulent Times: Prioritizing IT Initiatives Using Business Architecture
Martin Sykes
Microsoft Consulting Services
Brad Clayton
Microsoft Consulting Service
June 2009
Summary: This article describes a technique that Microsoft architects around the world use every day to ensure that IT projects have both a clear alignment with the strategic goals of the organization and a strong demonstrable impact.
Contents
Introduction
The Benefits Dependency Network
Creating the Enterprise Benefit Map
Creating the Enterprise Capability Model
What Is a Capability?
Microsoft Services Business Architecture (MSBA)
Bringing Together the BDN and Capability Model
Measuring the Capabilities
Mapping Project Technologies to Projects in the BDN
Using the Capability Heat Map and Benefits Model to Prioritize the Portfolio
Resourcing the Newly Sorted Portfolio and Putting On a Time Line
Conclusion
Introduction
In turbulent times, budget pressures increase and IT spending is scrutinized. We will describe a technique that Microsoft architects around the world use every day to ensure that IT projects have both a clear alignment with the strategic goals of the organization and a strong demonstrable impact. This is used to prioritize the project portfolio to maximize return on investment (ROI) and determine the projects that should receive budget and resource allocation.
Methods include Microsoft Services Business Architecture (MSBA) to identify what to change and the Benefits Dependency Network (BDN) to understand fully whythe changes must be made. This leads to a clear alignment withhow the projects will make those changes. By using these methods, we identify the people, processes, and technology that are to be changed and provide clear alignment with organizational goals so as to achieve both financial and nonfinancial benefits. Many organizations have subsequently incorporated these methods into their project management and portfolio-prioritization processes.
We will use a fictitious retail bank, Contoso Bank, where we are working with the Chief Information Officer (CIO) and the enterprise architecture (EA) team to address two needs:
- Provide a holistic way to review the IT portfolio and ensure that resources are focused effectively. We will create a common model that describes the business capabilities and associates the supporting people, processes, and technology. This will allow us to see areas in which duplication exists, as well as opportunities for reduction in cost and complexity.
- Produce a method for reporting on IT activities, so that stakeholders understand both how IT investments are structured and that we are realizing the predicted benefits.
Figure 1. Overview of the process (Click on the picture for a larger image)
Figure 1 provides an overview of the process. The two key methods work closely together to translate three inputs into a clear set of recommendations for a rationalized and optimized portfolio:
As an input, the EA team provides a consolidated list of all projects that are underway, as well as details of the benefits that are documented in the project proposals. We commonly find that most of the benefits are described in terms that the IT staff will understand or that have loose ties to the strategic direction of the business. Budgets are constantly undergoing scrutiny, and stakeholders need to know that the budget is used appropriately. This process will connect the
IT project portfolio to business capabilities and, in turn, business strategy. By clearly defining measurable benefits that can be aligned with an impact on the business, we will have a solid foundation for later measuring the realized value across the entire IT portfolio.
The Benefits Dependency Network
The Benefits Dependency Network (BDN) is a model—usually created on one page—that links IT projects to the business activities that are being changed and the reasons behind those changes. It is one part of the benefits- management approach that was developed by the Information Systems Research Centre at Cranfield University School of Management in the U.K. Over the last 10 years, we have extended the original model to include a time line.
Figure 2. Components of a BDN (Click on the picture for a larger image)
Figure 2 illustrates the key components of the BDN. In this model, we start with an understanding of why the business must change via the drivers, objectives, and benefits. We can then connect the benefits to the business processes and capabilities to understand what will have to change to realize the benefits. We also gain a better understanding of where the changes will happen in the organization units and specific locations. Finally, we can determine how to make the changes via projects that will change business activities and the technologies that will support them. In all of this, we can also identifywho are the stakeholders. Who will be responsible for demonstrating the benefits that are achieved; who owns the business activities that are to be changed; and who will run the projects?
By prioritizing the objectives and benefits, and then incorporating requirements in the order in which to change business activities, resource constraints on projects, and any technology dependencies, we can sequence the projects and showwhen they will be implemented on a time line.
Firstly, the value in a BDN is in having a clear definition of the why, what, and how. Secondly, the values are in the connections that are drawn across the diagram to show all of the relationships.
Typically, a BDN is started in a workshop and completed over a number of weeks via interviews and iteration. Often, we use the BDN at the start of major programs to define the projects, but we use it also to define the components of large projects and map the portfolio of projects in an IT organization.
Creating the Enterprise Benefit Map
Like many customers, Contoso Bank has hundreds of IT projects. Starting with the projects that have the largest business or IT contribution, we identify the business functions that will be affected, along with the benefits that are expected. By using the Contoso Bank business and IT strategies, we capture the top- level organizational drivers and objectives.
Figure 3. Extract from the BDN of Contoso Bank (Click on the picture for a larger image)
This information is laid out as Figure 3 shows— with projects on the left, business functions and benefits in the middle, and organizational drivers and objectives on the right. By working with the project stakeholders and subject-matter experts from both IT and the business, we connect the items in each column: aligning projects with the business function, the business function with the benefits, and so on.
This simple view provides us with the ability to quickly validate the portfolio and identify if there are projects that do not align with any of the objectives. For these projects, either we need more information or we have identified the first round of projects for possible rationalization.
We repeat the process again for the next tier of projects. Although the model grows in complexity, the process gathers pace as we iterate through the project portfolio.
Creating the Enterprise Capability Model
During creation of the BDN, we described the business function that was affected by the proposed change in terms that are used by the project definition. We must use a common framework for the business functions in order to compare projects and identify possible duplication or opportunities for optimization across projects. This framework is defined by MSBA.
We always begin development of capability maps from a predefined template. For this scenario, we begin with the retail-banking capability template. By using this model as a starting point, we validate the top two levels and adjust the naming of capabilities to reflect the terminology of the bank and create the framework into which to map projects.
With the EAs and the project, leads we work through the portfolio of projects. For each project, we validate the benefits and objectives that are identified in the workshop, understand the technical solutions that are required for the project, and identify the business capabilities that will be affected. During this process, we take the business functions and organizational groups that are identified in the workshop and perform a mapping to the capabilities model.
What Is a Capability?
A capability is an abstract view of a business function. A capability model provides a stable view of the organization, even if the implementation changes. Capabilities are hierarchical; each might contain child capabilities that provide greater detail and specificity. Capabilities are measurable and have properties that might include current performance, business value, consumers, owners, maturity, and key performance indicators. The properties will also detail the people, processes, and technology that are used to instantiate the capability.
Capabilities also can have connectors that are used to record relationships. The connectors include details about the type of relationship and service-level expectations.
While processes are modified, technology changes, and people reorganize, a business capability remains constant.
Microsoft Services Business Architecture (MSBA)
MSBA is a blueprint of a business that spans the organization- mapping information at a high level down to a detailed granular level and expresses each discreet function or business capability. MSBA defines business architecture as what the business does in the form of business capability. This is in contrast to how the business implements the capability in the form of people, processes, and technology.
MSBA is a view of the operating model of a business or organization, based on its business capabilities, and is not limited to the four walls of the legal entity of the organization. Use of capabilities provides an abstract view of the organization that remains stable, even as processes, technologies, and people change. Even the changes that are associated with outsourcing do not change the capability map.
The capability map acts as a common language that can be used between both the business and IT. It also provides a solid foundation for discovering and describing services, when defining a service- oriented architecture (SOA). Having studied businesses across many industries, Microsoft found that businesses within most industries exhibit five core operational capabilities, as shown in the center of Figure 4.
These MSBA capabilities are the root capabilities that are built on, when developing the business architecture for the operating model of an organization. The capabilities that appear outside of the diagram are known as the environmental constituents. These represent entities that are outside of the direct control of the organization and generally are provisioned by other organizations. In most cases, these entities are not detailed and include only the capabilities that are needed. It is common to see regulatory requirements called out in this area, with relationships to capabilities that are affected by the requirement.
Figure 4. MSBA capabilities (Click on the picture for a larger image)
Figure 4 identifies the core capabilities. Below this, we have a capabilities group at Level 2, and then business capabilities in Level 3 and below. This is an important distinction. While Levels 1 and 2 provide a framework to understand the business, it is only when we get to Levels 3 and below that we see a level in which specific project changes can be discussed and scoped sensibly.
The purpose of our capability model is to help understand the value of the IT portfolio. This means keeping the capability modeling at a high enough level that we do not get lost in the details and can retain the organizational overview.
In most cases, it will be necessary only to map the capabilities of a project to Level 3. In some cases, however, it might be necessary to map capabilities to Level 4. This is done when further clarity is required or to highlight specifics of one project when contrasted with another.
Bringing Together the BDN and Capability Model
It is time to bring together the two models. The original BDN contains the business functions from the initial project analysis. The capability model contains the capability definitions that are aligned with the wording that is used within the organization. We use this to update the BDN, so that it incorporates the new capability definitions that are replacing the business functions.
The example in Figure 2 from the initial workshop identified the SmartCheck project as affecting the “detect and reduce fraud” business activity. As we drilled into the capability model, we changed this to relate directly to a Level 4 business capability: “Fraud Detection.” In another example, the “OneContoso” project has the goal of providing an integrated customer account–management service. In this project, we identified many different capabilities at Level 4 that would be affected. These capabilities roll up into the Level 3 “Customer Services” capability. The Level 4 capabilities are important to the “OneContoso” project; for our purposes, however, we can focus on the higher Level 3 “Customer Services” capability.
Measuring the Capabilities
It is important to understand why we are going to measure the capabilities that we have identified. In most cases, we measure a set of properties for capabilities and plot these on the capability model to create a graphical representation that is called a heat map, in which the fill and border colors for capabilities represent the value of a property.
There are a few properties that are often included for project-scoping work:
- Business value: The strategic value of a capability or the degree to which it affects organizational performance. This is the measure to which a capability is a market differentiator or a competitive requirement.
- Maturity: The level of consistency and predictability with which the capability is performed. Is there a well-defined process in place that is monitored and measured?
- Performance:The capability that meets service-level expectations.
There might be additional properties that are important to each project; however, our goal by capturing the same information for each capability is to contrast the properties and identify where to focus. When reviewing a portfolio of projects, “level of IT investment” is a primary property. We use heat maps to provide comparisons quickly and enable us to focus on areas of interest.
The Contoso Bank Heat Map
A heat map is a graphical view of the entity map in which property values are used to define entity shape characteristics. For example, business value will be represented by the border color, and performance will be represented by the fill color of the shape.
Figure 5. The simplified Contoso Bank capability heat map (Click on the picture for a larger image)
Figure 5 show the Contoso capability map in which the fill color of the shape is determined by business value and the border is determined by the level of IT investment.
The two properties that are used to understand the portfolio are the business value that is to be achieved by improving the capability and the level of IT investment in the capability. A five-point scale is used to help quantify value and spend. By working with IT and business stakeholders, we capture their understanding of the value to be realized in each capability as a result of all of the IT work that is being done in the capability. A capability might be affected by more than one project; so, here we are interested in the cumulative impact. By working with the IT stakeholders, we assess the scale of IT investment in a capability. Just as there might be more than one project affecting a capability, we might also find many capabilities being affected by one project; so, we are asking for an assessment of how the IT investment is distributed.
One of the more important pieces in the assessment is the relative impact of each project on a capability, when more than one project is mapped to it; so, we identify projects that have overlaps in scope and could be rationalized to reduce costs.
Figure 5 shows a simplified heat map—down to Level 2—that was created for our Contoso Bank example. In reality, this would drill down to Level 3 and show only the capabilities that are being affected by the project portfolio.
Mapping Project Technologies to Projects in the BDN
We now return to the BDN and the portfolio of IT projects. Every IT department typically has many projects for the implementation of shared infrastructure, technology upgrades, or projects. Some of the technology projects will be uniquely associated with a project that enables a business change and, as such, will have been identified as we evaluated each of these projects earlier. We now bring all of them into the enterprise-level BDN and show the linkage between the projects that are for implementing technology and the projects that are for effecting change in the business.
We leave the technology projects until after the business projects, because our focus is on the value of IT to the business, and the business view is where we must start to get that structure right.
At this point, we find technology upgrades and deployments that do not obviously connect to business-change projects. Sometimes, these projects should just be stopped. In other cases, we find that the technology is required just to run the business. For example, it could be a network upgrade that is necessary to accommodate normal traffic growth.
We use capability modeling to replace the processes and organization names that initially were used for the business changes in the BDN, because capabilities persist, while their implementation in people, process, and technology will change over time by the actions of the projects in our portfolio. If it aids in understanding, we can also create alternative heat maps that use annotations to show which capabilities will be affected by specific enabling technologies.
Using the Capability Heat Map and Benefits Model to Prioritize the Portfolio
With a completed high-level BDN and heat map to demonstrate the potential business value that is being delivered by IT, we now can start a review of the portfolio of IT projects. For a project to have been in the initial portfolio, it would have to have cleared the basic ROI hurdles of the bank. With the information that we have now, we will:
• Recommend cancelation of projects that have no clear alignment with business objectives and benefits.
• Restructure projects that have overlapping impact on the same capabilities, so as to reduce duplication of effort.
• Rationalize IT projects to leverage common technologies across the business projects.
Finally, we can prioritize the remaining project portfolio, based on the highest priority objectives, strongest business benefits, and highest business-value capabilities. The Contoso Bank team has to determine which of the objectives, benefits, and capabilities it should use as the drivers of prioritization. However, the analysis that we have done makes this information clear. The information and approach that we have applied allows us also to compare projects that have strong financial and nonfinancial benefits.
The result of this prioritization is an enterprise-wide reduction in total cost of ownership (TCO) for IT and earlier realization of high- value business benefits that will lead to an improved ROI from the early realization of benefits. To achieve this, we also might have to review the resourcing and re-plan the implementation of the portfolio.
Resourcing the Newly Sorted Portfolio and Putting On a Time Line
With the projects listed in order of priority and allocated resources, we now produce a standard IT program plan and road map. Different views of this road map now can be created. One view shows the benefits that each project delivers, and the other the capabilities that are affected.
Just as a heat map can show the current value of properties, so can it be used also to demonstrate the value that is to be expected at some point in the future. Contoso Bank operates a quarterly reporting process to review the performance of every department. By using the new project time line, we work with the architects to create a heat map for each of the next eight quarters that shows the anticipated cumulative benefits to each capability in each quarter. The capability model itself does not change between quarters, as the capability abstractions do not change; it is their implementation that changes. So, the CIO now has a series of views to show a time sequence for how IT will deliver value and be used to track delivery against plan.
The BDN and capability map are resources that architects can update as projects progress and strategies evolve or are replaced. If the information is updated quarterly, it can be compared against the projected information, and adjustments can be made to future projects to deal with the gaps, as required.
Conclusion
A powerful and positive side effect of the use of a BDN and an MSBA capability model is the ability to tell a very clear and effective story about the IT portfolio. By using the capability heat map, the CIO has a powerful one-page model to focus attention on the impact of IT investments and to be included with updated information on the progress of projects—delivering the benefits against the plan. The information and analysis serves as the foundation for identification and prioritization of future projects.
The BDN at an enterprise-level provides an overview of the specific benefits from IT investments and a route into the BDNs for each specific project. By aligning each project with an enterprise road map, the realization of specific benefits can be noted also on the road map and tracked over time. For the first time, Contoso Bank not only can associate every IT project with the clear delivery of value, but also it can create a scorecard to demonstrate the realization of that benefit.
References
- Peppard, Professor Joe, Professor John Ward, and Professor Elizabeth Daniel. “Managing the Realization of Business Benefits from IT Investments.” MIS Quarterly Executive. Vol. 6, No. 1, 2007, pp. 1–11.
- Merrifield, Ric. Rethink: A Business Manifesto for Cutting Costs andBoosting Innovation. Upper Saddle River, NJ: FT Press, 2009.
- Merrifield, Ric, Jack Calhoun, and Dennis Stevens. “The Next Revolution in Productivity.” Harvard Business Review. June 2008.
- Ward, John, and Joe Peppard. Strategic Planning for InformationSystems. Third ed. Chichester: Wiley, 2008.
About the Authors
Martin Sykes (msykes@microsoft.com) is a Senior Program Manager in the Microsoft Consulting Service IT Architecture and Planning Service Line. His focus is on developing the methods and offerings for the Microsoft approach to IT Architecture & Planning.
Brad Clayton (bradcla@microsoft.com) is a Senior Program Manager in the Microsoft Consulting Service IT Architecture and Planning Service Line. His focus is on the evolution of the Advisory Services Program.
Follow up on this topic