What is business analysis?

... and why do I need a Business Analyst to help?

Any project is fundamentally to do with change. Whether it involves digital transformation or is just about changing the way that business processes are done, it always entails two basic things: finding out what is needed; and developing a solution that delivers it.

The job of the Business Analyst is to make sure that these two things match each other – in other words, that you get what you need at the end of the project.

This may sound easy, but it rarely is. This is because there are so many things that can go wrong during the course of the project to derail this crucial alignment between needs and delivery. In this article I talk about what these things are, how a Business Analyst combats them, and what that means for your project in the end.

Reading time: 8 minutes

What does a Business Analyst do?

Business analysis is a broad area of work which encompasses many things, including assessing business needs and requirements, managing scope creep, collaboration with stakeholders, procurement development and implementation support.

Those activities are ones that I have found to be key.

Business needs, or requirements analysis

You can’t answer the question of whether the solution satisfies the business needs if you don’t know what the needs are in the first place, and this is usually an early job of a Business Analyst – to understand and document where you want to get to in the end.

This doesn’t mean producing a big, unwieldy document, but it does mean agreeing fundamental objectives with the stakeholders. It also means working with the business throughout the project, because solution development is iterative and requirements will always evolve.

If this isn’t done, there can often be critical requirements which are simply not known about by the solution designers. If these are left to the later part of the project, they can cause extensive re-work, or even the failure of the project.

Scope creep

The requirements or user stories that are used in the design of the solution must be those that deliver the expected benefits and that are traceable back to the needs and aims of the project. A Business Analyst ensures that as user stories accumulate, they are agreed by stakeholders and they support the project objectives.

If rogue requirements find their way into the design, they may mean project overspend or cause unforeseen problems.

Collaboration between stakeholders

If a project is important to an organisation, there is bound to be disagreement among stakeholders about details. A key job of the Business Analyst is to identify all the stakeholders and help them to work together collaboratively, resolving conflicts and supporting them to reach a solution.

If there isn’t a Business Analyst working actively in this role then stakeholders can often get left out of the process, especially if they are outspoken, and business areas become alienated from the project. This may have disastrous consequences when it comes to implementation.

Procurement and development

Whether your project involves bought-in software or applications developed in-house, there needs to be someone with a good understanding of both the business requirements and the technical landscape to steer it through the pitfalls of solution development. The Business Analyst, who has been working closely with all sets of stakeholders, is best placed to do this.

Without a skilled person navigating at this stage, organisations often purchase inappropriate software, cannot manage suppliers effectively, or fail to control the process of code development.

Implementation support

The Business Analyst should be closely involved in the detail of implementation because they have the in-depth knowledge of what is needed, and why, in each business area. They are able to spot areas of weakness, such as insufficient training or poor help screens, where there is a risk of the business objectives not being met.

Many projects founder at the implementation stage, and it’s often because the Business Analyst is called away to do requirements for another project. Without that overall knowledge of critical requirements and needs, the implementation can become a box-ticking exercise where things look good but are failing beneath the surface.

It’s also very common for IT projects to go ahead and be entirely delivered without the use of a professional Business Analyst. As a result the business analysis activities are not carried out properly, or skipped completely. That’s one of the key reasons why IT projects fail more than they succeed.

If your project is on bumpy grounds, use our IT Project Healthcheck tool to find out why and how to address it.

Business analysis tools and techniques

There are many tools that have been developed over the years to support business analysis, and I list a few that I have found most useful. A key point is that each tool is rarely useful on all projects – a good Business Analyst chooses the most appropriate tool for the circumstances.

Some of these are techniques that require a level of skill, and others are little more than mnemonics to help remember what to think about. I’ve divided them broadly into their functional areas.

Stakeholder management

Stakeholder spreadsheet

This is a key document which holds a list of all the stakeholders and information about them, such as their business area, their level of seniority, and which workshops they have attended. I use this on a daily basis on all projects.

Power/interest grid

This maps the position of stakeholders on a 4-part grid showing power and interest in the project. This is useful on projects where the stakeholder landscape is complicated and there are competing factions.

It is also key to the development of the communication strategy and plan, with each category of stakeholders often requiring different channels, methods, frequency and tools to communicate effectively.

Strategic thinking

SWOT

This is a technique for analysing almost anything, but I find it’s most useful at the strategic level when looking at the current situation and thinking about how to move forward.

It stands for Strengths, Weaknesses, Opportunities and Threats. Strengths and weaknesses are generally internal to the business; opportunities and threats external.

When developing your strategies (whether for the whole business, your department or the digital transformation strategy), you should aim to capitalise on the strengths and opportunities; improve on the weaknesses or even turn them into strengths; and deal with the threats as part of your risk management approach.

Remember however that strengths and weaknesses are in relation to another party (generally competitors). For example, you may have excellent customer service, but if everyone else in your field also offers excellent customer service, this isn’t one of your strengths.

PESTLE

A mnemonic reminding you to think about different factors when looking at a business area or programme of work: Political, Economic, Social, Technological, Legal and Environmental. Using the technique means you spend time considering each of these in the depth appropriate for the situation.

PESTLE is a particularly useful tool when used as part of a SWOT analysis, to help identify the opportunities and threats external to the organisation.

SPOLIAT

This mnemonic helps ensure you’ve considered all the areas of the organisation that a project might impact.

Many projects concentrate on the applications and technology side, when there may be impacts or potential benefits in other areas too. For each area in the list, look at how it works in your organisation, and what effect the project may have – thinking about what pitfalls need to be avoided and about what opportunities for improvement the project might present.

A good mnemonic to use right from the start of a project and throughout to ensure you’ve covered everything.

Business processes

Business process mapping

Sooner or later, on any project, you will have to do some analysis of business processes, and putting them in visual form will be part of it. Diagrams come in hundreds of different flavours and there are lots of tools on the market. I tend to use Visio because it’s very flexible, but there are many good ones.

But beware – diagrams do need to be good quality – a poor diagram is simply confusing, and usually worse than nothing at all.

Use case modelling

Use cases describe, in visual and textual form, pieces of functionality. They are intended to be clear to both business and technical people, and they are part of the toolkit to span that crucial gap.

The detail

Entity Relationship Diagrams (ERD)

This is a visual picture describing the ‘things’ in a process, such as people, pieces of information, or objects, and showing their relationships to each other.

It can be used at all levels of technical design, but it is useful to the business analyst when the elements of the process are complicated and it’s hard to work out how they relate to each other. I often use this when looking at reporting requirements, because it helps in understanding which reports are straightforward and which would be harder to produce.

There are a number of different notations, but the ‘Crow’s Foot’ (shown) and UML notation are probably the most popular.

Note: Vertabelo have a good guide on the different types of notations if you’re interested to find out more on this topic.

Gap analysis

This is a catch-all term for working out the difference between where you are and where you want to be. The result is often the basis for a programme or project.

Techniques for doing business analysis

Interviews

I use one-to-one or one-to-two interviews extensively at the beginning of a project to understand and engage with stakeholders. They are useful throughout whenever you need to get information from specific people.

Workshops

These are a crucial tool of the business analysis, and workshop facilitation is a key skill. Workshops enable collaboration between everyone involved on the project. When people are asked to consider matters such as requirements or detailed design as a group, then they key off the comments of each other, and come up with ideas that they would never have imagined in isolation. Workshops are also a key part of agile development.

Brainstorming

This is a way of encouraging creative thinking in people, and is extremely valuable if done well. To get useful results, it needs to be followed up effectively so that ideas discovered during the session are made use of in subsequent solution design. It can become a waste of time if not managed well.

Key takeaways

In this article, I’ve covered what business analysis is and why you need a Business Analyst role within your organisation. Let’s recap and leave you with the key takeaways.

Any project is fundamentally about change. Whether it involves digital transformation or is just about changing the way that business processes are done, it always entails finding out what is needed; and developing a solution that delivers it.
A Business Analyst’s activities include assessing business needs/requirements, managing scope creep, collaborating with stakeholders, procurement development and providing implementation support.
There are many tools and techniques that can support business analysis— Stakeholder spreadsheets, power/interest grid, SWOT, PESTLE, SPOLIAT as well as tools and techniques for business processes.
Business analysis should be conducted using various methods including interviews, workshops and brainstorming.

At Digital Octopii, we use business analysts alongside project managers, or project managers with business analysis skills, throughout all phases of a project, for all types of IT projects.

Gillian Metheringham

Gillian has been a Senior Business Analyst and Project Manager for many years in organisations of all sizes. She started in the IT industry as a young programmer working in California, and then spent some years in Seattle as a business analyst in the banking sector.

When she came back to England to start a family, she stayed in the commercial area for some years and then moved on to the varied environment of a large public authority. She has now been consulting for nearly a decade, where she has experienced a wide range of projects in sectors from the construction industry to medical charities.