Myths about Business Analysis

In my years of working in the consulting industry, I got the opportunity to work across industries, domains, companies and countries. I have noticed that many have a very narrow view/awareness of the value of a Business Analyst. At times it frustrated me and other times it motivated me to do my best and make them realise the value of a Business Analyst. I did manage to turn the people around me and made them realise the value of analysis and how a Business Analyst fills that gap.

During all that time, I have been witness to quite a few myths about this field. I wish to focus on myths I have encountered about Business Analysis as a practice/field and attempt to bust those myths.

Myth #1: Business Analysts are only meant for IT projects

I have worked in organisations where they think like this, that Business Analysts are only needed when IT is involved.

“We are analysts who analyse the business, ergo Business Analysts”. Where does IT come in here? IT is often part of the solution, so we get involved in IT Projects because we need to make sure that the solution IT provides is actually meeting the business requirements that the Business Analyst collected, analysed, prioritised and negotiated.

If we were only meant for IT projects why are we called “Business” Analysts? Instead we should be called IT Analysts.

I have worked on many non-IT projects as a Business Analyst. For instance, I worked on a human centred design project which focussed on redesigning the store front to create a better customer experience when they walk in. IT was a very minuscule part of the solution and the emphasis was on customer experience through people and process. I have also worked on projects that were about increasing employee productivity by looking at the various back end processes and finding ways to eliminate waste by getting rid of tasks in the processes that are not valid in this day and age. The emphasis was placed on increasing productivity by eliminating duplication of work within the processes and where necessary replacing manual tasks with automation. In both situations, IT played little to no role in the solution and yet there was a need for a Business Analyst.

If we were only meant for IT projects why are we called “Business” Analysts? Instead we should be called IT Analysts.

I used this example in one of my previous articles too and I will use it again. I once worked in a financial institution when I was given a problem to solve. The problem was that the business could not print an entire quarterly report that was emailed to them.

I investigated and uncovered that the problem was with the size of the report. These reports were 700 pages long and the printers had a daily limit of 500 pages. I did a bit more digging to understand the purpose of the report and how it changes hands and what happens at the end. I found out that the print outs were taken by the Administration Officer to go through the customer list once a quarter and group the customers by Relationship Manager and then hand over the relevant part of the report to the relevant Relationship Manager. They then studied their part of the report to make sure their accounts were accurate in terms of what they sold to their customers in the last quarter. After all the accounts have been checked, the report was then binned. The business wanted me to prepare a business case to update the printers to have a higher daily page limit. This meant months of work put together to gather requirements, develop, test and implement in every printer across the organisation.

The “Business Solution” I came up with was to change the process of accessing the reports and the “IT Solution” was to use an existing reporting tool (which they were not aware of) to access the reports digitally and report any anomalies that can be fixed. I designed a customised training session for the reporting tool and taught all the relationship managers to access the reports digitally.

This not only saved them tens of thousands of dollars by not implementing the IT change but also saved a lot in terms of cost of paper used, not to mention the environmental benefits.

If you noticed here, what I did as the Business Analyst was to not jump into the symptom and fix it, instead I dug deeper to understand the core issue and changed the business process (outside IT) and used existing solutions to solve the business problem. We did not develop any new IT solution to address this matter. Essentially what Business Analysts do is solve business problems, which may or may not involve IT and which may or may not turn into a project at all.

Myth #2: Business Analysts are only focussed on “Requirements”

This is partly true and partly not. Let's see why it is not.

As I mentioned above, what I demonstrated there had nothing to do with gathering requirements in its traditional sense. Additionally, Business Analysts often get involved in Business Process Reengineering to make the current process more efficient by identifying waste and eliminating tasks in a process making it more efficient and increasing productivity.

We get involved in BAU activities where we focus on continuous improvement. These activities don’t always involve a project and requirements elicitation to be documented in a Business Requirements document for an IT solution development.

Let's see why it is partially true.

Source: CBAP/ CCBA Certified Business Analysis Study Guide

The BABOK? Guide defines a specific taxonomy or classification scheme for project requirements. The standard defines a requirement as a condition or capability needed by a stakeholder to solve a problem or to achieve an objective. According to the standard, Business Requirements are the highest level and are developed during Strategic Analysis activities. They define the high-level goals, objectives and needs of the business.

Stakeholder requirements are the next level of requirements which bridges the gap between business requirements and detailed solution requirements which defines how they interact with the solution, ideally by identifying the high level functionalities or features.

Solution Requirements is the next level where the features are broken down to detailed Functional and Non-Functional requirements (User stories in Agile) which dictates how the solution will interact with the end users and what capabilities it will provide to the users.

Transition Requirements defines what is required to transition from the current to the future state, for example migration requirements, training requirements etc.

The Business Analyst’s involvement is across the lifecycle of the project and the content of their discussion is dependent on the stage of the project and the audience they are interacting with. Business & Stakeholder Requirements usually come from the executives and the next level management, whereas the solution requirements and transition requirements come from the system’s end users. Requirements can also be the result of a gap analysis as a result of business process re-engineering which says that in order to go from the current state to the future state, the solution will have to perform some tasks differently which will mean development of an improved system process. So everything a Business Analyst does in a project revolves around requirements from one of these 4 stages. Requirements is often perceived as only the “Solution requirements” described above but the scope of requirements is multi-fold and a Business Analyst is involved at each level.

Myth #3: Business Analysts are needed only after a project kicks off

I suppose I addressed this myth as part of my previous point. Those Business Requirements and Stakeholder Requirements that I mentioned earlier often find their way into a Business Case, which gets analysed for risks, impacts, dependencies, benefits and constraints and are presented to the executives for approval.

Everyone is familiar with the fact that a Business Case is to look at the Return on Investment on the project and what the high-level complexities are. The approvers may very well review the business case and decide against the idea. In which case this initiative never becomes a project to begin with. These activities are what forms part of what is called Strategic Analysis in the BABOK?.

At the Strategic Business Analysis stage, what the Business Analyst works on may or may not end up becoming a project.

Business Analysts don’t (and must not) get involved only after the project kicks off, instead much earlier when the idea was just formed so that the business (highest level) requirements are gathered and analysed and in order to determine whether the project is indeed worth pursuing. After this stage, when the project is initiated, the Business Analyst’s involvement is not in doubt.

Myth #4: We don’t need a Business Analyst. We have the SME

The risk with using a Subject Matter Expert (SME) for business analysis is that they can get easily swayed into solution mode. They could be limited in thinking within the constraints of the system and forced to think the solution lies within the system and not outside.

For a Business Analyst, like I mentioned before, IT may or may not be part of the solution and we are conditioned to think there are many solutions to the problem. Solutions can mean, business process, people training, IT or a combination. SMEs are important partners to Business Analysts. They are complimentary, not supplementary.

Myth #5: Business Analysts are Project Managers’ personal note takers

This is my favourite. I have encountered such Project Managers myself and many of my Business Analyst associates have also experienced this attitude. Although this is becoming less and less common, there are still some PMs out there who think like this.

If you expect the BA in your project to be your shadow, you're seriously limiting the value that the BA in your project can deliver.

Firstly, in project delivery, everyone reports to a project schedule and not a person. Therefore the notion of a hierarchy is meaningless in projects.

Secondly, if you need someone with a Business Analyst’s pay scale to take your notes, there is obviously a need to reconsider whether you are getting value for the money you are spending on the project. If you expect the BA in your project to be your shadow, you're seriously limiting the value that the BA in your project can deliver. 

Conclusion

Business Analysts, for a long time have been subject to under-estimation and under-valuation. A big reason for such a limited view of business analysis and business analysts is the presence of such misconceptions.

What can business analysts do to change this perception? You can take the team through your thinking process and ask questions. Ask about gaps that you might have identified and get them thinking on how much they might be missing out on by not doing enough analysis. Business Analysts bring a lot to the table in the form of soft skills such as negotiation skills, setting the right expectations, translation (from business speak to technical and vice versa), negotiations, conflict resolution, relationship management, challenging the business, to name a few, that are just as important as the hard skills which include documentation, facilitation, elicitation etc.

I haven’t met a lot of Business Analysts who talk about what they have done. They simply produce the required artefacts and move on without giving themselves enough credit.

Other articles by this author

What professionals can learn from toddlers

Requirements vs Solutions

Agile – Why is it really so difficult for some organisations?

What do we Business Analysts really do?

Launching your career for fresh graduates – is it really as hard as it looks?

How to handle ever changing requirements?

What can leaders learn from Parenting?

What makes a good consultant?

Danger signs during recruitment….. For Candidates

How Agile can make you a better human being?

Business Analysis and Customer Experience – 2 sides of the same coin

What makes a good Product Owner?

Why I am a proud Business Analyst

About the Author

Click here to visit Arvind's Linkedin Profile