On Management: The Business Analyst's Role

In my previous article I looked at the role of Product Manager [ Kelly09 ] . Usually this role only exists inside software product companies, that is, companies which produce software products which customers buy. But, as we saw in a previous article there are two other types of software development organization that need to be considered.

Inside corporate IT departments - which create software for the corporation's own use - and external service providers (ESPs, companies which write bespoke software for a specific customers) someone must still decide what is required. Even if requirements documents are not written there needs to be someone who decides what should be included in the software, what should not be included and what priorities should be assigned.

In such organizations this is the role of the Business Analyst, or BA. While the BA role has similar responsibilities towards the development team as a Product Manager the role is very different and requires different skills and experience.

Scrum - and other Agile methods - have a Product Owner role. This title describes a role in the method. In general Product Owner can be considered an alias for either a Product Manager or Business Analyst.

Difference between Product Managers and Business Analysts

The main difference between Product Managers and BAs is that the latter is inward facing. They look inside the company, they look at processes and practices inside a single company and how these can be improved through the use of software technology. In contrast Product Managers are outward facing, they look at the market and at multiple independent customers.

The second difference between the two roles is that BAs perform work in support of another. Somewhere in the organization there is someone - or some group - who wants different systems. Those systems will enable to the organization to reduce costs, improve service, or bring a new product to market. However, BAs are a supporting role, they are proxy customers for those who want to see the change happen.

Product Managers are usually responsible to someone else in the organization but they play the role of informed customer. For BAs the ultimate customer is the person whose budget pays for the IT work and/or receives the benefit of the work. If they had the time and skills they could take on the role themselves - after all, they are the ultimate owner.

In a small organization such a person may be able to play the Product Owner/BA role but as the organization grows they will find demands on their time prevent them from filling the role adequately. This is the time when a proxy customer should be introduced: someone who has the time and skills to fill the role properly.

Lesson 1: Product Owners need to give time to the role. Development teams need time from the Product Owner, and the Product Owner needs time to understand the issues.

Multiple hats

While the Product Manager role is often overlooked, the BA role is often misunderstood. This is because under the title of Business Analyst there are many different types of BA. Some of these roles carry the BA title erroneously; things would be simplified if some BAs were given the title 'System Analyst' or 'Assistant Product Manager'.

BAs may be called upon to fill a number of difference jobs all under the one job title. So an individual BA may on one project work as an internal consultant to help invent a solution. The next project may be somewhat simpler and only need the BA to capture requirements. Later in the same project the same BA would be well placed to help with the testing of the final software.

There is debate within the BA community itself as to the proper role for analysts. Therefore it is important not to look on the role either too narrowly or to assume that all BAs work the same way.

One definition of core BA role states:

An internal consultancy role that has the responsibility for investigating business systems, identifying options for improving business systems and bridging the needs of the business with the use of IT.

In order to better understand the BA role it helps to first understand the different ways in which the title is used (and abused).

Non-IT Business Analyst

These Analysts have nothing to do with IT. They analyse businesses, business trends, markets, competitors and anything else that is connected with commerce and helps their employer. But they don't do it in order to create or change IT systems.

There is nothing wrong with this type of BA, it is just necessary to point out that not everyone with the title Business Analyst is concerned with IT systems.

Business Analyst as Systems Analyst or Software Designer

Before Business Analysts became a common in IT departments it was normal to find Systems Analysts. These analysts perform a similar function - deciding what should be in the system and what should not - but they focused on the computer system not the business. (Many Business Analyst are actually titled as Business Systems Analyst but for brevity the middle word gets dropped.)

This type of analysis creates a technology focus for work which should be business focused. Delivering a faster, better computer system should not be the objective. Satisfying a business need - which might mean a faster better computer system - should be.

Lesson 2: Business Analysis is not System Analysis. If a company really needs a System Analyst then they should appoint one. (It should first explain to itself why the system analysis cannot be undertaken by the development team or and Architect.)

Some BAs, and Systems Analysts, are expected to take a role in designing the software. This is a misuse of the BA role. The BA role needs to focus on the business; software design should be left to the specialists.

Usually BAs do not have the skills to design software. In asking them to do so 'the business' may believe it is more likely to get what it wants from development teams. The net effect is to move some of the design activity from those who are best placed to do it to those who are less able.

Lesson 3: BAs should not design software. BAs should confine their role to analysis and determining what the business needs from the software and systems.

A BA who undertakes specification from a systems point of view, or undertakes system design is neglecting their true responsibility. When systems analysis is needed it is either the team as a whole or of a designated Architect who should undertake the work. Similarly software design is not the responsibility of the BA, it is either a responsibility on the whole team or on a designated Architect.

By concentrating on the business need the BA provides the team with room to create a solution. The more a BA specifies system constraints, or design details, the greater the restriction on the team. When this happens requirements contain design constraints.

Business Analyst as Product Manager

In some companies Product Managers exist, they fulfil the type of external analysis described in the previous article but they bear the title Business Analyst. This may be because the company has its origins in corporate IT - perhaps it was spun out of a corporate IT department.

Lesson 4: Some BAs are Product Managers with incorrect titles.

Occasionally companies that have both Product Managers and Business Analysts. Usually the BA is not really filling a BA role, they are a Junior Product Manager or they are a System Analyst. But occasionally it makes sense.

As we noted before there is a lot of work for a Product Manager to do. One way of reducing the work load is to appoint specialists to help them in some way. In these cases a BA works as an assistant to the Product Manager on some specific aspect of the product.

For example, a BA may pick up the competitor monitoring work from the Product Manager. The BA will able to spend more time monitoring, investigating and analysing the competition then feed this information to Product Manager.

Lesson 5: Some BAs are Assistants to Product Managers.

Business Analyst as Subject Matter Expert

It is possible to work in IT and yet know little about the application domain under development. For example, a Java developer may use their knowledge of Java programming for a bank, or an oil company, or for a telecoms company. A Project Manager may manage projects at an oil company one month and at an airline the next. While it helps with have domain knowledge it is often not essential. Skills like Java programming and project management are transferable.

Complex domains need individuals who have in depth understanding. Banks need banking experts; telecoms companies need communication experts, etc. etc. For these individuals skills such as coding are secondary to their knowledge of the domain. Such people are often known as Subject Matter Experts.

Lesson 6: Some BAs are Subject Matter Experts, their knowledge is more important in understanding what needs to be done than actual analysis.

Since the Business Analyst role entails understanding and describing organizations and technical domains Subject Matter Experts (SMEs) may gravitate to this title.

Yet it is not a foregone conclusion that a BA needs to be an expert in the domain to perform their role. Indeed, being an expert in current practices may blind one to opportunities for change. Starting an analysis assignment with an open mind, or blank sheet of paper, may be advantageous.

Lesson 7: The core BA skill is analysis: the ability to analyse, to understand a domain and a problem, then to communicate what needs to be done to change it. Therefore, it is not essential for a BA to have extensive domain experience.

Lesson 8: Some BAs are Subject Matter Experts and can fill their role because of deep knowledge. Other BAs are experts in analysis and fresh thinking; they can fill their role because of clear thinking.

The Business Analyst role

In the IT context a BA is someone concerned with information systems for business applications. The role is IT centric and extends beyond the pure technology system to include the processes and practices of people who use the system. As such it may also cover change management.

BAs are concerned with the analysis of systems, processes, practices and operations within an organization. They are tasked with understanding these things and proposing changes. But they are not tasked with designing those changes in detail.

In understanding these systems, and suggesting changes the BA is expected to take into account the overall business objectives and direction. It is unlikely the BA will have responsibility for revenue or cost saving but they will need to include these in their analysis.

As with the Product Manager the BA role entails requirements discovery. That is, enquiring and analysing the application domain to uncover the requirements of a technology system to improve the domain. Although it is likely the Product Manager will be far closer financial targets. Senior Product Managers may even have responsibility for meeting financial or other targets.

Sometimes the BA role is one of collecting business needs in order to communicate the needs to those responsible for technology solutions. On other occasions the BA acts as an internal consultant, helping the business understand what is possible and envisaging a different way of working by using technology.

Lesson 9: When a business knows what it wants the BA will collect the needs and communicate them to the technology providers. When a business is less clear on what is needed the BA will work as a consultant to analyse the problem and envisage a solution.

Given the variety of work expected of BAs finding a definition of the role is problematic. The authors who supplied the definition of BA work above [ Paul06 ] noted this variety too:

Although there are different role definitions, depending on the organization, there does seem to be an area of common ground where most business analysts work. ...to investigate business systems ...

(Paul and Yates 2006)

Product Owner role and the team

As already noted, in the Agile teams - and particularly for teams following Scrum - it has become common to talk of a Product Owner. Yet outside of the description of the Agile process these methods say little about what the Product Owner does. Or rather, vanilla-Scrum and vanilla-XP only describe what the role does in the process.

Outside of the time the Product Owner spends in the Scrum process they need to use their time to support the process so they can speak from a position of knowledge. To do this the Product Owner needs the skills of a Product Manager or Business Analyst.

For the development team it matters little whether the Product Owner is a BA or Product Manager, the role is the same. The Product Owner decides what goes into a product, in what order and approves what is created. (To put it in technical terms, both BAs and Product Managers are implementations of the Product Owner role.) However there is a big difference in how BAs and Product Managers fill this role.

Lesson 10: A Scrum (and other Agile methods) Product Owner should normally be a Product Manager or a Business Analyst. In general, the title Product Owner can be considered an alias for Product Manager or Business Analyst.

On rare occasions the Product Owner may be from another background. They might, XP-style, be an actual customer. Or, for product which is technical facing the Product Owner may come from a technical background. For example, a Scrum team developing display drivers may have a video engineer as a Product Owner. However before accepting a technician as Product Owner look for alternatives first.

Just to complicate matters, and having spent this and the previous article sketching the two different roles the world is changing. Once up on a time the difference between a product company employing Product Managers and a corporate IT department employing BAs was clear. Now however the two are merging.

Consider for example an imaginary package travel company. Prior to the year 2000 all package holidays were sold via travel agents or over the telephone. IT systems existed to track customers, manage inventory, handle administration and so on. These were for internal use only so it made sense to use BAs for analysis.

Starting in 2000 the company has increasingly sold holidays over the web. The number of agent bookings has declined, retail stores have been closed but online bookings have soared. The web systems which handle these bookings are extensions to existing internal systems. To the end customer this internal/external difference is meaningless. Part of the holiday experience is the booking process.

In such a situation it is not clear whether the company should use BAs or Product Managers. To use BAs may neglect the customer experience side, while to use Product Managers may neglect the internal aspects. A mix of skill sets is required.

Lesson 11: Product Owners increasingly need a mix of Business Analyst and Product Manager skills.

Product Manager, Project Manager or Business Analyst?

As if the confusion between BA, Product Manager and Product Owner were not enough there is a third role which is sometimes added to the mix: the Project Manager.

Like Business Analyst the Project Manager role is somewhat ill-defined and quite elastic. The standard text for the PRINCE 2 method (a popular project management technique in the UK) does not define the role of Project Manager [ TSO05 ] .

As a rule-of-thumb BAs and Product Managers are concerned with the 'what' of a development while Project Managers are concerned with the 'when'. Beyond this different organizations slice-and-dice responsibilities differently.

While PRINCE 2 contains processes to ensure the 'what' and 'why' are defined (in the business case) it is silent on who should create these documents. Neither is there any guidance on how to create a business case or what skills are required to write one. This is because writing a business case is not a project manager's responsibility.

Lesson 12: Project Managers are not Product Owners, neither are they Business Analysts or Product Managers. Project Managers have different training, different objectives and often different experiences.

To complicate matters further, some companies use the title Architect for Product Managers. At the end of the day it is better to look at what individuals actually do rather than their title when trying to understand roles.

Finally

Hopefully this article and the previous one have gone some way to clarifying and disentangling the roles of Product Manager and Business Analyst. Along the way I hope to have convinced you that the Product Owner role is important - whether it is filled by a Product Manager or BA - and that there is more to it than meet the eye. Consequently it should be clear that these are not roles developers can do in their spare time.

References

[Kelly09] Kelly, A. 2009. 'The Product Manager role' ACCU Overload (90).

[Paul06] Paul, Debra and Yates, Donald. 2006. Business Analysis. Swindon: British Computer Society.

[TSO05] Commerce, Office of Government. 2005. Managing Successful Projects with PRINCE2. Fourth Edition. London: TSO (The Stationary Office).