2 INTRODUCING THE BA SERVICE FRAMEWORK

INTRODUCTION

Business analysis is a very broad discipline, encompassing numerous frameworks and techniques, and supporting a wide variety of business situations. It is accurate to describe it as a ‘portfolio’ role; however, the breadth of the portfolio raises difficulties with defining the business analyst role clearly.

Chapter 1 explained the issues that may arise when the business analyst role is not clearly defined, such as a lack of role clarity on the part of stakeholders and a lack of role identity on the part of business analysts. Many people think analytically about business situations and problems, applying techniques such as impact, risk or option analysis in order to help reach workable solutions. Therefore, without a clear business analyst role definition, it can sometimes appear that anyone is able to perform business analysis.

A discussion held during the BA Manager Forum in November 2017 confirmed this impression, concluding that business analysis is at risk because ‘anyone can wear the badge’ and that sometimes those with ‘the badge’ perform business analysis without the required expertise. This is a theme that seems to have emerged within the business analysis community and has raised concerns because of the potential impact upon the reputation and recognition of the business analysis contribution to organisational success. Chapter 5 discusses some specific unhelpful behaviours that have been exhibited by business analysts.

Chapter 1 explained how poor performance by an individual can have a detrimental impact on the reputation of an entire discipline. While a lack of role clarity and identity are not the sole reasons for these behaviours, they do not help and on occasion may prove to be the root cause of the problems. Therefore, we need to define the business analyst role clearly if we are to build a role identity, ensure role clarity for customers, colleagues and other stakeholders, and address unacceptable behaviour and poor performance.

Regarding business analysis as a service, applying the principles of service science should provide this much-needed clarity. A service view offers a basis for clarifying the business analyst role through defining the service portfolio for business analysis, the value proposition for each service, and the activities and techniques required to conduct each service. It should also ensure that business analysts can share a common language that helps them to understand their relevance to business change and IT projects and to perform their work effectively.

This chapter explores a service view of business analysis and covers the following topics:

• the nature of service and service science;

• the ‘value fallacy’ and the need for value co-creation;

• the Business Analysis Service Framework.

THE NATURE OF SERVICE

The nature of service has been the subject of much research over the last few decades. An emerging area of academic theory on the matter concerns Service Science, Mathematics, Engineering and Design (abbreviated to Service Science). Research into this area has examined what is meant by the term ‘service’ and how this may be delivered to customers. A succinct definition of ‘service’ provided by Service Science researchers is:

This book explores several aspects of this definition within the context of business analysis, in particular:

• the competences, such as knowledge and skills, that are required of business analysts;

• the application of business analysis competences when conducting business analysis;

• the benefits that may be achieved from the delivery of business analysis services;

• the beneficiaries of business analysis services.

The rationale for a BA Service definition

Stakeholders who initiate or work on business change projects are highly likely to work with business analysts. However, the work that the business analysts are required to do can vary significantly. The problems associated with role clarity mean that issues can occur when there is not a clear understanding of what business analysts do and the contribution they can make to a proposed business change initiative. Issues that often arise when business analysis is not understood or recognised are as follows:

• A change initiative is set up without due consideration of the problem to be addressed and the feasibility of proposed actions. In such situations, business analysis is not undertaken or is only done in a limited way. For example, a change is requested and a project is set up without questioning whether or not the change offers the desired outcomes and if there are other options available. In other words, the focus is on doing the thing right, but not necessarily doing the right thing (to paraphrase Drucker¹).

• Limitations are placed upon the ways in which business analysts conduct their work. For example, business analysts are asked to document requirements without being given any authority to apply their analytical skills, merely being required to record the requirements as they are described.

• Senior stakeholders focus too much on the implementation of software solutions. For example, a software product is selected without any business analysis and understanding of the business need.

• The project team also focuses on the IT solution without a recognition of the broader business context. For example, the assessment of the business readiness for the IT system is not conducted.

The history of IT is littered with examples of projects where the outcomes were not predicted or beneficial, and the issues listed above are typical reasons why this has occurred. All of these situations require business analysis if the risks of failure are to be overcome. However, the challenge faced by business analysts is to ensure that stakeholders understand what they can offer, so that a project is not initiated without their involvement.

A defined service portfolio, with stated value propositions, is helpful for both project stakeholders and the internal business analysis team. From a stakeholder perspective, it offers the opportunity for them to understand which business analysis services are available, how a particular service may be of benefit and, in overview, how the business analysis work would be performed. Within the business analysis community, it offers a basis for developing and establishing a professional business analysis community and effective service provision. Essentially, it provides a means of communicating why business analysis helps organisations and what business analysts can do.

The Business Analysis Service Framework

Empirical research conducted over a five-year period (Paul, 2018) identified that business analysts work on a variety of assignments and projects. The work may be conducted at an early stage in the business change life cycle, whereby the analysts investigate problems or potential opportunities to see if there is a need for a change programme or IS development project. Other assignments may be more specific such as to define the requirements for a particular change initiative or to improve specific processes.

The research culminated in the development of the Business Analysis Service Framework (BASF), which identified six services that may be offered by business analysts. These services, and associated objectives, are shown in Figure 2.1.

This framework is intended to provide a BA Service with a basis for defining the portfolio of services to be offered to an organisation.

THE NATURE OF VALUE

Service Science has clarified the nature of value – in particular, what is meant by the term ‘value’ and how ‘value’ is achieved. In the past, value has been said to be ‘delivered’, implying that value automatically results from the delivery of a product or service. This is contradicted by Service Science proponents who suggest that customers have to make use of what is delivered (whether in the form of purchased products or services) in order to realise value for themselves or their organisation.

Figure 2.1 The Business Analysis Service Framework (BASF)

This view challenges the assertions made regularly within the IT and business change industry that state that value may be delivered as a result of a product or service being delivered. Instead, Service Science suggests that tangible products are just the means through which a service is provided. This perspective states that value may only be realised if use is made of the products. For example:

• A person may purchase an expensive piece of equipment that has a very high specification but only realises value from this purchase if the item is used and the features exploited.

• A person may obtain tickets for a concert but only realises value by attending, and enjoying, the concert. If the person is given tickets to a concert that is of no interest, and so decides not to attend, the delivery of the tickets will generate no value whatsoever.

If this logic is applied to business analysis, the service deliverables offered by business analysis work may be seen as a means of supporting customers and enabling them to realise a valuable outcome. Although business analysis is needed as a basis for value realisation, the business analysis activities and deliverables do not, in themselves, deliver value. Where business process changes or requirements for a new IT system are analysed and documented, there is an opportunity for value to result but this is only where the defined process changes and requirements are exploited through being implemented. The business analysis artefacts are only valuable to the extent that they are used to achieve outcomes that may enable the realisation of value.

A further aspect of this logic concerns the involvement of a customer in deciding what product or service is required and which features it should offer. If a product or service is delivered to a customer but is not what is required, the prospects for realising value are very slim.

The delivery of value has been contrasted with the offering of a value proposition (Lusch and Nambisan, 2015), and it has been suggested that it is not possible for organisations to deliver value – rather, that they are limited to offering a value proposition.

The value fallacy

No entity, whether an enterprise, an internal function or a software product, can state that it ‘delivers value', as value has to be co-created with the recipient; instead, the entity can provide service that has a value proposition. However, it is often the case that inaccurate statements are made about delivering value even though this cannot be justified. Often, those making the statements are attempting to ‘sell’ something and the item may be a product, service, process or even an idea. Whatever the situation, a promise that value will be delivered is incorrect and misleading. This is the ‘value fallacy’ and includes the statements shown in Figure 2.2.

Figure 2.2 Comments on value delivery – the value fallacy

Statements such as those shown in Figure 2.2 are often used within business and IS change projects. A typical example concerns the frequent assertions that the application of Agile will deliver value. Another example is the claim that the delivery of software will result in the delivery of value. Both are promises that cannot be guaranteed and they risk raising customer expectations that will not be met. Such statements also have implications for business analysis because the focus is placed on software delivery rather than the holistic work system that encompasses all elements of the POPIT™ model: People, Organisation, Processes, Information and Technology.

It is important to recognise and understand that value cannot be delivered but is realised from the use of a product or service. In other words, value is not realised by the receipt of goods or the delivery of a service but by the uses to which they are put. Within a business and IS change context, the delivery of software will not create value for an organisation. It is only when it is used and, through this use, enables improvements or savings, that benefits are realised.

Rather than assuming that value is delivered through the exchange of products or services (this is sometimes called value-in-exchange), it is more accurate and helpful to focus on the realisation of value through the use of the delivered products or services (known as value-in-use). Examples abound of software products that have been developed or purchased, often at significant expense, yet are used to only a limited degree, if at all. There is no justification for claiming that value has been delivered by these products.

Value co-creation

The realisation of value is achieved through a process of collaboration between those requiring the value and those delivering the service or product. This is known as ‘value co-creation’. If this concept is applied to business analysis, it is possible to identify three phases of value co-creation. These are shown in Figure 2.3.

Figure 2.3 The business analyst and value realisation

These value co-creation phases are described in Table 2.1.

These three phases summarise the essence of the value proposition offered by the BA Service and the means of achieving value realisation for its customers.

The value proposition for the BA Service

Value propositions state the characteristics of the value that is offered to connect those offering a service with the possible beneficiaries. A defined value proposition offers clarity and sets an expectation for potential customers. It provides a basis for customers to understand how the business analysis service could be of benefit to them and, thereby, encourages engagement between a customer and a service provider. Engagement between a service supplier (for example, the BA Service) and a service customer (for example, an organisation and its stakeholders) is vital to co-create the value required from a service.

Table 2.1 Stages of business analysis collaboration

1. Collaborating to identify where value might be achieved	This business analysis work is concerned with services such as investigating problematic or opportunity-offering business situations and uncovering root causes of problems. Business analysts need to work collaboratively with business stakeholders to understand where action is needed to improve problem situations and grasp opportunities
2. Collaborating to develop a solution that offers value	This business analysis work is concerned with defining requirements at different levels of abstraction, from enterprise-wide to individual software features, and designing holistic solutions that address all aspects of the POPIT™ model. Business analysts should also be involved in solution development work, supporting business staff in ensuring that their requirements are fulfilled, challenging assumptions and received wisdom, and clarifying business rules
3. Collaborating to ensure that value is realised	This business analysis work is concerned with acceptance testing and deployment of business change solutions. Business analysts have to collaborate closely with their business and technical stakeholders to ensure a smooth transition and the usage of the new solution

Equally important is the clarification of the roles involved in value co-creation if misaligned expectations on the part of the stakeholders are to be avoided. This is a key issue for the BA Service as explained in Chapter 1. The lack of a clear definition of the business analyst role has the potential to create incompatible role expectations and to diminish the recognition of the BA Service and the important role business analysts can play in helping organisations to succeed in today’s dynamic business and technological world.

Fundamentally, a value proposition is a statement of what is offered to customers by an organisation or service provider. There are several frameworks for creating a value proposition; two popular frameworks are discussed below.

A value proposition (VP) may be examined through the lens of several elements, as shown in Figure 2.4.

These elements are defined within a business analysis context in Table 2.2.

An alternative view of a value proposition is offered by Osterwalder and Pigneur (2010) who describe a value proposition using the attributes shown in Figure 2.5.

Figure 2.4 Attributes of a value proposition (Paul, Cadle and Yeates, 2014, reproduced with permission from AssistKD)

Table 2.2 Attributes of a BA Service value proposition (1)

VP attribute	Contribution to business analysis value proposition
Functionality	The business analysis services offered and why they are needed; the beneficial outcomes that result from business analysis
Price	The cost of business analysis services and why this is justified given the potential risks and costs of failing to conduct business analysis
Quality	The quality standards applied when conducting business analysis
Choice	The different levels of business analyst from entry to expert, and the corresponding levels of ambiguity and complexity that they are able to handle
Availability	The availability of business analysts to work on change projects
Image	The impact business analysis has on the reputation of the enterprise
Relationship	The impact business analysis services have on the relationship with internal and external customers

These elements are defined from a business analysis perspective within Table 2.3.

The two approaches to defining a value proposition offer different attributes. However, there is commonality between the two sets of attributes as reflected in Table 2.4.

If the attributes offered in Tables 2.2 and 2.3 are reviewed within the BA Service context, it is possible to identify how selected elements would provide the basis for an overarching value proposition statement. The statement may differ from organisation to organisation and these tables may be used to support the customisation of each value proposition.

Figure 2.5 Attributes of a value proposition (based on Osterwalder and Pigneur, 2010)

Table 2.3 Attributes of a BA Service value proposition (2)

VP attribute	Contribution to business analysis value proposition
Newness	The ability of business analysts to offer an objective and innovative perspective on a business situation
Performance	The business analysis services offered and why they are needed; the beneficial outcomes that result from business analysis. The level of quality and skill offered by business analysts
Customisation	The ability of business analysts to tailor their approach to the particular situation and to ensure that proposed options are also relevant to the context
‘Getting the job done’	The skills offered by business analysts to ensure that business changes are holistic and enable an organisation to work effectively; the collaboration with stakeholders to ensure that the right things are done
Design	The improvements in product or service design that result from business analyst involvement
Brand/status	The impact business analysis has on the image presented by the enterprise and its change projects
Price	The reduction in the costs associated with business change/IT projects that result from business analysts being involved when relevant
Cost reduction	The avoided or decreased costs resulting from business analysis work
Risk reduction	The avoided or mitigated risks resulting from business analysis work
Accessibility	The improved level of accessibility to products and services that result from business analysis work
Convenience/usability	The improved levels of convenience and usability that result from business analysis work

Table 2.4 Commonalities of the two sets of VP attributes

An example value proposition for a BA Service could be defined as:

While a value proposition for business analysis may be helpful as an overview, the portfolio offered by the BA Service necessitates the identification of value propositions for each service within that portfolio. This offers a further dimension to the BA Service and clarifies the value each service within the BASF offers organisations.

Table 2.5 states the value propositions for each of the business analysis services within the BASF.

Table 2.5 Value propositions for each of the BASF services

Service	Value proposition
Situation investigation and problem analysis	State a clear definition of the problem to be addressed and the business needs to be met. Define the scope of the work to achieve this. Where a project is relevant, in outline, clarify the investment objectives and business benefits to be achieved by the project
Feasibility assessment and business case development	Define the rationale for a proposed business change, generate, describe and evaluate the options to achieve the business requirements, and quantify and/or describe the investment objectives and predicted business benefits
Business process improvement	Define the required enabling changes through describing and redesigning business processes, and identifying the actions to be undertaken to deploy the improved processes
Requirements definition	Define the required enabling changes through eliciting, analysing, describing and managing requirements for business and IT changes at the level of detail relevant to the context
Business acceptance testing	Collaborate with stakeholders to support business acceptance of the solution
Business change deployment	Collaborate with stakeholders to support the deployment of the required business changes and enable their adoption
Stakeholder engagement	Support the achievement of business and IS project success through stakeholder collaboration, communication and effective stakeholder relationship management

APPLYING THE BASF

Each service within the BASF sets out ‘what’ a BA Service may offer its customers. This needs to be supplemented by a definition of ‘how’ the work to deliver the services may be conducted. The BASF has been defined in terms of the activities required to carry out the service and the technique categories that should be considered.

The BASF activities

The BASF activities are defined at a sufficiently generic level such that they may be adapted or customised for an internal BA Service Catalogue. The extent to which each activity is conducted, and the team structure adopted when carrying out an activity, requires further definition. This is in recognition of the range of business analyst contexts and the different approaches and frameworks applied on IS and business change projects.

The widespread application of Agile software development, and the extension of some of the concepts, principles and techniques such that they are applied to holistic business change projects, sometimes manifests itself in a dismissal of analytical work. For example, requirements definition is sometimes dismissed as inappropriate when business analysts are working within an Agile development environment. However, experienced analysts recognise the importance of ensuring that a project is doing the right thing as well as doing the thing right. Too often, they encounter situations where the focus is on delivering something even if this runs the risk of being costly and inappropriate. These business analysts recognise the need to understand the requirements and appreciate that the level will vary according to the context. Sometimes, just the general business requirements need to be defined before proceeding to an evolutionary solution development process. On other occasions, precision may be essential as specific functional and non-functional requirements need to be defined, using a combination of narrative and diagrammatic documentation. Business analysis within an Agile context is described in depth in the BCS publication, Agile and Business Analysis (Girvan and Paul, 2017).

Table 2.6 sets out each service and the activities that may be conducted during the provision of the service. The varying nature of organisations and business situations requires business analysts to use their experience and judgement when deciding on the exact approach to be adopted. Essentially, the focus needs to be on undertaking the service activities that will achieve the desired outcomes for the organisation. The exact activities will depend on a combination of factors, including organisational standards, industry trends, the expertise of the business analysts and the characteristics of the situation.

Table 2.6 BA service portfolio and activities

The business analysis research used to create the BASF also identified an auxiliary service that cuts across each of the BASF services and focuses on working effectively with stakeholders. The importance of a customer orientation for the BA Service is discussed in Chapter 10.

The activities required to engage with stakeholders are defined in Table 2.7. These activities reflect the need to engage effectively with stakeholders.

The nature of stakeholder engagement is often misinterpreted as a need to build amicable relationships. However, given that the value proposition for business analysis is concerned with supporting organisational success, stakeholder engagement requires a facilitative approach that may also involve challenging and negotiating. These different aspects are reflected in the list of activities.

Stakeholder engagement has been defined as a separate service because the activities may be performed to support any of the primary six services. However, in some organisations a service may be offered that focuses on a particular stakeholder engagement service. A typical example concerns facilitation, which is sometimes viewed as a particular service that may be applied to workshops, meetings, forums and focus groups.

The BASF technique categories

Business analysis is a highly skilled discipline and has the potential to contribute to business and IT projects. The context for business analysis work is varied and often ambiguous. Therefore, it is rarely the case that the same approach can be applied to all business analysis work so the professional business analyst has to possess a range of skills. These skills often involve the use of specific business analysis techniques, which are standard ways of working that help in the conduct of an activity.

Table 2.7 Auxiliary BASF service and the activities conducted

The ‘T-shaped Professional’ framework provides a basis for identifying the broad range of skills required of business analysts and is discussed in Chapter 4. Each business analysis service requires a business analyst to carry out several activities, each of which may be enabled by the application of techniques. However, the techniques that are helpful will differ according to the specific context. There are numerous techniques available to the business analyst; the BCS publication Business Analysis Techniques (Cadle, Paul and Turner, 2014) lists 99 techniques and the toolkit seems to expand daily.

Given the number and variety of techniques within the business analysis toolkit, the BASF describes technique categories rather than listing each individual technique. Table 2.8 sets out the technique categories that are used frequently by business analysts and were identified during the research conducted into business analysis. The BCS Business Analysis Techniques publication provides additional information about the application of these techniques and also suggests additional techniques that are useful to business analysts.

There are numerous techniques that apply to each technique category and several categories may be relevant to an individual service. The technique categories that are most relevant to each business analysis service are shown in Table 2.9.

Each of the techniques results in the creation of a deliverable or contributes towards this. Some of the deliverables are intrinsically linked to the technique. For example, data modelling results in the production of a data model. Others are likely to contribute to a variety of deliverables and the exact nature will depend upon the situation and the standards applied in the organisation. For example, the use of a facilitated workshop to investigate a situation may result in the production of a range of deliverables, including a mind map, business process model, rich picture and use case diagram. Chapter 6 discusses the different standards and templates that may be applied to business analysis work.

Table 2.8 BASF technique categories and techniques

Technique category	Description
Agile development	Objectives: To apply Agile principles to a software development project; to govern the work of an Agile software development project Explanation: Agile software development projects adopt techniques and ceremonies that align with the Agile philosophy and principles. There are established techniques that are used to apply Agile effectively Techniques: Product/solution backlog, Kanban Board, daily stand-up, retrospective, sprint/iteration
Business case development	Objectives: To identify, define and evaluate options for business change; to ensure that there is a financial case for a proposed change Explanation: Business case development techniques are concerned with the analysis of options to address business problems or realise business opportunities. This is necessary to ensure that an organisation is going to invest financial and other resources in viable projects. These techniques consider four aspects relevant to options: the costs, benefits, impacts on the organisation, and risks. They also examine the likely business acceptance of an option Techniques: Cost/benefit analysis, investment appraisal, force-field analysis, risk analysis, benefits review, impact analysis, business impact assessment
Data modelling	Objectives: To represent the data required by an organisation or business area to support the delivery of services to customers (internal or external); to represent the business rules inherent in the structure of the data Explanation: Data models provide a view of an information system from a data perspective. They may be developed at different levels of granularity. For example, an information concept or domain view consisting of high-level areas or a detailed data model encompassing elements such as data groupings, relationships between the groupings, business rules and individual data items. There are two major modelling approaches used to represent data or information. These are entity relationship modelling and class modelling. While they represent similar concepts, there are differences in the ways those concepts are modelled and in some of the detail represented Techniques: Entity relationship diagram, class diagram, data definition, domain definition
Environment analysis	Objectives: To analyse the external business environment over which the organisation has little, if any, control; to analyse the factors within the organisation that must be considered when deciding on the strategy to respond to external factors Explanation: Environment analysis techniques provide a rigorous basis for developing a strengths, weaknesses, opportunities, threats (SWOT) analysis. However, this may result in a large number of factors to be considered in each quadrant of the SWOT and a degree of prioritisation is often required. The strengths and weaknesses are the internal factors that will help to determine the strategic choices available to an organisation. The opportunities and threats are the external factors facing the organisation; these need to be distinguished from the strategic choices made on the basis of the SWOT Techniques: Political, Economic, Social, Technological, Legal, Environmental (PESTLE) analysis, Porter’s 5-forces, SWOT analysis, Balanced Scorecard, critical success factor, key performance indicator
Gap analysis	Objectives: To examine a current and target state in order to determine where there are differences; to identify the actions required to move from a current or target state Explanation: Analysing the differences between current and target states might involve examining different representations of these states. For example, a popular approach is to compare ‘as is’ and ‘to be’ business process models; an alternative is to use a business activity model (BAM) as a conceptual view of a possible future state that may be compared with a representation or description of a current situation. Frameworks such as the POPIT™ model help to structure the gap analysis Techniques: Gap analysis, ‘as is’ and ‘to be’ comparison, BAM, POPIT™ model
Implementation	Objectives: To prepare affected business areas for the implementation of business changes; to deploy business changes successfully; to review the business change processes and outcomes Explanation: Implementation of business changes requires comprehensive planning and preparation. Typically, this includes consideration of areas such as communication, training, infrastructure set-up and data migration Techniques: Training needs analysis, training material development, Customer, Product, Process, Organisation, Location, Data, Applications, Technology (CPPOLDAT), post-implementation review
Investigation	Objectives: To explore situations with the aim of uncovering issues, problems, opportunities and other relevant information; to clarify the root causes of problems Explanation: Investigation techniques are concerned with understanding a situation from a holistic standpoint. Information that may initially seem irrelevant – such as the climate of a business area or ad hoc comments – is gathered and noted in case it illuminates the root causes of problems or helps to identify opportunities for change. A variety of techniques are available to business analysts when investigating situations. Many of these techniques overlap with those used during requirements elicitation. However, the application, stakeholders and focus are different in line with the often-ambiguous and vague business situations that the business analysts encounter Techniques: Interview, workshop, survey, observation, focus group, document analysis, prototyping, wireframing
Problem definition	Objectives: To identify the root cause of a business problem that is to be addressed by the BA Service; to create a statement setting out a clear definition of the problem Explanation: Problems that are identified to require investigation and resolution are often found to be symptoms or manifestations of an underlying problem. Business analysts are required to investigate situations, challenge statements and take a holistic view in order to identify the root causes of problems and ensure that these are addressed Techniques: Rich picture, mind map, problem statement, Ishikawa (fishbone) diagram, five whys, context diagram, brainstorming/brainwriting, Post-it™ exercise
Process modelling	Objectives: To represent processing conducted by an organisation or business area to deliver services to customers (internal or external); to provide a diagrammatic view that is a basis for improving business processes Explanation: Process models provide a view of an information system from a process perspective. They may be developed at different levels of granularity. For example, an organisational view of the value chain consisting of high-level activities or a cross-functional diagram showing detailed elements such as process flows, actors, decisions and tasks. The fundamental aspects of process modelling techniques are very similar, as they show activities or tasks and the flows between them. However, the level of detail represented will differ depending upon the context, and the modelling notation is variable depending upon the standard adopted within an organisation or by the BA Service Techniques: Business process model, swimlane diagram, Business Process Model and Notation (BPMN) diagram, business process map, decision modelling, value chain, activity diagram, event analysis
Requirements engineering	Objectives: To elicit tacit and explicit information from stakeholders regarding their requirements; to analyse this information with a view to understanding and recording why something is needed, what is needed, when it is required and who requires it Explanation: Different levels of requirements may be required for a project. For example, a senior executive may request a feature at an overview level of definition; this may need to be explored in further detail with operational business staff. Different techniques may be applied when recording requirements. These techniques record different aspects of the requirements and may be applied at different levels of detail Techniques: Requirements elicitation (see Investigation category), requirements analysis, prioritisation, traceability matrix, requirements catalogue, change control, version control
Stakeholder management	Objectives: To identify stakeholders with concerns relevant to a proposed business change; to analyse stakeholders’ levels of power and interest, and their values, beliefs and priorities; to determine stakeholder communication and management approaches relevant to the situation Explanation: Stakeholder management techniques are an essential part of the business analysis toolkit because of the volume and range of stakeholders likely to be interested or affected by proposed business changes. These techniques help to ensure that stakeholders are not overlooked and that their concerns are understood, considered and addressed where possible Techniques: Customer, Actor, Transformation, Weltanschauung (or world view), Owner, Environment (CATWOE), root definition, worldview analysis, stakeholder wheel, stakeholder map, power/interest grid, social network analysis, Responsible, Accountable, Consulted, Informed (RACI)
System requirements specification	Objectives: To create a detailed specification of the requirements to be delivered by an information system; to provide a basis for the development of an information system Explanation: Some systems development projects require detailed specification of the requirements and, in some organisations, business analysts may conduct or contribute to this work. For example, this may be for specific features or for non-functional requirements such as security and access. Techniques defined by the Unified Modelling Language (UML) are often used to provide a detailed level of specification Techniques: Sequence diagrams, state charts, Create, Read, Update, Delete (CRUD) matrix
User acceptance testing (UAT)	Objectives: To design and conduct test scenarios with a view to identifying where a product fails to meet the needs of the business user; to support the business user community in ensuring that a product is of a sufficient level of quality to be accepted for deployment Explanation: The confirmation that a product is acceptable is the responsibility of the business users. However, business analysts are often required to support the business users during user acceptance testing. This requires planning of the approach to the UAT and deciding the techniques and data that will be used during this process Techniques: User acceptance scenario, test case
User role modelling	Objectives: To explore the customer community, in particular the business user, to identify and clarify the requirements of a particular user role; to explore concerns specific to user roles with defined characteristics and needs Explanation: User role modelling helps to understand the perspectives, viewpoints and needs of different categories of customer Techniques: Use case diagram, scenario, user story, persona, user experience (UX) diagram, storyboard, empathy map, customer journey

THE BASF AND THE PORTFOLIO BUSINESS ANALYST

The BASF offers a definition of the portfolio to be offered by the BA Service and serves to clarify what business analysts do, the activities they perform and the techniques they might use to conduct business analysis work. This portfolio of services reflects the breadth of business analysis that has extended over the decades since it began to be recognised as a distinct discipline. This is reflected in the 3rd Wave model discussed in Chapter 1.

Much of the development of business analysis is due to a recognition, primarily within the business analysis community but increasingly by other related disciplines, that some of the issues associated with the failure of IS projects may be avoided if analysis activity is conducted.

Table 2.9 BASF services and technique categories

Particular examples include the following:

• a lack of analysis at an earlier stage in a project, resulting in a failure to identify the real problem to be addressed by the project;

• only limited evaluation of proposed solutions in order to assess the financial and business feasibility;

• a focus solely on the software product without considering the business environment into which it is to be delivered;

• a hasty move towards a ‘solution’ without consideration of the real problem to be addressed and whether there are other options.

However, it is not necessarily the case that all business analysis activity is effective. Where there is a lack of understanding of the business analyst role, there may be a failure to recognise the competences required to conduct business analysis effectively, which may result in assumptions that other professionals, for example, project managers or product owners, possess business analysis competences when, in practice, this is not the case. Where such assumptions are made, the analysis activity may be lacking and the opportunity to avoid the issues listed above may be lost.

The variety of situations where business analysis is beneficial crosses sectors, domains and business functions. The increasing awareness of the opportunities offered by a digital transformation perspective, for example to use technology and analytics to extend and personalise services offered to an organisation’s customers, has also raised further recognition that business analysis is essential in today’s complex business world. This combination of factors has resulted in business analysts specialising within specific business domains or industries and has raised questions about the possible fragmentation of the role.

The BASF offers an alternative approach to fragmentation by providing a basis for business analysts to review and plan their career paths on a service portfolio basis. It may be that an individual business analyst wishes to offer a personal portfolio comprising a sub-set of the business analysis services required by the organisation. For example, the requirements definition, business process improvement and business change deployment services.

A portfolio approach to a business analysis career will help business analysts to contextualise their experience and skills and direct their future career progression. It will also help to ensure that they can focus on the skills and techniques in which they need to be proficient if they are to offer the services within their portfolio.

THE BUSINESS CASE FOR THE BA SERVICE

The benefits offered by business analysis have to be clarified if a business case is to be made for the establishment of a BA Service within an organisation. While a value proposition sets out an intended beneficial outcome, it is sometimes necessary to examine the BA Service through a more detailed lens and set out a business case for its existence.

Two key components of a business case for the BA Service are as follows:

• the costs associated with running the BA Service;

• the benefits accrued from a BA Service.

These components are considered below.

Costs of a BA Service

The quantified costs associated with establishing and maintaining a BA Service will vary from one organisation to another. However, the areas of cost may be generalised across organisations. A helpful approach to determine these areas of cost is to consider a BAM for a BA Service; this is set out in Figure 2.6.

Figure 2.6 Business activity model for the BA Service

This model provides a basis for identifying the costs associated with establishing and maintaining a BA Service. Each business activity may be analysed to identify the elements that are required to establish the activity and the costs they will attract. For example, the activity ‘Recruit and manage BAs’ may require the definition and deployment of the following elements:

• policies and processes for recruitment, appraisal and performance review, performance management;

• BA job descriptions;

• training and mentoring in staff recruitment, appraisal and management.

Each of these elements may be analysed to identify the costs that will be incurred to establish this activity; for example, by estimating the effort required to develop the policies and processes identified.

This diagram also forms the basis for a gap analysis between this future view and the existing situation; this helps to identify the costs that would be incurred when setting up a BA Service. For example:

• Some activities may not be in place, so defining the elements required to establish those activities, and the costs of those elements, may be determined.

• Some activities may be partially in place because elements such as a skills framework or relevant support tools are already available and in use.

Comparing the current status of the BA Service with this BAM will help to identify the activities where costs will accrue and investment is required.

Benefits of a BA Service

Benefits from establishing a BA Service may be identified by looking at the four categories of benefit defined by Ward and Daniel (2012):

• Observable benefits that are not predicted in advance and may not be quantified financially. However, they may be observed following the introduction of the change. The observable benefits that may accrue from the introduction of a BA Service encompass:

▪ improved consistency of approach;

▪ increased clarity of service offering and value proposition;

▪ improved clarity of the business analyst role resulting in greater coherence between stakeholder expectations and the business analysis work.

• Measurable benefits that may not be predicted in advance but may be quantified financially following the introduction of the change. The measurable benefits that may accrue from the introduction of a BA Service encompass:

▪ reduced time to perform business analysis activities due to standardisation of approach and deliverables, and clear guidance on how to conduct the activities;

▪ increased quality of business analyst deliverables, resulting in less rework, due to the introduction of a standardised approach to personal development and performance management.

• Quantifiable benefits that may be predicted in advance of a change but cannot be quantified financially. The quantifiable benefits that may accrue from the introduction of a BA Service encompass:

▪ increased reputation for business analysts within an organisation;

▪ improved definition of requirements for new products or systems;

▪ easier adoption of new products or systems by business staff.

• Financial benefits that may be predicted and quantified in advance of the introduction of a change. The financial benefits that may accrue from the introduction of a BA Service encompass:

▪ reduced spending on unproductive software products and change initiatives that will fail to address the root cause of a problematic situation (due to greater rigour in the investigation of change initiatives);

▪ reduced costs associated with stakeholder involvement in change projects;

▪ increased efficiency of business processes, resulting in lower costs of service or product delivery;

▪ increased realisation of business benefits from a business change initiative.

An alternative way of considering the benefits from a BA Service is to evaluate the services offered by the business analysts in the light of the achievement of business benefits. The Benefits Dependency Network is a framework developed by Ward and Daniel that sets out the deliverables and dependencies that together lead towards the realisation of business benefits. The dimensions of the Benefits Dependency Network are:

• Investment objectives: what the business wishes to achieve from an information system investment.

• Business benefits: the positive advantage obtained by the organisation from an information system investment.

• Business changes: new ways of working adopted by the organisation.

• Enabling changes: one-off changes that provide a means of implementing the information system and business changes.

• IT enablers: the changes to the information systems and technology that are required to enact the enabling and business changes.

An overview of the Benefits Dependency Network is shown in Figure 2.7.

The contribution of the BA Service to the realisation of business benefits may be perceived by relating the portfolio of services to the elements shown in Figure 2.7. The relationships are as follows:

• Situation investigation and problem analysis: clarify the investment objectives and business benefits to be realised through providing a clear definition of the problem to be addressed, the business needs to be met and the scope of the project to achieve this.

Figure 2.7 Overview of the Benefits Dependency Network (after Ward and Daniel, 2012)

• Feasibility assessment and business case development: clarify the investment objectives and business benefits in further depth by defining the rationale for a proposed business change and generating, describing and evaluating the options.

• Business process improvement: define the required enabling changes through describing and redesigning business processes, and identifying actions required for their improvement.

• Requirements definition: define the required enabling changes and IT enablers through eliciting, analysing and describing requirements for business and IT changes.

• Business acceptance testing and business change deployment: clarify and enable the required business changes, enabling changes and IT enablers through collaborating with stakeholders to support business acceptance of the solution and enable its adoption.

Table 2.10 summarises the relationships between the dimensions of the Benefits Dependency Network and the business analysis services.

There are many benefits that may be realised from establishing a BA Service, both tangible and intangible. It is also possible to relate the business analysis services to the Benefits Dependency Network and thereby clarify how business analysis can support the realisation of business benefits predicted from a change initiative.

Table 2.10 The business analysis services and their relationship to the Benefits Dependency Network (adapted from Paul, 2018)

CONCLUSION

The elements described in this chapter clarify the why, what and how of the BA Service, as follows:

• the value proposition for business analysis (why the BA Service exists);

• the service portfolio offered by the BA Service (what the BA Service does);

• the standards applied by business analysts (how the BA Service conducts the business analysis work).

The business analyst role is subject to ambiguity and this has previously led to a lack of role identity and role clarity. In turn, this has had an impact upon customer expectations from business analysis and has resulted in a lack of recognition of the value that may be offered by business analysts.

This chapter has described the BASF, which advocates a defined portfolio of services that the BA Service may offer to customers. This portfolio also clarifies the value propositions for these services and the work activities to be undertaken by business analysts in the delivery of these services.

The BASF is intended to improve role clarity and enable increased recognition of business analysis by customers, colleagues and other stakeholders. It is also intended to offer opportunities for the standardisation of business analysis work and to provide a basis for identifying the benefits that may accrue from establishing a BA Service.

1 Drucker, P. Available from: www.bl.uk/people/peter-drucker