Business Analysis and ITSM

Debra Paul, Ivor Macfarlane

and Peter Brooks

AXELOS.com

White Paper
April 2016
Contents
Introduction 3
Definitions and descriptions 3
IT service management 4
Dependencies and collaboration opportunities between ITSM and BA 5
Mutual alignment of ITSM and BA 6
Appendix A: Business analysis and the business change lifecycle 11
Appendix B: History and maturity of SM, ITSM and ITIL 13
About AXELOS 14
Trade marks and statements 14
 Business analysis and ITSM 3

1 Introduction
This White Paper sets out to identify and illustrate the benefits of collaboration between the disciplines
of business analysis (BA) and IT service management (ITSM).
We have used the ITIL® framework as our main reference for ITSM, but the principles are generically
applicable to all those practising ITSM, whether following an established framework such as ITIL,
COBIT® or ISO/IEC20000®, or applying an empirical approach based upon experience and
good judgement.
This paper has three purposes:
To give those working in ITSM an awareness of the rationale for BA and the standards adopted in
conducting this work
To give a reciprocal view for those carrying out BA that clarifies the value offered by ITSM, the range
of ITSM activities, and the importance of communication between ITSM and BA practitioners
To facilitate communication channels between BA and ITSM in order to generate mutual support,
relevant information exchange and symbiosis, thus delivering more effective and economic services
and increasing the value for the realization of business value.

1.1 WHY DOES THIS MATTER?

The information systems (IS) industry incorporates a wide range of specialist fields. Initially comprising
systems analysis, programming and operations, there are now numerous IS specialisms and the need
for communication between them has become an increasingly significant issue. While this paper focuses
on the relationship between the BA and ITSM disciplines and the importance of establishing effective
communication channels between them, the observations made in this paper are relevant to all IS
specialist disciplines and reflect a need for positive collaboration across the IS industry.

2 Definitions and descriptions

Definitions of both the ITSM and BA disciplines are provided below. Given that the audience for this
paper is likely to be more familiar with ITSM, the definition of BA is more detailed than that provided
for ITSM. Additional detail regarding BA is shown in Appendix A to this paper; additional detail
regarding ITSM is shown in Appendix B to this paper.

2.1 BUSINESS ANALYSIS

Business analysis is a wide-ranging role with the primary objective of ensuring that organizations invest
wisely in business change initiatives. BCS, The Chartered Institute for IT, defines BA as:
An advisory role which has the responsibility for investigating and analyzing business
situations, identifying and evaluating options for improving business systems, elaborating
and defining requirements, and ensuring the effective implementation and use of
information systems in line with the needs of the business1
BA can be described as business problem-solving, whereby business problems are identified,
investigated and understood, and relevant options to resolve them evaluated. BA enables the execution
of business strategy and the delivery of successful business change. To achieve this, business analysts
work closely with other business change disciplines such as programme and project management,
solution development and testing and enterprise architecture.
Some of the key drivers for the development of BA were:
Dissatisfaction with the service provided by IT departments and the common realization that the
delivered IT systems did not meet business needs
An increased sense of ownership on the part of the business with regard to their IT systems
An increased drive towards outsourcing of IT development; this required greater understanding and
better definition of the business requirements to be delivered
Reduced funds for investment in business changes
An increased understanding that business needs could be met in a variety of ways and a
combination of factors may be required to deliver successful change initiatives.
4 Business analysis and ITSM

Initially, BA was focused on the definition of requirements, with a particular emphasis on ensuring the
linkage between the business requirements and the delivered IT solution. However, as the discipline
matured, a broader focus evolved to include wider business improvements that encompassed business
process, organizational structure and IT systems changes.
The broad, cross-functional view led business analysts to question why a proposed change initiative
was needed, the nature and root cause of the problem to be resolved, and the feasibility of the proposed
investment in addressing the issue. Having established this, the business analysts could define
alternative options for meeting the business needs. Without this ‘pre-project’ work business analysts
often felt that they were expected to investigate and document requirements for ill-conceived ‘solutions’
that would not address underlying problems, were not scoped accurately and which would waste
investment funds. The development of BA has resulted in business analysts conducting pre-project
analysis more often and has raised the profile of this activity.
Business analysts are now employed at different levels within organizations, with varying degrees of
authority. The business analyst has become a key actor in helping the organization adopt a
strategically focused, commercially aware approach to business change and BA is used to address the
following areas:
Investigate and evaluate proposed changes
Establish and analyze root causes
Consider the views of stakeholders
Take a holistic view
Ensure that all changes to the business services are made within the context of the business mission,
objectives and strategy.

In order to perform these activities, business analysts require extensive knowledge and skills in three
areas of competency:
Professional techniques to conduct business analysis work
Personal skills to enable and foster stakeholder engagement
Business and commercial awareness to ensure the viability of proposals.

If performed well, business analysis provides the opportunity to discover the underlying cause of
business issues and evaluate a range of potential solutions to address the situation. This helps ensure
that limited investment funds are spent wisely. The application of BA techniques also results in clear,
well-formed requirements that are aligned with stakeholder views and business needs.

3 IT service management
Service management in the broadest sense has been around for over 3000 years, illustrated by the
successful development of engineering artefacts that have endured and still deliver service to their
users. As services became IT-based, pervasive and faster, formal processes became essential to their
successful delivery. The ITIL initiative, started in the 1980s, documented these formalized processes.
The processes within ITSM ensure that IT services are provided in a focused, client-friendly and cost-
optimized manner. When ITSM is applied, IT services are clearly defined, success is measured with
regards to the service provision, and targeted improvement measures can be introduced
where necessary.
 Business analysis and ITSM 5

ITIL 2011 sets out a broad perspective across a wide range of ITSM, based on a five-phase
lifecycle structure:
Service strategy: developing and maintaining a service management strategy, ensuring services are,
and remain relevant to the business need.
Service design: ensuring services are designed holistically, with all relevant considerations designed
in to them.
Service transition: addressing the tasks and controls necessary to ensure the timely and accurate
introduction of new or changed services, and the retirement of those that are no longer relevant.
Service operation: ensuring the live services deliver the required business value and dealing with any
issues that arise.
Continual service improvement (CSI): ongoing improvement of all aspects of services, and all
processes, functions and considerations upon which those services rely.

ITIL covers this lifecycle in five books, one for each lifecycle phase. Each publication provides guidance
to service providers on the provision of quality IT services, and on the processes, functions and other
competencies needed to support them.

4 Dependencies and collaboration opportunities between ITSM

and BA
The ITSM and BA disciplines have expanded their remit as they increased in maturity over the last
25 or so years, and this has led to the development of significant dependencies between them. These
dependencies are clarified below by examining the impact when there is a lack of communication or
limited understanding between ITSM and BA.

4.1 BA WITHOUT ITSM

Where business analysts are not cognizant of ITSM and the operational and technical constraints and
opportunities, the following issues may arise:
The business analysts may propose solutions that are difficult, or even impossible, to support and
maintain thus diminishing the prospects for realizing business value
Innovation opportunities with the potential to deliver benefits to the business may be missed.

4.2 ITSM WITHOUT BA

If there are no communication channels between BA and ITSM, or they are ineffective, the following
issues may arise:
ITSM may focus on ‘doing the current things better’ rather than working to deliver greater business
value. There is a risk that they will deliver slightly updated versions of the current solution rather
than provide the best services possible.
A lack of communication between BA and ITSM may result in a lack of understanding of the
business outcomes enabled by the IT service.
Resources may be focused in the wrong areas or apply incorrect levels of priority. For example, there
might be too much emphasis on designing a highly resilient solution when the customer requires a
faster solution.

Understanding the inter-dependencies between ITSM and BA and the potential impact on business
outcomes is essential to achieve a collaborative approach between the two disciplines and deliver
increased business value.
6 Business analysis and ITSM

5 Mutual alignment of ITSM and BA

5.1 THE NATURE OF A SERVICE
The ITIL definition of a service is:
A means of delivering value to customers by facilitating outcomes customers want to
achieve without the ownership of specific costs and risks.2
This generic definition applies to any service, not just IT services. For example, it applies to a travel
agent that creates a holiday package for a customer, or a bank providing a current account. The
concepts of service management are therefore applicable to many circumstances. The ITIL definition
makes no reference to IT, IS, or indeed being limited in any way, illustrating that services extend to
cover every aspect of all the supporting processes that a business must rely upon. This is significant to
successful service management, since focusing exclusively on any subset is unlikely to deliver broad
support to the business. Similarly, BA takes the broadest possible perspective since the goal is to
facilitate successful business change, however it is delivered.
The common aspect of all services is that they have the potential to deliver value by meeting the
customers’ needs. Customers may be internal to the delivery organization or from external separate
companies, possibly based in distant locations.

5.2 LIFECYCLE WIDE LINKAGES

Although ITIL is built around a model that identifies lifecycle stages, many of the key ITSM processes
are applied across the development lifecycle, and therefore would benefit from interaction with BA
across the whole life of a service. Figure 5.1 highlights the key interactions between ITSM and BA, and
shows significant linkages between ITSM and BA, particularly in the areas of requirements definition
and service design.
A robust understanding of requirements is essential to effective service delivery leading to organizational
success. ITSM has to ensure that the business requirements are embedded at every level of the solution
and throughout its lifetime, and that the reporting of service effectiveness and the value delivered by
services is based on and measured against these requirements.
 Business analysis and ITSM 7

Figure 5.1 ITSM and BA linkages

8 Business analysis and ITSM

5.2.1 Link between BA and service strategy

The ITIL Service Strategy guidance explains the importance of establishing and delivering what the
organization needs to be done, rather than what could be, or traditionally has been, done. Without a
relevant and well-maintained service strategy, ITSM may focus on the means of delivering a service
rather than recognizing the aims of the service.
BA is concerned with understanding business needs and ensuring that the delivered solution aligns with
those needs. As a result, the BA activities are essential if the information required for the development
of an effective service strategy is to be available. Effective collaboration between BA and ITSM will
ensure that the business analysts understand the service strategy information needs and will enable the
elicitation and delivery of this information.

5.2.2 Link between BA and service design

The heart of ITILs service design ethos involves designing everything that is needed into the service
from the earliest stages. It is particularly important that the issues facing the business and the resultant
business requirements are understood and embedded in the service design. If this is not the case,
planned measurements may not reflect the aspects of interest to the business, and retro-fitting measures
following the service design is difficult, expensive, and rarely successful. Liaising effectively with the
business analysts and ensuring that they have a direct involvement in the service design stage can
provide a basis for significant improvements to the resulting design.
As discussed above, good BA establishes the underlying causes of business problems and defines the
requirements that will address these problems. The requirements defined by the business analysts are
at two levels, business and solution, and focus on four perspectives as follows:
Business requirements: general business policy and technical policy
Solution requirements: functional (utility) and non-functional (warranty).

Service design is better placed to build relevant services to address business needs when the ITSM
community is armed with the knowledge of the requirements. The business analysts are able to define
the requirements in varying levels of detail, depending upon the needs of other disciplines, and the
requirements document may include narrative and diagrammatic definitions in order to ensure clarity
and rigour.

Effective collaboration between ITSM and BA during service design has the potential to drive effective
and innovative design by enabling a deeper understanding of what constitutes business value and how
this may be measured and delivered.

5.2.3 Link between BA and service transition

Business analysts take a holistic view of business situations and can offer insights and guidance
throughout the business change lifecycle. Frameworks such as the POPIT model™ shown in figure 5.2
help the business analysts to explore the aspects required for a successful delivery of business change.
For example, business analysts will analyze the needs of the business users during the transition
process in order to support the development of any new competencies and build confidence in using
the new services. The knowledge and understanding gained from undertaking this holistic analysis
helps shape the release and deployment plans for services. This will also provide significant input to the
development and execution of the service-testing approach, as the ultimate criterion for a service test is
that it satisfies the business requirements as articulated during the BA work.

Full and final evaluation of a new or changed service, including how it meets the business requirements,
requires an extensive understanding of the organization and the business domain. This is another aspect
of service transition where support from business analysts is invaluable.
 Business analysis and ITSM 9

Figure 5.2 POPIT model™

5.2.4 Link between BA and service operation

BA work is often concerned with understanding service operation in order to evaluate proposals for
change and uncover root causes of business problems. In light of this, an awareness of business
operations is a crucial aspect of successful BA. This awareness needs to extend from the strategic level
to business operations. It requires an effective collaboration with service operations so that the current
services supporting the business may be discussed and understood.
A further aspect of BA work concerns the identification, planning and realisation of business benefits.
This involves the ongoing management of the original business case to take account of changes
requested during the business change lifecycle. The benefits review takes place after the deployment of
the solution, and after some or all of the benefits are realized. During this work, the business analysts
may identify further changes to be made in order for certain benefits to be delivered and this may
impact upon the service operation.
This link, during ITIL’s early life support phase of the service transition, allows both business analysts
and service managers to work together to uncover new requirements and identify those benefits that
have not been fully met. These activities present a good opportunity for the two disciplines to work
together to identify the operational factors, such as training, support and the provisions for security
and capacity, that may need improvement in order to optimize the value offered to the business and its
customers.
Business proposals that appear well-founded may ultimately fail because they are based on assumptions
and incomplete information. Communication and collaboration between BA and service operations help
to safeguard against this.

5.2.5 Link between BA and CSI

To enable continual service improvement, the relationship between BA and ITSM should be strong and
persistent, facilitated by ongoing communication and collaboration.
Service improvement is a tool to help deliver business improvement. Business improvement is a clear
goal of business analysis. Collaboration between CSI and BA reduces duplication of effort and reveals
synergies, opportunities and constraints.
10 Business analysis and ITSM

5.3 CONCLUSIONS
Too often IS solutions fail to meet business needs despite the best efforts of the professionals involved.
This will continue if we ‘do things right, rather than do the right thing’. To ensure that we are doing the
right thing, IS professionals need to be aware of their colleagues in other disciplines who can provide
insights and guidance, and require information in order to conduct their work effectively.
Improved collaboration between ITSM and BA has the potential to enable greater efficiency in delivering
services that meet business needs and improve business performance. While the ITSM and BA
communities may have different perspectives on the business improvement process, they both aim to
deliver success for organizations and value for customers. Integration of these communities is essential
to define the business requirements, and achieve these business goals by ensuring the right services
are delivered.

End Notes
1
Paul et al. (2014) Paul et al.Business Analysis (3rd Edition), Paul, Cadle and Yeates (Eds.), BCS.
2
AXELOS (2011).ITIL Service Operation,TSO. Norwich p.13
 Business analysis and ITSM 11

Appendix A: Business analysis and the business change

lifecycle
Business analysis is performed across the entire business change lifecycle. Some key aspects and tasks
illustrating the breadth of that range are described here.

6.1 STRATEGY EXECUTION

Business analysts may provide specialist input to support strategy analysis and definition. They may
use techniques such as PESTLE analysis (Political, Economic, Socio-cultural, Technological, Legal and
Environmental) and SWOT analysis (Strengths, Weaknesses, Opportunities and Threats) to identify how
business problems may be overcome and opportunities grasped. However, the primary focus of the
business analyst is on the execution of a strategy. Once the strategy has been defined, business analysts
may work with senior stakeholders to determine the business changes needed to execute the strategy.
Business analysts are also required to ensure that their work is conducted within the context of the
business strategy and that any proposed solutions align with the strategic direction of the organization.

6.2 INVESTIGATION OF BUSINESS SITUATIONS

All too often change programmes are initiated by a ‘great idea’ or the need to copy a competitor or
adopt a standard software package. Business analysis takes a holistic view of business problems and
opportunities, and challenges received wisdom or rash solutions if necessary.
A key aspect of the investigation activity is the exploration of the root causes of problems in order to
ensure that they, rather than the manifest symptoms, are resolved by any proposed solutions. This may
involve exploring why a business process takes longer than intended or an IT system is not providing
the predicted benefits, and ensuring that an assumed solution is not adopted without the analysis of the
business situation. Such early adoption of solutions, which are primarily technological, can be extremely
problematic, causing organizations to waste investment funding and time.

6.3 ANALYSIS OF BUSINESS NEEDS AND FEASIBILITY ASSESSMENT

Once the situation and the root causes of problems are understood, the business analyst considers what
a new business system might include and how it might operate. Potential changes include a re-designed
process, new job roles, and a new or improved IT system. The aim is to ensure that any changes that
are recommended address the underlying causes of problems and that these changes are financially
viable, technically feasible and acceptable to the organization.

6.4 DEFINITION OF REQUIREMENTS

Requirements definition is concerned with eliciting, documenting, modelling, analyzing and managing
the requirements for the proposed business system. During this work, the business analysts seek to
ensure that the requirements state the business needs and do not dictate any particular IT, or any
other solution.
Requirements definition is the area of business analysis work that has the most extensive standards and
Best Practice techniques. The processes for governing, managing and architecting the enterprise are
enabled through the set of requirements engineering activities described in Appendix A.
12 Business analysis and ITSM

6.5 SUPPORTING THE CHANGE LIFECYCLE

While the primary focus of business analysis concerns the investigation and definition of business
changes, the analysts also contribute during the later stages of the change lifecycle. The design of the
new processes may fall to the business analysts, in particular the definition of the detailed procedures
required to conduct individual tasks.
It is the role of business analysts to understand the requirements to be delivered by the new business
system, so that they are able to provide valuable support to the business during the development of the
IT systems. They are also well-placed to assist the business staff during the user acceptance-testing
process and the transition to the new ways of working.

6.6 MANAGEMENT AND REALIZATION OF BUSINESS BENEFITS

Business analysts provide valuable insight and assistance during the identification and management of
benefits, and throughout the change lifecycle.
 Business analysis and ITSM 13

Appendix B: History and maturity of SM, ITSM and ITIL

Service management in the broadest sense is over 3000 years old. There is irrefutable evidence of
skilled consideration and application of processes we would now consider SM ones. Without processes
like capacity management, configuration management etc. we would not have the Great Wall of China,
Stonehenge or the pyramids, certainly not the new engineering-based services of the 19th century.
As services became IT-based and therefore pervasive and faster, better processes were needed to
manage them. The speed aspect is a particular issue with IT, as things can go wrong too fast for a
human being to be able to spot and correct; this makes good processes essential rather than just
desirable because ‘on-the-job’ repair (or ‘fudging’ as engineering might call it) becomes impossible.
For the UK government in the 1980s empirical evidence of the need was seen through:
Software built but never implemented
High cost of services after go-live, in fact an unacceptable cost of ownership
Expected benefits not being available
Dissatisfaction and general disillusion with delivered IT.

In fact, the concern was that although the UK government successfully built software, its operation was
not so successful and so benefits were not being realized. The UK government had developed a widely-
adopted framework for software development (SSADM) and the intention was to develop an equivalent
for operating IT.
They took the approach of identifying organizations that performed certain tasks well, documenting
how they did it, and releasing the documentation as guidance in order to provide other organizations
with a framework by which they could improve their own work practices. The result was a set of
documented Best Practices, initially aimed at the UK government. They were soon adopted by
private sector organizations, which, it transpired, had exactly the same shortcomings and issues as
public sector organizations.
This set of Best Practices was called ITIL (IT Infrastructure Library, as this was years before the term IT
Service Management was used). The first volumes were published with an initial launch of five titles in
1989 and were completed with over 40 books in the late 1990s. ITIL has since evolved and matured
through versions 2 and 3, changing the initial focus from a function-based framework (version 1), to a
process-focus in version 2 and finally achieving a service-focused approach to service management with
version 3 (V3) in 2007.
The current ITIL version, ITIL 2011, takes a lifecycle approach. The ITIL processes are identified and
described across five books. Each book sets out to address a lifecycle stage. That should not be taken to
mean that each process can be mapped into a single lifecycle stage. In practice the majority of the ITSM
processes apply across multiple lifecycle stages. Many, for example change management, configuration
management and knowledge management, are whole lifecycle processes.
14 Business analysis and ITSM

6 About AXELOS
AXELOS is a joint venture company, created by the Cabinet Office on behalf of Her Majesty’s
Government (HMG) in the United Kingdom and Capita plc to run the Global Best Practice portfolio.
It boasts an already enviable track record and an unmatched portfolio of products, including ITIL®,
PRINCE2® and RESILIA™. RESILIA is the new Cyber Resilience Best Practice portfolio.
Used in the private, public and voluntary sectors in more than 180 countries worldwide, the Global
Best Practice products have long been associated with achievement, heightened standards and truly
measurable improved quality.
AXELOS has an ambitious programme of investment for developing innovative solutions and stimulating
the growth of a vibrant, open international ecosystem of training, consultancy and examination
organizations. Developments to the portfolio also include the launch of PRINCE2 Agile®, the ITIL
Practitioner qualification and a professional development programme for practitioners, fully aligned with
AXELOS Global Best Practice.

7 Trade marks and statements

AXELOS, the AXELOS logo, the AXELOS swirl logo, ITIL, MoP, M_o_R, MoV, MSP, P3M3, P3O, PRINCE2
and PRINCE2 Agile are registered trade marks of AXELOS Limited. RESILIA is a trade mark of AXELOS
Limited.
©Copyright AXELOS Limited 2016.
Figure 5.1 ©Peter Harvard Macleod Brooks and Debra Paul.
Figure 5.2 POPIT model™ is © Assist Knowledge Development.
COBIT® is a registered trademark of ISACA
ISO/IEC20000® is a registered trademark of ISO
Reuse of any content in this case study is permitted solely in accordance with the permission terms at
https://www.axelos.com/policies/legal/permitted-use-of-white-papers-and-case-studies.
A copy of these terms can be provided on application to AXELOS at Licensing@AXELOS.com.
Our White Paper series should not be taken as constituting advice of any sort and no liability is accepted
for any loss resulting from use of or reliance on its content. While every effort is made to ensure the
accuracy and reliability of the information, AXELOS cannot accept responsibility for errors, omissions
or inaccuracies. Content, diagrams, logos, and jackets are correct at time of going to press but may be
subject to change without notice.
Sourced and published on www.AXELOS.com.