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 has frustrated me, but at other times it has motivated me to do my best and make them realise the value of a Business Analyst. I have managed to bring people around me and make them realise the value of analysis and how a Business Analyst fills that gap.
During all this 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 them.
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, then why are we called “Business” Analysts? In that case 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-centered design project which focused on redesigning a storefront to create a better customer experience when customers 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.
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 this on 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.
What I did as the Business Analyst here was not jump into the symptom and fix it, instead I dug deeper to understand the core issue, 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 focused on “Requirements”
This is partly true and partly not. Let’s see why it is not.
As I mentioned above, what I demonstrated 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 the 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 the development of an IT solution.
Let’s see why myth #2 is partially true.
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 and defines how they interact with the solution, ideally by identifying the high level functionalities or features.
Solution Requirements are the next level where features are broken down into detailed Functional and Non-Functional requirements (user stories in Agile) which dictate how the solution will interact with the end users and what capabilities it will provide to the users.
Transition Requirements define 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 next level management, whereas the solution requirements and transition requirements come from the system’s end users. Requirements can also be derived from the findings 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 may mean the 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 are often perceived as only “solution requirements” 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 is presented to the executives for approval.
Everyone is familiar with the idea that a Business Case has to look at the Return on Investment on the project and what its 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 they should be involved much earlier, or when the idea is being 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 easily switch 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 of it.
For a Business Analyst, 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.
About the Author
Originally published at https://www.linkedin.com.
