Business analysis management: ITIL 4 Practice Guide

Practice

Practice
ITIL

February 25, 2020 |

25 min read

Practice
ITIL

This document provides practical guidance for the business analysis practice.

1. About this document

It is split into five main sections, covering:

general information about the practice
the practice’s processes and activities and their roles in the service value chain
the organizations and people involved in the practice
the information and technology supporting the practice
considerations for partners and suppliers for the practice.

1.1 ITIL® 4 qualification scheme

Selected content from this document is examinable as a part of the following syllabuses:

ITIL Specialist Drive Stakeholder Value
ITIL Specialist High Velocity IT.

Please refer to the respective syllabus documents for details.

2. General information

2.1 Purpose and description

Key message

The purpose of the business analysis practice is to analyse a part or the entirety of a business, define its needs, and recommend solutions to address these needs and/or solve a business problem. The solutions must facilitate value creation for the stakeholders. Business analysis enables an organization to communicate its needs in a meaningful way and express the rationale for change. This practice enables an organization to design and describe solutions that enable value creation, in alignment with the organization’s objectives.

The business analysis practice identifies and articulates an organization’s and customers’ needs. This practice then identifies and justifies the solution needed to fulfil that need. This practice includes assessing the requirements for people, technology, products, and services. However, the activities performed by this practice can vary between organizations. It can include tasks from the tactical and strategic analysis of the service consumer’s business processes, to a relatively narrow focus on information system analysis and the definition of the technical requirements.

The business analysis practice ensures that limited investment funds are wisely spent, by identifying the optimal solutions to address the customers’ and organizations’ needs. The application of business analysis techniques results in well-articulated requirements for the services.

The business analysis practice is evolving to accommodate the challenging demands of digital organizations, for instance by adopting agile ways of working. Organizations that are more digitally-enabled require: greater attention to understand strategic imperatives, customer and user experience, opportunities for the use of data and technology, reimagining business processes, and embracing digital business architecture.

The emergence of agile ways of working in small, autonomous, and interdisciplinary product teams has prompted organizations to evaluate the effectiveness of organizing work in specialized functions. The business analysis practice has traditionally been organized as a specialized function, coexisting with adjacent functions such as enterprise architecture management, software development and management, and so on. In the agile context, the business analysis practice is associated less with a specific team or role, but is increasingly applied by multi-skilled practitioners performing roles such as product or service owner. When this practice is performed by the product team, it is less project-driven and more of a continual activity.

As organizations evolve through digital transformation, digital solutions are progressively integrated into business value streams. Consequently, business analysis evolves from an interpreter between technology and business-focused teams, to an integrated business practice.

2.2 Terms and concepts

The business analysis role might be defined differently in each organization. For example, an organization wide business analysis practice would be focused on the analysis of all levels and aspects of the organization, to optimize the organization operations including its products and services. This model is more likely to be seen in organizations undergoing a digital transformation or looking for opportunities to improve their resources, portfolios, and operating models. Organization wide business analysis addresses the needs and requirements of a wide range of internal and external stakeholders.

In other organizations, the business analysis practice is limited to products and services. The practice is focused on the continual analysis of the customers’ and users’ needs and requirements. This model is usually found in external service providers that are engaged in a basic or cooperative relationship with their service consumers.

Business analysis can either be treated as a distinct stage of a solution lifecycle or continually performed during the lifecycle. The approach that is chosen will depend on the solution design and development approach adopted by the organization. The latter approach is common for digital agile organizations; the former is a legacy approach that does not provide enough agility in a digital environment.

This practice should understand the stakeholders’ needs, articulate and agree to their requirements, and identify an optimal solution to address these needs and fulfil the requirements. Typically, the needs and requirements can relate to an expected solution’s utility, warranty, or experience.

Definitions: Utility

Utility: The functionality offered by a product or service to meet a particular need. Utility can be summarized as ‘what the service does’ and can be used to determine whether a service is ‘fit for purpose’. To have utility, a service must either support the performance of the consumer or remove constraints from the consumer. Many services do both.

Warranty: Assurance that a product or service will meet agreed requirements. Warranty can be summarized as ‘how the service performs’ and can be used to determine whether a service is ‘fit for use’. Warranty often relates to service levels aligned with the needs of service consumers. This may be based on a formal agreement, or it may be a marketing message or brand image. Warranty typically addresses such areas as the availability of the service, its capacity, levels of security, and continuity. A service may be said to provide acceptable assurance, or ‘warranty’, if all defined and agreed conditions are met.

Experience: The sum of the functional and emotional interactions with a service and service provider as perceived by a stakeholder.

The definitions above refer to products and services; however, this classification of needs, requirements, and features can be used for other solutions, including organizational structures, partnerships, operating models, practices, and so on. A system of adapted definitions might be needed, depending on the scope of business analysis.

Business analysis may employ various analysis techniques relevant to the agreed scope and positioning of the practice. These might include generic models such as SWOT, or product-specific techniques, such as user stories.

2.2.1 SWOT analysis

SWOT (strengths, weaknesses, opportunities, and threats) analysis is often used to combine the results of internal and external assessments. It is used to evaluate whether a service is needed and if it should or should not be provided internally.

A SWOT analysis involves four specific aspects of an organization: the internal strengths, internal weaknesses, external opportunities, and external threats. A model SWOT analysis is shown in Figure 2.1.

It is important to remember the following key points when completing a SWOT analysis:

strengths can be developed
weaknesses must be managed or turned into strengths
opportunities should be identified
threats must be managed.

Image of Figure 2.1 shows a SWOT analysis diagram

Figure 2.1 SWOT analysis at the organization level

2.2.2 User stories

User story mapping is a common method of articulating service requirements. A user story represents areas of functionality, to generate understanding among team members to transform requirements into products and services. User stories describe fragments of a product or service.

The analyst might gather data about the customer’s needs and communicate the requirements in user stories. A user story has a very specific and simple form. The user might require something to enable a certain benefit.

The INVEST acronym provides a useful reminder that user stories should be:

independent
negotiable
valuable
estimable
small
testable.

More information on user story mapping can be found in ITIL^®4: Drive Stakeholder Value, Section 5.2.5.

SWOT analysis and user story mapping are just examples of different business analysis techniques that are applicable to different scopes of analysis. Many other techniques are available for various scenarios and needs.

2.3 Scope

The scope of the business analysis practice includes:

analysing organizations, architectures, business processes, products, and services, in the changing internal and external context¹
identifying and documenting the stakeholders’ needs and requirements
evaluating options and proposing actions that can be taken to address the stakeholders’ needs and/or requirements
communicating recommended solutions to relevant people and teams.

There are several activities and areas of responsibility that are not included in the business analysis practice, although they are still closely related to this practice. These are listed in Table 2.1, along with references to the practices in which they can be found. It is important to remember that ITIL practices are merely collections of tools to use in the context of value streams; they should be combined as necessary, depending on the situation.

Table 2.1 Activities related to the business analysis practice described in other practice guides

Activity	Practice guide
Improvements of business and product architectures	Architecture management
Justification of new solutions	Portfolio management
Optimization of interactions with stakeholders	Relationship management
Definition of direction objectives and constraints	Strategy management
Designing products and services based on identified solutions	Service design
Validation of the implemented solution	Service validation and testing
Risk analysis and response optimization	Risk management

2.4 Practice success factors

Definition: Practice success factor

A complex functional component of a practice that is required for the practice to fulfil its purpose.

A practice success factor (PSF) is more than a task or activity, as it includes components of all four dimensions of service management. The nature of the activities and resources of PSFs within a practice may differ, but together they ensure that the practice is effective.

The business analysis practice includes the following PSFs:

establishing and continually improving an organization-wide approach to business analysis to ensure that it is conducted in a consistent and effective manner
ensuring that current and future needs of the organization and its customers are understood, analysed, and supported with timely, efficient, and effective solution proposals.

2.4.1 Establishing and continually improving an organization-wide approach to business analysis to ensure that it is conducted in a consistent and effective manner

It is important that the organization takes a consistent approach to business analysis across its product and service portfolio. However, this does not mean that all business analysis tasks are processed in the same way. An approach might include several models to follow in different contexts such as: new products and services, changing needs, products managed in an agile way or with a legacy, monolithic methods, and so on.

Maintaining an understanding of the organization's internal and external environments is critical to ensure that the business analysis approach, meets the requirements of the organization and customer.

Business analysis is an intellectual discipline. It involves identifying and assessing the information needed for making investment decisions, and realize the solutions that fulfil the business objectives. As such, business analysts utilize multiple models to help them with the intellectual challenge of processing information, for example with: concepts, data, decisions, organizations, processes, scopes, and states. These models are used to support business analysis activities, including:

gathering information such as goals, requirements, and constraints from stakeholders
providing stakeholders with the information needed to fulfil their roles
identifying business needs and translating these into well-articulated requirements and/or solution proposals
assessing the actual solution’s performance and value, and recommending further improvements.

2.4.2 Ensuring that current and future needs of the organization and its customers are understood, analysed, and supported with timely, efficient, and effective solution proposals

Business analysis is an important step in the value stream that translates ideas into solutions, to enable value creation. The recipients must be able to act on the results of the business analysis. The analyses must be accurate descriptions of the current and proposed future states, and clearly communicate how the steps are needed to realize the proposals.

Business analysis provides input for two main parties: customers looking for solutions that fulfil their needs, and service provider’s teams who design, develop, and deliver these solutions.

The stakeholders require assurance that their needs have been understood. They require guidance on the available options and the associated benefits, costs, and risks for each option. To ensure this, business analysis might include a business case for the proposed solution(s). It is important to verify that the stakeholders have understood the information, and will offer their support anytime it is needed, during the implementation of the proposed solution(s).

The service provider teams require functional and non-functional requirements, which are amended with recommendations, such as the relative priorities of any components that could be delivered separately. They also require background information about the context where the solution will be used.

Apart from the requirements, it is important to understand the emotional context. Emotional intelligence and service empathy are important for the success of business analysis, especially for end-user services.

2.5 Key metrics

The effectiveness and performance of the ITIL practices should be assessed within the context of the value streams to which each practice contributes. As with the performance of any tool, the practice’s performance can only be assessed within the context of its application. However, tools can differ greatly in design and quality, and these differences define a tool’s potential or capability to be effective when used according to its purpose. Further guidance on metrics, key performance indicators (KPIs), and other techniques that can help with this can be found in the measurement and reporting practice guide.

Key metrics for the business analysis practice are mapped to its PSFs. They can be used as KPIs in the context of value streams to assess the contribution of the practice to the effectiveness and efficiency of those value streams. Some examples of key metrics are given in Table 2.2.

Table 2.2 Example of key metrics for the practice success factors

Practice success factors	Key metrics
Establishing and continually improving an organization-wide approach to business analysis, to ensure that it is conducted in a consistent and effective manner	Stakeholders’ satisfaction with the organization’s ability to understand their needs and address them with solutions Number and impact of registered misalignments of proposed or implemented solutions to the organization’s strategy Costs and risks associated with business analysis
Ensuring that the current and future needs of the organization and its customers are understood, analysed, and supported with timely, efficient, and effective solution proposals	Stakeholders’ satisfaction with proposed solutions Value realized with the identified and implemented solutions (including benefits, costs, and risks) Timeliness of the analysis and solution proposals Number/percentage and effect of solutions identified and proposed

The correct aggregation of metrics into complex indicators will make it easier to use the data for the ongoing management of value streams, and for the periodic assessment and continual improvement of the business analysis practice. There is no single best solution. Metrics will be based on the overall service strategy and priorities of an organization, as well as the goals of the value streams to which the practice contributes.

3. Value Streams and processes

3.1 Value stream contribution

Like any other ITIL management practice, the business analysis practice contributes to multiple value streams. It is important to remember that a value stream is never formed from a single practice. The business analysis practice combines with other practices to provide high-quality services to consumers. The main value chain activities to which the practice contributes are:

design and transition
deliver and support
engage
improve
obtain/build
plan.

The contribution of the business analysis practice to the service value chain is shown in Figure 3.1.

Image of 3.1 shows Heat map of the contribution of Business Analysis Practice to Value Chain activites

Figure 3.1 Heat map of the contribution of the business analysis practice to value chain activities

3.2 Processes

Each practice may include one or more processes and activities that may be necessary to fulfil the purpose of that practice.

3.2.1 Design and maintenance of a business analysis approach

The focus of this process is to establish a consistent and effective approach to business analysis, by addressing the current and anticipated needs of the organization.

This process includes the activities listed in Table 3.1 and transforms the inputs into outputs.

Table 3.1 Inputs, activities, and outputs of the design and maintenance of a business analysis approach process

Key inputs	Activity	Key outputs
Organization’s principles, policies, and vision Organizational strategy Organizational structure Product and service portfolio Customer portfolio Business analysis records and review reports Audit reports	Analyse the organization and requirements Develop and agree business analysis approach Review the business analysis approach	Business analysis approach, including scope, methods and techniques, procedures and responsibilities Improvement initiatives and requests for changes

Figure 3.2 shows a workflow diagram of the process.

Image of Figure 3.2 shows workflow of the design and maintenance of a Business Analysis approach process

Figure 3.2 Workflow of the design and maintenance of a business analysis approach process

Table 3.2 Activities of the design and maintenance of a business analysis approach

Activity	Organization-wide business analysis	Product-focused business analysis
Analyse the organization and requirements	Leaders of the organization analyse the organization’s strategy and portfolios, and define the role and scope of the business analysis practice and its position in the organization	CIO, product owners, architects, and business analysts review the information available regarding the organization’s strategy and requirements, and define the role and scope of the business analysis practice and its position in the organization
Develop and agree a business analysis approach	Business analysts, architects, product owners, and portfolio managers develop, agree, and communicate an organization-wide business analysis approach, including scope, methods and techniques, procedures and responsibilities	Business analysts, product architects, and product owners develop, agree, and communicate a product-focused business analysis approach, including scope, methods and techniques, procedures and responsibilities
Review the business analysis approach	Based on business analysis records, periodic reviews, and audit reports, business analysts together with product owners, architects, and portfolio managers review the effectiveness of the business analysis approach and provide input to the ‘analyse the organization and requirements’ activity, and/or initiate required changes	Based on business analysis records and periodic reviews, business analysts together with product owners review the effectiveness of the business analysis approach and provide input to the ‘analyse the organization and requirements’ activity, and/or initiate required changes

3.2.2 Business analysis and solution identification

This process is focused on analysing the stakeholders’ needs and requirements. It includes identifying and proposing solutions to address the stakeholders’ needs and requirements.

Table 3.3 Inputs, activities, and outputs of the business analysis and solution identification process

Key inputs	Activities	Key outputs
Business analysis approach Organizational strategy Stakeholders’ needs Stakeholders’ requirements Organization’s portfolios Architecture models and constraints Risk register Relevant industry trends and opportunities	Elicitation and analysis of information from stakeholders Defining solution options and identifying the recommended solution Providing support to the solution delivery teams Assessing the solution’s performance and value	Business analysis reports Recommendations and proposals Amendments to risk register, knowledge bases, and other information resources

Figure 3.3 shows a workflow of the business analysis and solution identification process.

Image of Figure 3.3 shows workflow of the Business Analysis and solution identification process

Figure 3.3 Workflow of the business analysis and solution identification process

Table 3.4 Activities of the business analysis and solution identification process

Activity	Example
Elicitation and analysis of information from stakeholders	A business analyst engages with the key stakeholders to learn about their needs and requirements. This can take the form of interviews, observations, documents and records studies, and workshops. The business analyst creates a business analysis report, including a traceability matrix to enable a requirements validation throughout the solution delivery and support.
Defining solution options and identifying the recommended solution	A business analyst together with the relevant SMEs drafts two or more alternative solutions, to address existing business needs and gaps, and to produce comparative analysis to justify either one of the options. The business analyst then presents the designated decision-making party with the solution options, and a justification for the option they recommend. The business analyst guides the responsible party (for example a service sponsor or a product owner) through the decision-making, and assists in initiating the solution delivery initiative(s).
Providing support to the solution delivery teams	The business analyst assists designers, developers, quality assurance, and deployment and operations teams in understanding and realizing the requirements. The business analyst can also be involved in the awareness and communication efforts during the solution delivery and operation.
Assessing the solution’s performance and value	The business analyst assesses the solution operations and monitors the additional value it yields for the stakeholders. The business analyst matches the benefits realized against the requirements and business goals. They then submit new improvement initiative items to the continual improvement register. The business analyst manages the changes to business requirements throughout the delivery and support. New identified needs and requirements serve as an input to the ‘elicitation and analysis of information from the stakeholders’ activity and might serve as an input to the ‘design and maintenance of a business analysis’ approach process.

4. Organizations and people

4.1 Roles, competencies, and responsibilities

The practice guides do not describe the practice management roles such as practice owner, practice lead, or practice coach. They focus instead on specialist roles that are specific to each practice. The structure and naming of each role may differ from organization to organization, so any roles defined in ITIL should not be treated as mandatory, or even recommended. Remember, roles are not job titles. One person can take on multiple roles and one role can be assigned to multiple people.

Roles are described in the context of processes and activities. Each role is characterized with a competency profile based on the following model shown in Table 4.1.

Table 4.1 Competency codes and profiles

Competency code	Competency profile (activities and skills)
L	Leader Decision-making, delegating, overseeing other activities, providing incentives and motivation, and evaluating outcomes
А	Administrator Assigning and prioritizing tasks, record-keeping, ongoing reporting, and initiating basic improvement
C	Coordinator/communicator Coordinating multiple parties, maintain communication between stakeholders, and running awareness campaigns
М	Methods and techniques expert Designing and implementing work techniques, documenting procedures, consulting on processes, work analysis, and continual improvement
Т	Technical expert Providing technical (IT) expertise and expertise-based assignments

Table 4.2 Examples of roles with responsibility for business analysis activities

Activity	Responsible roles	Competency profile	Specific skills
Design and maintenance of a business analysis approach
Analyse the organization and its requirements	Organization leader Team leader Business analyst Architects Product owner Portfolio manager	TCA	Good knowledge of the organization, its environment, portfolios, products, resources, and customers Understanding of business analysis frameworks
Develop and agree the business analysis approach	Business analyst Architect Product owner	TLMC	Good knowledge of the organization, its environment, portfolios, products, resources, and customers Strategic thinking Leadership skills Excellent knowledge of business analysis techniques and frameworks
Review the business analysis approach	Business analyst Architect Product owner	TCA	Good knowledge of the organization, its environment, portfolios, products, resources, and customers Understanding of business analysis techniques and frameworks Strategic thinking
Business analysis and solution identification process
Elicitation and analysis of information from stakeholders	Business analyst Product owner	CT	Understanding of the stakeholder’s context Good knowledge of the environment, current solutions, and constraints Analytical skills, expertise in business analysis techniques and frameworks
Defining solution options and identifying the recommended solution	Business analyst Product owner Solution designer Service owner	TC	Understanding of the stakeholder’s context Good knowledge of the environment, current solutions, and constraints Understanding of the target architecture and related constraints Good knowledge of the available technology and related opportunities Analytical skills, expertise in business analysis techniques and frameworks Good knowledge of the organization’s approach to solution design, development and operations
Providing support to the solution delivery teams	Business analyst Product owner Service owner	TC	Good knowledge of the organization’s approach to solution design, development, and operations Communication skills
Assessing solution’s performance and value	Business analyst Product owner Service owner	T	Understanding of the stakeholder’s context Good knowledge of the environment, current solutions, and constraints Analytical skills, expertise in business analysis techniques and frameworks

4.1.1 Business analyst

The key role in this practice is the business analyst, who can be specialized on an organization-level or solution-focused basis, depending on the practice scope. This role can be performed by a dedicated team or it can be under the product owner’s scope; the latter is typically found in solution-focused business analysis.

A business analyst role is similar to an investigator. They need to face the unknown, collect evidence, question the witnesses, and derive a hypothesis that they can then validate. This role might not require specific technical skills and knowledge, but it does require agility, systemic thinking, and creativeness.

It is not uncommon for organizations to hire highly experienced business analysts to explore a potentially new solution space, either in the business domain, or with solution technology, or both. The first stage is to grasp and articulate the issues that a stakeholder needs to solve, and to gather possible solutions. There are a few personality traits that make a person proficient in the role of a business analyst, such as:

persistency and analytical thinking
strong command of various problem-solving approaches
ability to quickly grasp new models and find the most important object and relationships in them
openness to new ideas.

Business analysts play a pivotal role in communicating business requirements in technical terms. A business analyst should be the primary source of knowledge for any requirement-related requests for information along the lifecycle of the solution, regardless of the development and delivery methods in use.

5. Information and technology

5.1 Information exchange

The effectiveness of the business analysis practice is based on the quality of the information used. This information includes, but is not limited to, information about:

organization’s strategy
organization’s environment and key stakeholders
organization’s portfolios: resources, products and services, and customers
organization’s architecture roadmap
strategy, architecture, and operating model of the organization’s service consumers
service configuration and IT asset information
change schedule
continual improvement register
organizational structure
technology trends.

This information may take various forms. The key inputs and outputs of the business analysis practice are listed in section 3.

5.2 Automation and tooling

The automation of the business analysis practice is focused around three main areas that enhance information exchange:

office automation tools: document, spreadsheet, and presentation tools
analysis and modelling tools, such as computer-aided design, diagramming, and data modelling tools
communication tools, such as workflow, task management, and communication systems.

Table 5.1 lists the specific means of automation relevant to each activity of the business analysis practice.

Table 5.1. Automation solutions for business analysis activities

Activity	Means of automation	Key functionality	Impact on the effectiveness of the practice
Design and maintenance of a business analysis approach
Analyse the organization and requirements	Communication and collaboration tools Analytical systems Knowledge management tools	Collection, processing, and presentation of data from diverse sources	High
Develop and agree business analysis approach	Communication and collaboration tools	Collaboration and information sharing	Medium
Review the business analysis approach	Communication and collaboration tools Analytical systems Knowledge management tools	Collection, processing, and presentation of data from diverse sources Reporting engines Dashboard systems	High
Business analysis and solution identification
Elicitation and analysis of information from stakeholders	Collaboration and communication toolset Analytical systems Knowledge management tools	Omnichannel communications with the stakeholders Collection, processing, and presentation of data from diverse sources	High
Defining solution options and identifying the recommended solution	Office productivity tools Collaboration and communication toolset Solution design and development systems	Presentation, spreadsheet, and document management	High
Providing support to the solution delivery teams	Workflow and task management tools Collaboration and communication tools Office productivity tools	Work planning and tracking Presentation management	Medium
Assessing the solution’s performance and value	Collaboration and communication toolset Knowledge management tools Reporting systems	Omnichannel communications with the stakeholders Collection, processing, and presentation of data from diverse sources	Medium

6. Partners and suppliers

It is not uncommon among both internal and commercial service providers to externally source the business analysis practice. External resources can have a greater availability and motivation to deliver solutions in the agreed limited timeframes.

Outsourcing of product development teams often presents a ‘built-in’ business analysis capability, where business analyst functions work closely with other roles engaged in the solution delivery, resulting in a more efficient information exchange.

However, internal business analysis has its merits, mainly that it possesses ongoing knowledge of the business domain. Internal business analysts can be more motivated to empathize with the challenges that business stakeholders face. As they are internal employees, they might also be more motivated that external business analysts.

In organizations undergoing a digital transformation, business analysis is more likely to be applied to a wider scope to gain a better understanding of the organization’s context. This makes business analysis a key practice in enabling an organization’s strategic development and leadership, and therefore more likely to be retained rather than outsourced.

Good understanding of the organization’s dependencies and partnerships is critical to the effectiveness of business analysis, regardless of the organizational positioning of the practice.

7. Important reminder

Most of the content of the practice guides should be taken as a suggestion of areas that an organization might consider when establishing and nurturing their own practices. The practice guides are catalogues of things that organizations might think about, not a list of answers. When using the content of the ITIL practice guides, organizations should always follow the ITIL guiding principles:

focus on value
start where you are
progress iteratively with feedback
collaborate and promote visibility
think and work holistically
keep it simple and practical
optimize and automate.

More information on the guiding principles and their application can be found in section 4.3 of the ITIL® Foundation: ITIL 4 Edition publication.

8. Acknowledgements

AXELOS Ltd is grateful to everyone who has contributed to the development of this guidance. These practice guides incorporate an unprecedented level of enthusiasm and feedback from across the ITIL community. In particular, AXELOS would like to thank the following people.

8.1 Authors

Konstantin Naryzhny, Mark Smalley

8.2 Reviewers

Monika Perendyk, Bas van Gils, Dinara Adyrbayeva, Roman Jouravlev

References

Scope of the business analysis practice in a specific organization may include some or all of the listed objects; Also, depending on whether the organization acts as an internal or external service provider, ‘organizations, architectures, business processes’ might refer to the organization’s service consumers or the organization itself.