This chapter covers the following topics:

INTRODUCTION

Effective business analysis requires ongoing engagement with stakeholders across a range of roles and disciplines. This requirement is likely to apply irrespective of the characteristics of the project and the approach to be taken to the work. However, the adoption of agile places particular demands upon both analysts and stakeholders because of the collaborative and iterative approach to the development and delivery of solutions. In this chapter we discuss the different categories of stakeholders and explore the engagement between the business analyst, stakeholders and customers. In addition, we introduce the concept of the T-shaped professional.

THE NATURE OF STAKEHOLDERS

Working with key stakeholders such as customers and understanding the roles they play is always an important aspect of any change project. These stakeholders are likely to be directly affected by new ways of working and will often have a detailed understanding of existing work practices and inherent problems. There are also stakeholders who may not be directly affected by any business changes but are involved in developing the changes or have to be consulted about them. These stakeholders often hold roles with responsibility for areas such as project governance or enterprise architecture, and may have different perspectives that will impact upon the project. Whichever the case, any business analyst working in an agile environment needs to be aware of the different groups of stakeholders and how they should be engaged with. There are three key groups to consider.

Collaborative working

The Oxford English Dictionary defines the term ‘collaborate’ as: ‘work jointly on an activity or project’. Collaborative working is a fundamental principle of the agile philosophy. However, in an agile work environment collaboration is not just about working jointly with stakeholders, it is about working towards a common goal, negotiating the conflicts that inevitably arise and achieving consensus. Constant, ongoing collaboration is to be expected as a means of ensuring that business needs are understood and incremental solutions are delivered early. Business analysts need to recognise that this approach changes the dynamic of working relationships and places additional responsibilities on analysts, project team members and other stakeholders. For example, when using a traditional linear approach it would usually be the case that customers would be invited to a workshop or an appointment would be made for an interview; when using agile, customers may need to work within the project team rather than just providing their input on request.

The business analysis skill set includes a range of interpersonal skills, such as communication facilitation and rapport building, which are invaluable for collaborating with stakeholders. Further, the holistic nature of the work encourages business analysts to have a broad skill set that includes an understanding of business and the business domain, each of which will aid the collaboration process. These skills enable business analysts to work well with stakeholders and communicate with both the business and technical representatives. While this is important for the success of any change project, it is essential on an agile project where documentation is minimised and effective communication is imperative.

Working with stakeholders

Communication and business skills are even more important where stakeholders are geographically dispersed. Many organisations operate across different countries and cultures, and, therefore, their business analysts need to be able to communicate within environments where there are constraints caused by different languages, time zones and technology. Such constraints require careful consideration and planning if they are to be managed within an agile context.

A common error is to consider a stakeholder as someone who can be slotted neatly into a job title or role and let this determine the engagement and communication approach. This overlooks the critical point that each stakeholder is an individual with their own ideas, constraints, priorities and needs. So, when working with stakeholders, business analysts need to apply an analytical approach and consider the following:

Consideration of these points will help to ensure that there will be effective working relationships with stakeholders of varying levels of seniority and with differing communication needs. The last point about understanding perspectives is particularly important. This often relates to the role and responsibilities of the stakeholder. For example, if someone is responsible for the regulatory compliance of the solution, this is where they will focus their efforts and feel the priorities lie. The range of stakeholder roles and responsibilities is described later in this chapter.

On projects using more traditional approaches, obtaining access to stakeholders is often an area of difficulty. Agile projects place responsibilities on both the organisation and the stakeholders, including requiring significant access to those working within the project team. It is also the case that the stakeholders will need to have an appreciation of the agile philosophy and the impact this will have on the working practices undertaken by projects. Successful application of agile may require business analysts to provide guidance, or even training, in the adoption of an agile mindset and approach.

Business analysis on agile projects

The types of business problems being solved by agile project teams today are not significantly different to the types of business problems that have been solved by teams using more traditional approaches. Since those teams rely heavily on sound business analysis skills to achieve success, it should be evident that agile teams also need these skills. This is especially true when agile approaches are being applied to complex, novel or high-risk change projects or projects with large amounts of user interaction.

One problem facing business analysts (and an important reason for this book) is that the value of business analysis is not as widely recognised as it should be, and many agile training courses, books, blogs and methods appear to ignore business analysis. Dig a little deeper, however, and it becomes clear that this is not always the case. Scrum is by far the most common agile method, and the Scrum Alliance (2016) guide states:

What this means is that business analysis needs to be addressed, but this doesn’t mean there must be a dedicated business analyst on the team. This is true of many published methods – just because there isn’t a dedicated role for a business analyst does not mean that business analysis skills are not needed.

In some circumstances, it may be possible for the development team to assume responsibility for business analysis, as may be the case with other specialist work. So, business analysts may be able to support areas of testing and testing specialists may be able to help with some analysis. However, there are risks associated with this approach that may result in conflicts and a failure to explore the business needs in sufficient detail. Also, the individuals performing these roles may not have the time or expertise required to understand the root causes of problems or to explore the rationale for requirements, resulting in time spent on ill-conceived ideas.

While agile recommends the formation of self-organising, multi-skilled project teams, this needs to be done with care. Where roles attempt to encompass specialisms such as business analysis and assume that specialist expertise is never required, they can become single points of failure and cause difficulties in the longer term. The concept of the T-shaped professional, discussed in the next section, can help to clarify the need for IS professionals to have both generic and specialist skills, including the interpersonal skills required to work effectively with stakeholders.

Given the importance agile attaches to strong and constant customer engagement, and a Just Enough, Just in Time approach to the project deliverables (including the requirements definition and acceptance criteria), the skills of a business analyst are critical for successful agile projects.

THE MULTI-SKILLED TEAM

The concept of the self-organising team was introduced in Chapter 4. Achieving a team that can self-organise, however, requires team members to be multi-skilled and we explore the multi-skilled team further here.

The T-shaped professional

Service Science theory underpins the service thinking approach (discussed in Chapter 3) and has popularised a concept known as the T-shaped professional. This term refers to professionals who have a suite of generic skills that supplement and enhance the specific skills required of their particular profession. The definition of a T-shaped professional from the Handbook of Service Science (Spohrer and Maglio, 2010) is as follows.

An example of a T-shaped professional profile for a business analyst is shown in Figure 7.1 below.

 

Figure 7.1 The T-shaped BA professional

Source: Spohrer and Maglio (2010)

The vertical and horizontal components of this model focus on the following aspects:

The horizontal skills

Business analysts require competence in three key areas – business, personal and technical skills – if they are to be T-shaped professionals and contribute effectively across a range of change projects. They require generalist business skills and knowledge in order to be able to communicate effectively with stakeholders from different external and internal constituencies; this includes a broad commercial awareness. They also need strong interpersonal skills to ensure that they engage with stakeholders and members of the project team. Effective collaboration requires this mix of professional and interpersonal skills.

A good understanding of the business change and solution development processes, including more technical domains such as data management, application architecture and software testing, is also necessary, for business analysts to contribute effectively when working in cross-functional agile teams.

The vertical skills

Whereas the generalist skills above are held by many IS professionals, business analysts also need to possess the specialist skills that enable them to investigate ideas and problems, and identify and help to evaluate potential solutions.

Business analysis is a specialist discipline, so business analysts need to develop and maintain an extensive professional toolkit containing many analytical techniques and frameworks. In addition to the analytical skills, business analysts also need to have an in-depth understanding of the business domain within which they work. This includes knowledge of the terminology, concepts and particular concerns of the business domain. For example, business analysts may require knowledge of relevant governance structures, or legal and regulatory matters.

Specifically for an agile business analyst, the core skills also need to include the understanding of, and the ability to apply, the agile principles and values across business analysis activities. When working on an agile project, business analysts need to have generic and specific agile skills as follows:

The T-shaped professional concept is highly relevant to today’s business world where collaborative working helps to break down traditional barriers and apply a cross-functional view of the organisation. This has been assisted by the use of thinking frameworks such as service thinking (Chapter 3). An agile mindset, coupled with a T-shaped toolkit, will help business analysts to work successfully on agile change projects and, ultimately, support organisational agility.

The generalising specialist

The concept of an agile team formed of ‘generalizing specialists’ was developed by Scott Ambler and Mark Lines (2012); and has many similarities to the T-shaped professional concept. The definition, below – provided by Ambler and Lines – states that a generalising specialist is someone who has multiple skills.

Ambler and Lines (2012) suggest that an agile development team should be formed of multi-skilled professionals. Team members should possess a cross-functional understanding of the entire solution development process, enabling them to work successfully with colleagues across the different specialist domains. They should also have at least one, but possibly more, specialist area of competence. While the detailed investigation and analysis work will be, in the main, the responsibility of the business analysts, there may be occasions when other team members are required to conduct business analysis; for example, when working alongside the business users to develop some software functionality or define business rules. There may also be business analysts working within the agile team who can perform other tasks such as supporting testing activity.

This approach helps to remove the strict role delineations that are often found during solution development and can diminish the occurrence of hand-offs and delays. Hand-offs may occur when a requirements expert hands over the completed requirements to the developer for coding, or the developer hands over the code to the tester for testing and so forth. This approach can result in a ‘silo’ mentality, whereby individuals focus on their part of the process and work towards their own personal targets; or work on low priority tasks in their own specialism despite other, high priority tasks in another specialism being incomplete. Unfortunately, this can also mean that accountability for the finished product inevitably gets lost while the team is working towards delivery. The formation of agile teams from generalising specialists is a means of overcoming this issue and enabling greater collaboration.

Adopting this approach enables agile development teams to provide the skills and experience required to develop the solution in a collaborative way. While each team member will not have a full range of the required skills, and is likely to specialise in a specific area, it does mean that they will have a sufficient grasp of other disciplines. This will improve communication, ensure that the team is better able to complete the high priority work, and enable everyone to make contributions during the development of the solution.

The business analyst in a multi-skilled team

Business analysts are well placed to work in a generalised environment because of the breadth of the role and the range of skills and knowledge they are expected to possess. When working within a relatively small project team, it is often the case that a business analyst is expected to take on an additional area of responsibility such as project management or business acceptance testing. Some business analysts may be required to review code or database structures. Similarly, other types of specialist may attend business analysis training and undertake some business analysis tasks, perhaps under the supervision or guidance of a more experienced analyst.

Figure 7.2 shows how the two concepts of the T-shaped professional and the generalising specialist may be combined to define the skill requirements of some specialists. These examples identify the types of skills and experience three different T-shaped professionals in an agile development team may need to have.

Many business analysts began their careers working in technical disciplines; this has enabled them to develop into T-shaped BA professionals. Where this is the case, individual business analysts may have the ability to support the work of other disciplines, thereby contributing to the agility of both the development team and the organisation.

 

Figure 7.2 Example of different types of T-shaped professionals in a development team

CUSTOMER CATEGORIES

It is often the case that the term ‘customer’ is used to refer to anyone who is the recipient or beneficiary of a new product or service. However, grouping customers together in this way risks overlooking different perspectives and priorities. As a result, it is important that we do not categorise customers as one group but understand the range of different customer roles, each of which has the potential to hold different perspectives and have varying business requirements. Agile techniques such as user stories and personas (see Chapter 11) help us to consider a situation from the viewpoint of a given role. Where this is a customer role, understanding the customer categories can provide insights into the different needs that are likely to exist.

Within an agile development environment, business analysts may work with many different types of customer and need to appreciate where their requirements might differ. Although some customers, such as business managers, may be relatively straightforward to identify, it is possible to overlook others. For example, project stakeholders such as solution developers or technical architects should be perceived as customers because they consume some of the artefacts delivered from the business analysis work, and can have specific needs that the project should meet (for example, training). Also, the term ‘end user’ may cover a range of different types of business customer, each of which might have differing needs to be met.

Throughout a project, we need to look at the standard roles and consider where a customer/supplier relationship exists and where we need to take into account different categories of customer, each with the potential to have a different perspective on the situation or project.

Figure 7.3 sets out six possible types of business customer, all of whom may be perceived as ‘end users’ depending upon the project context.

 

Figure 7.3 Types of business customer

The characteristics of each customer category are described below.

Employees		The people who work for the organisation and will use the new processes and systems.
Managers		The management team who set the business objectives and determine the strategy and tactics for the organisation; there may be several levels of manager.
Owners		The owners of the organisation. In a commercial organisation, the owners will expect to receive dividends from the profits; in a non-profit organisation, the owners may be trustees; in a government organisation, the owners may be politicians or senior government executives.
Partners		The intermediary customers such as partner or reseller organisations who sell (and often deliver) the organisation’s services and products to the consumer.
Purchasers		The customer who orders the products or services and ensures that payment is made, but does not ‘consume’ the purchased items. This may be a stakeholder working in a procurement capacity.
Consumers		The ‘end customer’ who receives or consumes the services and products.

Anyone working as an agile business analyst should recognise the different categories of customer. This is for two reasons:

Understanding the different types of customer and their varying priorities and perspectives will help us to recognise where there may be issues relating to the realisation of value for customers. Customer expectations exist whenever an organisation sells a service or product. While organisations often say that they deliver value, in reality value cannot be delivered – it can only be offered by an organisation. Hence the term ‘value proposition’ – the organisation proposes a service or product that is intended to offer value. Any actual value has to be realised by the customer engaging with the service or product. For example, an organisation can purchase a software package that offers extensive functionality but if the employees do not use the package, then no value will be realised.

Given that it is customers who obtain value from a delivered product or service, they need to determine whether or not something of value has been delivered. However, where a project is concerned with several different categories of customer it is important to recognise that the nature of ‘value’ may also differ. As discussed in Chapter 3, an organisation has to identify and deliver a value proposition to their customers but it is not necessarily the case that organisational and customer perceptions of value are aligned; there is the potential for value misalignment, as represented in Figure 7.4. Understanding different customer categories and their different perspectives on what constitutes 'value', will help to ensure that customer and organisation value expectations are aligned.

When working on a change project, business analysts should be concerned with investigating the value expectations of different customers in order to identify where problems may arise through misalignment. Techniques such as use cases, user stories and personas, particularly when considered at a business level, can help with analysing customers and their value expectations. Failure to do this may result in dissatisfied customers and may risk the success of the change project.

 

Figure 7.4 Organisation versus customer value perceptions

STAKEHOLDER ENGAGEMENT

Stakeholder engagement requires the identification, analysis and management of anyone involved in the project or affected by the outcomes. It also requires effective communication and rapport building to establish working relationships and, importantly, ensure they persist. Stakeholder engagement is a key area of business analysis work and is essential if there is to be collaboration on an agile project. Therefore, agile business analysts are often closely involved in engaging with stakeholders and facilitating collaborative working relationships.

There are four aspects that are necessary to support effective stakeholder engagement. 'Identify, analyse, communicate, review'. These aspects are described below.

Identify

It is important to identify who needs to be involved, their level of involvement and when they will be involved. Different stakeholders will need to be included at different times and this needs to be thought through carefully before embarking on attempts to collaborate with the stakeholders. One way of identifying stakeholders is to use a framework such as the stakeholder wheel shown in Figure 7.5.

Another means of identifying stakeholders is to break down some of these groups into four categories: external stakeholders, business/governance stakeholders, architectural stakeholders and project team stakeholders. The types of stakeholder roles within these four categories are described in detail later in this chapter.

 

Figure 7.5 Stakeholder wheel

Analyse

Once stakeholders have been identified, some thought must be given about how the engagement with the stakeholders needs to work. It is not possible to collaborate with every individual stakeholder, as there will usually be far too many of them with an interest in the project. An analysis of the individual stakeholders both at an individual (typically, for more senior stakeholders) and group level needs to be carried out at this point. An understanding of the perspectives held by the stakeholders, particularly the more influential stakeholders within the business and the roles that they are going to play in the project, is vital for the successful development of the solution. Techniques such as the power/interest grid, RACI and world view analysis (described below) are invaluable for thinking about different stakeholders and their perspectives. Analysis of personas and extreme characters (see Chapter 11) can also provide useful insights, particularly regarding customer stakeholders.

Power/interest grid

This matrix (shown in Figure 7.6) provides a means of considering the level of power wielded by a stakeholder or stakeholder group and the level of interest in the project that these stakeholders have. This helps to determine how communication and engagement with the stakeholders will be conducted.

 

Figure 7.6 Power/interest grid

RACI/RASCI		A RACI chart (which is sometimes extended to RASCI) provides a summary of the stakeholders and the way in which they will engage with the project. The choices are: R: responsible A: accountable C: consulted S: supportive (if included) I: informed Again, this provides a means of understanding the stakeholders and their responsibilities, and helps to decide how we should engage with them.
World view analysis		We often talk about ‘perspectives’ that people hold on situations or systems. World view analysis attempts to view the system under investigation from the position of an individual or group. It seeks to understand why people hold certain views or priorities by analysing their values and beliefs. A frequent – and often highly publicised – example of world view analysis occurs with regard to politicians, whereby their comments or statements are analysed and conclusions drawn about why they are taking up a particular position. However, this can also be done with stakeholders. Understanding why an individual or group holds a particular view, or has expressed certain thoughts, can be invaluable in helping to engage with stakeholders.

Communicate

Once we have some understanding about the stakeholders, it is important to think about how we will communicate and collaborate with them, and their level and frequency of involvement within the project. The power/interest grid, RACI chart and world view analysis help when considering this.

Examples of the different styles and frequency of stakeholder engagement are:

Review

Throughout any project, it is important to appreciate that stakeholder engagement is ongoing. Rapport can be built but also needs to be maintained if working relationships are to endure. It is all too easy to break rapport, for example, by ceasing communication with a stakeholder because they are no longer important to the project. Changes in views also need to be borne in mind throughout a change project. Perspectives can alter over time and a stakeholder who has perceived a requirement to be of low priority can suddenly adopt a completely different position and expect delivery of the required feature to be imminent. As a result, we need to revisit the analysis of the stakeholders regularly and consider whether positions or perspectives have changed.

When working with stakeholders on an agile project, there will be some who sit within the project team and others who represent areas external to the project. Everyone within the team will need to work closely and collaboratively with each other, including the business analysts. Where these stakeholders are customers, their views are likely to be at the forefront of the project work, so frequent, focused communication will be required.

There will be other stakeholders who are not working within the project team but still need to be on the communication radar because they have concerns and interests that the project needs to take into account. It is also the case that these concerns and interests can change as the project progresses. For example, someone who was not very engaged with the project at the outset may become more interested as the work progresses and delivery moves closer; this increasing engagement with the project is likely to result in a need for more frequent and active communication.

One final thought about stakeholder engagement. We often talk about collaboration and rapport but can find it difficult to sustain this approach, particularly when there are time pressures. The best maxim is to treat stakeholders as you would want to be treated yourself. We often talk about understanding the ‘voice of the customer’ or standing in the customers’ shoes, and it is extremely helpful to think about how the situation looks from their perspective. Failing to do this can result in assumptions being made, stakeholders being overlooked, rapport breaking and general difficulties arising for the project.

STAKEHOLDER CATEGORIES, ROLES AND PERSPECTIVES

Working on business change projects often means that business analysts are involved with a wide range of stakeholders, both internal and external to the organisation. The stakeholder wheel in Figure 7.5 identified some of the key stakeholder categories that we might investigate. However, as we have already seen, within the customer category there are many different perspectives to uncover. The ‘employee’ and ‘owner’ categories will contain a range of stakeholders and roles that are relevant to a change project. Understanding these different categories is important if we are to ensure that we don’t overlook any perspectives and are clear about the priorities for the change project.

Within an agile project, there may be fewer defined job roles and, as discussed earlier, there may be team members who have a range of skills and the ability to adopt a number of roles. However, it is still important to be aware of the different stakeholder roles and their areas of interest. Engaging carefully with stakeholders is highly relevant to agile business analysis, as it helps clarify what needs to be delivered, the business constraints to be complied with, and how the project aligns with other projects and the enterprise architecture. It should also help us to distinguish between ‘wish list’ thinking and requirements that really can address business issues and opportunities.

Understanding roles

It helps to think about the four different constituencies represented by stakeholders: the business/project governance, the architectural domains, the external environment and the development team. Within each of these constituencies there will be numerous roles that are adopted by the stakeholders. The term ‘role’ is often used on agile (and other types of) development projects and it is useful to understand what is meant by this and how the roles can change, depending upon the nature of the project.

A role can be thought of as a hat that a stakeholder takes on – however, they don’t always wear just one hat. You often hear people saying ‘I am wearing a number of hats at this meeting’ and by this they mean that they are playing, or representing, a number of different roles, with each role looking at the situation from a particular angle or viewpoint. For example, many stakeholders may have an ‘end-user’ role for a new IT system but some may also be subject-matter experts (SMEs), and one of them may have the project sponsor role for the project. The term ‘end user’ might also cover a number of roles, each of which has different characteristics and requires the delivery of different features. For example, in a payroll system, all of the employed stakeholders will have the ‘employee’ role, but some will also have the ‘line manager’ role (and authorise salary increases) and there may also be a payroll manager role, responsible for authorising all of the payments.

It is important to understand the nature of roles if we are to work successfully with stakeholders. Roles and individual stakeholders have a many-to-many relationship, as shown in Figure 7.7 below.

 

Figure 7.7 The relationship between stakeholders and roles

This means that each stakeholder may take on one or more roles and each role may be covered by one or more stakeholders. However, this doesn’t mean that all of the job titles will be represented. For example, in a Scrum agile development team, each participant – other than the Scrum master – is called a developer and there are no specialist job titles. However, the need for different roles still exists because there is specialist work to be carried out. Recognising these roles, their responsibilities and the skills required is essential if the work is to be carried out successfully. Similarly, we need to be aware of the different roles and responsibilities that are external to the project team but still impact upon the project activities.

The roles typically found within the four stakeholder constituencies are discussed below.

The business/governance perspective

Each change project has business representatives who are responsible for various aspects of the business involvement. These stakeholders provide the business viewpoint and governance. The most important roles are shown in Figure 7.8 and discussed below.

 

Figure 7.8 Business/governance roles on change projects

Project sponsor		This is the most senior governance role for the change project. The project sponsor acts as the business representative who champions the project within the business and is ultimately accountable for its success. The project sponsor has to ensure that sufficient funds and other resources are available to the project and will accept (or reject) the deliverables. As the person who commissioned the project, the project sponsor is the owner of the business case and has responsibility for the delivery of the business benefits. There should be one project sponsor who is in post for the duration of the project, providing a clear escalation route for problems and issues and setting the strategic direction.
Business managers		Business managers typically manage the staff who will use a new system and carry out new processes and procedures. However, they may be users of the system themselves in some situations. They are often owners of requirements, even if the sources were more junior staff. As a result, in addition to providing information regarding the requirements, they will have to be consulted to find out the underlying rationale. This is particularly important where there are conflicts or a lack of clarity around the requirements. For example, where two of the end users have requested opposing functional requirements or where there is uncertainty surrounding non-functional requirements.
Programme manager		Programmes comprise a series of inter-dependent change projects that, together, contribute to the achievement of business objectives. Each project may focus on a different element of the programme, for example the software development, the process changes or possibly a different workflow area. The programme manager is responsible for managing the programme, in particular the dependencies between the projects, and ensuring that the work on the projects is aligned so that the programme is delivered successfully.
Project manager		Responsible for ensuring that the project is delivered according to the defined terms of reference. These include the project objectives and the time, cost and quality constraints. The project manager also manages the agile process adopted for the project.

The architectural domains perspective

Each change project needs to align with the enterprise architecture and the sub-domains such as business, applications, data and infrastructure architecture. The stakeholders working in these areas ensure that this alignment is in place. Business analysts may have to work closely with these stakeholders, in particular the business, solution and data architects. Most projects, particularly those that have an IT or technology component, will have a number of architectural stakeholders that must be considered.

These stakeholders will often have perspectives and responsibilities that extend beyond the scope of the change project and it is important that their views are properly considered. This may mean that they provide requirements (functional and non-functional), acceptance criteria or undertake a formal approval role. It may be that the project doesn’t need to include their requirements until a later stage which could require some sensitive stakeholder management.

Architectural stakeholders will often have longer term interests and be concerned with trying to ensure that projects are future proof and can enable future developments. This can cause some conflict with agile project teams where early delivery of business benefit is important and longer term constraints can seem unnecessary. In such situations, the business analyst may be required to negotiate a path through some difficult issues by applying their stakeholder management skills. The approach to stakeholder engagement described earlier, whereby stakeholder views and responsibilities are analysed, can be very helpful when conducting this work (Figure 7.9).

 

Figure 7.9 Architectural domain roles on change projects

Business architect		The Object Management Group’s Business Architecture Specialist Interest Group (BAsig)1 defines business architecture as follows: A blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands. The business architect role is focused on ensuring a solution aligns with the business architecture blueprints for the organisation, so that the strategic objectives and tactical demands are met. The blueprint provides a representation of the structure and behaviour of a business system and covers the business capabilities, value-adding processes and the actors who conduct the work. The capabilities and processes are aligned with the business goals and business services they support, and the applications and data needed to realise them.
Solution architect/designer		The solution architect or designer is responsible for creating the design artefacts that set out the blueprint for the whole solution including business and infrastructure layers. These artefacts need to align the services provided by the solution components to the business architecture in line with the standards governed by the enterprise architecture.
Software/application architect		Where the solution involves considerable reuse and integration with existing software components and sub-systems, a software or application architect may be involved to ensure that existing services and standards are maintained.
Data architect/manager		The data architect or manager is responsible for the governance and coordination of the definition, structure, storage and movement of data that supports the information requirements of a business, especially data maintained by the software applications. Their focus should be on aspects like data quality, consistency and security.

The external perspective

Some stakeholders are not only external to the project team but to the entire organisation. Consequently, it is difficult to collaborate with some of these stakeholders and the information they offer may need to be obtained through various communication channels. For example:

It is important not to overlook these stakeholders as they can be extremely important to the success of the project and business analysts are often responsible for analysing the information these stakeholders provide. Some of the key external stakeholder roles are shown in Figure 7.10 and discussed below.

 

Figure 7.10 External stakeholder roles on change projects

Customer		This is the end customer role, typically the person paying, or representing an organisation that is paying for the product or service delivered. Customers are a complex set of stakeholders, as discussed earlier.
Supplier		The supplier provides products or services to the project or organisation. These stakeholders may be significant particularly if they are providing outsourced services or off-the-shelf software products. Where the supplier is providing bespoke products, they may themselves be operating agile delivery models, so the business analyst may be a stakeholder of the supplier team.
Competitor		Competitor organisations may not seem to be obvious stakeholders. However, a change project may need to take into account competitor strategies and actions, or may need to consider how the project may affect competitors. In some cases it is essential to think about potential responses from competitors and, in some situations, it may be desirable to collaborate with a competitor. New information about a competitor’s product could affect the project goal or change key drivers in the business case. This could require the project team to change course or, in extreme cases, to shut down.
Government/legal/regulatory bodies		These organisations are the sources for rules and regulations with which the organisation needs to comply; new or changed regulations are often the reasons for initiating change projects. No matter how embedded the agile philosophy is within an organisation, compliance with such regulations is usually mandatory and this may impact upon the approach to be adopted on projects.

The project team perspective

The project team is responsible for ensuring the requirements are elaborated and developed into product increments. Business analysts typically work within the project team, facilitating communication, analysing requirements and clarifying the business rules. They also ensure that there is alignment with business objectives and needs. While some agile approaches, such as Scrum, do not define individual job roles, it is important to recognise the skill areas of certain stakeholder roles that need to be represented within the project team. These roles are shown in Figure 7.11 and discussed below.

 

Figure 7.11 Stakeholder roles within the development team

Domain expert		The domain expert (also known as the SME) is a business person who has significant knowledge and understanding of the business domain. This knowledge is necessarily more extensive than that of the end user and often derives from having taken a senior role within the organisation or having experience across the particular industry. An example may be an individual with extensive experience and knowledge of retail business operations or taxation law. The domain expert is able to provide information about the area of business that the solution will be deployed within and is able to clarify business requirements. This role provides input to an agile project by providing information about the broader business domain, the particular business situation and any issues that can arise. The domain expert may be an employee of the company or may be an external consultant. The advantages of having an external consultant fill this role are that the consultant will be able to: • provide an objective view; • identify where local practice is not necessarily best practice; • bring ideas from other organisations operating within the business domain; • distinguish between requirements based on business need rather than tradition or assumption. Where an external consultant is performing the domain expert role issues may arise due to a lack of understanding of the organisation and the politics, power bases and culture that exist.
Customer/end user		The end-user role represents the business staff who will use a new system or work with a new product. Within an agile project, there should be representatives of the customer community working within the project team. This may be one person or could be a team of people, depending upon the size of the customer community to be represented and the complexity of the work. The end users within the project team must be empowered to make decisions on behalf of the user community.
Team leader		The team leader is responsible for ensuring that the project team is operating in a collective and collaborative manner, and is meeting its objectives successfully. This role reports progress and issues to the project manager.
Solution developer		The solution developer interprets business requirements and translates them into a deployable solution that meets the functional and non-functional requirements. The work of the developer usually entails building software components and unit (program/component) testing their work. Where the focus is on the development of the entire solution, covering processes and organisational aspects, the role may have a broader remit, possibly encompassing aspects of business analysis. In some organisations there may be a product developer role that is responsible for developing the products to be offered by the organisation. Whichever is the case, developers need to work closely with the business analyst in order to ensure that the business requirements are understood and the desired product or service is delivered. In agile systems development, the solution developer role may also encompass the role of the solution architect/designer.
Solution tester		The solution tester role is responsible for defining test cases and test scenarios that will be used to identify whether or not the solution meets the requirements. There may be different levels or types of tests such as integration testing and system testing (where an IT system has been developed as part of the solution). Business acceptance testing may also be required to ensure that the solution meets the business needs.

It is worth reiterating that agile teams may not designate specific roles. However, that does not mean that the work for which those roles are responsible is not carried out. It is part of the agile philosophy that project teams are multi-skilled and have the responsibility for the different areas of work required to develop the solution. Therefore, individuals may be called upon to support or conduct work across a range of areas. For example, if there are testing tasks to complete, a team member with a ‘developer’ job title may perform a ‘tester’ role for the duration of the testing tasks. In some cases, the whole agile team may be responsible for defining test cases and test scenarios.

CONCLUSION

Stakeholder engagement and management is vital within any project. However, this is particularly the case when using agile, given the emphasis on effective collaboration. Business change projects tend to require the involvement of a wide range of stakeholders from different constituencies; some may be internal to the project team, others may be from within the organisation but external to the project, while others may be external to the entire organisation. While business analysts should have the ability to facilitate communication and collaboration through effective stakeholder engagement, the nature of this engagement will differ depending upon the role and the level of collaboration required. To work effectively in an agile environment, business analysts need to adopt the ‘mindset’ encapsulated in the agile philosophy and principles. They also need to support stakeholders to adapt their working practices to the needs of agile projects.

Business analysts are concerned primarily with ensuring that business needs are met and value is realised for the customer. Although many agile approaches identify the need to focus on end-user customers, in reality the business customer landscape is much more complex and encompasses many different customer roles.

While some agile methods do not require the involvement of a business analyst, change projects will always need business analysis. This is indisputably the case for projects using agile, where stakeholder collaboration is key to project success.

NOTE

1 When originally established by the OMG in December 2007 it was known as the Business Architecture Working Group (BAWG).

REFERENCES

Ambler, S.W. and Lines, M. (2012) Disciplined Agile delivery. Upper Saddle River, NJ IBM Press.

Scrum Alliance (2016) Scrum alliance home page. Scrum Alliance. Available from: www.scrumalliance.org/ [20 December 2016].

FURTHER READING

Ambler, S. (2003) Agile database techniques. New York: John Wiley & Sons.

Maglio, P.P., Kieliszewski, C.A. and Spohrer, J.C. (2010) Handbook of Service Science. Service Science: research and innovations in the service economy. New York: Springer.

Paul, D., Cadle, J. and Yeates, D. (2014) Business analysis: 3rd edition. Swindon: BCS.

Spohrer J.C. and Maglio P.P. (2010) Toward a science of service systems: value and symbols. In Maglio, Paul P., Kieliszewski, Cheryl A. and Spohrer, James C. (eds). Handbook of Service Science. Service Science: research and innovations in the service economy, Part 2. New York: Springer.