7 Common Mistakes Often Committed By Business Analysts

A business analyst ensures that the end product meets the requirements and parameters of project's stakeholders. Business analyst holds the responsibility to gather the requirements through streamlined communication with stakeholders and to make the sense of collected information in order to help the project team complete the tasks successfully. The most challenging and wide-scoped task of BA is to give the users what they want instead of giving what they need during requirements gathering. The business analyst is expected to bridge the gap between the traditional and advanced practices of information gathering; it saves the time of all the project team members that they otherwise invest in pulling data from a spreadsheet and then feeding it into the Excel sheet to make it accessible at different points.

The certified business analyst works on a very wide landscape with possibilities to commit mistakes unknowingly; and, even the single mistake affects the profitability, team members’ performance, and customer satisfaction. The learning is a continuous process; the following often committed 7 mistakes by business analysts will help you improve your performance:    

7 Common Mistakes You Need To Avoid:     

1. Requirements Review without Proper Collaboration

The requirements review shouldn’t be considered as a task to be completed solely by the business analyst. The requirements review should be done with the proper involvement of concerned stakeholders to validate the importance of requirements against different perspectives. Checking the collected requirements against the related attributes with concerned stakeholders helps to minimize the possible defects before the application stage.

2. Improper Language in Requirements

BA often fails in expressing the requirements in proper technical terms from the specific technical viewpoint. Business Analysts are expected to keep the requirements tested and well structured. Business Analysts need to make the requirements - SMART: Specific – Measurable- Attainable- Realizable -Time-bound. Going a step ahead from this commonly used ‘SMART’ approach, you can follow - SMART-CC that adds Complete & Concise also to ‘SMART’ acronym. The organization itself is the primary user of the requirements that you collect and make smart for testing; so, ensure that there is no confusion in understanding by anyone involved.  

3. Allowing The Team Go For Designing Without Fixing Requirements: 

I have been engaged in many activities of reviewing and fixing stakeholders’ requirements; I noticed that numbers of stakeholders start discussing the designs and approach implementation too early without waiting for getting the analyzed and fixed requirements from business analyst. BA needs to squash such practices immediately because such practices tend to overshadow the actual requirements. Before understanding the stakeholders’ requirements, initiating the process designing may harm the project’ success. 

4. The Conversation without a Thought Line 

The proper conversation with stakeholders is the key to complete the project successfully but it needs to be in the line of the perspectives you get after the analysis of business needs and that of the project. Non-relevant discussions put just the blinders to actual requirements and distract the team members from the task causing frustration. The competent business analysts avoid involving too many stakeholders in discussions to get the best solution for a particular issue; all the meetings should be issue based.  

5. Taking the Requirements granted 100% Complete & Accurate before Discussing with Stakeholders: 

The numbers of business analysts feel that the documented requirements are 100% correct even before sharing with stakeholders. The less experienced business analysts have a common notion that the correction in documented requirements means that they didn’t do the job correctly; however, there are no fixed parameters for BA’s evaluation that stop them to change the once documented requirements. 

6. Getting Approval for Documented Requirements without the Shared Understanding

Some business analysts tend to get fast approval of requirements to expedite the process but a smart business analyst is expected to share the documented requirements with concerned stakeholders to assess their understanding and viewpoints. The common understanding is must to complete the project successfully on the time.  

7. Each project has different requirements and success measuring parameters

but some business analysts tend to use the most used template of BRD (Business Requirements Document) just to make the task easier. The BRD template, you select to use, may have some irrelevant categories to make your task more complex and time-consuming; if you notice such categories either remove these or mark N/A.

The success mantra for accurate business analysis is to ensure that you discuss with all those with whom you should do to share your vision of requirements for designing a collaborative approach.