It has been just over a year since I published my book, and that makes it easier for me to measure what has happened since then.
I have spent this year visiting many companies and discussing their business analysis function. In some cases, I have performed an assessment on the business analysts as well as the business analysis function within many large Corporates.
It has now got to the point where I could document the findings before I start the investigation. The reason for this is that the problems are the same. From articles and discussions from other countries it appears the problems are similar the world over. These are the problems I encounter most often:
- A lack of understanding of the role of the business analyst, by both the business analysts themselves and by the business. So nobody knows what is expected from them, and it changes from project to project, depending on the interpretation of the business analyst on the project.
- Most projects are in design-mode long before they have established what the problem that they are trying to solve has been defined. Too often I see project teams discussing how the screen is going to look and what push buttons are going to do before anyone knows what business problem we are trying to fix.
- An inability to control the “nice to have” requirements. Standish Group has revealed that 45% of the features of systems are never used; these then can only be “nice to haves” that nobody actually needed.
- A lack of standards. Often there is a requirements template but what gets put into that template can vary from project to project, with little or no quality control.
- No career path for business analysts. When business analysts want to make a move in their careers - they change jobs and, no, business analysts do not want to become project managers as the next move in their careers.
- A shortage of business analysts, and a bigger shortage of good skilled, experienced business analysts.
What I discovered in the last year was that, at most sites, business analysis is in a sorry state. I recently spoke at a seminar and afterwards a young BA approached me. He was delighted with the presentation I had done, but not from a content perspective. What he was pleased about was the fact there were attendees from so many companies nodding in agreement as we went through some of these issues and what pleased him the most was to find that it was not just his company alone experiencing these problems.
So if these are the unpleasant truths, what do they teach us? Well, the most important lesson of all is how to fix them. I have spent most of this year planning with clients on just how to do that. I have found that the best starting point is to get business analysts to understand what business analysis is trying to achieve. Firstly we do this by getting the definition of the role business analysis right. In order to do this I looked around for a definition that has been tested against the market. The one I settled on was the following one from the IIBA:
“Business Analysis is the set of tasks, knowledge, and techniques required to identify business needs and determine solutions to business problems. Solutions often include a systems development component, but may also consist of process improvement or organisational change.”
International Institute of Business Analysis (IIBA) Business Analysis Body of Knowledge BABOK™ version 1.6
The IIBA is an organisation that has been created to formalise business analysis in order for it to become a recognised profession and this makes this definition significant.
Let’s look at the first underlined phrase - “determine solutions to business problems”.
This gives a very good guide to the role of the business analysis. This in fact should be the underlying driver behind everything the BA does, but let us use it in formulating a starting point for the business analysis. The first thing we need to do is determine what is the problem that we are trying to solve; this is something that is lost in starting many projects and often this omission is the cause of many of the problems on a subsequent project. We, as BAs, must first define the problem we are trying to fix.
This problem definition should not be some wishy-washy statement, for example, “increase customer satisfaction” which I have seen used often. It is the BA’s job to get to the heart of the problem. Where is the desire to make customers happier coming from? Is it to increase the customers’ retention levels, or is it to attract new customers, or is it to decrease the number of complaints? All of these would be addressed by “increase customer satisfaction”. But which of them are we trying to address with the project, as a clear understanding of this will affect the solution recommended. The business should also define the measurable targets they are aiming to achieve.
For example:
- We want to attract 20% more customers
- We wish to drop the customer loss percentage by 15%
- We wish to reduce customer complaints by 30%
If we are going to set measurable targets, we also need to define how we intend to measure the results to prove that we can achieve what we set out to do.
These measurable targets are extremely important, as they represent the benefits that can be enjoyed by solving the business problem. They serve to keep the whole project on track. If the business can see the value they will derive, their desire to be involved will have more meaning. The BA can use this to show the business value that they deliver on a successful conclusion of the project.
Only once we have defined the problem, then and only then can we establish what needs to be done to rectify it.
Problem Identification:
- What is the business trying to achieve?
- What needs to be done to do it?
These two areas can collectively be referred to as the Business Requirements. The critical thing is to keep the solution design out of this section of the requirements. These need to be defined in business terms, such as the Business Process, Business Information required to support those Processes, and lastly the Business Rules that are applied by those Processes. Anything that does not in some way solve the business problem should be discarded. The Subject Matter Experts must be able to show how anything included will have a direct or indirect impact on what the business is trying to achieve with this project. I use the following to illustrate the concept:
Now we are ready to look at how we can create a solution that will solve the business problem or business objective we defined in the beginning of the project.
Let’s look at the second phrase I underlined in the IIBA’s BABOK - “Solutions often include a systems development component, but may also consist of process improvement or organisational change.” We can use this to guide us, illustrated as follows:
The proof of the pudding is in the eating. Let’s return to the problems identified in the beginning of this article and see if this approach will go some of the way to fix them. Let us revisit the first three:
- A lack of understanding of the role of the business analyst. Well, using the IIBA’s BABOK, we have a clearly defined the role for the BA. It will take some time for the business to become aware of this and some sort of communications plan needs to be put in place to expedite this.
- Most projects are in design-mode long before they have established what the problem they are trying to solve has been defined. We will only move into solution design once we have completed the problem identification and solutions blueprint. In this way we do not start solution design too early but rather in the right place and at the right time.
- An inability to control the “nice to have” requirements. By ensuring we have only documented that portion that will have a direct or indirect role in solving the problem, the “nice to have” will largely disappear as it will play no role in solving the problem we have defined to be solved.
So, yes, we have largely addressed the first three issues. As to the remaining three issues, these are primarily due to a lack of Business Analysis Maturity. Increasing the Business Analysis Maturity is critical to making the business analysis function within any organisation function more effectively. There are several Maturity Models being put forward by several thought leaders. The maturity model I like to use in my client engagement is one developed in the white paper Journey to Business Analysis Maturity by Angie Perris, CBAP / Vice President B2T Training & J. “Kupe” Kupersmith, CBAP / Director, Business Analysis B2T Training. It is based on the CMMI Maturity Model but developed specifically for the Business Analysis environment.
In my experience with my clients, the last three issues identified previously in this article can be successfully addressed by raising the maturity level of the business analysis function within the organisation, if this is done in a planned, and monitored, manner with executive support. Organisation that attempts to do this without executive support or attempts too big a jump in their maturity level, will experience a high level of failure.
In closing, this has been a wonderful year. I have been working with clients who are committed to taking their business analysis function to higher levels, and wish to deliver more business value by solving business problems the right way, the first time, and it is exciting to be part of that process.
Author: Robin Grace, Principal Consultant BA Practice for IndigoCube in South Africa.
Robin has been involved with Businesses Analysis for nearly twenty years and has used a variety of Methodologies, Modelling techniques, and Tools. He is well known for his presentations on various aspects of Business Analysis.
Robin recently published a book titled “Aligning Business Analysis, Assessing Business Analysis from a Results Focus”.