Introduction:
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).
Synopsis:
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!
Detail:
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. http://www.infoq.com/articles/chaos-1998-failure-stats) 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.
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:
- 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.
- 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.
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.
- Incomplete/inaccurate requirements
- Lack of user involvement
- Unrealistic expectations
- Lack of executive support
- Changing requirements
- Lack of planning
-
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.
-
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.
Context.
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.
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:
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.
Scope.
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).
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.
-
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:
-
- become a centre of excellence for customer service
- 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.
-
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.
-
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:
-
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
Conclusion:
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: www.smart-BA.com