Sign in

Business Analysis and ITSM White Paper

White Paper

Business Analysis and ITSM White Paper

White Paper

  • White Paper
  • Business solutions
  • Collaboration
  • ITIL

Author  Debra Paul, Ivor Macfarlane and Peter Brooks

April 18, 2016 |

 20 min read

  • White Paper
  • Business solutions
  • Collaboration
  • ITIL

This White Paper identifies & illustrates the benefits of collaboration between the disciplines of business analysis (BA) and IT service management (ITSM).

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.

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.

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.

IT Service Management

Service management in the broadest sense has been around for over 3,000 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.

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.

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.

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.

Image of Figure-5.1 ITSM and BA linkages

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 ITIL's 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 analyse 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.

Image of Figure 5.2 POPIT model

Add image 

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.

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

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.

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.

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

Service management in the broadest sense is over 3,000 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.

Business Analysis and ITSM