Elicitation involves bringing out or drawing out information. Elicitation is a key task in business analysis as without proper elicitation the requirements for the solution to the business needs cannot be identified.
1. Not understanding underlying business need
Organization’s business environment keeps changing with respect to Customers, Marketplace, Technology and Marketing function. It is these changes in business environment that leads to identification of business needs at the strategic level in terms of problem or opportunity faced by the organization.
Defining business needs is the most important step in business analysis. Without understanding and defining underlying business needs, it would not be possible to identify all affected stakeholders and elicit appropriate requirements.
2. Not identifying all affected stakeholders
It is important to identify all the stakeholders affected by the given business need. If any stakeholder is identified late (or worst not at all!) may lead to incomplete set of requirements and could require a revision to requirements increasing project cost and time.
3. Treating elicitation as a phase
I have found many Business Analysts consider elicitation as a phase after planning (and before requirements analysis). But this is not true. If you think little more deeply, information gets elicited whenever we interact with stakeholders such as sponsor, domain subject matter experts (SMEs), implementation SMEs, users etc.
Elicitation is performed to understand the current state and elicit business requirements. Business requirements are used when eliciting stakeholder, solution and transition requirements. During requirements analysis, we may identify gaps which would require further elicitation. Information is also elicited from the stakeholders about solution performance after implementation of a new solution.
So elicitation is performed on an ongoing basis as long as business analysis work is performed.
4. Not asking probing questions to elicit requirements
Many novice Business Analysts assume stakeholders can proactively provide all the detailed information required for the business analysis work. Such a passive approach can be called requirement gathering but not an elicitation. Such an approach can only lead to identification of shallow requirements.
It is the job of the Business Analyst to extract or draw out the detailed requirements from the minds of the stakeholders. Business Analyst need to ask probing questions to elicit detailed requirements.
5. Not setting stakeholder’s expectations
In your career as a Business Analyst, at times you would find some stakeholder who would state their wants (whims and wishes!) as if they are their needs and expect them to be in the solution. You may find their expectations not only difficult but impossible. If you capture their wants as requirements it would be difficult later on to deliver to their expectations.
With your interpersonal and negotiation skills you need to communicate and set the right expectations.
6. Not using combination of complementary elicitation techniques
I have seen many Business Analysis teams often rely only on one technique such as interviews for elicitation. While interviews is the most effective elicitation technique but its effectiveness depends on the skills of the Business Analyst such as business domain knowledge and ability to ask probing questions.
So, apart from interviews, a Business Analyst should have knowledge of other commonly used fundamental requirements elicitation techniques such as Document Analysis, Observation and Prototyping. While a senior Business Analyst should have knowledge of advanced elicitation techniques such as Brainstorming, Focus Groups, Requirements Workshops and Surveys.
A Business Analyst should be able to understand the given situation and use combination of complementary elicitation techniques.
7. Not eliciting assumptions and constraints
Requirements are often stated (knowingly or unknowingly) based on certain assumptions which are believed to be true at that time. Requirements get impacted if those assumptions are later found to be false.
Constraints are limitations or restrictions (such as regulatory restrictions, budgetary restrictions, time restrictions etc) that restrict potential solutions to requirements. Identified potential solutions may change if there are any changes in the constraints.
If underlying assumptions and constraints are not captured for requirements, it would be difficult to assess impact on requirements if certain assumptions are later found to be false and/ or on potential solutions if constraints are changed.
8. No plan to elicit requirement iteratively
In order to elicit requirements, a Business Analyst contacts a stakeholder and requests their time. Many Business Analysts do not plan to elicit requirements iteratively and assume that stakeholders will provide all the information required for the business analysis work.
However, most of times, stakeholders are not aware why they are being contacted. After their initial meetings, stakeholder will have some idea what is expected out of him/ her. In the subsequent meetings, stakeholder is likely to give bit more detailed information. So, in order to elicit detailed information, Business Analyst needs to plan to elicit requirement iteratively.
9. Not confirming the elicited information
Work of elicitation is not over once Business Analyst is done talking to stakeholders. Business Analyst has to organize the elicited information and send it to the stakeholders for review. The purpose is to check if discussion has been properly documented and confirm the elicited information.
10. Not collaborating with stakeholders to have common understanding of requirements
When the elicited requirements are shared with stakeholders, there can be difference of opinions and conflicts between stakeholders. A Business Analyst has to collaborate, mediate and resolve conflict between stakeholders to reach a common understanding of requirements. Business Analyst should identify the stakeholder’s problems and help to identify solutions to satisfy those problems.
About Author - Trividh Patel, CBAP
Trividh Patel has about 20 years of experience in Business Analysis and Consulting in IT services industry.
Currently, he is working as Facilitator and Mentor - Business Analysis providing self-paced online courses in Business Analysis. Previously, he has worked for leading IT Services companies as Business Architect, Lead/ Sr. Business Analyst, and as IT Project Manager. He has executed several business analysis projects for reputed organizations from USA, UK, Europe, Middle East, Japan and India. He has good track record of leading team of Business Analysts to deliver business analysis projects.
Trividh Patel has done MBA in Systems and Bachelor of Engineering from University of Mumbai (India) and is Certified Business Analysis Professional (CBAP) by International Institute of Business Analysis (IIBA), Canada since March 2012. He is also Certified Six Sigma Black Belt.
For Consulting, Coaching or Guidance on IIBA Certification (or just to connect!), Trividh Patel can be reached on LinkedIn: http://www.linkedin.com/in/trividhpatel-cbap