Business Analysis Guidebook/Keys and Barriers to Business Analyst Success

Keys and Barriers to Business Analyst Success

Factors That Are Key to BA Success

• Stakeholder involvement & commitment: It is imperative that a BA gets access to and involvement of stakeholders during the life of a project, but especially at inception. Having the ‘buy in’ of interested/affected parties would go a long way towards reducing resistance to the project, and increasing the likelihood that the end-product would be utilized and supported. Since the final product (usually a system) is geared towards the end-user, it is vitally important to have them for areas like helping to drive the usability and usage of the end-product, helping to define the business rules, performing User Acceptance Testing, etc.

• Accurate requirements management: There is a direct correlation between what users/stakeholders require and what’s delivered - that link is ‘Requirements Management’; i.e. requirements planning, gathering, elicit action, facilitation, documentation, etc. It is important to adhere to adequate methods of solicitation, to accurately capture key elements of a system/product being designed and built. This will also go a long way in the effort of modeling the system.

• Effective modeling/representations: Different models/representations of a system can be a very effective way of representing the ‘as is’ and to-be’ of a system. Different models can be the perfect representation to different stake-holders, and the level of detail may vary for different audience members. Some common models are flow diagrams, ER Diagrams, use-case diagrams, systems diagrams, architectural diagrams, prototypes and even presentations. Note: reference picture to be included, of famous illustration from 'Modern Analyst' where a requirement was interpreted in several, different ways.

Barriers to BA Success

• Unclear definition of Key Artifacts/Requirements: Much confusion can be avoided by determining what artifacts are needed, and having a clear picture of what each is. Questions that a BA can ask are: Do I create functional or non-functional requirements? Do I create a business use case? Do I create a system use case? Do I create a user story? Is a use case needed at all, based on the methodology in place?
• Being inconsistent & not adhering to the methodology in place: A BA must be clear about the methodology being used: Example - Is it Agile? Waterfall? Iterative? SCRUM? By introducing activities that are not in line with the methodology being used in their organization, much effort can be wasted in activities that are not needed, and can lead to inadequate planning and timelines. Example - if the SCRUM methodology is in place, then a use case would not be needed. The user-story would serve a purpose similar to a use case, but a use case would not be needed.
• Lack of Tools-of-the-Trade: Some tools help to make the work of a BA much easier, especially as it pertain to managing requirements. As listed in the following examples, the lack of some of these tools can make the work of a BA much more time-consuming, and can hamper efforts with other team members like quality assurance staff. Examples are: a repository for holding use-cases, etc. (like RequisitePro) where revisions can be easily tracked; a testing tool (like Quality Center) where test cases can be housed, and can provide the ability to synch such test cases to use-cases; lack of a tool for automated testing like QTP (geared more towards quality assurance staff).
• Blurring the lines between what’s a BA and other roles: There can be added complications when a BA wears the hat of multiple resources - Example: BA vs.Tester; BA vs.PM. When the lines are blurred or crossed, it can create problems as it relates to division of labor, conflict of interest, etc. Of course, there are situations when it's necessary for a BA to wear many hats, due to varying constraints; e.g. on small teams/entities with limited resources.
• Inadequate requirements management: There is danger in too much wasted effort, if a BA is not careful about minimizing non-value-adding activities. Examples include developing more artifacts and models than are needed, creating requirements that go beyond the business and may incorporate design, falling into the trap of a drawn-out process of clarifying all requirements up front. In cases where there's a lack change control, requirements could constantly keep changing, which can help to extend the project scope. If need be, a freeze must be set to prohibit any further changes for a particular release, and further changes handled in future iterations.
• Lack of stakeholder and end user ‘buy in’: If Stakeholders are not sold on a project, there is a greater likelihood of their not making decisions that can move a project along, not being available for meetings and discussions, or causing a project to not even get off the ground. If the project somehow reaches completion, there’s a chance that it may not be further supported or further phases may not be built. If end users are not entirely sold on the project, there’s a great risk that the project may not be used after being built.