Task 1 - BCM Method - Guide V5e Final

The World Bank
Official Use Only Ed BUSINESS CAPABILITY MODELING
TASK 1 DELIVERABLE METHOD GUIDE

Ver. <5 Including Heat Map Chapter> Project ID: <8003150> Prepared By Staff Name Richard Hudson Christine Etue Bob Etris Denise Bedford Susan Dubas Irma Mentzer Denisa Popescu Virginia Yee Luisita Guanlao Version 4 Approved By Version 5 Approved By Change Control Version Version 4 Luisita Guanlao Luisita Guanlao Role Grant Thornton Team Grant Thornton Team Grant Thornton Team Grant Thornton Team Grant Thornton Team Business Architecture V1 V2 V3 V4 V5 Team Date May 6, 2008 May 13, 2008 May 27, 2008 June 30, 2008 May 9 May 17 May 9 May 9 May 9 May 9 May 9 May 19 June 2
Reviewed By
Business Architecture Team EA Office EA Office EA Office World Bank - Project Manager World Bank - Project Manager World Bank - Project Manager
Staff Name Christine Etue
Version 5
Richard Hudson Bob Etris
Change Description Completed items in Appendix 2 based upon outputs from Tasks 2 & 4 Added Sections 4.2.1, 4.2.2, 4.3 Include chapter on Heat Maps as part of Extension Task A. Apply updates to rest of document to conform to new chapter (e.g. Appendix 1 Business Capability Model Templates)
Date June 26 June 26 Sept 29
Page 1 of 86
<Task 1 - BCM Method_Guide v5e Final.doc >
Business Capability Method
The World Bank
Official Use Only Information Solutions Group The World Bank Table of Contents
1 2 3 4 5 6 7 8 9 10 11
INTRODUCTION .............................................................................................. 3 METHOD OVERVIEW ....................................................................................... 5 APPROACH .................................................................................................... 12 TECHNIQUES AND NOTATION ....................................................................... 19 BUSINESS CAPABILITY HEAT MAPS .............................................................. 31 ROLES AND RESPONSIBILITIES .................................................................... 58 METHOD AND MODEL GOVERNANCE ............................................................. 61 CHANGE CONFIGURATION PROCESS ............................................................. 63 GLOSSARY OF TERMS .................................................................................... 66 APPENDIX 1 BUSINESS CAPABILITY MODEL TEMPLATES........................... 69 APPENDIX 2 MODEL REFERENCE DOCUMENTS ........................................... 72
Electronically distributed, uncontrolled if printed.
Page 2 of 86
The World Bank
Official Use Only
1 Introduction
1.1 Background
This deliverable is primarily focused on describing the approach to business capability modelling. A business capability describes what a business does - its external visible behavior and the expected level of performance (versus how it does it its internal behavior). Business capabilities have customers and they are expected to perform at a certain level in terms of delivery of a product to that customer (such as units per period of time, or with a specified level of quality). The business capability describes what is done and the expected, or contracted, level to which it is done. Inside the capability are the specifics of how that capability is implemented at a given point of time with respect to people, procedural steps, technology and so forth. In building the capability model we focus on the external aspects. How they are achieved is not important to the definition of the capability. The emphasis is on describing the external, observable and measurable behavior of the business.
1.2 Architecture Benefits

A goal of the Information Systems Group (ISG) is the adoption of an approach that supports greater engagement with business stakeholders to define, implement and manage business rules and policies for their respective business applications. By having a better understanding of the business and by developing a fully elaborated business architecture, ISG will be able to re-orient the current vertical, application-oriented architecture to one that is better aligned to business needs; is more streamlined; will extend the use of open standards; will facilitate the redeployment of platforms to support changing business needs; and, will reduce overall integration costs. The main benefits of having an overall architecture are to: Increase the agility with which IT can respond to changes in the business Increase the value of IT spend by prioritizing against overall business needs and driving cost efficiencies Ensure cross-functional alignment Increase re-use of applications and services Increase the capacity to sustain current operations Eliminate redundancy Better understand the impact of change Be better prepared and less reactive to change The advantages of the business capability approach within the overall architecture are that the model: Focuses on commonly understood, externally visible attributes as opposed to the details of internal flows; Speaks to business owners in their own language; Is a more rigorous approach to the definition of business requirements and their eventual technical implementation; and, Aims to maximize the life expectancy of the implementation in an ever changing environment - organizational structures and process flows change.
1.3 Primary Audience

The primary audience for this document are:
Page 3 of 86
The World Bank
Official Use Only
the Enterprise Architecture Office; and, the Business Partnership Teams.
1.4 Overview of the Document

Business capability modelling is just one facet of a business architecture, which itself is just one view of an enterprise architecture. To be able to properly describe the context for business capability modelling, it is therefore important to place it in the context of an overall architecture framework so that the key dependencies to other architecture views are understood. Therefore, this document is structured to build from a general description of an architecture framework to the specific details and templates to support business capability modelling. A summary of the main sections of the document follows: Section 2 - Method Overview: Provides an overview of the Integration Framework and introduces the main phases through which an architecture is elaborated. It also shows the main architecture views and describes the relationships between various architecture models. Section 3 Approach: Provide more details on business architecture at the enterprise level and then for a specific initiative. It describes the process for building the business architecture using the business capability modelling approach, the main inputs to the process, the deliverables that are produced and the key participants. Section 4 Techniques and Notation: Focuses specifically on business capability modelling and the various levels of model. The section defines the components, the steps in building a capability model and the key attributes of the model. Section 5 Business Capability Heat Maps: Presents the method for developing heat maps to demonstrate the application of criteria pertaining to performance, business value, predictability, change impact against business capabilities. The generation of heat maps facilitates decision making regarding architecture and development directions. Section 6 Roles and Responsibilities: Describes the roles of the main participants to business capability modelling. There are three main considerations, roles for those who develop and maintain the method; roles for those who develop and maintain the enterprise-level models; and, roles for those who develop and maintain the models associated with a specific initiative. Section 7 Governance: This section describes the main decisions rights and accountabilities for business architecture and the architecture methods. Section 8 Change Configuration Process: Provides an introduction to the management of models. Section 9 Glossary. Provides a definition of the main concepts introduced in this document.
Page 4 of 86
The World Bank
Official Use Only
2 Method Overview
2.1 Introduction
In todays environment, organizations have usually defined a high-level target state referred to as an enterprise vision, complemented by strategic goals and objectives. To enable achievement of the vision it needs to be described as a target state in terms of customer priorities, performance goals, business capabilities and the supporting human, financial and information technology resources. Combined, these elements are appropriately described through the standard components and inter-relationships of an enterprise architecture. To implement the enterprise architecture, an organization must make sure that the information technology is aligned with the business needs and supporting resources. This necessitates having a clear understanding of business priorities and the ability to define projects that can effectively deliver the information technology to enable the desired business capabilities. Optimally, an organization should take a holistic view of the enterprise at a strategic level and then use it to plan and execute multiple projects simultaneously. Characteristically, the holistic view accommodates comparison between: A performance-based view, which addresses the contribution of an initiative to the realization of the strategic objectives. A program-based view, that addresses the resources required to deliver the projects comprising the initiative and addresses the capacity of those impacted by the initiatives implementation. An anchor initiative view, that relates to an integrated infrastructure initiative such as implementation of an ERP system or an enterprise data warehouse that has major crosscutting impact on multiple business owners. The development of the enterprise architecture and consideration of trade-offs is a complex and difficult challenge, especially when recognizing that many interdependencies between projects exist that must be coordinated to achieve success. The challenge is exacerbated as the target state cannot be implemented overnight, but as time passes the business needs evolve. Changes to the architecture are therefore inevitable and a mechanism needs to exist to assess the enterprise impact of change on all the related architecture components and the projects that are implementing them. The architect therefore has to fully understand the transition state and follow a method that allows it to continually evolve. Without coordination of the interdependencies and their changes over time, an organization could successfully complete each project but find that the lack of integration across the projects result in a failure to implement the enterprise vision. In response to these challenges, the Integration Framework was developed. It builds upon the work done in methods such as the Zachmann framework, the Department of Defense Architecture Framework (DoDAF) and the Federal Enterprise Architecture Framework (FEAF). Like the precursors, the integration framework defines a series of integration points and work products that must be specifically addressed to properly synchronize efforts to deliver the target state. However, it builds on these and introduces a new discipline of integration management to address the inevitable changes that occur as the target state vision is implemented. Integration Management, shown as the central circle in Figure 2-1, coordinates three management disciplines:
Page 5 of 86
The World Bank
Official Use Only
1. Architecture Management involves documenting current state business capabilities, information, systems, technology and performance results; defining a target state architecture; and identifying the initiatives in the form of programs required to close gaps between the current and target states. 2. Program Management includes activities such as planning and managing scope, performance and earned value; identifying and managing risks; tracking budgets, schedules and milestones; establishing and monitoring adherence to quality standards; and coordinating change through communications. 3. Outcome Management involves activities that allow managers to not only measure program success, but also helps to make certain that program successes, and corresponding investments, support larger organizational objectives. Outcomes Management includes activities such as output and outcomes planning, performance measurement and management, business case preparation and justification, and performance analysis and oversight.
Figure 2-1 illustrates the Main Management Disciplines of the Integration Framework . Each of these management disciplines focus on a subset of the concerns that must be controlled during program and project execution. Integration Management fosters a clear understanding of the relationships among outcome requirements, architecture decisions, project costs, schedules and risk mitigation strategies. Moreover, Integration Management transition, project planning and control activities help managers make sure that: Projects are Coordinated: Projects comprised within a program are treated as parts of an integrated strategy and not as independent investments; Trade-offs are Balanced: Project solution alternatives are considered within the context of larger program objectives and not just in terms of a projects near-term needs; Architectures Drive Investment: Architecture efforts are more than just compliance exercises architectures are the basis of target state planning activities and investment decisions; and Changes are Addressed: Target state plans are regularly reviewed, adjusted and kept in tune with current organizational priorities, available resources and program accomplishments. The following section introduces the Integration Framework and sets the context for Business Capability Models.
Page 6 of 86
The World Bank
Official Use Only
2.2 Integration Framework Phases

The Integration Framework defines an organized and integrated set of processes and work products that may be used to define a target state vision for an organization at the enterprise level, and to define the overall concept and high-level requirements for an individual initiative. A simple representation of the framework in terms of the main phases and activities is shown in Figure 2-2. The area highlighted in yellow represents the business architecture view. The Framework defines two sets of visioning work products: The Enterprise Vision, which creates an integrated view of the entire enterprise within which the relationships between the high-level business and IT components are described. It also defines the sequencing for the integrated enterprise-wide suite of initiatives. The Initiative Vision, which defines a single initiative to a level of detail that would support its acquisition. This includes describing the alignment of the initiative to desired performance standards. A separate Initiative Vision will be produced for each initiative that is defined by the Enterprise Vision. The Initiative Vision work products may become part of a statement of objectives that is used to acquire an initiative solution or to guide a system development activity.
Figure 2-2 illustrates the Integration Frameworks phases and core activities. The scope of the architecture described using the framework may be very large (for example, the entire enterprise) or focused on a single solution or initiative. The level of detail in the description will increase as the scope decreases to focus on a single initiative.
Page 7 of 86
The World Bank
Official Use Only
2.3 Integration Framework Work Streams

The Integration Framework defines work products that will support both the Enterprise Vision and the Initiative Vision. These work products are grouped by work stream and by system development lifecycle phase. The Integration Framework work streams are: Performance, which defines the metrics by which the success of the business will be measured. Business, which defines what the business does to deliver products and services to its customers. People, which defines the nature of the human resource, the organizational culture and leadership, and the organizational structure and responsibilities of the units that make up the enterprise. Information, which defines the data and information that is required to support the Business Capabilities. Application, which defines the application systems and service components that realize the Business Capabilities. Technology, which defines the technical standards and products the enterprise may use in support of the Business Capabilities. Integration Plan which defines the overall concept of operation, the plans for its implementation, the sequencing of key activities, change impacts and approach to controlling the initiatives as they implement. Figure 2-3 illustrates the Integration Frameworks phases and work streams.
Figure 2-3 Integration Framework Phases and Work Streams Some examples of the key work products within the work streams of the integration framework are:
Page 8 of 86
The World Bank
Official Use Only
Performance Work Stream Business Performance Model, which defines the strategic performance objectives and the key performance indicators in the context of better support to clients, employees and other stakeholders. Business Work Stream Business Capability Model, which defines the Business Capabilities, associated with the architecture segments in support of the enterprise mission. Business Use Cases, Business Process Flow and Core Business Requirements which together describe how the Business Capability is to be delivered. People Work Stream Human Resource Model which documents the organizational culture, the structure of the enterprise in terms of relationships between organizational units, the key roles and distinct personas of the enterprise. Information Work Stream Enterprise Conceptual Data Model and Logical Data Model which defines the major business data entities and relationships between the entities. The Conceptual Data Model is a high-level overview of the enterprise-wide data that is created during the Enterprise Vision phase, while the Logical Data Model is a more detailed model (based upon the Conceptual Data Model) that is created during an Initiative Vision phase. The Logical Data Model focuses upon the subset of the enterprise data entities that are used by a particular initiative. Information Exchange Diagram, which shows the information exchanged within the enterprise and between the enterprise and external partners and citizens. Application Work Stream Application Component Model, which defines a high-level view of executable software or business service components that implement one or more business processes or parts of business processes. Ultimately, an initiative is a project that implements one or more components.
Page 9 of 86
The World Bank
Official Use Only
Most of the work streams utilize and build upon the work products of other work streams. Many of the work streams contain traceability matrices that express relationships between architectural elements defined by their work products and created by other work streams. For this reason, work streams (and work products within a particular work stream) have dependencies upon each other. Figure 2-4 depicts the main relationships between the high level work streams.
Figure 2-4 Work Stream Model Dependencies A preferable ordering for starting the development of work streams that honors these dependencies is: 1. Performance 2. Business 3. Information 4. Human Resource 5. Technology 6. Application 7. Integration Plan However, the development of the models is iterative and there is rarely the situation that all enterprise level models can be completed before work starts on the more detailed architecture for an initiative. It is important to not lose sight of the fact that we gain value through architecture by taking contributions from all the layers at one time and implementing them to deliver a business capability Figure 2-5 below presents a comprehensive list of the work products and work product components that comprise the Integration Framework.
Page 10 of 86
The World Bank
Official Use Only
Performance
Enterprise Mission, Vision & Objectives Extended Enterprise Value Chain Products & Services Outcomes Map (strategy map)
Initiative Performance Indicators Product & Service Description
Business
Enterprise Architecture Segments Business Capability Areas Business Capabilities Business Principles
Business Capability Model Business Process Model Business Use Cases Functional Requirements
Human Resource
Organizational Culture & Principles Organizational Structure Organizational Roles Employee Personas Human Resource Relationships Matrix
Organizational Structure Organizational Roles Employee Personas Human Resource Relationships Matrix Initiative Change Management Strategy Initiative Communication Plan
Information
Information Principles Conceptual Data Model (Subject/Entity) Data Taxonomy & Dictionary Information Exchange Matrix Information Relationships Matrix
Logical Data Model (Subject/Entity/Attribute) Data Taxonomy & Dictionary Information Relationships Matrix
Applications
Application Principles Application Component Model Application Component Relationships Matrix
Application Component Model Application Component Relationships Matrix
Technology
Technology Principles Technology Standards Technology Component Model Technology Component Relationships Matrix
Technology Standards Technology Component Model Technology Component Relationships Matrix
Integration Plan
Target State Concept of Operations Target State Change Impacts Integration Sequence Plan Initiative Concept of Operations Initiative Business Case
Initiative Concept of Operations Initiative Change Impacts Initiative Transition Plan Initiative Business Case
Updates to Enterprise Vision
Figure 2-5 Integration Framework Work Products The flow depicted at the bottom of the chart shows how the architecture models need to be updated as initiative visions are completed and solutions are implemented. As mentioned earlier, it is important for the architect to have a clear understanding of both the target state and the current transition state. The Integration Framework does not prescribe the fine details of the implementation of each work product or recommend tools to produce the work products. The framework was designed to allow each visioning task to select their own work product implementation and tools as long as the work product implementations achieve the objectives specified in the framework.
Page 11 of 86
Syst
em D el Work ivery Life cy prod ucts cle
System Delivery Lifecycle Phases
Enterprise Vision
Initiative Vision
The World Bank
Official Use Only
3 Approach
3.1 Introduction
This section introduces the approach to building the Work Products of the Enterprise Business Architecture and the Initiative Business Architecture with a specific focus on the identification and definition of Business Capabilities. This represents just one of the seven work streams of the integration framework.
3.2 Enterprise Business Architecture

The purpose of defining the business architecture at the enterprise vision level is to define the optimal set of Business Capabilities to realize the vision and strategic objective of the organization. This includes identifying the main resources required to enable the Capabilities and to provide the context for prioritizing and delivering improvements to the Capabilities. Figure 3-1 shows the key elements involved in developing the enterprise business architecture.
Define Enterprise Business Architecture

Inputs
Enterprise Mission / Vision Target Performance Model Current Business Processes Current Organizational Model
Participants
Business Sponsors Business Managers Operational Subject Matter Experts Business Partnership Teams EA Office
Main Process Steps

Identify the main external stakeholders in terms of customer, suppliers, strategic partners, regulators, etc. Identify the core functions of the enterprise in terms of those that deliver products & services to customers Identify the functions that provides direction and guides the organization to its mission and vision Identify the functions that provide support to the realization of the mission and the delivery of products Aggregate the functions around a common purpose to identify a unique segment Identify what the business does to deliver its main products & services to customers Identify what the business does to provide direction to and enable business operations Map the capability areas identified to architecture segments Validate against the mission of each organizational unit with each architecture segment Validate the initial map of the business capability areas For each business capability area, identify the business capabilities: What are main components required to deliver the capability? Who is the customer and what is the major result (outcome) delivered to them? How is the delivery of the result measured (metrics)? Is there a dependence between any of the capabilities? Create a diagram that shows the main business capabilities and their dependencies Describe each capability in terms of the customers, products/services, performance criteria, triggers/inputs and identify what manages or controls the capability Describe each capability in terms of the key resources required in support of the capability (human resources, information, applications, technology) Validate the business capabilities
Deliverables
Enterprise Architecture Segment Business Capability Areas Business Capabilities Business Principles
Page 12 of 86
The World Bank
Official Use Only Figure 3-1 Enterprise Business Architecture
Capability improvements are delivered by structuring the architecture into initiatives based upon priorities for improvement, inherent dependencies between Capabilities, funding constraints and capacity to implement the initiative solution. Core techniques to support business architecture development include: Value chain analysis 1: This is a technique for analyzing the relative cost and added value of a business's primary and support activities in the delivery of a product or service to the customer. Value chain analysis diagrams a business's activities vertically and horizontally. The vertical (upstream to downstream) view represents the primary activities of transforming an input into an output (inbound logistics, operations, outbound logistics, marketing and sales, service). The horizontal view shows support activities (firm infrastructure, human resource management, technology development, procurement). The configuration of these activities drives the cost and value of a delivered product or service, providing inputs for defining the activities and resources of the business unit (organizational boundaries). Analysis of supplier and customer value chains can identify opportunities or threats for customer and network choices. Affinity analysis 2: is a data analysis and data mining technique that discovers cooccurrence relationships among activities performed by (or recorded about) specific individuals, groups, or in general about objects for which there is a desire to aggregate by some common characteristics. Business scenario analysis 3: This is a technique in which sets of internally consistent assumptions about future environmental conditions and events are projected. Developing these projections may include an analysis of external factors derived from environmental scanning or other similar techniques. Customer value analysis 4: Measurement of customer and non-customer satisfaction with products and services, relative to those of competitors. Customer value analysis measures market-perceived benefits of products and services adjusted for their relative price. Strength, Weakness, Opportunity, and Threat (SWOT) analysis: A technique for the identification of opportunities and threats and analysis of an organization strengths and weaknesses in the business context. SWOT analysis involves specifying the objective of a business venture or project and identifying the internal and external factors that are favorable and unfavorable to achieving the objective Strengths attributes of the organization that are helpful to attaining the objective Weaknesses attributes of the organization that are harmful too achieving the objective Opportunities external conditions that are helpful to achieving the objective Threats external condition that are harmful to achieving the objective Balanced Scorecard 5: Procedure in which financial performance targets are related to other performance measures from strategic and organizational perspectives on the basis of causal linkages. The scorecard can link short-term objectives (financial performance) Porter, Michael, Competitive Advantage: Creating and Sustaining Superior Performance, The Free Press, 1985 2 J. Han et al, 2006, Data Mining: Concepts and Techniques 3 Schwartz, Peter, The Art of the Long View: Paths to Strategic Insight for Yourself and Your Company, Doubleday Currency, New York, Second edition, 1996 4 Gale, Bradley T., Managing Customer Value, The Free Press, 1994, 5 Kaplan Robert S. and Norton David P., Using the Balanced Scorecard as a Strategic Management System, Harvard Business Review, 1996
1
Page 13 of 86
The World Bank
Official Use Only
with long-term objectives (strategic objectives). It originally served to align the objectives (milestones), measurements, targets and initiatives of four perspectives financial, customer, business process and learning. Figure 3-2 presents the purpose and content of each deliverable:
Enterprise Business Architecture Deliverables

Purpose: To define the business in terms of: The core line of business associated with the delivery of products and services The functions involved in providing direction and guiding the enterprise towards the vision The functions involved in providing support Content: Architecture segment description Mapping to business units
Enterprise Architecture Segment
Business Capability Area

Purpose: To define what the business does to deliver products and services, to provide direction and guide the enterprise towards the vision and to provide support Content: Architecture segment to business capability area map Business capability area description
Business Capability
Purpose: To define what the business does to deliver an output to a customer within a specific business capability area To identify business capabilities that cross business capability areas Content: Business capability dependency diagram Business capability description
Business Principle Purpose: To provide clear guidelines for business and architectural decisions To state the fundamental beliefs that the organization wishes to establish as the basis for decisions Content: Statement of the principle Implications and rationale
Page 14 of 86
The World Bank
Official Use Only
Figure 3-2 Enterprise Business Architecture Deliverables
3.3 Initiative Business Architecture

The Initiative Business Architecture identifies the Business Capabilities that belong to the target initiative, and elaborates the details pertaining to the role and relationships of supporting resources such as people, information and technology in delivering the products and services to the customer. This facilitates the development of functional requirements and Use Cases that can be used by developers to create a solution(s) that enable the Capability performance improvements. The Initiative Business Architecture: Clarifies business scope of the initiative by defining specific Business Capabilities and requirements Describes how the business requirements are delivered through the business processes, including control activities, and shows what resources are required. Aligns the Capabilities to specific key performance indicators Translates the Business Capabilities into Use Cases and creates the core functional requirements that can be used to make technology choices or guide systems development.
Figure 3-3 shows the key elements involved in developing the initiative business architecture.
Page 15 of 86
The World Bank
Official Use Only
Define Initiative Business Architecture

Inputs
Business Capabilities Initiative Concept of Operations Initiative Performance Indicators Target/Current Business Processes Target/Current Resource Models (Human, Information, Application & Technology)
Participants
Initiative Sponsor Subject Matter Experts - Initiative Business Managers - Business Users Business Partnership Teams Enterprise Architecture Office Information Technology Specialists
Main Process Steps

For each business capability in the Initiative Concept of Operations: What are main components required to deliver the capability? Who is the customer and what is the major result (outcome) delivered to them? How is the delivery of the result measured (metrics)? What dependencies exist between the capabilities? Create a diagram that shows the main business capabilities that comprise this initiative Describe each capability in terms of the customers, products/services, performance criteria, triggers/inputs and identify what manages or controls the capability Validate the performance criteria against the Initiative Performance Indicators Describe each capability in terms of the key resources required in support of the capability (human resources, information, applications, technology) Validate the business capabilities with the business users and IT team Identify the core business requirements associated with each business capability Develop the process flow in support of each capability (identify key inputs, outputs and steps in the process) Develop Use Case descriptions addressing flow of events, goals and actors Using the business requirements from the capabilities, the use case model and the content of the initiative resource models (human, information, application & technology) create a list of functional requirements
Deliverables
Business Capability Model Business Process Model Business Use Cases Functional Requirements
Figure 3-3 Initiative Business Architecture Core techniques to support Initiative Business Architecture include: Stakeholder analysis 6 is a form of analysis that aims to identify the stakeholders that are likely to be affected by the activities and outcomes of a project, and to assess how those stakeholders are likely to be impacted by the project. Stakeholder analysis has the goal of developing cooperation between the stakeholder and the project team and, ultimately, assuring successful outcomes for the project. Prototyping is the process of quickly putting together a working model (a prototype) in order to test various aspects of a design, illustrate ideas or features and gather early user feedback. Prototyping is often treated as an integral part of the system design process, where it is believed to reduce project risk and cost. However, it can also be used during the initiative vision phase to help validate a concept. Often one or more prototypes are made in a process of iterative and incremental development where each prototype is influenced by the performance of previous designs, in this way problems or deficiencies in design can be corrected Scenario Analysis combines the concepts of prototyping with business scenario analysis to prepare different usage scenarios to help validate the completeness of a
6
Savage, G. T., T. W. Nix, Whitehead and Blair. (1991). "Strategies for assessing and managing organizational stakeholders." Academy of Management Executive
Page 16 of 86
The World Bank
Official Use Only
Figure 3-4 presents the purpose and content of each deliverable:
concept of operations. It is usually a paper-based exercise to assess how the capabilities will meet the requirements of the various stakeholders based on their different requirements of the capability Strength, Weakness, Opportunity, and Threat (SWOT) analysis: Identification of opportunities and threats and analysis of an organization strengths and weaknesses in the business context. SWOT analysis involves specifying the objective of a business venture or project and identifying the internal and external factors that are favorable and unfavorable to achieving the objective Strengths attributes of the organization that are helpful to attaining the objective Weaknesses attributes of the organization that are harmful too achieving the objective Opportunities external conditions that are helpful to achieving the objective Threats external condition that are harmful to achieving the objective
Initiative Business Architecture Deliverables

Purpose: To define what the business does to deliver its output(s) to its customers and how its performance is measured To articulate the main components required to provide a business capability and to define business requirements Content: Business capability dependency diagram Business capability description Business capability resources Business requirements
Business Capability Model
Business Process Model

Purpose: To define how the business applies resources to create its outputs and provide appropriate controls To graphically depict the business process steps to show sequence, dependency and role of resources Content: Business process model Business process description
Use Case
Purpose: To provide a link between the business capability and the applications/services required to support the capability Content: Use Case diagram Use Case description Use Case relationships matrix (relationships to business capability, process, data, user class)
Purpose: To provide clear statements of functionality to be provided by the automated solution To set priorities to allow effective evaluation of alternative solutions Content: Requirement identifier/name and description Priority (mandatory, desirable, optional) Type
Functional Requirements
Figure 3-4 Initiative Business Architecture Deliverables
Page 17 of 86
The World Bank
Official Use Only
Figure 3-5 shows the main relationships between the deliverables of the Initiative Vision phase and how they feed the selection of a technology solution and the main phases that support thats technologys implementation
Initiative Vision Phase

Business Capability Descriptions
Enabled by Provide formal structure for Enabled by
Use Cases
Define technology usage through
Business Requirements
Define activity sequence through
Business Process
Derived from
Derived from
Derived from
Drive the selection of
Solution Delivery Lifecycle
Technology Solution
Configuration Design
Detailed Configuration Requirements
Solution Configuration
Solution Implementation
Figure 3-5 Initiative Business Architecture Deliverable Relationships
Page 18 of 86
The World Bank
Official Use Only
4 Techniques and Notation

4.1 Introduction
In this Section, we introduce one of the main concepts that is used to articulate a business architecture, the Business Capability. We describe how to build a business capability and what attributes of the capability should be captured to support the design of the resources and other architecture components that enable the business capability. A business capability is "what the business does to perform something of value to that business". This is in contrast to a business process, which describes how the business performs or implements the given capability or how capabilities connect to deliver a desired outcome. Business capabilities describe the stable elements of the business to model your organization and provide the critical layer that aligns application services to business operations, and hence drives the development of a service-oriented architecture. A business capability is expressed in terms of outcomes and service levels, to create value for the customer (who may be internal or external). Business-capability mapping is the process of modeling what a business does (its capabilities), to reach its objectives. Links between capabilities are defined as capability connectors that focus on information exchange in terms of inputs (what is consumed) and outputs (products and outcomes) and controls (policies, standards, approvers, etc.). Business capabilities may be defined at different levels within an organization: Capability Areas exist at level 2 of the business architecture, and reside one level below each of the Banks architecture segments. Examples of Capability Areas with the architecture segment of Enterprise Business Management include Enable Collaboration, Procure Goods and Services, and Pay Administrative Expenses. Capability Sub-Areas exist at level 3 of the business architecture, and are the logically decomposed elements within a Capability Area. Capabilities exist within Capability Areas and Sub-Areas. They are the more granular group of activities that physically appear as capability objects on the diagram itself. The level at which capabilities are defined varies in accordance with the individual needs of each initiative.
4.2 Techniques for Identifying Capabilities

The Enterprise Vision defines the Capabilities of the organization in levels 1 (architecture segments) and 2 (Capability Areas). These compose the essential elements of the highlevel enterprise Business Capability framework for the Bank. In reality, however, most Capability Diagrams contain elements that cross Architecture Segments, or that cross Capability Areas within Segments. As a result, each Capability that is identified for modeling purposes needs to be analyzed by the Capability Facilitator 7 in the context of this broader framework to ensure alignment across segments.
See Section 5.2 of this document for a description of the role of the Capability facilitator.
Page 19 of 86
The World Bank
Official Use Only
Level 1 Architecture Segments
Architecture Segment: Enterprise Business Management
Architecture Segment: Finance, Banking, and Investment Management
Level 2 Capability Area
Capability Area: Corporate Procurement
Capability Area: Expenditure Management
High-Level BCM Framework
Level 3 Capability Sub-Area
Capability Sub-Area: 1 - Procure Goods and Services 2 - Monitor Receipt of Goods and Services
Capability Sub-Area: 1 Pay Administrative Expenses
Capability Diagram
Level 4 to n Capability
Requisition / SOW
Procure Goods and Services
Monitor Receipt of Goods & Services
Pay Administrative Expenses

Paid Invoice
Sample Capability Obtain and Pay for Goods and Services: From Order to Invoice
Figure 4-1 - Sample Relationship between Segments, Capability Areas, and Capability Models Figure 4-1 above shows a representative example of how a Capability diagram titled Obtain and Pay for Goods and Services, a typical procurement Capability, ties back to the Banks Architecture Segments and Capability Areas and Sub-Areas. To define a Capability Model, the Capability Facilitator leads the steps detailed in Section 2.2 of this document. 4.2.1 Steps to Define Enterprise Level Capabilities The following section details the high level steps that can be used to identify capabilities at the Enterprise level (Level 0 and Level 1): Step1: Review Literature and Background Materials: Review existing materials through a Discovery Phase, including business function schemes, strategic priorities, organizational alignment, and operational strategy. Step 2: Develop Straw Model of Level 0 Capabilities and Conduct Initial Validation: Using information gleaned from the existing literature, define segments or lenses by which the organization can view the capability definitions. Using these lenses 8, develop an initial model to define the main markets/clients and the highlevel products and services that are delivered to these markets / clients. Review this model with key business stakeholders for accuracy, relevance, and potential additions.
Lenses used at the Bank during the initial development of the level 0 model included architecture segment, value chain, business process team, and strategic theme.
Page 20 of 86
The World Bank
Official Use Only
Step 3: Identify Level 1 Capabilities: Once the context of the high level model has been established, continue to drill down into the Level 1 Capabilities across the Enterprise. This definition will: provide greater definition for validating the context at the higher level; demonstrate uniqueness in the capability by high-lighting overlaps and duplicates; and, enable mapping of the capabilities to the business units that provide the capability. Step 4: Validate High-Level Model with Business Owners: Review the model with key business stakeholders to validate wording and completeness of the Level 0 diagram. These stakeholders should be a cross-functional representation in terms of networks, regions, country offices and the main market segments. Step 5 Validate Lower-Level Model with Business Owners: Once the top level capability map has been validated, the stakeholders validate the second level of capabilities (Level 1). This review includes looking at naming conventions, model completeness and accuracy of the listed capabilities. 4.2.2 Steps to Define Initiative Level Capabilities The following section details the high level steps that can be used to identify capabilities at the Initiative level (Level 2 and Below). This section is broken into two parts studying the Current State or As-Is and the visioning of the Target State or To-Be. 4.2.2.1 Business Capability As-Is Playbook Step 1: Scope Capability: Similar to the Enterprise Level, the Initiative As-Is definition begins with a review of existing materials to define the scope of the initiative. This activity reviews the Level 0 and Level 1 documentation as well as establishes a baseline understanding of the initiative capability area. The scope defined in this step is validated with the Business Sponsors of the initiative. Step 2: Compartmentalize Capabilities: Utilize existing information and business sponsor input to identify potential capabilities. This activity should focus across the entire capability area and capture key elements and potential gaps in information. Step 3: Develop Strawman Maps: Draft the Level 2 Capability Map and any Level 3 or 4 maps where information in sufficient to do so. This diagram provides an integrated view of each capability and obvious / important objects. Step 4: Interviews with Stakeholders: Collect questions or issues identified through the initial scope and mapping exercise. Identify key stakeholders for interviews, ordered by broad subject matter expertise and level of influence in the organization. Interviews should focus on the following four components: Goals for the project to understand interests and perspectives Measures of success to understand each interviewees desired outcome from the project Review of Draft Capability Diagrams to orient each interviewee to the highlevel capability diagram Questions specific to the interview to clarify questions, fill gaps, and analyze capabilities
Page 21 of 86
The World Bank
Official Use Only
Upon completion of the interviews, produce formal notes and document key subject matter input on the capability map(s). Step 5: Draft Capability Templates: Utilize information gathered during the interview process to draft a capability template for the lowest level diagrams, including business requirements identified by the stakeholders and interviewees. The template for this documentation can be found in Appendix 1. Step 6: Conduct Workshops: Utilize a workshop format to validate capability components and related business requirements and identify additional items. Workshops should be attended by core team members and key stakeholders. The draft capability maps resulting from the interview process provided sufficient detail to begin work on the underlying capability templates. Step 7: Detailed Capability Models: Document the final As-Is capability models and templates and validate with the Project Sponsor and key stakeholders through interviews. 4.2.2.2 Business Capability To-Be Playbook Step 1: Gap Analysis: Review the capabilities, issues, and parking lot ideas captured during the As-Is analysis to develop a list of capability gaps that could be addressed in the Target State analysis. Validate and prioritize this list with the key team members (either in small group sessions or in larger workshop settings). Step 2: Revisit the Capability Diagram: Determine the impact of the improvements on the capability diagrams and reflect key changes on the To-Be maps. Potential changes include the addition of capabilities, the rearranging of objects, or a change in object form (e.g. document to data). Step 3: Develop a Concept of Operations: In a narrative form, describe the Target State capabilities and key concepts. Include detail about objects and relationships, and how changes to the As-Is state will improve capability performance. Step 4: Derive Functional Requirements (optional): Utilizing the capability definitions and the desired To-Be state, capture the high-level business and functional requirements necessary to achieve the end state.
4.3 Usage of Capability Definition in Decision Making

Capability definitions provide a foundation for analytical analysis at both the Enterprise and Initiative level. At the Enterprise level, capabilities can be assessed for criticality and effectiveness, highlighting specific focus areas for performance improvement. At the initiative level, capabilities can assist with project portfolio management and selection of IT solutions. 1. Criteria for Performance Assessment Capability analysis provides an analytical foundation for performance analysis and improvement opportunity definition. The following types of questions are used to derive information from stakeholders on current and desired performance:
Page 22 of 86
The World Bank
Official Use Only
Business value: o Does the capability differentiate the Bank and influence client satisfaction including whether countries desire the Banks products and services? o Does the capability drive a key performance measure such as project results, speed and quality of service delivery, or risk tolerance? Current Performance: o Is the performance of a capability excellent, inconsistent or poor in terms of the Banks needs? o Is client demand for the capability increasing or decreasing? o Does the capability perform equally well for each customer group (LIC, MIC, FCS)
A heat map 9 provides a pictorial representation of capabilities that are highly effective, meet expectations, and others that are potential areas to focus improvement. This tool is effective in situations where a given capability may have different performance characteristics in different customer markets and may require more context-specific analysis. The heat map can also be used to assist with sourcing decisions in terms of: Primary: those capabilities that the Bank should keep in house and should be the top priority for performance improvement Shifted: those capabilities that can be transferred to customers, suppliers or operational specialists Automated: capabilities whose outcomes are highly predictable (in terms of cost, time quality) and are strong candidates for becoming web services or for which the user interface should be automated. Further details on the application of the Heat Mapping technique are given in Section 5 of this guide. 2. Resource Allocation Analysis An allocation analysis to assess the alignment of proposed IT capital investment to business needs. Capability areas can be aligned to the allocation of IT capital funding, providing a view into strategic alignment of capital spend. The intent is not to provide judgment whether the funds proposed are being invested appropriately but rather to utilize capability analysis as a planning tool to ensure the organization is investing in the right things to realize the business strategy. 3. Progressive Commitment of Resources Elaboration of the high-level business architecture can be used for progressive commitment of funding for an initiative. As shown in Figure 4-2, the high-level business/enterprise architecture proposes a series of initiative concepts, which are described through an Initiative Concept Proposal. This Initiative Concept Proposal is reviewed by the Architecture Review Board who would make a recommendation to the governance body for funding.
See Harvard Business Review: June 2008 The Next Revolution in Productivity
Page 23 of 86
The World Bank
Official Use Only
Figure 4-2: Progressive Commitment of Resources The business case associated with the Initiative Concept Proposal addresses the full lifecycle cost of the initiative, but Initiative Concept Proposal focused primarily on the plan and investment required to complete the Initiative Vision. In this way, the organization can approve just the funding for the Initiative Vision Phase. This approach provides a checkpoint between concept approval and detailed design approval before a solution is implemented. Once the Initiative Vision Phase is completed, the business case is updated as now the initiative is understood and the decision can be made whether to fund the full implementation. 4. Technology Solution Selection The analysis completed as part of the Initiative vision sets the foundation for analytical work within the Software Development Life Cycle. The capability definition and ensuing business and functional requirements can be leveraged by the business and information technology organizations to understand and define the scope of a technology solution.
4.4 Model Components Diagram Symbols and Attributes in Capability Templates

This section describes the components of and notation required to develop Capability Models. Capability Models are composed of Capability diagrams, completed Capability templates, and (in some cases, as-needed) Capability to business requirements or use case mappings. Specific deliverables included at each level of the enterprise Business Capability Model are detailed below: Level 1 Enterprise Architecture Segment: No model deliverables
Page 24 of 86
The World Bank
Official Use Only
Level 2 Capability Areas: Capability Area Template (see Figure A-1 in Appendix) Level 3 to Level n Capability Sub-Areas: Capability Model Templates (See Figure A-2 in Appendix), Capability Model Diagrams, and (as-needed) Business Requirements matrix that maps each requirement to a Business Capability. An overview of the Business Capability Modeling Notation follows.
Page 25 of 86
The World Bank
Official Use Only
The primary elements of a Capability Model are events and objects. Models also include connectors and capability keys. A generic example of a capability model showing the various components is depicted in Figure 4-3. The description of the various components of the model and their attributes is given below. The Model itself contains a series of events and objects that depicts what the business does to deliver value to the customer (either internal or external). The model development method can be applied to develop either the components of a Capability Area, or the relevant Capability segments (spread across Capability Areas or architecture segments) that make up a Capability diagram. Key Model Attributes: Descriptive Attributes Vision / Mission a brief statement of what the Capability intends to be (vision) or the purpose of the Capability (mission). Description of the Capability an overview of the scope of what the diagram will include. Dependencies (upstream and downstream) identification of other Capabilities or Capability elements (such as objects or keys) that could influence or are subject to influence by this Capability. Issues / Risks potential problems or events that threaten the Banks ability to realize the capability Parking Lot Ideas proposals or ideas out of scope for the initiative, but worth capturing for future reference Segment Category the architecture segment grouping within which the Capability resides (Direction, Core Business, or Support) State Representation As-Is or To-Be Importance increasing, stable, declining (with comments used in the context of reengineering purposes or ranking) Individual Capability Attributes Outputs / Outcomes the vocabulary that is critical to the Capability Lexicon terminology specific to the capability Resources data, information, and objects that are critical to successfully performing the capability Tools and Techniques systems, job-aids, or training elements that enable the successful execution of the capability Individual Capability Attributes Business Requirement a description of the operation required for the business result to be achieved Category (used for on-boarding) Forms Mgmt, Info Presentation, Internal Process, System, Customer Interface, Data Transfer Customer the primary customer of the business requirement (external or internal to the Bank) (Additional Categories) additional notes can be added to the template to address issues specific to each initiative
Capability Model
Page 26 of 86
The World Bank
Official Use Only Capabilities represent activities that transform objects. Capabilities correspond to Capability Areas or Sub-Areas, or a further decomposition of a Capability within a Sub-Area. For example a decomposition of a Capability within Procure Goods and Services might be Create Requisition. Key Capability Attributes: Name convention is an active verb followed by a noun Description a brief description of what the Capability produces (for either internal or external customers) Key Attributes itemized in the templates that appear in Appendix 1. Outputs the physical or abstract resource of value produced by the Capability (typically also identified as an object on the diagram) Outcomes / Performance Measures (optional, depending on needs of the diagram) expected results that the Capability will deliver to the customers and/or the metrics by which achieving that result will be measured Resources (People, Applications and Data ) elements contributing to the realization of the Capability that focus on the who, where, and how; of value to the analysis, but at a level below the business architecture (information, application, network) Tools and Techniques job aids, training information, methods, or localized best-practices that enable the Capability Attributes specific to a Capability Component: Business Requirements include a name, description, priority, and category
Capabilities
Object Object
Objects represent the physical or abstract resources of value. Objects are bits or groups of information, documents and forms, records, products, and other business resources that flow between and can be transformed by events. Each object has been given a category, largely drawn from Enterprise Content Type listing that supports enterprise search and records management. These categories appear in the legend at the top of each capability map. If multiple objects interact with a single event, they should be stacked as appears in the sample to the left. Key Object Attributes: Name convention is a noun, potentially followed by a descriptor (in parenthesis) Description a brief overview of the object Category attributes drawn from Enterprise Content Type listing that supports enterprise search and records management: Documents & Reports, Publications, Communications, Knowledge, Data, Services, People and Communities, and Collections.
Page 27 of 86
The World Bank
Official Use Only
Relationships: The arrows represent the relationship between the event and the object. Represents "object" required to trigger the event The tail of the arrow departs from the object, and the head connects to the event. Show the "object" that controls/manages the event The heads of the arrow connect both the object and the event. Shows the result created through transformation by the event The tail of the arrow departs from the event, and the head connects to the object.
Key: The key represents a decision or attribute within the Capability chain that lies on the critical path to that Capabilitys primary output or outcome. These may be controls that are in place which dictate if a Capability event may continue, dependencies within the Capability that are critical to the eventual outcome to the customer, entry or exit criteria, or the like. K A Capability key can represent entry rules, exit rules, critical decision criteria, or barriers to change. Capability keys are identified within the Capability Model on the top-right hand corner of either the event or object which they apply to. In the context of Figure 4-1 above, a capability key associated with the object Pay Invoice might be that two written approval signatures must be captured before an invoice can be paid (exit rule). A separate example of a key associated with the capability Monitor Receipt of Goods and Services could be that the lack of a claims process impairs any ability to improve inventory control (a barrier to change).
Page 28 of 86
The World Bank

LEGEND: Capability Document / Report Publication Communication
Official Use Only
Knowledge
Data
Services
People / Communities
Collections
Non-Bank Artifacts
Service 1 Communication 1
Knowledge Document 2
Document 1
Capability D
Community 1
Capability B
Document 3
Capability A
Data 2 Data 1 Physical Asset NBA 1 Data 3
Capability C
# - <Capability Area/Sub-Area> <Capability> Business Segment <Business Segment>
Figure 4-3 Generic Capability Model Example
4.5 Extending the Capability Model to Business Requirements

Within each Capability Area or Sub-Area, the Capability Facilitator may wish to derive business requirements that align to Capabilities within the diagram. Though a single business requirement may span multiple Capabilities, this approach of vertically analyzing Capabilities provides a clear framework for eliciting business requirements from business owners. Whereas requirement brainstorming is often abstract and process modeling too detailed, the Capability method allows the business requirement to focus on the what of the business the elements core to successfully realizing the value chain. As Figure 4-4 illustrates, requirements management driven by a Business Capability Model provides a consistent structure and clear alignment back to business operations.
Requirements Brainstorming
Requirement Requirement
Requirements Grounded in Business Capabilities

Object Object
Capability Capability
Requirement Requirement Requirement Requirement
Object Object
NEW Requirement REFINED Requirement Requirement Requirement Business Requirement Requirement Requirement REFINED Requirement Requirement Business Requirement Requirement
Requirement Requirement Requirement Requirement
Requirement Requirement Requirement Requirement REFINED Requirement
NEW Requirement
Requirement Requirement Business Requirement Requirement Requirement
Value - Requirements more comprehensive resulting from alignment to business awareness
Figure 4-4 - Value of Business Requirements Tied to Capabilities A business requirement is defined as a specification of what the business wants, typically expressed in terms of outcomes the activities generate rather than the functions or specific
Page 29 of 86
The World Bank
Official Use Only
operations any system or person will perform. The identification of business requirements as one of the critical deliverables within the initiative business architecture later drives capturing functional requirements. A functional requirement is defined as a specification of a particular system that can include how data or information manipulation, processing, or other behaviors of the system. The core of the business requirement is the description of the required behavior. The definition of Business Capabilities also drives the definition of use cases, which are a description of a sequence of events that taken together lead to a system doing something useful 10. Many requirements will be uncovered during the use case development. As a result, Business Capabilities are critical in both feeding functional requirements and the definition of use cases. These items then drive the work within the system development lifecycle.
Business Requirements and Use-Cases Systems Development Lifecycle
Business Capabilities
Kurt Bittner, Ian Spence (2002). Use Case Modeling. Addison Wesley Professional, 2-3. ISBN 0-201-70913-9.
10
Page 30 of 86
The World Bank
Official Use Only
5 Business Capability Heat Maps

5.1 Introduction Why Heat Maps
A heat map is a graphical representation of data where values taken by a variable in a twodimensional map are represented as colors. In the context of the business capability model, each capability is annotated with the values of selected evaluation criteria, with color-coding of capabilities to indicate the overall evaluation. The Capability Heat Map allows us to make more informed decisions about a number of critical business and technology issues, including the following: Business value: Is the business capability a key contributor to the realization of the Banks strategy, does it differentiate the Bank, and is the demand for the capability increasing? Business performance: Is the performance of a capability excellent, inconsistent, or poor in terms of the Banks needs and relative to competitors? How much investment is necessary to raise performance to the required level? Would the higher performance justify the investment? Leverage: Is the capability a candidate to be leveraged or offered as shared services including using alternate sourcing / partnering arrangements? Would improving the capability result in benefits for other capabilities? Technology: How dependent is the capability on IT? How mature are the technologies that support the capability? What level of management or control should be applied to the technology supporting a specific capability? Investment priority: How much does a proposed project contribute to addressing the areas identified as needing attention? Are the stakeholders impacted by changes to the capability ready to assimilate the change? The Heat Map is focused on supporting the architecture planning processes: What are the capabilities requiring attention (e.g., critical to business, poor performing, can be leveraged to other parts of the organization)? How much do the planned initiatives address the areas identified? The Heat Map can also support more focused, initiative- or capability- specific questions: How mature is the Enterprise Architecture or Business Architecture within the capability? For the capabilities requiring architecture attention, which dimension appears to be the primary focus for improvement (business, human resource, information, application, technology)? How should the solution be architecturally configured (enterprise vs. group vs. individual)? How do some of the lower-level capabilities perform and how does their complexity impact the rollout strategy? Which capabilities deserve the greatest attention from the EA team? However, it is important to realize that the heat map is strictly a tool for identifying areas for attention. By providing an overview of all the activities in a business, it can help managers throughout the organization agree on priorities for an improvement program. However, it does not replace the need for a formal portfolio management process.
Page 31 of 86
The World Bank
Official Use Only
Complementary to the use of Heat Maps as a planning tool, Portfolio Management is more focused on resource allocation, relying on analytical approaches other than heat maps in order to answer the following questions: Which initiatives will deliver the highest value? Which resources should get allocated where? Should an initiative continue to get funding based upon its overall performance It is also important to recognize that many of the questions pertain to operational performance. However, it is essential that the managers reviewing the heat map do not look upon it as an operational dashboard. Operational reviews of performance, including portfolio reviews, are likely to be conducted at least monthly. However, the heat map will be generated at most quarterly and often only annually as part of the capital and administrative budgeting process. The key questions that management will use to assess priorities are: Business Value - What level of business value does the capability deliver? Does the capability differentiate Bank products and services? Is the capability a key contributor to the Banks strategic goals? Is demand for the capability increasing? Performance - Is the capability performing well or poorly? Is stakeholder satisfaction with the capability at a satisfactory level? Is the capability efficient? Does the capability meet the compliance requirements? Leveraged - Is the capability a candidate to be leveraged? Is the capability predictable? Is the capability integrated? Does improving the capability enable improvements to other capabilities? Annual planning processes can also use Heat Maps to analyze the following questions in an effort to understand if proposed capital projects or initiatives are well aligned with identified business needs and priorities: What is the level of requested budget for each initiative, by capability? Does the capability have the capacity to assimilate the change (i.e. necessary resources to participate in and sustain the initiative) What is the relative return-on-investment (ROI), by capability?
Heat Maps are also used for two other, more specialized purposes. 1). The Enterprise Architecture office and working group can use a heat map to understand architecture configuration and maturity. This use of a heat map answers the following questions: What is maturity of EA/BA components (ie human resources, information, application and technology)? What is the consistency of the capability? How complex is the capability (# suppliers, # vendors, # orgl units) What is the architectural configuration of the capability (central vs. local) 2). IT management within ISG can use a different Heat Map to identify the highest areas of IT risk by understanding answers to the following questions:
Page 32 of 86
The World Bank
Official Use Only
Which capabilities are heavily dependent on IT? Which capabilities require complex IT applications and configurations? Which capabilities have the most IT problems reported? How mature are the IT platforms supporting the capability? Which capabilities have a standard IT platform (e.g. none, some, fully shared) Which capabilities have inappropriate IT support (e.g., lack sufficient numbers of adequately trained resources)?
5.2 Stakeholders for Heat Maps

Heat maps address information needs of the following Bank stakeholders: Tier 1: Strategic direction (e.g. ITGG) uses heat maps to support investment allocation at the enterprise level. Tier 2: Right projects (e.g., EA Working Group) uses heat maps to reconcile the degree to which proposed initiatives are aligned with business needs or to understand the capacity of a capability to assimilate a change. Tier 3: Oversight (e.g., OIS, Audit, EA Office) uses heat maps to assess if there are specific capabilities that appear to present higher levels of risk to the Bank. Tier 4: Value delivered (e.g., SPMO) uses heat maps to compare capability performance, leverageability, maturity, and IT risk ratings before and after an initiative has completed to help assess its success.
5.3 Definition of Heat Map Categories

The categories described in this section of the document allow stakeholders to identify capabilities or capability groups that meet criteria of interest. The following category groups have been identified to encompass the primary realm of analysis: Business Value Performance Leverageable
The categories that support the primary heat map categories are organized into the following groups, encompassing the secondary tier of heat map analysis: Assimilating the Change - the degree to which the capability is sufficiently mature to sustain a change, and the degree to which the Bank would benefit from its improvement. Maturity degree to which documentation and implementation of information and technology systems meets Bank standards and industry best-practices. Information Technology the degree to which IT successfully supports the capability
Within each of these heat map categories, the attributes defined in the table below include the following components: Category Description articulates the purpose of the category and the business question it is intended to address.
Page 33 of 86
The World Bank
Official Use Only
Attributes the characteristics that the capability is measured against in this category, including clarifications (where needed) to describe how these characteristics should be interpreted. Anchoring of Values (e.g. scale) the rating system used to apply a numerical value to an assessment of the attributes Data Collection and Data Sources a description of where and how information can be collected to measure capabilities against each attribute in order to apply a rating
Section 5.7 provides a sample questionnaire that can be used with business users to assess the capabilities.
Page 34 of 86
The World Bank
Official Use Only
Table 1 below depicts the categories applicable to developing Heat Maps that support the Annual Planning process: Table 1 - Annual Planning Heat Map Categories Description Attributes Anchoring of Values Data Collection / Sources and Comments o o o o o o Bank iPhone chart Market research Independent market assessment(s) Customer feedback survey(s) Departmental business plans New product listings
BUSINESS VALUE Differentiation - criticality to key stakeholders, customer service delivery, relationship to Banks core, customer-facing capabilities o o o Stakeholder facing vs not Impact to Banks reputation Import to differentiate the Banks value proposition (i.e. independent ratings / assessments / benchmarking against comps) Generates business (i.e. draws customers) Importance for successful delivery of stakeholder outcome # of successful new products produced that customers like (innovation) o High Attention Key stakeholder/Customer facing (core), impacts Banks reputation, differentiates Banks value proposition (i.e. independent ratings / assessments / benchmarking against comps), draws customers, required for successful delivery of customer outcome; Medium Attention Policy setting and standard setting in a way thats core to the Bank themes and sectors; develop talent and people (skills as a differentiator); IT infrastructure; sales and marketing; annual meetings; Low Attention Enabling and governing capabilities wholly removed to the customer (facilities, food services, training, fitness centers, other GSD);
o o
Page 35 of 86
The World Bank Description Strategic Alignment Criticality to realization of strategic initiatives Attributes o
Official Use Only Anchoring of Values o High Attention Fully supports or fundamental to realization of the strategic objective(s) (if a capability supports multiple objectives, it would also be high); Medium Attention Enables or partially required for the realization of the strategic objective(s) (expert judgment required if a capability partially enables multiple objectives); Low Attention Does not contribute; High Attention - 5% or better improvement, year to year Medium Attention - -5% to 5% change, year to year Low Attention - 5% or worse degradation, year to year Data Collection / Sources and Comments o o Bank strategic objectives / strategic plan Expert judgment of Level 0 and 1 capabilities against objectives
Fully supports or fundamental to realization of the strategic objective;
Stakeholder Demand Stakeholder demand for the capability
relative throughput change (year to year), o # of repeat customers (year to year), o # of transactions (year to year) o change in budget or staff (year to year); o
o o o
o o o
Production volume information Customer (volume) data Budget data for organizational units (and then applied to capabilities they support)
Note predictability, under analysis, should often be viewed with organizational complexity to see whats isolated and predictable vs. whats not.
PERFORMANCE Performance / Service Levels - Capabilities Performance / Service Levels o Client level expectations (i.e. customer satisfaction ratings, timeliness of delivery, SLAs) o o o High Attention consistently miss performance expectations Medium Attention inconsistently meet expectations Low Attention consistently meet or exceed client level expectations o Organizational performance information (Balance Scorecard (BSC) Client) Customer feedback surveys Control performance information
o o
Page 36 of 86
The World Bank Description Efficiency Efficiency of the Capability Attributes o
Official Use Only Anchoring of Values o High Attention capability consistently and significantly underperforms with respect to time, budget, and scope. Medium Attention delivery varies with respect to time, budget, and scope; Low Attention consistently delivers on time, within budget, within scope; Data Collection / Sources and Comments o Organizational performance information (Balanced Scorecard (BSC) Internal Business Process) Control performance information Capability performance data (likely to be aggregated based on analysis of supporting organizational units performance data) HR data Financial performance and budget data # reported IT issues Customer feedback data (Understanding of) laws and industry regulations that impact capability List of Bank policies List of Bank organizational charter(s) Charters of committees involved with capabilities
o o
Existence and measurement of service level (i.e. % of performance targets achieved, including quality) Ability to address control needs Ability to deliver on time, within budget, within scope;
o o
o o o o Compliance Subject to compliance requirements o o o o Subject to laws Subject to organizational policies Subject to government or industry regulations Subject to organizational oversight o High Attention high level of oversight, significant numbers of laws, policies, regulations, etc., strong requirement for internal controls Medium Attention some oversight, moderate number of laws, policies, regulations applicable; typical requirements for internal controls Low Attention minimal oversight, minimal numbers of laws, policies, regulations, etc., minimal levels of internal controls required o
o o o
LEVERAGEABLE
Page 37 of 86
The World Bank Description Predictability Predictability of the capability 11 Attributes o o o o o o
Official Use Only Anchoring of Values o High Attention Strong standards, strong controls, highly mature, defined service levels, consistent quality, (if performed across business units) performed consistently Medium Attention reasonable standards, some controls present, less mature, inconsistently service levels, reasonable quality, (if performed across business units) performed with some consistency Low Attention poor standards, few controls present, immature processes, undefined service levels, inconsistent quality, performed differently across business units Data Collection / Sources and Comments o o o o o Organizational performance information (BSC) Standards documentation Service level agreement(s) Quality requirements and monitoring procedures Cross-comparison of organizational performance data (to measure consistency)
Standards level, Controls level, Maturity level, Service level definitions, Quality levels and consistency, (if performed across business units) consistency
The answer to the predictability question is important because if the outcomes are highly unpredictable, the activity (or at least its user interface) will be difficult to automate. If it cannot be automated according to SOA guidelines, sharing it with other divisions or shifting it to customers or suppliers will be difficult.
11
Page 38 of 86
The World Bank Description Integrated Capability is commonly utilized Attributes o
Official Use Only Anchoring of Values o High Attention capability is utilized in a number of other places, if it is unavailable or performing badly many capabilities would be impacted Medium Attention capability is reused in a few places, but if it is unavailable or performing poorly the related capabilities continue to function with minor impact Low Attention capability is highly isolated and is not shared with other capabilities High Attention many capabilities improved if a single capability improved Medium Attention some capabilities are improved Low Attention no other capabilities are improved Data Collection / Sources and Comments o Capability usage analysis within the business architecture
# of occasions where capability is reused to support other capabilities
Capability Dependencies - Dependence of other capabilities on the capability
# of capabilities that will be improved if a single capability is improved (of those improved) to what degree will they improve
Capability dependency analysis within the business architecture
o o
Example enabling capabilities will enhance many other capabilities
Need to define threshold for successes
Page 39 of 86
The World Bank
Official Use Only
The table below depicts the categories applicable to developing Heat Maps that support analysis of the degree to which proposed initiatives support identified business needs: Table 2 - Initiative Alignment Heat Map Categories Description Attributes Anchoring of Values Data Collection / Sources and Comments o Approved capital budget(s)
ALIGNMENT BETWEEN PROPOSED INITIATIVES AND CAPABILITIES Requested Budget capital budget levels ROI - Return on Investment Per Capability o Requested Budget Amount o $ (relative, analyzed by capability)
Return-on-investment value(s)
Difference between expected (planned) ROI and actual ROI
o o
Capital project CBAs (Ability to analyze) Benefits related to individual capabilities
Notes 1) is data available to produce it (i.e. CBAs) and 2) how would it be bounded in a heat map (many capabilities improved on a cross-cutting basis)
Capacity to Assimilate Capacity of the capability to support and enable the change
Availability and willingness of Bank to set resources aside Presence of a business / project plan that includes: costs, time, resources, and business case Number of initiatives contained within a capability Successful history of project implementations
High Attention yes to availability of resources, with 1 initiative contained Medium Attention some availability of resources and/or 2 or 3 initiatives within a single capability Low Attention inadequate availability of resources and 3+ initiatives within a single capability
o o o o
Enterprise resource planning data Project de-brief or close-out documentation Interviews or discussions with business owners Business cases or project management plans
Page 40 of 86
The World Bank
Official Use Only
Table 3 below depicts the categories applicable to developing Heat Maps that help analyze the architectural maturity of individual business capabilities: Table 3 - Architectural Maturity Heat Map Categories Description MATURITY BA Maturity maturity of the capabilitys business architecture o o o Components defined Components understood Components appropriately owned / used by the business to drive implementation of change (with IT) o o High Attention Components partially or not defined Medium Attention Components somewhat defined or defined but not used/owned consistently Low Attention Components defined as well as understood and owned/used by the business to drive implementation of change (with IT) High Attention Components partially or not defined Medium Attention Components somewhat defined or defined but not used/owned consistently, somewhat or inconsistently used to drive change Low Attention Components defined as well as understood and owned/used by the business to drive implementation of change (with IT) o o (Review of) available BA components (Analysis of) business understanding of BA components (Observation of) businesss use of BA to work with IT Attributes Anchoring of Values Data Collection / Sources and Comments
Human Resource Maturity maturity of the capabilitys HR layer
o o o
HR Components defined for the capability HR Components understood HR Components appropriately owned / used by the business to drive implementation of change (with IT)
o o
o o
(Review of) available EA components (Analysis of) business understanding of EA components (Observation of) businesss use of EA to work with IT
Page 41 of 86
The World Bank Description Information Resource Maturity maturity of the capabilitys HR layer Attributes o o o
Official Use Only Anchoring of Values o o High Attention Components partially or not defined Medium Attention Components somewhat defined or defined but not used/owned consistently, somewhat or inconsistently used to drive change Low Attention Components defined as well as understood and owned/used by the business to drive implementation of change (with IT) High Attention Components partially or not defined Medium Attention Components somewhat defined or defined but not used/owned consistently, somewhat or inconsistently used to drive change Low Attention Components defined as well as understood and owned/used by the business to drive implementation of change (with IT) Data Collection / Sources and Comments o o (Review of) available EA components (Analysis of) business understanding of EA components (Observation of) businesss use of EA to work with IT
Information components defined for the capability Information components understood Information components appropriately owned / used by the business to drive implementation of change (with IT)
Application Resource Maturity maturity of the capabilitys HR layer
o o o
Application components defined for the capability Application components understood Application components appropriately owned / used by the business to drive implementation of change (with IT)
o o
o o
(Review of) available EA components (Analysis of) business understanding of EA components (Observation of) businesss use of EA to work with IT
Page 42 of 86
The World Bank Description Technology Resource Maturity maturity of the capabilitys HR layer Attributes o o o
Official Use Only Anchoring of Values o o High Attention Components partially or not defined Medium Attention Components somewhat defined or defined but not used/owned consistently, somewhat or inconsistently used to drive change Low Attention Components defined as well as understood and owned/used by the business to drive implementation of change (with IT) High Attention large number of supplies / external dependencies, multiple organizational units, highlevel of regulatory oversight or compliance requirements. Medium Attention typical number of supplies / external dependencies, one or two organizational units, typical level of regulatory oversight or compliance. Low Attention minimal number of suppliers / external dependencies, single organizational unit, low levels of regulatory oversight or compliance. Data Collection / Sources and Comments o o (Review of) available EA components (Analysis of) business understanding of EA components (Observation of) businesss use of EA to work with IT
Technology components defined for the capability Technology components understood Technology components appropriately owned / used by the business to drive implementation of change (with IT)
Complexity Complexity of the capability
o o o o o
# of suppliers # of external dependencies # of organizational units involved volume of regulatory oversight and compliance Degree to which skills required to perform the capability are unique to the needs of the Banks mission
o o o o o
Capability supplier list(s) Capability (service and product) vendor list(s) HR models for the capability Rating / value associated with Compliance category List of job titles and ratio of internal vs. external resources supporting capabilities (using HR data)
Page 43 of 86
The World Bank Description Architectural Control Geographic location of capability delivery Attributes o
Official Use Only Anchoring of Values o High Attention central function requiring high-level of investment and standardization across the bank; Medium Attention partially centralized ; Low Attention local function with little or no integration with other centralized Bank activities; Data Collection / Sources and Comments o SME analysis of geographic distribution supporting capabilities
Centrally configured vs. mixed configuration (central and regional) vs. exclusively regional configuration
o o
Page 44 of 86
The World Bank
Official Use Only
Table 4 below depicts the categories applicable to developing Heat Maps that help IT management analyze the performance, risks, and maturity of the IT environment supporting a capability: Table 4 - IT Performance, Risk, and Maturity Heat Map Categories Description Attributes Anchoring of Values Data Collection / Sources and Comments o Registry of IT resources identified within a business capability model SME analysis of critical capabilities against critical applications
INFORMATION TECHNOLOGY IT Reliance Importance of information technology to the capability o Degree of capability reliance (operations suffer, shut-down, etc) o High Attention Capability critically disabled, severe loss of operational capacity, shut-down, etc. Medium Attention Capability moderately impacted, some but not all business activities continue Low Attention Capability marginally impacted, business activities continue, manual workarounds sufficient with minimal or acceptable delays High Attention capability uses over X IT systems Medium Attention capability uses between Y and Z IT systems Low Attention capability uses less than Z IT systems
IT Volume Volume of use of IT within the capability
# of IT systems / applications
o o o
Registry of IT resources identified within a business capability model
Note ideal to understand Volume per community of users. Also, answering this question implies understanding a full view of the EA;
Page 45 of 86
The World Bank Description IT Issues - IT Problems per Capability Attributes o o
Official Use Only Anchoring of Values o o o High Attention lots of problems Medium Attention some problems Low Attention little or no problems Data Collection / Sources and Comments o IT helpdesk metrics
# of reported IT issues of those reported severity of IT issues
Note ideal to understand problems per volume of IT per community of users ; need to define scale, also important to understand criticality of problems reported; recommend doing on an annual basis (?) with some trend analysis o o Bank IT standards Analysis of application and technology models with Bank standards Review of application maturity within capability
IT Maturity To what degree is capability supported by mature, standard platforms?
o o o
Fully mature Bank-standard Aligns with Banks technology standards and direction(s)
High Attention fully mature, Bank-standard, aligns with Banks technology standards and direction(s) Medium Attention somewhat mature (ad-hoc customization in areas), generally aligns to Banks standards Low Attention immature and frequently not Bank-standard and/or technologies are generally not supported by ISG High Attention Capability operates on a fully shared platform Medium Attention capability operates on a somewhat shared platform Low Attention capability operates on fully independent / none-shared platform
IT Platform capabilities that share or operate on an independent platform
Degree of platform sharing
o o
o o
Application models Documented relationships between applications and capabilities
Page 46 of 86
The World Bank Description IT Skill Types degree of risk associated with support of the capability IT resources Attributes o o o o
Official Use Only Anchoring of Values o High Attention insufficient resources available, significant / boutique skills requirements, outdated systems (no longer supported, companies gone under) used, lack of documentation Medium Attention resources available, moderate skills requirements, many systems up-todate, some documentation Low Attention resources available, widely-available skill-sets, current systems, extensive documentation Data Collection / Sources and Comments o Application models / registry with contact people, version information, and indication of available documentation (Potentially) interviews with support staff
Unique nature of skills required Resources available to support Relative current-ness of systems Documentation available on systems
Page 47 of 86
The World Bank
Official Use Only
5.4 Approach to Generating Heat Maps

This section describes the approach to generating Heat Maps at the Bank. 5.4.1 Standard maps Figure 5.1 summarizes the key categories and the application of the ratings to arrive at the areas requiring specific architecture attention.
Category
Differentiation
Value Value
Low Attention
Medium Attention
High Attention
Strategic Demand Service Level
Critical to Bank
Performance Performance
Efficiency Compliance Predictable
Performance Improvement Opportunity
Leverage Leverage
Integrated Dependency
Sourcing / Automation Opportunity
Figure 5-1 - Heat Map Category Ratings Though the categories defined above afford the opportunity to generate a wide variety of heat-maps and analyze capabilities across a multitude of different dimensions, there remain a few basic questions that can be considered the standard set of evaluation criteria to be applied. This section identifies that standard set of questions and indicates the filters that need to be applied to answer the requisite business question. ENTERPRISE PLANNING HEAT MAPS:
Heat Map 1 Management Strategy for Investment Allocation o Business Question What core Bank capabilities are related to the organizations strategic objectives and need to be addressed to improve performance? o Filters Business Value (in aggregate), then Performance (in aggregate), then Leveragability (in aggregate) o Level of Application applied to Level 0 and, as-needed, Level 1 of the Business Architecture
Page 48 of 86
The World Bank
Official Use Only
Heat Map 2 Alignment of Initiatives to Investment Needs o Business Question To what degree are the proposed capital projects aligned with the identified needs of the organization (developed in Heat Map #1) o Pre-requisite Completed version of Heat Map 1 o Filters requested budget, capacity to assimilate, and relative return-oninvestment (by capability) o Level of Application applied to Level 0 and, as-needed, Level 1 of the Business Architecture
INITIATIVE PLANNING HEAT MAPS:
Heat Map 3 - EA Maturity o Business Question How mature is the level of architecture within a Bank capability? o Filters EA maturity, BA maturity, capability consistency, complexity of the capability, and/or architectural configuration (location) of the capability NOTE no more than 3 of these filters should be used in any one heat map, in order to simplify aggregate presentation. o Level of Application applied to Level 1 of the Business Architecture (within the context of a particular initiative or series of initiatives) Heat Map 4 IT Risk and Needs o Business Question How exposed to IT risk are different Bank capabilities? o Filters IT dependency, IT complexity, # of IT problems reported, maturity of IT platforms, standardization of IT platforms, and/or (adequacy) of IT resource support NOTE no more than 3 of these filters should be used in any one heat map, in order to simply aggregate presentation. o Level of Application applied to Level 1 of the Business Architecture (within the context of a particular initiative or series of initiatives)
5.4.2 Interpretation of data It is important to realize that the information represented by the map is not always good or bad. The goal of the heat map is to compare investment opportunities based on different questions and categories of analysis - to inform where people should be focusing their attention. For example:
High business value is going to have a rating that indicates it demands attention. Capabilities that demonstrate immature predictability and immature IT will also receive an indication that they need attention. Capabilities that have strong governance and compliance will receive an indication that they need attention.
Conversely, attributes such as non-core, well-functioning, lacking complexity are all indicative of a capability that may not merit specific attention or investment. For example:
If a capability is meeting performing expectations, analysis on that category will indicate that no attention is required. Similarly, analysis on the category of dependencies that yields a low rating would again indicate that no immediate attention or investment is required.
Page 49 of 86
The World Bank 5.4.3 Presentation of data
Official Use Only
Heat maps use quantitative or qualitative data to apply a rating for each attribute in the table above. This section describes how those ratings can be analyzed and aggregated to make a judgment about the question at hand (business value, performance, maturity, etc). A spreadsheet has been developed, shown in Figure 5-2, for architects to assign an architectural attention rating to individual capabilities.
Figure 5-2 - Heat Map Calculator Template Note that the architect fills out a value in each of the 9 sub-categories for the primary heat map (architectural attention), and these values aggregate (through calculations embedded in the template) to a quantitative result. The Architect applies a rating of high (h), medium (m), or low (l) to the business value, performance, and leveragability categories. The scales highlighted in yellow both the values of high vs. medium vs. low as well as the relative importance ratings of business value vs. performance vs. leveragability can be adjusted by the architect based on the business problem being addressed or the need to conduct what-if analysis. Applying a rating to each of the individual criteria creates an aggregate value as illustrated in Figure 5-3 below. The formula used to calculate this aggregate rating sums the following three calculations into a single, overall value: Capability Biz Value Attention Rating (h = 9, m = 3, l = 1) * Biz Value Significance Weight (= 3), plus Capability Performance Value Attention Rating (h = 9, m = 3, l = 1) * Performance Significance Weight (= 2), plus Capability Leveragability Attention Rating (h = 9, m = 3, l = 1) * Leveragability Significance Weight (= 1)
Page 50 of 86
The World Bank
Official Use Only
Note that both the attention rating scale (h=9, m=3, l=1) and the weight of each category (business value, performance, and leveragability) can be adjusted within the template. The individual attention ratings are calculated using the following formulas:
Biz Value Attention Rating 12: o If the sum of Differentiation + Strategic Alignment + Stakeholder Demand is between 0 and 2, Biz Value = Low; o If the sum of Differentiation + Strategic Alignment + Stakeholder Demand is between 3 and 7, Biz Value = Medium; o If the sum of Differentiation + Strategic Alignment + Stakeholder Demand is between 8 and 9, Biz Value = High; Performance Attention Rating: o If the sum of Satisfaction + Efficiency + Compliance is between 0 and 2, Biz Value = Low; o If the sum of Satisfaction + Efficiency + Compliance is between 3 and 7, Biz Value = Medium; o If the sum of Satisfaction + Efficiency + Compliance is between 8 and 9, Biz Value = High; Leveragability Attention Rating: o If the sum of Predictable + Integration + Enabling of Other Capabilities is between 0 and 2, Biz Value = Low; o If the sum of Predictable + Integration + Enabling of Other Capabilities is between 3 and 7, Biz Value = Medium; o If the sum of Predictable + Integration + Enabling of Other Capabilities is between 8 and 9, Biz Value = High;
Figure 5-3 - Heat Map Calculator, Aggregate Values as Applied to Example
12 These scales can be adjusted using the template. Note that when the scales in the template are adjusted, the multiplier used to normalize the values on a 100pt scale will need to be adjusted as well.
Page 51 of 86
The World Bank
Official Use Only
Based on criteria selected and responses applied to each criterion, data should be interpreted according to the following scale 13:
No color (rating of 0-25) does not merit attention or investment Light Turquoise (rating of 25-50) may merits some attention or investment Light Yellow (rating of 50 75) definitely merits attention or investment Light Orange (rating of 75 100) merits significant attention or investment
Note that this template as well as the scale (described above) can be adjusted based on the needs of the individual question being answered. The same template could be used, with slight modifications of headers and scale values, to handle the architectural maturity, IT risk, and readiness for change heat maps. 5.4.4 Adding new criteria This section describes the process for adding new criteria to be used in Heat Maps. The essential steps include the following: Identify a new heat map use that addresses a specific information need or augments the EA offices planning and engagement model; Get approval from Chief EA that new map should be added: Identify observable, measurable, or otherwise discernable attributes within a capability that can be used to address the information need; Identify criteria used to measure the attributes; Add the identified criteria to the method guide; Add the criteria to the EA resource model(s) so as to ensure they are captured / updated appropriately as each initiative is undertaken;
5.5 Example Heat Map

A summary of an example heat map, and the steps undertaken to produce it, appear in this section as a reference tool for staff producing heat maps in the Bank. In summary, the following stages were addressed: Assess Needs of Bank Capabilities using the 2008 IDA-14 controls report findings, as well as EA staff member understanding of the Banks environment, a summary table was developed to assess business value, performance, and leveragability ratings (see Figure 5.4 below). These ratings were then overlaid on the high-level Bank on a page diagram.
It is recommended that this same scale be used for other heat maps as well, though of course the tolerance levels between points on the scale can be easily adjusted using the calculator template. For example, in some cases the Bank may choose to say that 0-35 does not merit attention or investment, etc.
13
Page 52 of 86
The World Bank
Official Use Only
Figure 5-4 - Table to Assess Bank Capabilities Assess Impact of ECDM each capability was then analyzed in a separate spreadsheet to indicate high vs. low impact of ECDM programs across capabilities. A scale was developed to reflect which capabilities are critically, highly, and moderately impacted by the ECDM program components. Figure 5-5 below illustrates how this analysis was developed.
Figure 5-5 Table to Assess Impact of ECDM Projects against Capabilities Integrate Heat Map of ECDM Impact against Needs developed an integrated view of the needs of the high-level business capabilities against the impact of ECDM project components to those same high-level business capabilities. This visualization can help inform investment planning and the rollout strategy. Figure 5-6 below illustrates how this heat map might appear, using a color-scale to illustrate areas of high vs. low attention needs.
Page 53 of 86
The World Bank
Official Use Only
Figure 5-6 - Heat Map of Business Capability Needs
After this kind of attention/needs analysis is undertaken, the heat map presents an understanding of where resources (financial, human, and/or information technology solutions) should be applied within the Banks business capability environment. The next step is to perform a high-level analysis of the high-priority areas identified via the heat-map in order to elaborate a conceptual-level set of requirements. These high-level requirements would then drive the development of a business case and justification for moving forward with a new initiative. It should be noted that this example is best applied for a project such as Enterprise Content and Document Management before any software solution has been purchased. The heat map in our example overlays high-level capabilities in need of architectural attention against those capabilities that would most benefit from the sorts of components an ECDM software solution offers. Such an analysis would inform investment planning and rollout strategies across capabilities that span multiple organizational units. 5.5.1 Supporting IT Project Portfolio Investment Decisions
Page 54 of 86
The World Bank
Official Use Only
The high-level map has also been used to assess the alignment of proposed IT capital investment to business needs. Figure 5-7 shows the allocation of IT capital funding for FY09-11 to each capability area.
Figure 5-7: Alignment of IT Capital FY09-11 to capabilities Figure 5-8 provides a summary of the relative level of investment by capability group.
IT Capital Project FY09-11

Advocacy Strategy
0%
3% Convening 0% 2%
Advising
2 Advocacy 3 Convening 4 Advising 5 Financing 6 Implementing
29% Financing
Enabling
65%
1% Implementing
7 Enabling 1 Strategy
Page 55 of 86
The World Bank
Official Use Only
Figure 5-8: Relative level of IT Capital Investment (FY09-11) by capability grouping Again the intent here is not to provide judgment whether the funds proposed are being invested appropriately. The intent is to indicate that as a planning tool one of the key requirements of enterprise architecture is that it drives capital investment by ensuring that the organization is investing in the right things to realize the business strategy.
5.6 Extending Heat Maps Capital Investment and Planning Techniques

The results of the heat-map analysis can be used as a foundation to develop a consistent, Bank-wide approach to distribute limited organizational resources among competing programs or initiatives within the proposed IT capital portfolio. This distribution method applies conditions and business drivers of business owners to decision criterion so as to mathematically calculate the optimal funding levels within each of the Banks IT capital projects. In order to do achieve this result, the Bank can use the concept of decision conferences within its IT governance committees and tools built around statistically-sound decisiontheory to aid decision makers. The broad steps associated with this work, and its relationship to heat-mapping, include the following steps: 1. Build a shared understanding of the key issues where proposed IT-related programs and initiatives must compete for scarce organizational resources. This is accomplished via Heat Mapping to identify the areas where improvements are needed.
2. Pre-work by a subject matter expert works to capture in a logical, transparent, malleable decision model all of the options, possible outcomes, costs and benefits that are relevant for evaluating alternative uses of limited resources against the organizations objectives. The capability categories within the heat-maps become the foundation for this decision model.
3. Use the model to narrow (through minimal effort and the use of a decision-theory tool) tens of thousands of possible combinations of allocations to proposed programs and initiatives down to the few combinations that would likely provide the most overall value per unit of resource invested. Data entry by the decision makers is minimized by understanding key drivers and making those variables the ones used to drive alternatives.
4. Reveal which envisaged capabilities or services should be added to initiatives or programs if more resources become available, and which should be postponed or abandoned if budgets are reduced. Differentiate between 100% gold-plated or straight-lined 80% fulfilled vs. a more intelligent allocation of resources.
5. Update and re-run the allocation model as conditions change, more information becomes available, new initiatives are proposed or older ones are completed or abandoned. Conduct quick what-if analysis.
Page 56 of 86
The World Bank
Official Use Only
5.7 Heat Map Business Questions

1 Business Value - Differentiation To what extent does the capability contribute to the delivery of a product or service directly to a key Bank stakeholder? To what extent does the capability contribute to differentiating the Banks value proposition? To what extent does the capability contribute to generating business for the Bank (e.g. new projects, customers)? To what extent is the capability contribute to the successful delivery of a stakeholder outcome (e.g. timely repayment on a loan, successful implementation of technical assistance advice)? To what extent does the capability contribute to the successful creation of new Bank products and services? 2 Business Value - Strategic Alignment Response To what extent does this capability contribute to the realization of the Bank's strategic objectives? Response High contribution High contribution High contribution High contribution Options Medium contribution Medium contribution Medium contribution Medium contribution Low contribution Low contribution Low contribution Low contribution
High contribution
Medium contribution
Low contribution
High contribution
Options Medium contribution
Low contribution
3 Business Value - Stakeholder Demand To what extent is the demand for the capability increasing (e.g. relative throughput change, number of repeat customers, number of transactions, change in budget or staff)?
Response >5%
Options -5%-5%
<-5%
4 Performance - Service Levels Response To what extent does the capability meet stakeholder expectations for performance (e.g., meeting Consistently exceeds service levels, timelines of delivery, stakeholder satisfaction rating)? expectations 5 Performance - Capability Efficiency To what extent does the capability operate under defined performance expectations and measure performance? To what extent does the capability address the control requirements? To what extent does the capability deliver on-time, within budget, within scope? Response
Options Inconsistently meets expectations
Consistently misses expectations
Options Measures defined but not met Controls defined and applied Controls defined but not applied Consistently exceeds Inconsistently meets expectations expectations Measures defined and met Options Some oversight
Measures not defined No controls Consistently misses expectations
6 Performance - Compliance To what extent is the capability subject to compliance requirements (subject to laws, policies, government or industry regulation, or organizational governance)? 7 Leverage - Predictability To what extent does the capability result in consistent quality of performance when delivered in different environment, by different business units or to different stakeholder groups?
Response High level of oversight
Minimal oversight
Response High level of consistency
Options Some consistency
No consistency
8 Leverage - Integration To what extent is the reused to support other capabilities? To what extent does this capability impact other capabilities (if it was unavailable or performing badly how many other capabilities would be affected? 9 Leverage - Capability Dependencies If the performance of this capability is improved to what degree will other capabilities be improved?
Response Heavily reused Many capabilities impacted
Options Reused in a few places A few capabilities impacted
Isolated No capabilities impacted
Response Many capabilities improved
Options A few capabilities improved
No capabilities improved
Page 57 of 86
The World Bank
Official Use Only
6 Roles and Responsibilities

The roles and responsibilities for Business Capability Modeling are divided into two distinct categories: Business Capability Method Framework and Business Capability Model management. As the guiding principle behind developing Business Capabilities is to enumerate on elements of the business that are more stable over time, it is anticipated that the management of the models and the framework will require fewer lifecycles than a process mapping effort of a similar scope.
6.1 Business Capability Method Framework

The Enterprise Business Capability Method will be owned by the Enterprise Architecture team, including the Capability development framework, deliverables, and training materials. The Enterprise Architecture team will assume responsibility for the management of these materials as well as ensuring longevity of the process through annual reviews and other revisions per Bank strategy. The roles and responsibilities related to the Business Capability Method Framework are outlined in the following table: Role Method Framework Ownership Group Personnel Enterprise Architecture (EA) Team Responsibilities Maintain version control of the Framework documentation including training materials and all job aids Perform an annual assessment of the method applicability and initiate necessary changes to the structure and process Review and evaluate changes to the Framework Advocate for the use of the Method in other initiatives Communicate benefits of the Framework Identify opportunities for improvement to the Business Capability Method Framework Update the BCM Framework at the request of the Model Framework Ownership Group Coordinate changes to the Framework with other areas of the business and enterprise architecture Leverage Subject Matter Experts as needed
Method Advisory Team
Business Architecture Working Group (EA, BPT, and select business owners) Comprised of EA team, Others as identified
Framework Development Team
6.2 Business Capability Model Development

At the Enterprise Vision phase, the architecture segments and business capability areas need to be validated a representing the key components of the business architecture for the whole organization. This requires participation from all business sponsors, senior management and specific subject matter experts. The models themselves are built by the business partnership teams supported by the enterprise architecture office. These responsibilities are described in the table below.
Page 58 of 86
The World Bank Role Business Sponsor Personnel Business Leaders
Official Use Only Responsibilities Provide strategic direction to the team Secure commitment of resources to support the model development Facilitate the generation of consensus around the models Provide documentation and expertise on processes, performance measures, and supporting resources Participate in meetings and model development sessions Review and evaluate deliverables Lead the development of the Business Capability Area and Sub-Area(s) by following the standard method Facilitate meetings and model development sessions Select and apply appropriate techniques (such as environmental scanning) Utilize resources and expertise provided by team members Provide strategic context and expertise in the development of Business Capability Models Provide documentation and expertise on technology and systems supporting the Capability Area Lend expertise to opportunities, issues and constraints posed by technology Participate in meetings and model development sessions Maintain existing models Communicate benefits of the Business Architecture
Subject Matter Experts
Managers and Individual Contributors from the Capability Area
Capability Facilitator
Business Partnership Team (BPT)
Enterprise Architects / Architecture Working Groups
Enterprise Architecture (EA) Representatives
Business Architecture Model Management
Business Partnership Team
For each Business Capability Area, a more detailed model of the comprising Business Capabilities should be developed during the Initiative Vision phase. These detailed Capability Models are developed by cross-functional teams made up of both business and information technology (IT) representatives as illustrated in the table below. There is also a role to ensure that the models created as part of the Initiative Vision are integrated into the overall Enterprise Business Architecture. Role Initiative Sponsor Personnel Capability Area Leader or Designated Representative Managers and Individual Contributors from the Responsibilities Provide strategic direction to the team Secure commitment of resources to support the model development Facilitate the generation of consensus around the models Provide documentation and expertise on processes, performance measures, and
Subject Matter Experts
Page 59 of 86
The World Bank Role Personnel Capability Area
Official Use Only Responsibilities supporting resources Participate in meetings and model development sessions Review and evaluate deliverables Lead the development of the Business Capability Model by following the standard method Facilitate meetings and model development sessions Utilize resources and expertise provided by team members Serve as the project manager for the Business Capability Model development within the targeted Capability Area Develop Project Schedule Set meeting schedule Provide documentation and expertise on technology and systems supporting the Capability Area Lend expertise to opportunities, issues and constraints posed by technology Participate in meetings and model development sessions Review and evaluate deliverables Provide strategic context and expertise in the development of Business Capability Models Ensure scope of team Business Capability Model development is bounded and relevant Validate team deliverables and work products to ensure they align with the business architecture Ensure horizontal alignment across capability areas Ensure vertical alignment to other work streams and EA components (information, technology, applications) Identify new areas for Business Capability analysis Perform an annual assessment of the Business Capability Models and initiate BCM development teams as needed Maintain existing models Communicate benefits of the Business Architecture
Capability Facilitator
Business Partnership Manager (BPM)
IT Specialist
IT Representative with strong knowledge of systems supporting the Capability Area
Business Architect
Enterprise Architecture (EA) Representative
Business Architecture Model Management
Business Partnership Team
Page 60 of 86
The World Bank
Official Use Only
7 Method and Model Governance

One goal of the Enterprise Architecture practice at the Bank is to establish an institutionalized IT governance process to evaluate alignment with technology direction. Information & Technology Governance Group (ITGG) is the legislative governance body reporting to the IPC and represents the Banks lines of business. The primary areas of responsibility of ITGG are to review and provide funding to IT projects, set policy and guidance related to IT, provide oversight to IT work program and budgets, and promote institutional awareness to the organization. The Governance process for the business capability models and business architecture leverages existing organization and governance structure to provide oversight and management to the Capability Modeling efforts across the Bank. The Business Capability Method, including the process by which Capability Models are developed, will be issued and owned by the Enterprise Architecture team. Changes or modifications to the Method or completed Business Capability Models will be managed through the governance process. The relationship between the main governance bodies is depicted in Figure 6-1.
Page 61 of 86
The World Bank
Official Use Only
Business Architecture Governance

World Bank Information and Technology Governance Group (ITGG)
Membership: Voting Members both elected and assigned by Line of Business and Units, Line of Business Representatives Meets: As required Mission: The executive decision making body for capital planning and IT investments Performs review and approval of business cases arising from work on the Enterprise and Initiative Vision and sets criteria for prioritization of initiatives for funding.
1.
2.
Architecture Review Board

Membership: Business Partnership Managers, Enterprise Architecture Team, Information Policy, Information Security, Enterprise Applications, Enterprise Technology, etc. Meets: As required Mission: Review and approve the Enterprise Vision and make recommendations on funding for the creation of an Initiative Vision for the priority initiatives. Review and approve Initiative Visions and make recommendations on approving implementation budget. Monitor project execution health and make recommendations to adjust the project portfolio.
3.
Business Partnership Manager (BPM)

Membership: Line of Business BPM Meets: As required Mission: Facilitate the development of the initiative business architecture and make sure the the business needs are captured
4.
Business / Initiative Sponsor

Membership: Process Area Owners Meets: As required Mission: Review and approve business architecture. Commit business resources to participate in the project
5.
Enterprise / Initiative Project Team

Membership: Team lead and project team members Meets: As needed/weekly throughout Enterprise/Initiative Vision Phase Mission: Develop the deliverables of the Enterprise/Initiative Business Architecture. Liaise with the other groups to ensure consistency with other architecture components
Figure 6-1 Business Architecture Governance Key decisions for these bodies are aligned with specific stage gate milestones in the Integration Framework. Figure 6-2 shows the key stage gates and the types of questions that the Architecture Review Board, through direction from the ITGG, is seeking to address at each stage.
Page 62 of 86
The World Bank
Official Use Only
Figure 6-2 Stage Gate Decisions
8 Change Configuration Process

This section highlights the general procedures and principles necessary to establish and maintain consistency of the corporate Capability Models utility throughout its lifespan. These procedures apply to models developed either by Bank Staff or by external resources (consultants, contractors, etc).
8.1 Change Control Baseline

The first stage in the configuration management process is the identification of attributes and standards as a baseline for comparison. This document serves to meet some of those needs notation standards, glossary of terms, model components, attributes of the model components, and field definitions in each of the Capability templates. In addition, the following baseline documentation (contained in Appendix 2) should be defined and referenced by the Bank: Master model repository an electronic location for storage of completed and approved Business Capability Models. This repository would be subject to Change Control procedures. Repository management guidelines a 1-page checklist for documenting decisions taken and artefacts chosen to be removed from or eventually returned to the Master repository. This ensures an ability to audit historical decisions and track the evolving nature of the repository over time. Model standards documentation a comprehensive list of naming conventions, required attributes and samples of best-practice descriptions, model size and/or complexity guidelines, logic guidelines, etc. Reference guide for modellers best practice advice on what differentiates a good model vs. a bad model. This should be revisited periodically, after each initiative.
Page 63 of 86
The World Bank
Official Use Only
Training materials the training course for business capability modelling within the overall curriculum of training for a business architect.
8.2 Business Capability Repository Change Control

The change control process involves taking information from, manipulating information within, or adding new information back to the Banks master Business Capability Model repository. Most typically these events are triggered by a new project or initiated when a change is required to an existing Business Capability Model. Change control during a project is most critical at the start, during the peer review process of primary deliverables, and during close-out. The key steps for each project stage are outlined below: At project kick-off model initiation (or edits to existing model forms): Establish business need, Broadly define scope, Engage EA office to develop Capability Model strategy (existing parts to be used, new parts envisioned to be added) Check-out sub-model components for manipulation Enterprise Master Business Capability Repository
Check Out Diagrams, Templates, Requirements
Check In Diagrams, Templates, Requirements
Project / Initiative Sub-Model
During project model development: During peer reviews EA office performs QA 14 o Notation o Naming conventions o Logical structure o Review of descriptions o Completed templates At conclusion of project EA officer performs Final QA Align final model (both new additions and updates to existing components) to enterprise-level framework (and review for any potential changes or impact) o Review opportunities for Capability overlap or re-use across segments o Confirm any changes to the enterprise vision and Capability Areas Review same elements included during the peer review QA Apply numbering scheme to model artifacts (diagrams and templates) Standards document will need to be developed in concert with the EA Office and BA Review Board.
14
Page 64 of 86
The World Bank
Official Use Only
Store in the repository (maintain file naming conventions, diagram naming conventions) o Diagrams and templates store project files o Models and completed descriptions store in BCM repository o All files - tie to IRIS records as-needed More information regarding the Model Repository can be found in Appendix 2, Section 10.1.
8.3 Capability Model Notation

This section introduces the numbering scheme for Capability Models at the Bank. Level 1 Architecture Segments #. Example: 1 Enterprise Business Management Level 2 Capability Areas #.# Example: 1.1 Corporate Procurement Level 3 Capability Sub-Areas #.#.@ Example: 1.1.a. Procure Goods and Services
Though many Capability Models will have a one-to-one relationship with Capability Areas and Sub-Areas, some models may also include parts of Capability Areas from a separate architecture segment. In these cases, the numbering scheme of the Capability Model should follow from the architecture segment that includes the majority of the Capabilities shown within the model. Using the example in Figure 4-1 from an earlier section in this document, then, the model would be numbered according to the Enterprise Business Management number scheme because 2 of the 3 depicted Capabilities are contained in the Enterprise Business Management architecture segment. More information regarding Capability Model notation can be found in Appendix 2.
Page 65 of 86
The World Bank
Official Use Only
9 Glossary of Terms
Term Architecture Segment Description Highest grouping level in the Enterprise Business Capability Model, mapping to the lines of business within the organization. The segments are usually categorized into three main areas: 1. Direction those functions that the business performs to create the organizations direction and guide the organization towards realizing its vision 2. Core those functions that the business performs to deliver its products and services to its external customers 3. Enabling those functions that the business performs to enable efficient, effective operations in the other areas Business Architecture A logical framework for documenting and analyzing business functions and related objects in order to structure accountability over the individual aspects of the activities such as processes, data, systems, and organizations. What the business does to perform something of value to that business. Business Capability mapping is the process of modeling what a business does to reach its objectives (its capabilities), instead of how it does it (its business processes). The goal of this approach is to model the business on its most stable elements. Level 1 drill down of the Architecture Segment that defines the primary groupings of work that directly support the delivery of products and services core to that Architecture Segment. This is the highest level of Capability within a business. Defines the Business Capabilities associated with an architecture segment, including relationships across Capabilities, dependencies, objects, and resources. A typical Business Capability Model will include diagram(s), descriptive templates, and (for lower-level Capabilities) business requirements listings. Level 2 drill down from the Business Capability Areas that further define the groupings of work. It can be represented by a collection of individual Capabilities. Form used by Capability Facilitators to ensure complete data capture during Capability Modeling projects Technologies, applications and practices for the collection, integration, analysis, and presentation of business information and (also, sometimes) of the information itself. The purpose of business intelligence is to support better business decision making. Specification of what the business wants, typically expressed in terms of outcomes the activity generates rather than functions or specific operations any system or person will perform A series of activities bringing about a result. A business process
Business Capability
Business Capability Area
Business Capability Model
Business Capability Sub-Areas Business Capability Template Business Intelligence
Business Requirement Business Process
Page 66 of 86
The World Bank Term Description
Official Use Only
model describes how the business performs or implements the given Capability or how Capabilities connect to deliver a desired outcome Capability Component An individual activity or process step within a Capability that contributes to the realization of that Capability. Capability components often have a one-to-one relationship with business or functional requirements, depending on the level of granularity at which the model is developed. Links between Capabilities that focus on information exchange in terms of inputs (what is consumed) , outputs (products and outcomes) and controls (policies, standards, approvers, etc.). Visual depiction of the interaction between objects and Capabilities Decision , control, , or other attribute within the Capability chain that lies on the critical path to the primary output or outcome A description, typically in both narrative and pictorial format, that characterizes the target state vision or an initiative vision in a more granular fashion to show the relationships between the main components and focuses on the functions and attributes of the system, mock-ups or prototypes of interface components, process descriptions, implications to roles and responsibilities, and policy changes. In the context of a Business Capability, other Capabilities or elements of Capabilities that can influence or are subject to influence The alignment of information technology with business strategy, including integration and standardization of the relationships between various business entities with other layers of the architecture strategy, information, application, and infrastructure. An integrated view of the entire enterprise including relationships between the high-level business and IT components A graphical representation of data where the values taken by a variable in a two dimensional map are represented as colors. Indicates the future state importance of each Capability , which can be characterized as increasing, stable, or declining Defines a single initiative to a level of detail that would support its acquisition, including describing the high-level business and functional requirements for each initiative. A method for organizing and expressing the business, information, application and technology infrastructure architecture of an enterprise. The scope of the architecture described using the framework may be very large (for example, entire enterprise) or focused on a single solution or initiative. The level of detail in the description will increase as the scope decreases to focus on a single initiative.
Capability Connector
Capability Diagram Capability Key Concept of Operations
Dependencies
Enterprise Architecture
Enterprise Vision Heat Map Importance Initiative Vision
Integration Framework
Page 67 of 86
The World Bank Term Lexicon Description
Official Use Only
Vocabulary and terminology that is specific to and critical for understanding and/or describing a Capability Area, Capability SubArea, or Capability itself Comprehensive list of attributes required for each model and the descriptions of these attributes to include naming conventions, required vs. optional fields, sample best practice descriptions, model size, complexity guidelines, and logic guidelines Within a Capability Model, objects represent the physical or abstract resources of value in the categories of data, documents, service, knowledge, learning, people, communications or publications Expected results that a Capability will deliver to the customer as noted in a performance measure, either qualitative than quantitative The physical or abstract resource of value produced by the Capability, often noted as an object on the Capability diagram Checklist for documenting decisions and artifacts chosen to be removed from or returned to the master repository People, Applications, and Data contributing to the realization of the Capability The architecture segment grouping of the Capability: 1. Direction those functions that the business performs to create the organizations direction and guide the organization towards realizing its vision 2. Core those functions that the business performs to deliver its products and services to its external customers Enabling those functions that the business performs to enable efficient, effective operations in the other areas
Model Standards
Object
Outcomes
Outputs Repository Management Guidelines Resources Segment Category
Tools and Techniques Work Products
Job aids, training, methods, or localized best practices that enable the Capability The deliverables associated with an initiative (at either the enterprise or initiative level) of a phase or task within an initiative. Work products typically take the form of documents, diagrams and tabular listings of descriptive content. The content of a work product varies according to the phase or task it flows from. The integration framework defines the structure and required content of each work product to varying levels of detail.
Page 68 of 86
The World Bank
Official Use Only
10 Appendix 1 Business Capability Model Templates

10.1 Template I High-Level Capabilities
The template below is used to describe Business Capability Areas (Level 2) as outlined in Section Level 1 Capability <<Name>> Capability description Outputs (products/services) Triggers Business Value A short description of mission/vision of the capability A description of the main clients and the products/services delivered to them A description of any suppliers and key input that is required for the capability to be provided What level of business value does the capability deliver? Does the capability differentiate Bank products and services? Is the capability a key contributor to the Banks strategic goals? Is demand for the capability increasing? Is the capability performing well or poorly? Is stakeholder satisfaction with the capability at an acceptable level? Is the capability efficient? Does the capability meet the compliance requirements? Is the capability a candidate to be leveraged in other parts of the organization? Is the capability predictable? Is the capability integrated? Does improving the capability enable improvements to other capabilities? Provide a summaryl assessment of the efficiency and effectiveness of the capability plus any indicators or factors that should be considered as part of the performance improvement. These are often captured as constraints upon the resources such as cycle time, throughput, peak periods, volumes, resources available and costs. Enabling Components Processes & Management Controls Identify the specific processes and management controls (e.g. laws, policies, standards) that apply to capability. Identify the key performance indicators or other criteria used to measure the performance of the capability Identify by name the subjects and key entities from the enterprise information model that used by this capability. Designate the nature of the use in terms of create, update, read or delete. Note if this information is currently provided. Note any issues or specific considerations with regard to the information that could improve capability performance Identify the business unit that is responsible or involved in the
Performance
Leverage
Performance characteristics & resource issues
Information Resources
Human Resources
Page 69 of 86
The World Bank
Official Use Only delivery of this capability. Designate the involvement in terms of RACI (Reviewer, Approver/Accountable, Concur, Informed). Identify the various personas that need to be considered by the concept of operations. Note any issues or specific considerations with regard to the human resources that could improve capability performance
Application Resources
Identify by name the applications from the enterprise application model that support this capability. Note any issues or specific considerations with regard to the applications that could improve capability performance Identify by name any specific technologies from the enterprise technology model that support this capability. Note any issues or specific considerations with regard to the technologies that could improve capability performance Figure A-1 - Business Capability Area Template
Technology Resources
Page 70 of 86
The World Bank
Official Use Only
10.2 Template II Detailed Capability Analysis

The template below is used to capture Business Capability attributes outlined in Section 3.3 of this document.
Business Capability Model - Detailed Template World Bank - Business Architecture Development Capability Team Facilitator (or designated author): Date Created: Last Updated:
<Business Capability Name>
Related Business Capability Areas: (Reference related Architecture Segments)
Vision/Mission
Capability Description
Dependencies (upstream / downstream)
Lexicon
Architecture Segment Capability Importance Issues/Risks
State Representation Identify and document issues or risks pertaining to the capability documented in this template.
As-Is / To-Be
Parking Lot Ideas
Identify and document issues or improvement opportunities gathered when defining this capability but that are NOT in scope for this capability. Capabilities
Capability Components Outputs Outcomes / Performance Measures Resources Tools & Techniques Objects Name Description Category Business Capability Model
Figure A-2 - Business Capability Model Template
Page 71 of 86
The World Bank
Official Use Only
11 Appendix 2 Model Reference Documents

Items in this appendix were finalized through the proof of concept (Task 2) and training process (Task 4) and amended to this document in June 2008. All of the items contained in this Appendix are available as stand-alone documents. The following documents are included: Repository Management Guidelines - describes a series of activities for documenting decisions taken related to the Business Architecture, removing artifacts from the Master repository, and eventually returning them to the Master repository. Activities related to repository management are described in the context of the Banks IT Capital Project lifecycle. Modelers Quick Reference Guide - This document identifies how a modeler should prepare for a Business Capability Modeling project and describes bestpractices for creating and managing individual diagrams. Business Capability QA Checklist - This table describes a series of steps that should be taken during peer review and final quality assurance reviews of all business capability models. Business Capability Modelling One page Reference Guide the one-page reference guide is available with the BCM training materials in the Banks Enterprise Architecture Master Repository.
11.1 Repository Management Guidelines

Purpose This document describes a series of activities for documenting decisions taken and artifacts chosen to be removed from or eventually returned to the Master repository. This ensures an ability to audit historical decisions and track the evolving nature of the repository over time. Audience This document is primarily targeted at the administrators of the Business Architecture Master Repository. Related Documents and References Business Capability Modeling Method Guide Guide for Capability Modeling Standards (appendix within the Method Guide)
Contents Introduction and Context Business Architecture Repository Management and Procedures o o o o Stage I ITGG Planning Stage II Architecture Review Board Stage III Project Initiation Stage IV Project Closure
Page 72 of 86
The World Bank 11.1.1 Introduction and Context
Official Use Only
The repository management process involves taking information from, manipulating information within, or adding new information back to the Banks Master Business Capability Model repository. Most typically these events are triggered by a new project or initiated when a change is required to an existing Business Capability Model. In other cases, however, repository management can result from changes to enterprise objects or components that flow from the products of enterprise governing bodies such as the Information and Technology Governance Group (ITGG) and the Architecture Review Board 15. This document provides an introduction to the sorts of tasks that are required at each stage of the repository management lifecycle: o o Enterprise Repository Administration the maintenance of business components stemming from stages I, II, and IV of the IT capital project lifecycle. Project Lifecycle Repository Administration - the processes involved in initiating a project, removing a sub-model from the master BA repository, performing a mid-project review of the model, and eventually merging the model and its relevant artefacts back into the enterprise repository (stages III and IV).
Stage IV Project Closure BA Repository Administration Lifecycle Stage III Project Initiation
Stage I ITGG Capital Planning
Stage II Architecture Review Board
Figure 4 - Relating the Repository Management Lifecycle to Business Architecture Governance Stages
For the purposes of this document, it is assumed the Architecture Review Board serves the following roles: 1) Makes actionable the recommendations of the ITGG with respect to specific budgets and allocations to different projects, and 2) serves as a project portfolio management body for the Bank. To the degree that the Bank has other roles that perform these operations, their names can be substituted in this document.
15
Page 73 of 86
The World Bank
Official Use Only
Business Architecture Repository Management Procedures 1. Stage I ITGG Capital Planning Stage I ITGG Capital Planning The ITGG capital planning stage includes the following activities (as defined in the Business Capability Modelling Method Guide):
The executive decision making body for capital planning and IT investments. Performs review and approval of business cases arising from work on the Enterprise Initiative Vision (strategic direction for the Bank) and sets criteria for prioritization of initiatives for funding. As a by-product of this work, the following types of updates to the Business Architecture Master Repository could be triggered (note that all updates resulting from the ITGGs work exist at the Enterprise level and are not applicable to the work products of individual projects): Business Capability and Sub-Capability Definitions discussions about the work of the Bank and its ongoing operations may illuminate a necessary change to the high-level business capability model. Once identification for such a change is made, it would need to be reviewed with the relevant business owners. If approved, the master model would then be updated. Business Principles and Management Controls review of individual business cases within the ITGG may also highlight the need for a new or updated business principle (a change to policy or new management directive) as well as new or updated management controls (similar circumstances to the business principle). These set of changes would be reviewed by the Enterprise Architecture Office and updated, as needed, to the master model. Common Enterprise Components the Enterprise Initiative Vision may include a strategic direction for the capture and review of a new or updated set of common enterprise components, such as standards around document integration, consistency of shared knowledge, workflow of transactional review procedures, etc. Awareness of this strategy impacts the planning of individual projects and the addition of new common components to the registry in the BA Master Repository.
2.
Stage II Architecture Review Board Stage II Architecture Review Board The Architecture Review Board stage includes the following activities (as defined in the Business Capability Modelling Method Guide):
Review and approve the enterprise vision and make recommendations on funding for the creation of an Initiative Vision for the priority initiatives (as outlined in the ITGG). Review and approve Initiative Visions (individual capital projects) and make recommendations on approving the implementation budget. Monitor project execution and health and make recommendations to adjust the project portfolio. As a by-product of the work of the Architecture Review Board, the following types of updates to the Business Architecture Master Repository could be triggered:
Page 74 of 86
The World Bank Enterprise Repository Administration:
Official Use Only
Business Capability and Sub-Capability Definitions (drivers leading to an update and the steps required to approve an update mirror those at the ITGG level). Business Principles and Management Controls (drivers leading to an update and the steps required to approve an update mirror those at the ITGG level). Common Enterprise Components (drivers leading to an update and the steps required to approve an update mirror those at the ITGG level).
Project Lifecycle Repository Administration: Business Capability Models periodic review of projects, their scope, and their relationship to the high-level capability model may lead to a new or different understanding about the linkages among the lower-level capabilities and their high-level parent objects. In these cases the Business Architecture staff in the EA office would need to analyze the suggested changes or additions and, as-needed, make the relevant adjustments within the Master Repository. Stage III Project Initiation Stage III Project Initiation The Business Partnership Manager, in conjunction with the Business Sponsor and the Project team, perform the following activities as outlined in the Business Capability Modelling Method Guide:
3.
Facilitate the development of the initiative business architecture and ensure that the business needs are captured; Review and approve the business architecture, and commit the resources to fulfil the project needs; Develop the deliverables of the business architecture, and liaise with other project teams to manage dependencies, risks and points of interaction.
Within this context, the following types of interactions are typically required as part of the project initiation and implementation lifecycle: Enterprise Repository Administration: Business Capability and Sub-Capability Definitions identify a strategy for how the scope of the initiative will relate to the enterprise capability model, and use that model as an analytical too to help structure the project goals. Updates to the model may result from this analysis, and would need to be approved by business owners before they are implemented by the EA office. Business Principles, Management Controls, and Common Components review the registry of enterprise principles, controls and components that are associated with the capabilities to be addressed within the project. Develop a strategy for their use within the development of project models and deliverables. Updates to the registries may also result from this analysis.
Page 75 of 86
The World Bank
Official Use Only
Project Lifecycle Repository Administration: Business Capability Models the following activities are performed: o Engage EA office to develop Capability Model strategy - existing parts of the Master Repository to be used, new parts envisioned to be added o Check-out sub-model components for manipulation - capability diagrams and completed templates o Identify business architecture artifacts of use for reference during the project: o Enterprise capability diagram the Bank on a page o Completed enterprise capability sub-area templates and diagrams o Registries of enterprise business components o Use-case or requirements examples o During project model development: peer reviews, EA office performs QA 16 o Notation o Naming conventions o Logical structure o Review of descriptions and completed templates Enterprise Master Business Capability Repository
Check Out Diagrams, Templates, Requirements
Check In Diagrams, Templates, Requirements
Project / Initiative Sub-Model
Figure 5 - Overview of the Lifecycle of a Business Capability Master Model and Sub-Model Business Process Models the following activities are performed: o Engage EA office to develop Process Model strategy - existing parts of the Master Repository to be used, new parts envisioned to be added o Identify business architecture artifacts of use for reference during the project: o Archived process or capability models o Use-case or requirements examples o During project model development: peer reviews, EA office performs QA 17 o Notation o Naming conventions o Logical structure o Review of descriptions and diagram contents
16 17
Standards document will need to be developed in concert with the EA Office and BA Review Board. Standards document will need to be developed in concert with the EA Office and BA Review Board.
<Task 1 - BCM Method_Guide v5e Final.doc > Business Capability Method
Page 76 of 86
The World Bank
Official Use Only
Use Cases and Requirements Documentation extract the relevant Use Cases (including templates, if they exist) and Requirements documents (including templates, if they exist) for use during the projects execution.
4. Stage III Project Closure Stage IV Project Closure The Business Partnership Manager, in conjunction with the Business Sponsor and the Project team, will have performed the following activities as outlined in the Business Capability Modelling Method Guide:
Develop the deliverables of the business architecture, and liaise with other project teams to manage dependencies, risks and points of interaction. Within this context, the following types of interactions are typically required as part of the project closure lifecycle: Enterprise Repository Administration: Business Capability and Sub-Capability Definitions lessons learned and the final, approved contents of the capability and process model(s) may identify a need to also update the contents of the enterprise capability diagram. Business Principles, Management Controls, and Common Components lessons learned and the final, approved contents of the capability and process model(s) may identify a need to also review the contents of the enterprise principles, controls, and common components registries. Updates to the registries typically result from this analysis.
Project Lifecycle Repository Administration: Business Capability Models the following activities are performed: o Deliver completed model to EA office o Conduct final QA o Align final model (both new additions and updates to existing components) to enterprise-level framework (and review for any potential changes or impact) o Address any changes to the enterprise vision and capability areas o Review opportunities for capability overlap or re-use across segments o Merge model back into BA repository o Apply numbering scheme to model artifacts (diagrams and templates) o Store in the repository (maintain file naming conventions, diagram naming conventions) Diagrams and templates store project files Models and completed descriptions store in BCM repository All files - tie to IRIS records as-needed Business Process Models the following activities are performed: o Deliver completed model to EA office o Conduct final QA o Align final model (both new additions and updates to existing components) to capability-level framework (and review for any potential changes or impact) -
Page 77 of 86
The World Bank
Official Use Only
address any implications to potential changes to higher-level capability diagrams Merge model back into BA repository o Apply numbering scheme to model artifacts (diagrams and templates) o Store in the repository (maintain file naming conventions, diagram naming conventions) Models and completed descriptions store in BCM repository All files - tie to IRIS records as-needed
Use Cases and Requirements the following activities are performed: o Review project outputs and store, as-needed, relevant artefacts that add value to the Master Repository for future reference or re-use
Page 78 of 86
The World Bank
Official Use Only
11.2 Modeller Reference Guide

Purpose This document identifies how a modeler should prepare for a Business Capability Modeling project and describes best-practices for creating and managing individual diagrams. Audience All internal Bank staff and consultants who develop Business Capability Model diagrams at the World Bank. Related Documents and References

Business Capability Modeling Method Guide Task 2 - Proof of Concept Deliverable for Business Capability Modeling Project Modeling at the Bank Overview of Capability Models Getting Started Preparation for a Successful Project Tips and Best Practices Revision History
Contents

Modeling at the Bank Overview of Models A business capability is "what the business does to perform something of value to that business". This is in contrast to a business process, which describes how the business performs or implements the given capability or how capabilities connect to deliver a desired outcome. Business capabilities describe the stable elements of the business to model your organization and provide the critical layer that aligns application services to business operations, and hence drives the development of a service-oriented architecture. A business capability is expressed in terms of outcomes and service levels, to create value for the customer (who may be internal or external). Business-capability mapping is the process of modeling what a business does (its capabilities), to reach its objectives. Links between capabilities are defined as capability connectors that focus on information exchange in terms of inputs (what is consumed) and outputs (products and outcomes) and controls (policies, standards, approvers, etc.). The Enterprise Vision defines the Capabilities of the organization in levels 1 (architecture segments) and 2 (Capability Areas). These compose the essential elements of the highlevel enterprise Business Capability framework for the Bank. In reality, however, most Capability Diagrams contain elements that cross Architecture Segments, or that cross Capability Areas within Segments. As a result, each Capability that is identified for modeling purposes needs to be analyzed by the Capability Facilitator 18 in the context of this broader framework to ensure alignment across segments.
18
See Section 5.2 of this document for a description of the role of the Capability facilitator.
<Task 1 - BCM Method_Guide v5e Final.doc > Business Capability Method
Page 79 of 86
The World Bank
Official Use Only
Getting Started Because there are many different staff and consultants modeling at the Bank, the Enterprise Architecture Office at the Bank has developed modeling best-practices to which all diagrammers and analysts are directed so that diagrams are consistent when they are merged into the Bank Master Repository. The process for modeling at the Bank requires that staff and consultants do the following: Attend trainingthe EA Office has BCM training available to consultants starting a major modeling effort in the Bank. The training is a practical, hands-on session covering use of the Business Capability Modeling approach and how to meet the Banks requirements. NOTE - Timing and attendance for the training is critical: Project kick-off is often too early for modeler training. Training should be conducted as modeling is about to get started so the skills can be easily transferred. It is imperative that all modelers be present at the training. Orient the Capability Framework with EA StaffThe EA staff member overseeing the modeling effort will work with you to determine which previously developed diagrams residing in the Master Repository are associated with the modeling effort. Once these diagrams are identified, the EA staff member pulls the diagrams into a folder or workspace in which you create and modify diagrams. Preparation for a Successful Modeling Project When approaching an As-Is or To-Be modeling project, it is important to have a good understanding of the following before you start diagramming: Scope of the studyKnow the goal of the study and how the modeling will support that goal. This will help keep the modeling on track, as frequently more information is provided by the client than is required for the specific study at hand. Breakdown of the major components of the processUnderstand the major components of the process to be diagrammed, so you can determine how the process should be split up, or chunked, into separate diagrams. This will help you structure your data gathering around specific topics, and minimize the number of client participants that have to attend any one interview session. Appropriate level of detail for diagrammingHave a sense for how many processes and how much detail for each capability should be diagrammed. Will the documentation be at a high level (e.g., just identifying the main steps) or will it be at a more detailed level (e.g., showing handoffs and swim lanes more typical of a process model)? Knowing the level of detail will help guide the data gathering stage. Meaning of the different modeler shapes and notationKnow how to read a business capability diagram by knowing the shapes for capabilities, connectors, objects, and the contents of the underlying models. Modeling will be relatively easy if you have the shapes and notation in mind when gathering information from the client. A summary of the model notation scheme appears in Section 4.2. Tips and Best Practices for Using Business Capability Modeling Planning your Diagram
Page 80 of 86
The World Bank
Official Use Only
Diagrams should be scoped using a top-down approach to the analysis. This allow
the modeler to understand the big picture by identifying the beginning and terminating capability within the project scope, analyzing the capabilities between these boundaries, and developing a high-level model to illustrate this straw-man diagram. Consider working off a single diagram at the beginning of the project to see interrelationships among capabilities on a single view before creating detailed drilldowns of individual capabilities.
Diagram Descriptions & Names Diagram descriptions should be in present tense and provide an overview of the capability shown in the diagram with any diagram-specific details. Diagram names are usually the same as the capability name from which they drill down. A detailed diagram description should be incorporated in the underlying capability template. Higher-level or aggregate capability diagrams do not necessarily require a detailed capability template to be completed. This decision is left, initially, to the discretion of the modeler. Diagram Titles Diagram titles should appear on all process diagrams. Title boxes should appear in the bottom left corner of the diagram, aligned with the near-corner of the canvas. The size of the title box should be made to fit the title text. Diagram Appearance The natural flow of a capability diagram output goes from left to right, top to bottom. Therefore, it is prudent (where possible) to arrange the objects on the diagram in order from left to right, top to bottom to minimize the amount of manual re-ordering of processes that must be done to finalize the Procedure Manual. Diagrams must be scaled to be easily read. Test-print your diagram prior to completion to ensure it remains legible and printer friendly. Diagram objects should constructed using the templates provided in the BCM Model Sample diagram, contained in the EA Master Repository. So that all diagrams produced by staff and consultants have the same look and feel, the pre-defined diagram defaults should not be changed. Diagram Version Control Boxes A Version Control Box should appear on all diagrams A Version Control Box is added to the bottom, right-hand corner of the diagram. The Version Control Box should include the date created, modeler name, and date last updated. Capabilities Capability names should begin with a verb and end with a noun. Capability names should avoid any prepositions or forms of the verb to-be Capability names should avoid the use of the verb perform. A list of recommended verbs appears as an attachment to this document. Objects
Page 81 of 86
The World Bank
Official Use Only
Frame objects on the diagram so that when multiple objects serve as an input to a Categorize objects according to the information architecture categories maintained It should be up to the diagrammers discretion as to whether or not a free-text
capability they overlap diagonally, descending downward.
by the EA Office. These same categories appear as legends on the diagram.
comment next to any one object helps add clarity to the diagram. Questions about the use of such comments should be direct to the EA Office.
Connectors Connectors sometimes benefit from a description that articulates one of the following elements: The object is only conditionally transformed by a capability, and that condition is not self-evident without a description; The object is not consistently transformed by the capability, or is somehow consumed by the capability in a way that merits an explanation on the diagram; The capability may reject the object, which is in turn re-submitted to the capability on an iterative basis the condition that allows this iteration to cease may be worth highlighting. In any of these cases, a description should only be added it provides a critical level of understanding to the reader and illuminates a critical component of the capability flow. A minimal volume of descriptive text is desirable on any connectors. It is equally desirable to minimize the number of connectors with a description. Revision History 6/18/08 First draft of bulletin
Page 82 of 86
The World Bank
Official Use Only
11.3 Business Capability QA Checklist

This table describes a series of steps that should be taken during peer review and final quality assurance reviews of all business capability models. # 1. QA Process Step Before giving the checklist to new staff or consultants, indicate if any criteria will not apply Make sure that no non-standard object types or symbols have been added. Outcome Document exceptions Findings
2.
Document any unauthorized additions or exceptions and ask Enterprise Architecture officers if the non-standard items have already been approved. Document any deviations from the standards.
3.
Check that capabilities were captured correctly: Capabilities captured on more than one diagram are described consistently Capabilities follow the correct Verb Noun naming convention The first word of each capability is capitalized Capability names avoid references to technologies, people, or organizational units
4.
Check for the following within each of the capability templates: Capabilities without descriptions Capability diagrams missing any of the template header information Capabilities without business requirements Acronyms listed on the capability diagram are described in the capability template
Correct and fill any information gaps in the capability templates
5.
Check that the diagrams are structured correctly.
List issues identified and proposals for
Page 83 of 86
The World Bank #
Official Use Only QA Process Step Outcome resolution of each issue. Findings
Diagram title in lower left-hand corner of the map Diagram version control box in the lower right-hand corner of the map Legend at the top of each diagram No floating objects or capabilities (objects or capabilities not connected to one another) Objects that serve as an input to a capability generally enter the left-hand side of the capability hexagon, and objects that are transformed by a capability generally exit from the righthand side of the capability hexagon.
Check that the names of all diagrams are in the correct format. 6. Check that diagram flows are logically correct. Objects that terminate at the end of a capability chain on one diagram are likely (thought not required) to begin as objects that initiation a new capability chain on another diagram; Objects that are transformed by multiple capabilities are adequately explained in the text of the diagram template; Non-bank artifacts and Bank physical artifacts appear in the correct symbol type and not as the more common rectangular object type. List issues identified and proposals for resolution of each issue.
7.
Validate that the model contents are filed and stored in the Enterprise Architecture master repository.
Page 84 of 86
The World Bank
Official Use Only
11.4 Business Capability Modeling One page Reference Guide

This reference guide elaborates the purpose and key steps for each main activity within Business Capability Modeling, the best practices for execution, and the deliverables for each activity. Note: This document is formatted to Legal size for readability.
Page 85 of 86
The World Bank
Official Use Only

Best Practices Be practical on scope set strong boundaries based on project timeline Keep team size limited to approximately 7 core individuals Draw out the project scope visually Utilize interviews to communicate key project goals Interview the stakeholders in order of knowledge about the area Focus more on the capabilities and the critical inputs/outputs, less on the process Keep interviews short and follow up as needed Brainstorm first on sticky notes or a dry erase board to develop strawman outline Use the modeling notation guide to limit rework Work with a team member Validate diagram drafts with stakeholders outside of the workshops Limit Workshops to 2-3 hours, and assume 2 hours prep for each 1 hour in session Utilize wall space versus handouts to keep discussion engaged Have a designated note-taker Use sessions for validation and consensus building Focus on improving the customer experience (and understanding who the real customers are) Maintain a To-Be Diary to capture ideas Scope and phase ideas into logical groupings Be realistic and practical Refer often to the scope of the project Documentation is an iterative process that may require multiple revisions Speak & write in the language of the business Identify key issues and downstream impacts for each capability Identify business requirements by translating interview and workshop notes Work Products Meeting Notes from discussion with the Project Sponsor Team Member list with Roles and Responsibilities Project Scope diagram and narrative High Level Project Plan Interview list with rationale Interview agendas with key questions Interview notes with Follow up information Initial draft of a To Be Diary containing improvement ideas identified so far Capability Area diagram(s) Capability diagram(s) for each Capability Area Identified capabilities, objects, and relationships Completed As-Is capability template(s) Workshop plan and schedule Workshop agenda(s) Wall charts Meeting notes and issue documentation Updated diagrams and templates Updated To-Be Diary (improvement ideas) Future state Concept of Operations Phasing approach for improvements To-Be Capability Diagrams Narrative summary of key changes (capabilities remain relatively stable) Completed Capability Templates Documented business requirements Documentation sign off Finalized package of project deliverables
Business Capability Modeling Project Lifecycle Reference Guide Purpose Steps 1. Meet with the Project Sponsor to discuss the Understand the strategic context for the vision and timeline for the project project 2. Identify Potential Team Members Assemble a Project Team 3. Recruit and Assemble Team Set the scope and target deliverables 4. Define Roles and Responsibilities 5. Determine Project scope
Kickoff
Interviews
Gather knowledge from team members and other Subject Matter Experts Document current practices and potential improvements Build enthusiasm for the project Document the Business Capability in the form of Business Capability Diagrams Identify the capabilities, key objects, and their relationships
1. Develop and prioritize a stakeholder interview list 2. Determine objectives for each interview and compose agendas 3. Schedule and conduct interviews 4. Document interview notes and validate with stakeholders 1. Use interview content and scope notes to develop strawman diagrams 2. Identify key objects for each Capability 3. Develop a diagram for each Capability (and asneeded, at a more aggregate level) 4. Validate the diagrams with stakeholders 1. Plan purpose and schedule of project workshops 2. Set firm agendas and send invitations to key stakeholders 3. Prepare wall charts 4. Facilitate session(s) 5. Send follow up actions and notes 1. Perform a Gap Analysis on the As-Is Capabilities 2. Identify and prioritize improvement ideas from the customer perspective (sessions & interviews) 3. Gain consensus amongst team and key stakeholders 4. Develop To-Be templates and diagrams 1. Finalize the Capability Template (including all content attributes) for each capability 2. Validate with Stakeholders 3. Define Business Requirements 4. Obtain Sign-off and complete documentation
Diagramming
Workshops
Engage business owners, stimulate discussion, and garner buy-in Validate information gathered through interviews Discuss key issues and ideas Develop a go-forward strategy Develop a business vision for the future state Document key ideas and focus areas Identify near term and long term improvement opportunities Produce formal document summarizing the project work Provide historical records Document metrics, lexicon, resources, and tools used for each capability
Capability Documentation
Concept of Operations
Page 86 of 86

Task 1 - BCM Method - Guide V5e Final

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Task 1 - BCM Method - Guide V5e Final

Uploaded by

Copyright:

Available Formats

The World Bank

Official Use Only Ed BUSINESS CAPABILITY MODELING

TASK 1 DELIVERABLE METHOD GUIDE

Staff Name Christine Etue

Richard Hudson Bob Etris

Date June 26 June 26 Sept 29