The Benefits of Business Analysis

Here’s a question that often gets asked: What are the benefits of Business Analysis? The depressing but true answer is that the benefits are usually invisible: good Business Analysis ensures that the project implements the right solution, and because it is the right solution no-one ever sees all the cost, time and effort that has been avoided (a project that does not do sufficient Business Analysis has to re-work all the bugs that slipped through the ‘analysis’ stage because the analysis was never done).
Business Analysts are one of two critical roles in a project (the other being the Project Manager). These two roles determine the fate of the project – its success or failure. The Project Manager makes sure everything is in place, proceeding to schedule, on target to deliver the solution on time to budget. The Business Analyst makes sure the right project is being delivered by the Project Manager’s efforts. “Right” is defined as achieving the objectives. Without Business Analysis the project may or may not deliver anything, but it’s a certainty that anything that is delivered won’t be the right thing!
Let’s look at the top 6 reasons for project failure and consider if Business Analysts contribute to mitigating the risk of each happening. These reasons come from the Standish Group Chaos reports. Interestingly, there is now a good deal of debate on the validity of this research (e.g. but as this seems to be a list that resonates with all the roles involved in change projects we will use it as the baseline for the article.
Benefits of Business Analysis pie chart
In order to understand how Business Analysis mitigates these risks, we need to understand the role of the Business Analyst. When you look at the following diagram that scopes this role, bear in mind two points:
  1. Business Analysis is not always done by Business Analysts! This is most evident during change project creation when driver and objectives are being defined and the Project Manager may be doing the analysis.
  2. While a Business Analyst may not actually do all of the activities listed, they will need the products of all these analysis activities to do the subsequent analysis.
Benefits of Business Analysis pipe diagram

Scope of the BA diagram narrative.

Owners’ are those people who can enable a project to proceed or cancel it. They will include budget holders but almost certainly there will be other owners who may or may not be officially recognised as such but who can – if they desire – stop the project. For example, an IT Director might be one owner of a Business project involving a new system if there are IT standards which must be adhered to before a system can go live. These owners need to agree what the change project will accomplish and analysis is needed to define these objectives in terms of what the measures of success will be and – for each measure – the target value that equates to success.

Strategists’ will define an approach for achieving the objectives. Analysis is needed to ensure that the strategy is justifiable to the owners. Note that it is very common for an Owner to also be a Strategist! But not all Owners will be Strategists.

Sponsors’ will back a programme of change. A programme is defined as a collection of projects. Taken together these projects will deliver the strategy that has been agreed will achieve the objectives. Note that it is very common for an Owner to also be a Sponsor! But not all Owners will be Sponsors. Analysis will be needed to define the Terms of Reference (TOR) for the Programme: the Objectives, Scope and High Level Requirements as a bare minimum.

Programme Managers’ will initiate the projects that make up the programme. The same note for Programmes apply to Projects: it is very common for an Owner to also be a Programme Manager! But not all Owners will be Programme Managers. Analysis will be needed to define the Terms of Reference (TOR) for the Programme: the Objectives, Scope and High Level Requirements as a bare minimum.

Project stakeholders’ will generate and sign-off requirements for the project. Analysis is required to define the process, data and non-functional requirements.

Design analysts’ will take the products of analysis and propose the best solution to meet the requirements (‘best’ being defined as satisfies most requirements). Any compromises required will be mediated by the Business Analyst with all who need to accept the compromise. Note that Design Analysts can be IT analysts for IT components, HR analysts for people and organisation units, and others for other components.

Solution Builders’ take the design specifications and construct solutions. Note that these solutions are not constrained to IT components but must all work together to provide the whole solution.

Solution builders and Business’ test the solution. The requirements analysis should be used to construct the test plans – especially the user acceptance testing. Note that the Business Analyst should q/a that the UAT does test that the requirements have been met.

Project Manager’ will co-ordinate the whole project and implementing the solution, and the Business Analyst (being a subject matter expert on project Objectives, Scope, and Requirements) should be able to contribute significantly to the design of all implementation activity, all the while ensuring that requirements are being met.
In an ideal world, ‘post implementation’ how well the objectives have been met will be fed back to the Owners.
Now that we have a shared understanding of what the Business Analysis role is let’s look at the top 6 reasons for project failure and consider how this role can mitigate these risks.
  1. Incomplete/inaccurate requirements
  2. Lack of user involvement
  3. Unrealistic expectations
  4. Lack of executive support
  5. Changing requirements
  6. Lack of planning
  1. Incomplete/inaccurate requirements

Business Analysts own requirements. They may not always be the people who generate them, but if the signed-off requirements are not fit for purpose (that purpose being the development of all aspects of solutions, computerised or not) then it is the Business Analyst who should be held responsible. A good Business Analyst then should remove the risk of inaccurate requirements, and should significantly mitigate the risk of incomplete requirements. They cannot remove this risk as they will be dependant to an extent on the quality of the other people who are supplying requirements. 
  1. Lack of user involvement

To mitigate the risk of lack of user involvement, we need to know which users need to be involved, why and how.

A Business Analyst should be analysing and documenting the context and scope of the solution.

External entities on the these diagrams (see following example) define user groups that need to be engaged by the project in the course of defining the context in which the solution will operate.


Benefits of Business Analysis solution context
This diagram tells us the user and customer groups who interact with the solution, but are unchanged by it.
It is also useful to construct a context diagram for the project itself to define who is to be engaged by the project and how:
Benefits of Business Analysis project context
These diagrams tell us about user groups who need engagement because they are impacted (but not changed) by the solution or are involved with the project.
Organisation structure units within scoping diagrams (see following example) define the user groups that are going to be changed by the solution (what they do, how they do it, how they are structured and so on).
Benefits of Business Analysis solution scope
These users need to be engaged to gather requirements. The Business Analyst has the responsibility for ensuring that these context and scope definitions are full, complete and accurate.
This analysis should mitigate the risk of lack of user involvement. What the analysis does NOT do is analyse who the solution needs to be ‘sold to’ and how to ‘sell it’. Thus the Business Analyst can mitigate the risk of lack of user involvement but not remove it.
  1. Unrealistic expectations

Unrealistic expectations can be caused by many reasons and the majority of them will not be directly attributable to the Business Analyst so they can not mitigate the risk. The area that Business Analysts can and must mitigate risk is the area of unrealistic expectations for the project deliverables. Logically, this can be traced back to the objectives for the project. Unless objectives are specific, measurable, achievable, directly relevant to what the project will deliver and fundamentally important to the business owners of the project, then they can be interpreted in any number of ways leading directly to unrealistic expectations about what the project will deliver. For example, consider these two objectives:
    1. become a centre of excellence for customer service
    2. increase sales by 10%

Objective ‘a’ immediately raises the question of how the business will know it has become a centre of customer service. What measure will it use as a scale of customer service and what value on that scale means that the business has achieved being a centre of customer service? Define that and there is no doubt about what the project is setting out to achieve.

The Business Analyst owns responsibility for ensuring that the objectives are fit for purpose (that purpose being the development of requirements that – when implemented – will result in the objectives being achieved). Note that the Business Analyst does not have to do the work of defining the objectives (in the real world they are often done by Project Managers), they must simply make sure they are fit for purpose. If they are not, then the project runs the significant risk of failure due to unrealistic expectations caused by a poor definition of what the project will achieve.

  1. Lack of executive support

Surely the Business Analyst is not responsible for senior exec buy-in? Consider this: you are a Business Analyst working on a project and for some reason the people who can make the go/no-go decisions are always too busy to attend steering group meetings and so on. The question is why? There can be a multitude of reasons which are outside of the control of the Business Analyst and – indeed – the project.

However, one reason that is in control of the project (and may be in control of the Business Analyst themselves) is that the senior execs are not interested because they do not care about the deliverables of the project.

Suppose now you are a senior exec and you have 2 projects for which you hold ultimate authority. One project will deliver a solution that takes you some way to meeting your sales targets that you are responsible to the company board for achieving. The other project delivers a cultural change programme centred around the slogan of “becoming a centre of excellence for customer service”.

Which would you focus on?

By the way, both of these projects were projects in the real world – guess which one got completed and which failed due to lack of decisions by the senior execs?

Business Analysts can make sure that the objectives are directly relevant to what the project will deliver and fundamentally important to the business owners of the project. If they are not then the Business Analyst should raise the risk that the project will fail due to lack of senior exec support.
  1. Changing requirements

Requirements can change because the business environment changes, the business users come to understand what they are asking for is not what they need or because of misunderstandings about what the requirement really is.

It is this last reason that the Business Analyst can mitigate against.

By building up a rigorous chain of inductive logic starting with the precise definition of what the project seeks to address (in terms of problems and/or opportunities) and following through to the full set of process and data requirements for the change, the Business Analyst can deliver a justified set of change of requirements that will not change because of misunderstandings. This ‘chain of reasoning’ is the subject of other articles, but is summarised by the following diagram:
Benefits of Business Analysis chain of reasoning
  1. Lack of planning

The Business Analyst is not a Project Manager (or vice-versa) – they are very different skills sets and (typically) the type of person who makes a good Business Analyst does not make a good Project Manager (and vice-versa).

Planning is owned by the Project Manager.

In the real world, most projects are planned by setting an implementation date and then the plan is constructed back from that date to try and fit everything in. This implementation date constraint is often outside of the control of the project team.

What the Business Analyst can and must do is define what they need to do, who and what they need to do it with and how much effort will be involved. At least that part of the plan will then have some rational justification.

Business Analysts must also analyse the risks of cutting back on the analysis – and in the real world the risk is (typically) project full or partial failure due to

1.      Incomplete/inaccurate requirements
2.      Lack of user involvement
3.      Unrealistic expectations
4.      Lack of executive support
5.      Changing requirements
6.      Lack of planning 


Some statistics: According to Barry Boehm the cost of fixing errors that arise in the analysis phase of a project rises by a factor of 100 if that error is not fixed until implementation. According to IBM (“Calculating your return on investment from more effective requirements management”) most errors occur during analysis and are the most expensive to fix after the analysis phase. Around 75% of total project re-work costs are consumed on fixing analysis errors.

Typically, most projects expend least time and effort on analysis (Staffordshire University estimate the average around 10%).

The summary of this is that most projects spend least time and effort where most errors occur and which cost most to fix!

This article has sought to make the case that Business Analysis mitigates against the top 6 reasons for project failure as defined by the Standish Group Chaos Report.

So, is it worth doing rigorous Business Analysis?  You do the math!

Author: Guy Beauchamp is a Business Analyst practitioner, trainer and mentor.  For more details on visit:

Like this article:
  33 members liked this article


David Wright posted on Monday, November 10, 2008 1:04 PM
Excellent stuff, Guy.

What I would ask you and all other readers is: have you seen statistics on the actuall benefits realized by companies who introduced Business Analysis?

The strict expectation is that the number of errors caught later in development would decline, but by how much really... Certainly its is tough for companies to measure success of specific projects, so it would be much harder to measure the overall success of a program to implement Business Analysis.

...but its a big world, I have to think some companies have done this. Anyone seen this done?
Guy Beauchamp posted on Tuesday, November 11, 2008 2:31 AM
David, the (frankly) annoying thing about the benefits in this article is that they are avoidance benefits. These are (by definition) hard to measure as the benefit is in avoiding them! So you can measure that you have reduced occurance of things, but how do you prove how many would have happened without BA?
So I don't have any stats (which is why I went with the Standish Choas report as it seems to be the most widely accepted reference for this sort of thing). But like you I would be VERY grateful if anyone has any better information.
Guy Beauchamp
David Wright posted on Tuesday, November 11, 2008 1:48 PM
What would be needed are companies that have tracked the number of change requests submitted for each of their projects over a period of time and, if possible, classify them as requirement changes versus design or other types of changes.

Such companies would then have to have introduced Requirements Management, and then still tracked the number of (requirements-related) change requests for a number of projects using RM, and see what the difference is. Until we see this kind of measurement and metric, we will never really know if the expected benefits of RM are realized.

Unfortunately, measuring such things consistently over longer periods of time is difficult to do, for all the same reasons that getting any metrics is difficult (like using past projects' actual costs to help estimate the costs of a new project... too much changes, including the management will to keep doing it).

But if anyone has managed to do this, its a secret. A web search turns up nothing like this.
Angela Wick posted on Monday, November 17, 2008 12:42 PM
Great article! I really like your Scope of the Business Analyst Role image depicting all the influential touch points a BA has. As BA practicioners we need to constantly be able to tell this story and lead by showing the value we bring to these touch points everyday. So many times others see us as just "requirements gatherers"; this shows us the opportunity we have each day to bring additional value and influence to our projects on multiple levels.
Guy Beauchamp posted on Tuesday, November 18, 2008 2:53 AM
thanks for your kind comments! I hope that as well as showing the opportunities that BAs have each day, the diagram also shows the necessity of the BA understanding all the previous points in the pipe regardless of the point they join the project at.
Thanks again,
Guy Beauchamp
Byron posted on Thursday, November 20, 2008 4:59 PM
A good article - thanks.

I noticed that a few folks were asking for metrics that indicate the benefits of BA work. Try Capers Jones at [email protected]. He has a wealth of information.
Timothy Johnson posted on Sunday, January 4, 2009 8:46 PM
Great article, Guy. Really no need to apologize for extrapolating the CHAOS report to prove your point... your extrapolation made for spot-on analysis of the problem. As someone who is transitioning more and more from PM to BA, it would be interesting to see a CHAOS equivalent be developed for this discipline.

As was already pointed out, you've done a masterful job of demonstrating all of the organizational touch-points. Thanks!
Guy Beauchamp posted on Monday, January 5, 2009 2:42 AM
Apologies for the delay in responding - thanks for the reference which I will follow up and thanks again.
Guy Beauchamp
Guy Beauchamp posted on Monday, January 5, 2009 3:01 AM
Many thanks for your kind comments and I'm glad you found the article useful.

It is an interesting question you raise - and Byron has suggested a resource that might go some way to addressing this though I have not yet had the chance to check it out myself yet.

Thanks again,
Guy Beauchamp
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC