Tuesday, 22 February 2011 10:42

Bad Business Analysts or Bad Assignments?

Written by 
Rate this item
(0 votes)

Feb22_BA_FeatureOften 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.

Project Objectives

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

Ill-equipped BA

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.

Time Box

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.

Summary

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.

 Don't forget to leave your comments below.

 

Read 4372 times Last modified on Tuesday, 27 March 2012 13:46

Comments  

 
0 # Colin101 2011-02-22 10:02
Scope Creep Problem: The business owner provides additional requirements that extend the scope, sometimes under the guise of providing more detail to currently documented requirements. S olution: Ensure that the scope of the project is clearly documented and agreed before the requirements elicitation phase. Then compare all requirements and suggested changes to requirements to the scope, insist that any that impact the scope follow the change request process. Tip: Involve the Project Manager he/she has a vested interest in avoiding scope creep.
Reply | Reply with quote | Quote
 
 
0 # Seo Keo 2011-02-22 17:00
The only comment I can make is: any BA must be prepared to be in one of the mentioned situations. There is no panacea per se but learning and personal development coupled with a desire to help business to improve the "as is" state helps successfully complete a project. To get "there" the BA must play different roles apart from being just a BA.
Reply | Reply with quote | Quote
 
 
0 # M. Naveed Noor 2011-02-23 15:24
This is Very Good Article and in Fact Last part "Time Box" is very important issue highlighted by the author. I Would like to suggest that this guidline should be added in BABok and BA Competency Model so that a greater community know about this fact. Most of the time in my experience shorter time lines forces Us (I mean to BA's) to focus more on important things only and to listen key stakeholders which ultimatly leads us towards other directions. An y how at the end i would also liek to write that BA's should know these dilemmas and take care of, so that thay dont misleads towards wrong directions
Reply | Reply with quote | Quote
 
 
0 # Ernesto 2011-02-23 22:02
What about IT-driven projects? Many times I've experienced the typical IT project where a BA is given the task to document very technical requirements, like an interface specification, in the form of a Use Case. This happens mainly when the role of the BA is understood to be as the generic "requirements specifier" and when the Use Case technique is believed to be the only way to capture any kind of requirements. The result is an artifact that doesn't make sense and probably lacks the important technical pieces that it should have. This mistake is also very common at projects where the "one size fits all" approach is followed instead of identifying the right analysis activities and work products that best suit that specific project.
Reply | Reply with quote | Quote
 
 
0 # Barbara Carkenord 2011-02-24 00:06
Great article! These are very common problems which BAs need to expect and anticipate. Our best tool is the ability to ask good questions. When the project objectives are unclear, pose questions like "Do we expect the result of this project to decrease costs by 10% or do we expect to increase sales by 10%?" Getting executives to think about specific goals will improve their expectations. They may not know the answers exactly but we will move them towards thinking more specifically about what they want.
Reply | Reply with quote | Quote
 
 
0 # David Reinhardt 2011-02-28 18:38
This is a good piece, I've seen all of these type of projects. I think an important consideration is that an experienced BA should also be taking a risk based perspective and raising issues through the relevant governance channels. In all cases, there are actions which can mitigate the relevant risk and BA's should be looking to these types of issues and taking ownership to address them. I'm not suggesting BA's should carry all the weight (blame?), but I am mindful that an experienced BA should be considering the overall success of the project and working towards that rather than just doing analysis work.
Reply | Reply with quote | Quote
 
 
0 # SOPHIST GmbH 2011-03-02 23:47
An interesting article which is, unfortunately, often far too close to reality.
Reply | Reply with quote | Quote
 

Add comment