How to overcome the common elicitation challenges a Business Analyst faces
By: Swati Pitre
Tags: Cbap, Agile Business Analysis, Business Analysis, Training, Business Analyst

Image Credit: pixabay.com

What are the most common elicitation challenges? This is one of the most discussed topics from my business analysis training sessions. A business analyst extracts information in various forms, from various sources, and transforms those findings into requirements and design artifacts. Let’s take a look at some of the common challenges during the elicitation process and how to address them.

Analysis paralysis

In this classic situation, the analysis of the current problem is neverending. We overthink the possibilities and alternatives. That in itself may lead to deadlocks. This in turn results in no forward movement on the task. Sometimes we may delay a decision until ‘all’ the data is available. Sometimes a decision is delayed for the best decision to be taken later. And sometimes we may exert effort on research which is actually not necessary. All this can lead to slow movement in the production stages. This is even more relevant in today’s Agile/DevOps projects. Here are some ways to manage this:

Elicitation is an iterative activity and its deliverables are also incremental. It is often not a stand-alone activity either. Ensure that you are reviewing business analysis and elicitation artifacts with the stakeholders. A culture of self-reviews, internal reviews, and quality checklists helps too.

Maintain a list of risks related to your analysis activities. You may add these in your elicitation tracker or you may want to maintain a separate risk register. The key is to mention the risks along with the consensus on their assessment and mitigation plan. This will help prevent analysis paralysis and aid in taking the next step forward.

Inadequate stakeholder involvement

In this situation, a business analyst tends to work more in silos and produce something which is not what stakeholders need and/or is not adequately reviewed with the right stakeholders. A business analyst needs to collaborate with stakeholders from business teams such as domain SMEs, partners, suppliers, and sponsors. A business analyst also collaborates with IT teams and stakeholders such as development, quality assurance, architecture, infrastructure, support, and governance. The root cause of inadequate stakeholder involvement can also be that the stakeholder analysis is not completed at the beginning of a project or not updated during the project. Another root cause can be the inertia of some fear of receiving feedback. Inadequate stakeholder involvement coupled with analysis paralysis is a risk zone. Here are some ways to manage this:

Shared understanding with each stakeholder group is crucial. Identify and review with each stakeholder group. Gain an understanding of how they would be contributing to the initiative. Understanding RACI for each task you would be performing as a business analyst helps too. The key is to ensure you are collaborating with the right stakeholders and know who is going to be the decision authority for each business analysis task.

Having a plan for effective collaboration is important as well. For regular review and feedback, ensure how you will collaborate (which tools), how frequently, what timings, etc. If you are part of a large project team, working in a structured framework such as scrum, you will likely have these already plotted. Despite the size and type of project, the main thing is to adequately involve the stakeholders associated with the right information in the preferred format.

Vague requirements

A business analyst needs to work through information from a plethora of sources. The information could be in various forms such as verbal, whiteboard snapshots, emails, rough notes, audio recordings, etc. It is very crucial to create the right set of requirements view for each stakeholder group. Sometimes there is no existing documentation or existing documentation is incomplete. All this may lead to some gaps in requirements with an incomplete picture. Especially those who are new in a business analysis role may find it a daunting problem to solve and their written requirements could remain vague and unclear. Here are some ways to manage this:

Start preparing well for elicitation activities through questions and track the answers through some kind of tracker. Ensure you have precise questions and use simple language. Also, keep in mind which stakeholders you are asking which questions.

While converting the elicitation notes into your business analysis deliverables, make sure you phrase the requirements accurately. Whenever needed, provide artifacts such as process models, data models, decision tables, etc. Ensure requirements traceability, by linking user stories, user cases, process models, BRDs, FRDs, etc, with the right artifacts. This will help add clarity and trace for impact analysis. Thinking like a business user and writing stepwise acceptance criteria is a crucial part too.

Conclusion

These are glimpses into typical elicitation challenges and some ideas on how to overcome those. In business analysis training sessions, I simulate these challenges through role-playing and case studies. In reality, elicitation activity, at times, seems like river rafting to me. You do want to jump into the flowing river, but you may be scared of the what/how/when of the rafting. You must know the right techniques of rafting and be ready to make ‘in-flight’, intuitive, and out-of-the-box decisions as well.

Thoughts?

Author info

Swati Pitre, CBAP®, is Sr. Business Analyst with 18+ years of industry experience across various domains and geographies. Her specialties include Product Development, BPM, Process Improvement Consulting, Business Analysis/CBAP®/ CCBA®/ ECBA® Training.

*This article is previously also published on LinkedIn: https://www.linkedin.com/pulse/how-overcome-common-elicitation-challenges-business-pitre-cbap-/