9 OPERATING THE BA SERVICE

INTRODUCTION

A number of operational and management activities are required if the benefits of a coordinated business analysis effort are to be realised by the organisation. This chapter discusses the key processes that underpin the operation of the BA Service. These are:

• consultancy management;

• demand management;

• planning and estimating;

• process management, including knowledge management, risk and issue management and financial management.

Many of these processes are not unique to business analysis, and there may be opportunities to align them to corporate approaches or to apply common standards in some organisations. However, the specific context of the BA Service, and the corresponding challenges that may arise when applying these processes within that context, need to be considered.

GAP ANALYSIS OF THE MANAGEMENT PROCESSES

When effective management is in place, it is not always evident to team members what managers actually do! This same conundrum often applies to the discipline of business analysis as a whole, where practitioners often struggle to articulate the benefits of business analysis, but the impacts of poor or no analysis are readily apparent.

It is helpful to use defined frameworks to identify potential gaps in management processes, capacity and capability. Two possible approaches are:

1. The project ‘Triple Constraint’ model of time, cost and quality (TCQ) sets out the major aspects to be managed to enable successful delivery. This can be applied to the BA Service to ensure that these aspects receive appropriate attention and there is clarity of responsibility and accountability.

2. The POPIT^TM model provides a further level of detail to consider whether appropriate management processes and controls have been defined and are consistently applied.

These frameworks are discussed in the light of the BA Service context in Table 9.1.

Table 9.1 Management gap analysis

Management process category	BA Service management responsibilities
Time	Planning and estimating business analysis activities and deliverables; comparing planned with actuals and providing evidence; refining planning and estimating processes
Cost	Providing clarity on ownership and management of the budget for the BA Service; demonstrating cost-effectiveness and efficiencies; identifying appropriate non-staff costs to develop the Service (including training and events, recruitment costs, materials, software); developing a charging model for the Service; tracking and forecasting budgets
Quality	Overseeing business analysis activities and deliverables; assuring quality of approach, completeness and accuracy; defining and assuring the use of standards and templates
People	Providing clarity on who provides support for people and their professional development, including coaching, mentoring and management; having responsibility for recruitment and retention of staff, and resource/demand management; ensuring adherence to relevant HR procedures and policies; creating and maintaining appropriate networks and relationships for the Service
Organisation	Having responsibility for BA Service structures and career paths; defining job roles; defining and monitoring relevant metrics, including critical success factors (CSFs) and key performance indicators (KPIs) (see Chapter 13); designing how the BA Service interfaces and operates with other related functions within the organisation
Processes	Deciding who defines and owns the processes used to deliver the BA Service, and the interfaces and relationships with other processes
Information	Having responsibility for information about the BA Service, in particular information used by those delivering the Service, knowledge management, information sharing and skill transfer, and re-use of information and deliverables
Technology	Having responsibility for determining, implementing and supporting technology required to provide the BA Service

BUSINESS ANALYSIS CONSULTANCY MANAGEMENT

Business analysts are often referred to as ‘internal consultants’, able to act in an objective way, see things from a new perspective and bring relevant experience, knowledge and expertise. They provide a service, hand over the results of their work, and then move on to their next assignment. Many business analysts act as internal consultants; those who do this most successfully have an understanding of the consulting cycle. The BA Consulting Cycle is shown in Figure 9.1. The cycle is comprised of two halves that cover the following aspects:

• Doing business analysis: delivering business analysis services (see Chapter 2 for the Business Analysis Service Framework). The practice of business analysis, including the activities, tasks and techniques.

• Enabling business analysis: delivering business analysis as a service. This means starting and ending each piece of work or project in a way that sets up the business analyst for success, builds the relationship with the customer and enhances the reputation of the BA Service.

An individual BA may be able to perform both halves of this cycle effectively (and for external ‘contract’ business analysts, their business model depends on it) but, for larger BA Services, BA leaders may be responsible for undertaking all or part of the enabling phases.

Figure 9.1 The BA Consulting Cycle

Table 9.2 shows each of the phases of the BA Consulting Cycle in more detail.

Table 9.2 Phases of the BA Consulting Cycle

If business analysts within the organisation are only concerned with ‘doing business analysis’, and the enabling phases are missed, the BA Service will be operating at a low level of maturity. There are a number of issues that can occur when there is limited understanding of the consulting cycle, or when phases are not adequately addressed – these are shown in Table 9.3.

These issues can occur on both short-term pieces of work and longer-term assignments; for example, where the business analyst is embedded in a development or product team. Both situations can still be considered internal consultancy services.

Table 9.3 Common issues arising throughout the BA Consulting Cycle

BUSINESS ANALYSIS DEMAND MANAGEMENT

Allocating business analysts to requests for business analysis support is a core component of operating the BA Service. Receiving, assessing, prioritising and addressing requests for business analysis support are processes that must take account of many factors. There is often a belief within organisations that resource management can be achieved through use of a tool or spreadsheet. These can support the process, but the number and complexity of human factors at play mean this is never a fully automated process.

Fluctuating demand

Managing fluctuating demand for business analysis support can be time-consuming and complex but it is unusual to have completely level and predictable demand within an organisation. So, the need to manage fluctuating demand for business analysts is a key issue for anyone managing a BA Service.

Demand for business analysis will be influenced by the:

• level of understanding and awareness of business analysis within the organisation;

• mix and stages of portfolio of projects/programmes/business as usual (BAU)within the organisation;

• perceived complexity of change initiatives;

• level of stability of the organisation and the need for change;

• speed of mobilisation;

• level of maturity of the BA Service;

• reputation of the BA Service;

• ease or likelihood of obtaining a business analyst;

• other roles in use across the organisation;

• access to business analysis skills via other routes.

Depending on the mix of factors at work, BA leaders may be faced with various demand issues. The key situations that arise, and may need close management, are as follows:

• Insufficient demand, which occurs where there is not sufficient work for the business analysts. Options to address this situation include raising the profile of the BA Service, targeting potential internal customers and, in the short term, using the time to focus on continual service improvement of the BA Service. If demand does not increase, allowing people to use transferable skills or develop new skills so that they can support areas of skills shortage elsewhere in the organisation, or reducing the size of the BA Service, may be longer-term options.

• Demand equal to supply, which occurs where all of the business analysts are occupied, future demand is planned and small deviations from these plans can be accommodated by the Service.

• Excess demand, which occurs where the BA Service cannot meet all the requests for business analysis support. In this situation, the BA Service will have to either increase the supply by hiring additional business analysts on a permanent or contract basis (depending on the longer-term need) or limit the demand by applying a prioritisation approach. Ensuring that business analysts are doing appropriate work and not plugging resource gaps for other roles may be another way of ‘freeing up’ additional BA Service capacity.

Prioritising demand

The relative priority of two projects or work assignments is often difficult to evaluate. Many organisations do not have a single view of priorities, with each department or business area having its own set of prioritised initiatives. Some organisations have established mechanisms for prioritising all work within their change portfolio. However, even where a clear ranking for projects or assignments is known, the high-level priority does not necessarily translate to the most appropriate deployment for the business analysts. Table 9.4 sets out an example comparison of project requests.

BA leaders must understand and apply multiple criteria to inform business analysis resource decisions, including the factors shown in Table 9.5. The number of factors mean that, inevitably, leaders will at times have to make resourcing decisions that are unpopular with business analysts or with customers. Having the ability to justify the resourcing decisions made and demonstrating an empathetic and customer-focused attitude, will help to build up trust in the decisions made.

Resourcing models

The BA Service can deploy business analysts using various deployment models. Within the BA Service, several of these models are likely to be evident as different models are required to respond to different situations. For example, the approach may depend upon:

• the size and complexity of different projects/assignments;

• the experience of the business analysts and the levels of support required;

• the need for increased responsibility for more senior business analyst roles.

Table 9.4 Example comparison of business analyst resource requests

Table 9.5 Criteria impacting business analyst resourcing decisions

Criteria	Key questions
Priority	Is this an organisational priority? How do we know the level of priority?
Risk/impact	What would be the impact of not supporting the request? Is this a high-risk project or assignment?
Relationships	Who is the customer? What would be the impact on stakeholder relationships of not supporting the request? Is the request likely to be escalated? Does this request present a new area or new opportunity for the BA Service?
Clarity	Is the request clear? Is the business analyst role understood? Is this within the scope of the BA service portfolio? Does the requester know what is needed? Does the BA Service have the opportunity to influence?
Lateral thinking	Who else could do the work required? Are there options to fulfil the request in a different way? What alternatives or compromises could be suggested?
Business knowledge	Is it appropriate to assign a business analyst with existing knowledge and experience of this area? Do any of the business analysts need to build knowledge in this area?
Development needs and preferences	What skills and knowledge are required? (Business knowledge or business analysis skill set?) Do any of the business analysts need to develop skills in this area? Do any business analysts have a preference or aptitude for working in this area?

Four possible models for business analyst deployment are shown in Figure 9.2. The concept of a ‘project’ is used to illustrate any piece of business analysis work, which includes projects, assignments, programmes, teams, business areas or work packages.

Model D is most likely to occur where there are specialist skills or knowledge within the BA Service that need to be shared across multiple assignments, or where there is a hierarchy of business analysts where more junior business analysts are dedicated to the project and a more experienced business analyst provides leadership or oversight across multiple projects.

There is also the possibility of a many-to-many model where a group of business analysts work on multiple projects simultaneously. This is far less common because a sufficiently large or complex project will require the input of multiple business analysts and it is usually preferable that most, if not all of them, will be dedicated to that work. The many-to-many model may be applicable in a consultancy setting where a team of business analysts work together across several projects.

Table 9.6 provides an explanation of the advantages and disadvantages of the models within Figure 9.2.

Model C probably requires the most planning and ongoing management, as it is important to consider how different areas of responsibility can be divided across the assigned business analysts. For example, where there is a large project or programme of work, it is usually possible to allocate individual business analysts to different business areas, work streams, releases or areas of functionality. The use of work packages (see Appendix 7) is critical to establish accountability and avoid the disadvantages of this model.

Figure 9.2 Business analysis resourcing models

Table 9.6 Advantages and disadvantages of business analysis resourcing models

Additional resources

Adding more business analysts is not necessarily the answer to the perceived need for additional business analysis resource. Supplementing the business analyst team without identifying or quantifying individual effort can lead to ‘social loafing’ (Karau and Williams, 1997), explained as follows:

To avoid this situation, it is important to have defined areas of responsibility, so that the contribution of an individual is visible to the team. Too many analysts operating in the same space can also lead to reduced efficiency due to duplication of effort and analysis by committee.

It is important to understand at the outset whether the existing business analyst(s) are focused on delivering business analysis services or whether they are involved in other types of work. Consideration is then required to determine if the business analysts could be reallocated or working more efficiently.

Providing additional business analysts increases the relationship complexity of the work. If only two people are engaged in delivering a piece of work, there is only one relationship to build and maintain. If there are three people, there are three relationships. However, for five people, there are ten relationships, and, where there are as many as nine people, there will be 36 individual relationships!

To determine the number of one-to-one relationships relative to the number of individuals in the group (n), the following calculation may be used:

This calculation shows the additional communication and relationship management overhead required as the number of people, and relationships, increases. This is likely to impact significantly upon the overall time available for the group to deliver the work.

Hoarding resources

Customers of the BA Service, such as project managers, product owners and delivery managers, sometimes act in the best interests of their business area, at the expense of wider organisational priorities. This is an example of the ‘just-in-case’ mindset, with statements such as:

• ‘If we release the business analyst, we might not get them back.’

• ‘We are not busy now, but what if something comes up?’

• ‘The analysis activities are complete, but there are lots of other things the business analyst could get involved in.’

These statements are indicators of ‘resource hoarding’ behaviour. It does not benefit the organisation as a whole to have skilled business analysts underutilised or inappropriately engaged. BA leaders and individual business analysts may have a role to play in negotiating project priorities versus needs of the organisation.

Assignment process

Creating a structured process for customers to be able to request business analysis support is a BA Service imperative. The process must be consistent and repeatable in order to maintain good relationships with customers. An example process is shown in Figure 9.3.

The level of formality and documentation can vary significantly. For example, the whole process could be managed as a series of conversations, so, in this case, steps 1–3 of the process in Figure 9.3 would be covered by a single phone call. At the other end of the scale, a ‘request’ may be required using a structured template that is submitted via a workflow management system with various checks and approvals.

The assignment may be on a time frame of days, months or even years, so the process must accommodate a wide range of situations. Before an assignment can be made, a recruitment may have to occur, so the process may experience significant waiting periods. Ensuring customer communication is maintained through the process is critical whatever the timespan of the process.

Figure 9.3 Business analyst assignment process

This process assumes that all business analysis resource requests progress to assignment. In reality, requests may be withdrawn, refused or fulfilled differently.

Ensuring that a planned end date is in place is helpful for customers, the business analyst and BA Service planning. Validating the end date, planning any handover and seeking feedback are important activities towards the end of the assignment.

Assignment issues

Many assignments end as planned at the expected time but often this is not the case. There are several common resourcing scenarios which may arise that the BA Service will need to address. Where possible, both business analysts and customers should be encouraged to try to address the issue directly before involving others. Often, this is not felt to be possible and a more senior representative of the BA Service may need to be involved. Some of the most typical scenarios are described in Table 9.7.

Table 9.7 Common business analyst resource management scenarios

Assignment basis: input versus output

A typical BA Service will provide business analysts on an input basis, usually a number of hours per week or a percentage of a whole-time equivalent (WTE). This is because it is easier to plan and re-charge on this basis.

It may be useful to agree with customers and business analysts that a ‘100 per cent allocation’ to an assignment is likely to include time required for other responsibilities, such as personal development, BA Service improvement commitments, line management responsibilities or peer reviewing. It may be necessary to convey some of the two-way benefits gained from these activities (such as efficiency, quality, re-use, knowledge sharing and identifying dependencies), or else to agree that the assignment equates to 100 per cent of their delivery hours; for example, these may be 80 per cent of a working week. The need for ‘service overhead time’ may need to be considered as part of the charging model.

Customers are more accepting of business analysts being assigned to service improvement activities or multiple areas of work if the agreement is based on the business analysis outputs to be completed within a pre-determined time frame, rather than being based on the time worked. This requires a level of trust that the business analyst will be able to balance competing demands and produce the agreed deliverables by the required deadline.

BUSINESS ANALYSIS PLANNING

Ensuring that appropriate analysis activities can be carried out within timescales needed by customers may feel like competing concepts to business analysts, as analysis can often be improved or provide more information if given more time. Therefore, anyone in a leadership role for the BA Service needs to champion business analysis planning and assist this process as far as possible.

Estimation and planning

Estimates for business analysis activities often emerge by working backwards from a hard deadline in order to develop a plan. A more realistic approach is to break down business analysis deliverables and activities and build up an estimate by making informed assumptions. It is common that the causes of overdue business analysis products include the fact that the plan was never realistic, or the business analyst has not agreed with the delivery timescale.

Where the BA Service is good at delivering business analysis but poor at planning, this will impact:

• the reputation of the BA Service;

• the level of customer satisfaction;

• the timely delivery of the work;

• the business analysts’ morale and motivation;

• the level of pressure business analysts experience.

Therefore, planning is vitally important to the delivery of an effective BA Service. Figure 9.4 shows the key steps in the estimating and planning process. This cycle shows the need to tailor business analysis activities and deliverables to meet the situation, deliver within constraints and learn from the process.

It is very difficult to be entirely certain about a business analysis approach before analysis has started. New information comes to light, stakeholders emerge and priorities change. Business analysts with responsibility for planning and estimating need to build and constantly refine a bank of activity estimates. These should reflect what was planned, plus details of the conditions that have affected actual delivery time.

Indicative timelines for business analysis services can be communicated to stakeholders using a ‘plus or minus’ tolerance (for example, 10 days effort, ± 2 days). Estimates and timescales may be explained using evidence-based statements such as the following:

• ‘The last three times we have produced X for a project, the average time had been Y.’

• ‘We have never delivered Z in less than three weeks, although this does not include sign-off timescales.’

Figure 9.4 Business analysis estimating and planning process

Evidence-based approaches help to build confidence and provide a starting point for a constructive negotiation with customers regarding the delivery of business analysis outputs. This also helps to manage customer expectations.

Where a business analyst has no visibility or understanding of the impact of failing to meet a deadline, they will be unlikely to achieve it. Good professional practice dictates the need for business analysts to highlight a risk that a deadline will not be met. However, a sense that a deadline is ‘moveable’ may cause business analysts to question if this may be overlooked in order to ensure that the required level of quality is achieved. In essence, they may be more concerned with producing a detailed and accurate document than one that is fit for purpose and delivered within the required time frame. It is extremely important for timescales and quality to be agreed between business analysts and customers at the earliest opportunity (see Appendix 7).

The process step of ‘Understand constraints and priorities’ must consider several viewpoints and requires a level of negotiation between different stakeholders. Potential viewpoints are shown in Table 9.8.

Table 9.8 Business analysis planning constraints and priorities

Viewpoint	Constraints and priorities
Customer	Urgent issues, areas to focus analysis effort, external commitments, budget, timescales, expectations, level of clarity on business analysis work packages needed
BA Service	BA service portfolio, standards, customer relationship, reputation, avoiding over-commitment
Business analyst	Skills and experience, development needs, capacity (other assigned work and commitments)

BA planning profiles

When projects over-run in terms of time or cost, there are two areas that require scrutiny: the way the work is being delivered and the planning of the work. In some situations, the work may be progressing at an appropriate speed, but it is the plans that are unrealistic.

The business analysis delivery process typically comes under more scrutiny than the business analysis planning process. Figure 9.5 shows a number of different planning profiles for how business analysis effort is assigned to projects and pieces of analysis work.

Many organisations take a simple approach to planning, agreeing start date, end date and WTE. This is often difficult to implement in practice, as a piece of work may take a while to get started, other stakeholders may not be readily available and prior pieces of work may be ongoing and taking up the business analysts’ time.

Even where organisations believe they are using a block planning approach (see profile A in Figure 9.5), it is often the case that profile C is actually occurring. Business analysts may feel they are in a difficult position if their ‘new’ project does not fully occupy their time and their previous project or team still requires their input, even though it is ‘supposed’ to have finished. Profile D provides a useful solution that can be discussed and shared with all customers. The business analyst draws an existing assignment to a close (‘roll-off'), in a controlled handover, and embarks on new work (‘ramp-up’), leaving a ‘gap’ so that there is sufficient capacity to contribute to BA Service improvement activities and engage in personal development opportunities.

Table 9.9 provides an explanation of the advantages and disadvantages of the profiles within Figure 9.5.

Figure 9.5 Business analysis resource profiles

Business analysts and BA leaders should use these different resource profiles to initiate conversations with customers about the best planning approach to adopt for each business analysis assignment.

Table 9.9 Advantages and disadvantages of different BA resource profiles

Defining business analysis activities and deliverables

There are often multiple valid ways that analysis for any given situation could be approached. The BA Service must provide a framework for analysis that can be tailored and scaled to provide consistency and repeatability. It is this framework that marks the step change from a number of business analysis practitioners deployed independently and using business analysis techniques as they deem appropriate, to a coherent and coordinated BA Service. This is discussed in more detail in Chapter 6.

For large, lengthy or complex business analysis assignments, it is useful to set out the approach that will be taken. This could take the format of a document, diagram, presentation, plan or structured conversation. An example is provided in Appendix 8.

Figure 9.4 offers a generic life cycle that is applicable to any of the business analysis services, including improving business processes, supporting change or defining requirements. The process does not change depending on the development methodology in use, although the mechanisms to carry out the process and the outputs of the process may be different.

In a Linear (or Waterfall) development environment, the process may result in, or contribute to, documented plans. Where the BA Service is being delivered within an Agile development environment, the process may become the structure of a conversation repeated on a daily or weekly basis and fed into sprint or release planning. In this setting it is still important to track actual versus estimates to be able to provide more accurate estimates in future.

The high-level requirements dilemma

A common issue that arises at an early stage of a project is the difference and overlap between ‘scoping’ and ‘high-level requirements’. The impact of this can be highly detrimental to the progress of the project in the following ways:

• No clear scope agreed. There are different interpretations of what the project needs to achieve.

• Limited engagement from senior stakeholders. Occurs where requirements engineering is seen as a more detailed task involving lower levels of business stakeholder.

• Lack of direction for those involved in the project.

• Unclear responsibilities for bringing clarity and facilitating consensus.

• Circular conversations between business analysts and other stakeholders. For example, stakeholders asking, ‘when will high-level requirements be ready?’, and business analysts requiring an agreed scope as the boundary of analysis, responding, ‘it depends when we can agree the scope...’.

Scoping and determining high-level requirements are not synonymous activities. Scoping may be considered primarily a planning activity, while defining the high-level requirements is an analysis activity. Neither can be done in isolation and each informs the other. It is impossible to provide a definition of ‘high-level requirements’ that is applicable in all contexts. The level of requirements must be informed by the purpose for creating them.

Requirements engineering is a route to understanding, agreeing and documenting business needs. The level of granularity needed will be influenced by a wide range of factors, most significantly the context, the objective of the project and the audience of the output.

This issue of ‘analysis versus planning’ can be demonstrated by considering a simple example.

Example: digging a hole

A group decides that a hole in the ground is needed. Each person can clearly picture the hole. This seems a simple proposition, and a couple of people are given responsibility to ‘make it happen’. Progress towards digging the hole will not be perceived until soil is moving.

Table 9.10 Analysis and planning example

In the time taken to ask and answer the questions shown in Table 9.10, the original group is starting to think ‘It’s only a hole, why is it taking so long? Work has not even started. I could have dug it myself by now.’ However, without answers to these analysis and planning questions, a hole of the wrong size will be dug in the wrong place (or perhaps a hole is not even needed!).

In this example, planning concerns resources, timescales, risks and costs; analysis focuses on drivers, purpose, options and stakeholders. The intersection of the two processes describes the features of the hole itself. When stakeholders ask for ‘high-level requirements’, they typically mean this intersection of planning and analysis and do not fully understand that both processes must be undertaken and iterated to have confidence in the answers given.

The BA Service must be clear with customers about the services it offers in relation to scoping and high-level analysis (see Chapter 2). Within the BA Service, it may be useful to define various levels of analysis that can be referred to consistently across projects and develop a bank of examples that can be used to ‘calibrate’ the level of detail. This allows a learning feedback loop to be applied such as: ‘this level of requirements was created for the purpose of X [gaining stakeholder approval/invitation to tender/ specifying a system…] and these are the types of issues we have had feedback about…’.

To address the ‘high-level requirements dilemma’, keep scoping conversations focused on business outcomes. Appropriate techniques such as a business use case model or an inception deck can act as a helpful starting point for scoping discussions.

The ‘grey area’ of project work

While there are deliverables and activities that fall clearly within the category of ‘business analysis work’, that is, within the BA Service Framework (see Chapter 2), there are some that fall outside the typical BA Service remit. For example, project management, system testing or code generation. However, there may be activities that fall into a ‘grey area’, shown in Figure 9.6, where there is uncertainty about whether or not the work falls within the business analysts’ area of responsibility.

What constitutes the grey area will depend on the level of detail specified in the portfolio offered by a particular BA Service (which may be an adaptation of the BA Service Framework) and, to some extent, on the other specialised roles that exist within the organisation, such as business architect, business change manager, user researcher, user acceptance tester, product owner and data analyst. Where these roles do not exist, some of the work that they might undertake may become the responsibility of the business analysts.

Figure 9.6 The BA Service grey area

There may be valid reasons for an individual business analyst to undertake non-standard business analysis work (grey area work). For example, it may offer the opportunity to develop new skills, to enhance existing skills or knowledge or to support the achievement of the project objectives. This needs to be a conscious decision taken by the BA Service, the business analyst and the customer (e.g. project or business stakeholders). Where this is done unconsciously, or without the agreement of all parties, a number of issues can arise, including the following:

• a lack of clarity regarding the business analyst role;

• a failure to meet expectations on all sides;

• the business analyst feeling or becoming de-skilled;

• the business analyst feeling uncertain and ill-equipped to meet the demand;

• business analysis activities that are needed do not happen;

• skill and capacity gaps are hidden;

• business analysis skills shortage may occur elsewhere.

It is important that BA leaders identify when grey area tasks are requested of the BA Service and make informed decisions about whether or not to permit these tasks to be conducted by the business analysts. The BA Service should be focused on conducting business analysis work, but a known quantity of grey area or non-BA work may be performed as long as it is recognised as such and agreed and accepted by all those involved.

Sustained demand for certain grey area work may mean that a new service should be added to the BASF or that a specialist role is now required by the organisation.

BUSINESS ANALYSIS PROCESS MANAGEMENT

Operating business analysis as a service means delivering a coherent and coordinated business analysis function. Effective management of the BA Service requires the definition and delivery of some key processes that are used to support and deliver business analysis within the organisation. The level of complexity and formality of each of these processes may vary for different organisations depending on factors such as size of the BA Service and organisation, and culture and level of maturity of the BA Service.

To ensure consistency (if applied by more than one person, or by one person infrequently) these processes need to be documented in some form. Where only one person is carrying out the process for the whole BA Service, consistency is not necessarily the key driver – knowledge management and succession planning may be more relevant. The maturity of the BA Service would experience a significant setback if the owners for the BA Service processes were to move to another organisation or function and these processes were not documented sufficiently.

Continual service improvement is difficult to achieve or evidence if a baseline process is not available. Equally, improved ways of working do not ‘stick’ unless practitioners are able to refer to records setting out what should be done. This does not mean that business analysts have to undertake weeks or months of mapping the processes that underpin the BA Service. A pragmatic approach should be taken, which could include the steps shown in Figure 9.7.

Defining a lower level of detail for the more complex or contentious processes could involve documenting the process in a number of different ways, such as business process models, task descriptions and SIPOC models. The creation of these models would provide several benefits for the BA Service by providing:

• the opportunity to standardise and agree processes within the BA Service;

• a basis for training and future reference for new business analysts;

• a backlog of service improvement work that can be undertaken during periods when there are business analysis resources available;

• the opportunity for business analysts to practice creating unfamiliar models in a low-risk context;

• the opportunity for business analysts to be subject matter experts for a process modelling assignment and thereby gain insight into the customer perspective.

Figure 9.7 Business analysis process inventory approach

A process inventory for the BA Service will also help to identify where the processes need enhancement or refinement, providing a basis for continual improvement of the BA Service (see Chapter 12).

Knowledge management for the BA Service

Knowledge management (KM) is not simply a repository of information, it also requires the creation of opportunities, forums and networks that will allow knowledge to be shared and discussed. It necessitates the development of a culture that encourages knowledge sharing, re-use and the adoption of new knowledge. BA leaders are responsible for the following actions:

• encourage an environment and culture where knowledge sharing is valued;

• establish and encourage events, networks and forums that allow knowledge to be shared;

• provide the necessary mechanisms to underpin knowledge management.

Support or guidance is required for knowledge to be captured, shared and used by others. Business analysts need access to knowledge relating to business analysis, their specific area of work and their organisation/sector. Therefore, a variety of different networks, forums and KM systems may be required to provide the necessary infrastructure.

The business analysis KM cycle is shown in Figure 9.8. This cycle emphasises the continuous nature of knowledge management and the stages that are necessary for the BA Service to obtain benefit from the knowledge.

Figure 9.8 Business analysis knowledge management cycle

The purpose of the business analysis knowledge management cycle is to:

• avoid business analysts and stakeholders wasting time re-discovering things that are already known;

• reduce the risk of loss of knowledge from the BA Service and organisation;

• promote the generation of new information and knowledge to provide organisational efficiency, innovation and competitive advantage;

• reduce unintended consequences of change;

• ensure that information can be appropriately accessed in a timely way;

• reduce the risk of business analysts becoming SMEs and not being able to move away from an assignment.

The stages of the business analysis knowledge management cycle are described in Table 9.11.

Risk and issue management

All services face risks and must manage issues. The BA Service should take a structured but proportionate approach to identifying and assessing service risks. Some organisations have a corporate approach to risk management across services and change initiatives, where risks are aggregated, reported on and managed at several levels within the organisation. Where a wider corporate approach is not available, the BA Service must consider, document and manage key risks that could impact the delivery of the BA Service and then take appropriate action (see Appendix 13).

Table 9.11 Business analysis knowledge management cycle stages

Cycle stage	Stage description
Collect	Research and obtain information from different sources Assess, analyse and transform the information
Use	Apply the information to the BA Service activities; this is the primary purpose for which the information has been collected
Store	Apply clear organising principles to ensure effective storage and the ability to search for information quickly Business analysts should be encouraged to use the KM store as the starting point, then add to and enhance as necessary
Share	Disseminate, present and guide others on the use of the information in order to genuinely share knowledge
Enhance	Add, extend, enhance and refine the existing information
Maintain	Keep KM assets up to date. This can be challenging, so triage the KM assets by applying three categories: 1. A small sub-set of the knowledge assets that will be actively updated 2. The assets that will be reviewed at suitable time intervals 3. The assets that should be verified before use, as they will not be actively maintained BA Service knowledge assets that should be actively maintained (so are in category 1) include glossaries and lists of acronyms, organisational charts, project summary information, business rules and key contacts

There are several reasons for creating and maintaining a BA Service risk assessment. This document:

• provides the opportunity to consider both challenges and opportunities;

• allows the BA Service to be proactive rather than reactive;

• ensures that a plan exists to provide a quicker response to risks that materialise;

• supports the case for additional BA Service funding.

The POPIT^TM model provides a framework for a holistic assessment of risks. Many of the potential risks faced by the BA Service will relate to the ‘People’ element, including loss of key members of staff, lack of progression opportunity or significant changes in demand for business analysts.

Simply identifying and logging risks serves no real purpose. For risk management to be of benefit to the BA Service, actions must be taken to evaluate each risk, identify counter-measures that will address the risk and to create a plan setting out actions to take if the risk becomes an issue. In a large BA Service, there may also be complex or persisting issues, which would point to the need for structured documentation and management of issues in a similar way. For a small BA Service, issues are often managed less formally than risks.

Financial management for the BA Service

The BA Service provides a service portfolio that is delivered through the skills held by people. While the major part of the BA Service budget will relate to staff costs, the total budget needed to deliver the BA Service will need to cover more than the aggregated salaries of those delivering business analysis. Areas that the budget should encompass are:

• ongoing overheads such as management and administration costs;

• irregular but ongoing costs such as recruitment;

• training and development;

• travel and expenses;

• internal event costs;

• equipment such as laptops, phones and tablets, as business analysts may be more mobile than other business areas;

• specialist software, including licences;

• materials, as business analysts may require a larger range and volume of stationery than other areas of the business.

Anyone in a leading role within a BA Service needs to have financial management skills such as budgetary forecasting, tracking, baselining and reporting. A key financial management area concerns the charging model applied for the BA Service, which concerns the costs of delivering the BA Service. Organisations often have multiple charging models in place. For example, an HR department may be ‘top-sliced’, so that all departments pay for an element of the HR service operating costs based on the number of employees in each department; a business change function may be project-funded, and will only work on projects or initiatives that provide specific and agreed funding for the staff. Table 9.12 discusses the various charging models used when delivering the BA Service.

Where the costs of business analysts are split over a number of budgets (for example, across different areas of the business or different projects), it is still necessary to understand the full cost of delivering the Service and ensure that the non-salary costs are quantified. The ability of the Service to develop and provide the maximum benefit to the organisation will be significantly hampered if it constantly runs up against costs that have fallen through the gaps in budget planning.

The BA Service operates as an internal consultancy to the other areas of the business within some organisations. In these situations, re-charge mechanisms need to be clearly defined and understood, or the cost of the Service must be ‘top-sliced’ as a centrally provided capability. It is also possible to run a mixed model, where some customers can access the service for ‘free’ and others explicitly pay for the service. In this model the approach to how work will be allocated and prioritised must be clearly defined, particularly if there is a shortage of business analyst availability.

Table 9.12 Common charging models

Charging model	Description
Re-charge	The BA Service must (at least) cover its own costs by charging customers for the Service This model may use hourly rate, daily rate or fixed pricing. This may require a mechanism to track time allocated so that it may be invoiced or re-charged accordingly
Top-slice	All potential (internal) customers of the Service share the cost of the BA Service; this may be based on the relative size of the customer divisions or teams
Centrally funded	The BA Service is provided as a central function, costs are met by the organisation or a sub-function, and no re-charging occurs This approach may require a clear prioritisation mechanism, as there is no concept of ‘having the budget’ to access business analyst resources, which would typically limit the usage
Project-funded	Business analysts are recruited or assigned to specific projects or business areas, each of which meets all of the attendant costs This approach can leave a gap relating to overheads and non-salary costs, unless they are factored into the project costs
Mixed models	There are various ways of operating mixed models: 1. Certain internal customers have access to business analysis services, others will be re-charged 2. Certain business analysis services are provided from central funds, additional services will be re-charged 3. Individual business analysts are directly funded by projects/business areas, but management and service overheads are centrally funded

CONCLUSION

The BA Service may be considered an internal consultancy service that operates within an organisation. This perspective requires the BA Service to apply a professional consultancy life cycle when engaging with the organisation. The consultancy life cycle includes the phases of service delivery but also recognises the need for the BA Service to ‘gain entry’ to business change initiatives and to disengage from assignments.

This chapter has identified a number of key processes that need to be in place to ensure that the BA Service is run in an effective and efficient way. These processes concern the management of the demand for business analysis services, the approaches to planning and estimating the delivery of these services, and the processes for managing BA Service knowledge sharing, service delivery risks and finances. Each of these processes must be defined, applied consistently and subject to continual improvement. These key processes do not stand alone, but are interrelated, and the BA leader has the responsibility for managing any overlaps and dependencies.

Fulfilling the operational responsibilities of the BA Service can be time-consuming and requires generic management skills. However, business analysis principles and techniques are invaluable to BA leaders as they offer novel ways to consider how best to manage and operate the BA Service.

CASE STUDY 7: OPERATING A LARGE-SCALE BA SERVICE

Jamie Toyne, Department of Work and Pensions (DWP)

With over 300 BAs across the organisation, the DWP has focused on building a shared understanding of business analysis and demonstrating the value the role can offer. There are six hubs spread across the UK, so building a sense of both professional identity and local community has been extremely important. Jamie Toyne is the Head of Role for Business Analysis within DWP and works alongside a number of lead and senior business analysts to deliver an effective BA Service for a wide range of digital services being developed for use by UK citizens.

With a large number of people and activities to keep track of, tools are used to understand what BAs are doing and the dates they may become available for future work. Jamie noted, ‘We do use tools to support us, but conversations are much better for really getting information, identifying development opportunities and understanding what is happening for a particular development team. The tools are a way of recording conversations, not driving them.’ It is useful to get the perspectives from both the business analyst and service or product lead, as there are sometimes different views on what business analysis work is still needed and these conversations provide the opportunity to bring clarity and gain agreement.

A key part of operating the service is negotiating with stakeholders about the business analysis activities that are required, what proportion of a business analyst’s time is needed, opportunities and development needs and whether it is even a business analyst role at all! BA leaders must be advocates for the profession – as Jamie put it: ‘promoting what BAs are (and what they aren’t!)’. Building relationships with stakeholders and business analysts is critical, making sure that BA leaders don’t hide behind their inboxes, but regularly speak to people, listen to ideas and hear concerns first hand. Operating at scale means a single leader cannot know every individual well. Jamie said: ‘Make sure you have the right structure around you, you can’t know everyone, and have all the conversations yourself.’

Not every business analyst is a good fit for every piece of work. Some of the services being developed require specialist skills, or a higher level of experience. Some require only a sub-set of BA skills and techniques, which for some BAs provides a great opportunity to practice those techniques; for others, this might be too repetitive and might not give them the chance to develop. Some development teams are very supportive of rotating BAs, giving people the opportunity to use their professional BA toolkit and to avoid becoming SMEs on a particular product or service.

The DWP uses local BA Communities of Practice to share and develop best practice. They have found that when launching a new community or initiative, it pays to practice what they preach: ‘Be iterative – fail fast and learn fast, apply the same techniques we use as a BA to our own areas, such as building the community.’