Often a Business Analyst (BA) gets branded as being a bad analyst as a result of a project effort that has gone astray. Fortunately most of the time it is not the fault of the BA, but rather the project to which they have been assigned. This could be the result of any or all of the following situations.
Problem: One of the first problems encountered is being assigned to a project which has unclear objectives or simply an idea or concept in the head of management (not to mention “objectives/management by airplane magazine articles”). In trying to determine the scope, objectives or real reason for initiating the project, the BA may appear to be struggling or confused, when in fact the confusion originated at the top. Often these projects are unofficially entitled “Top Management’s Pet Project(s).”
Solution: If a business case has been prepared it can help determine the objectives for this effort. If there is no business case – maybe that should be developed as the initial step of the project. At the completion of the project the entire effort should be re-evaluated and “lessons learned” documented. This might prevent future projects from being initiated without a purpose being clearly identified and all stakeholders being in agreement before moving forward and consuming valuable resources.
Wrong Business Users:
Problem: Since the role of the BA is to elicit requirements from the business, the result is only as good as the users from whom these requirements are elicited. Often the business users that are provided for these information gathering sessions are the users that are “available” and very often not the one who has the knowledge to provide the answers that the BA requires. They often admit that they have no idea why they were asked to attend the sessions. In addition, if there are not business users with the authority to make decisions, approve compromises and/or prioritize the requirements, the results will be at minimum questionable. The final result will only be as good as the requirements provided – and who gets the blame?
Solution: Probably the most important activity to fully understand the “team” that has been assembled for this effort is to perform a thorough and extensive stakeholder analysis. Through this effort the discovery of potential weaknesses can be exposed. I am not saying that the BA will have the authority to request resource changes, but at least understanding the situation will help identify potential risks and escalate the situation to management
Problem: I am not speaking of a BA that is not qualified to be a BA, but rather one that is thrown into a project that supports an area of the business with which they have no experience or familiarity. As a business analyst, the BA is usually familiar with and supports the needs of a specific functional area. They are able to build on that knowledge to develop meaningful and thorough requirements that meet the functional needs.
Solution: If a BA is very familiar with analysis tools, especially process and data modeling techniques, this lack of functional background can be overcome. The tools will enable the gathering and analysis of information and the rules of the tools themselves will show where gaps exist and additional information must be gathered. The BA should feel comfortable relying on their knowledge and application of the appropriate tools and techniques to guide them through the project.
Another suggestion would be to contract a consultant with the appropriate business background to support the BA and help accelerate the learning curve. This be a successful solution most of the time. The team must be alert to the possibility that the consultant may attempt to implement business processes and/or business rules from their previous engagements, and not fully understanding the current project/organization situation.
Problem: In the traditional analysis methodologies the analysis of requirements was done until ALL requirements had been gathered and analyzed. This often led to the perception of the good ‘ole “analysis paralysis.” As a result more accelerated methods have been accepted by many organizations in which the analysis time has been reduced – with the intention of being able to deliver a result in a shorter period of time.
Solution: This reduction in time is critical but often the “time box” that is imposed causes important items to be overlooked, causing an end result that is not correct and/or requires extensive rework. Once again the question is pertinent – “Do you want it quick or correct?” The BA is forced to pay more attention to project scope and not wander off analyzing additional requirements that are out of scope.
There are obviously other areas that can go wrong on a project that unfortunately will be attributed to a “bad BA” – but as we all know, there is plenty of blame to go around to all.