February 24, 2020 25 min read

ITIL ITIL4 Practice Guides

Business analysis management: ITIL 4

Practice Guide
35 Likes

This document provides practical guidance for the business analysis practice.

Table of Contents
1. About this document

2. General information

3. Value Streams and processes

4. Organizations and people

5. Information and technology

6. Partners and suppliers

7. Important reminder
8. Acknowledgements

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.

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 context1

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 Service design

solutions

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
Stakeholders’ satisfaction with the
analysis, to ensure that it is conducted in a
organization’s ability to understand
consistent and effective manner
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
Stakeholders’ satisfaction with
customers are understood, analysed, and
proposed solutions
supported with timely, efficient, and
effective solution proposals
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 V l S d
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.
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 Analyse the Business analysis approach,

principles, policies, organization and including scope, methods and
and vision requirements techniques, procedures and
responsibilities
Organizational Develop and agree
strategy business analysis Improvement initiatives and
approach requests for changes
Organizational
structure Review the
business analysis
Product and service approach
portfolio

Customer portfolio

Business analysis
records and review
reports

Audit reports

Figure 3.2 shows a workflow diagram of the 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 Product-focused business

analysis analysis

Analyse the Leaders of the organization CIO, product owners, architects,

organization analyse the organization’s strategy and business analysts review
and and portfolios, and define the role the information available
requirements and scope of the business analysis regarding the organization’s
practice and its position in the strategy and requirements, and
organization define the role and scope of the
 business analysis practice and
its position in the organization

Develop and Business analysts, architects, Business analysts, product

agree a product owners, and portfolio architects, and product owners
business managers develop, agree, and develop, agree, and
analysis communicate an organization- communicate a product-
approach wide business analysis approach, focused business analysis
including scope, methods and approach, including scope,
techniques, procedures and methods and techniques,
responsibilities procedures and responsibilities

Review the Based on business analysis Based on business analysis

business records, periodic reviews, and records and periodic reviews,
analysis audit reports, business analysts business analysts together with
approach together with product owners, product owners review the
architects, and portfolio managers effectiveness of the business
review the effectiveness of the analysis approach and provide
business analysis approach and input to the ‘analyse the
provide input to the ‘analyse the organization and requirements’
organization and requirements’ activity, and/or initiate required
activity, and/or initiate required changes
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 Elicitation and analysis Business analysis reports
approach of information from
stakeholders Recommendations and
Organizational proposals
strategy Defining solution
options and Amendments to risk
Stakeholders’ identifying the register, knowledge bases,
needs recommended and other information
solution resources
Stakeholders’
requirements Providing support to
the solution delivery
teams
Organization’s
portfolios
Assessing the
solution’s performance
Architecture
and value
models and
constraints

Risk register

Relevant industry
trends and
opportunities

Figure 3.3 shows a 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 A business analyst engages with the key stakeholders to learn
analysis of about their needs and requirements. This can take the form of
information from interviews, observations, documents and records studies, and
stakeholders 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
A business analyst together with the relevant SMEs drafts
identifying the
two or more alternative solutions, to address existing
recommended
business needs and gaps, and to produce comparative
solution
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
The business analyst assists designers, developers, quality
teams
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
The business analyst assesses the solution operations and
performance and
monitors the additional value it yields for the stakeholders.
value
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 Competency profile (activities and skills)

code

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 Competency Specific skills
roles profile

Design and
maintenance of a
business analysis
approach

Analyse the TCA

organization and its
Organization Good knowledge of the
requirements
leader organization, its
environment, portfolios,
Team leader products, resources, and
customers
Business
analyst Understanding of
business analysis
Architects frameworks

Product
owner

Portfolio
manager

Develop and agree TLMC

the business
Business Good knowledge of the
analysis approach
analyst organization, its
environment, portfolios,
Architect products, resources, and
customers
Product
owner Strategic thinking

Leadership skills
 Excellent knowledge of
business analysis
techniques and
frameworks

Review the business TCA

analysis approach
Business Good knowledge of the
analyst organization, its
environment, portfolios,
Architect products, resources, and
customers
Product
owner Understanding of
business analysis
techniques and
frameworks

Strategic thinking

Business analysis
and solution
identification
process

Elicitation and CT
analysis of
Business Understanding of the
information from
analyst stakeholder’s context
stakeholders

Product Good knowledge of the

owner environment, current
solutions, and
constraints

Analytical skills,
expertise in business
 analysis techniques and
frameworks

Defining solution TC
options and
Business Understanding of the
identifying the
analyst stakeholder’s context
recommended
solution
Product Good knowledge of the
owner environment, current
solutions, and
Solution constraints
designer
Understanding of the
Service target architecture and
owner 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 TC
to the solution
Business Good knowledge of the
delivery teams
analyst organization’s approach
to solution design,
Product development, and
owner operations
 Service Communication skills
owner

Assessing solution’s T
performance and
Business Understanding of the
value
analyst stakeholder’s context

Product Good knowledge of the

owner environment, current
solutions, and
Service constraints
owner
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 Key functionality Impact on the

automation effectiveness
of the practice

Design and
maintenance of a
business analysis
approach

Analyse the Collection, processing, High

organization and and presentation of
Communication
requirements data from diverse
and collaboration
sources
tools

Analytical
 systems

Knowledge
management
tools

Develop and Communication and Collaboration and Medium

agree business collaboration tools information sharing
analysis approach

Review the High

business analysis
Communication Collection,
approach
and collaboration processing, and
tools presentation of
data from diverse
Analytical sources
systems
Reporting engines
Knowledge
management Dashboard systems
tools

Business analysis
and solution
identification

Elicitation and High

analysis of
Collaboration and Omnichannel
information from
communication communications
stakeholders
toolset with the
stakeholders
Analytical
systems Collection,
processing, and
Knowledge presentation of
management data from diverse
sources
 tools

Defining solution Presentation, High

options and spreadsheet, and
Office
identifying the document
productivity tools
recommended management
solution
Collaboration and
communication
toolset

Solution design
and development
systems

Providing support Medium

to the solution
Workflow and Work planning and
delivery teams
task tracking
management
tools Presentation
management
Collaboration and
communication
tools

Office
productivity tools

Assessing the Medium

solution’s
Collaboration and Omnichannel
performance and
communication communications
value
toolset with the
stakeholders
Knowledge
management Collection,
tools processing, and
presentation of
 Reporting data from diverse
systems sources

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
1. 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.
Home Resources CPD Badges Events Help Legal