Module in Strategic Business Analysis

Dr. Lorenzo B. Cabili, CPA, JD

Faculty, College of Business Administration

5
ELICITATION

“Be brave enough to start conversation that matters.”

Overview

Welcome to Module 5!

This lesson deals with the elicitation phase of the analysis process.
Elicitation defines the tasks associated with elicitation activities, including
how the business analyst will work with stakeholders to identify and
understand their needs and concerns, the environment in which they
work, and filter out wants from actual needs r their business. On this
module you will learn the tasks associated with elicitation as well as the
various techniques commonly used in elicitation activities.

Learning Objectives

At the end of this module, you should be able to:

Identify the requirements for elicitation

Illustrate the techniques for elicitation
Discuss issues and challenges of elicitation
Understand the ways to document elicitation results
 REQUIREMENTS ELICITATION

Business analysts elicit the necessary information to

develop their business, stakeholder, solution, and
transition requirements for their projects. The four tasks in
the Elicitation knowledge area guide you in gathering and
understanding what your project stakeholders need from a
new solution.

Elicitation is very much like a scientific investigation. You

will find yourself actively engaged in research, reading, talking, and
observing what is going on in the organization as it relates to your project
requirements.

Elicitation is defined as “to draw forth or bring out something latent or

potential” or to “call forth or draw out information or a response.” When
eliciting requirements, you should be able to:

 Understand the commonly used requirements elicitation techniques

 Select the appropriate technique or set of techniques to be used
 Prepare, execute, and complete each requirements elicitation technique

Requirements elicitation can be very challenging. When working with your

stakeholders to define requirements, you are often faced with
stakeholders who express those requirements in their own terms. You
must learn to speak the stakeholders’ language in order to understand the
capabilities that are being described. Stakeholders don’t always tell you
everything that you need to know, at least not the first time around.

The Business Analyst’s Task List

You have four tasks to perform in the Elicitation knowledge area, these
include:

 Preparing for requirements elicitation

 Conducting the elicitation activity
 Documenting the elicitation results
 Confirming the elicitation results

These tasks focus on obtaining the right information from the right
sources in order to develop the right requirements for your project.
Remember, effective requirements elicitation in your projects is
multifaceted and requires:

 The right sources

 The right information
 The right technique
 Clear organization
 Evaluation and understanding
 Accurate reporting
When Does Elicitation Take Place?
The tasks in the Elicitation knowledge area begin early in the project life
cycle and typically peak during the more detailed requirements
development phase of the project. Requirements can be elicited at any
point in the project life cycle. Typically, you elicit information for the first
time early in the project life cycle. You will also find yourself eliciting
information to clarify things you have missed or misinterpreted along the
way. Changing requirements also trigger additional elicitation efforts later
in the project life cycle.

Prepare for Elicitation

The first task in the Elicitation knowledge area is where you prepare a
detailed schedule of your elicitation activities. Your elicitation activities
can include interviewing an individual face - to - face, creating a survey to
send out to a thousand worldwide end users, or facilitating a group
workshop of 15 people. Your preparation work should include:

 Building a detailed schedule for the elicitation activity

 Defining the more detailed tasks that need to be done
 Scheduling those detailed tasks

This preparation step ensures that the necessary stakeholder resources

are organized and scheduled in advance. This step also allows you to get
all of your ducks in a row — from meeting room logistics, to required
materials, to attendance and attention from the right people.

Elicit, Don’t Gather:

To get Developing the Rightreveal
your stakeholders Questions
the real issue, you have to
develop a bit of hunting. To be successful in your analysis,
you must go beyond just gathering whatever information
the stakeholders present to you and elicit requirements
instead. The first step in developing the greatest question
ever is to figure out which type of
question “what”, “how”, “why,” “when,” or “where”—you want to asked
based on the information you need to obtain.

“What” Question The answers to “what” questions help you

build a general, big picture framework so
you can start filling in details with the
other types of questions later the answers
to “what” questions provide information on
the scope of the problem or a description of
the problem.

“Who” Questions If you want to know the people involved in

any given aspect o the project you’re
analyzing, ask a “who” question. The
answers to “who” questions
 help you understand not only the people
but also the systems within the scope of the
project.

“Why Questions If you want to understand the reason

behind the project, ask a “why” question.
This question type gets you the motivation
behind the request. It
can also unearth deeply hidden information
because it requires stakeholders to be really
conscious of their operations. These queries
are great questions to lead you to the
reason the company is spending money
pursuing this opportunity.

“Where” Questions If you need to understand where something is

happening, ask a “where” question.
“Where” questions help you understand
data sources and can also help with
planning.

“When” Questions If you want to know the time aspect of

something,
ask a “when” question. The “when”
question gives you an idea, when the
problem or the trigger
for a process occurs. The answers to
“when” questions also give you more clues
about how all the different stakeholders
and task are related— key information for
your overall understanding.

“How” Question The “how” question primes the pump for

getting down to a solution. The answer to a
“how” question helps you understand the
current way in which a task or activity is
done or the impact a change has to a
business area.

IMPORTANCE OF ELICITING INFORMATION

The result of elicitation are the core input for business analysis work.
Information is not only elicited to generate requirements or answer
questions from the solution team, but the information becomes the basis
to effectively complete the other business analyst’s tasks, such as:

 Support executive decision making

 Apply influence successfully
 Assist in negotiation or mediation
 Resolve conflict
 Define problems
Failing to elicit enough information can result in erroneous conclusions
and increased number of assumptions, but too many assumption may
hinder the team’s ability to move forward.
Many types of questions are used in gathering requirements information.
Using all types of questions as part of your requirements elicitation
activities allows you to organize and discover what the stakeholders need
and want within the scope of the proposed solution. Remember, skilled
requirements analysts are experts at asking questions, especially when
they don’t know the answers. The types of questions a skilled business
analyst should be proficient with include:

Research questions

These are general questions inviting your stakeholders to provide you

Meta Questions
with information about their concerns, interests, and needs relative to
the solution scope. Research questions allow a skilled business
analyst
Detailed to scope are
questions
Meta questions out powerful
the stakeholder needs.
tools. They People
allow youare
to comfortable
clarify and
answering
enhance what research
has questions
just been whensaid. the questions
Basically, are questions
meta not limitedare or
specific and the answers
questions about questions. are not controlled in any way. An example of
Directive
a questions
research
Detailed question
questions might
focus on be, “What
gathering constitutes
specific success
information for
within this
the
This communications strategy allows the business analyst to promote
predefined solution scope.
open communication These questionsway.
in a non-threatening are typically the stepclarify
Meta questions after
research
Directive questions
and summarize
questions whatand
are thehelp the business
business
used analyst
primarily analyst
has been
by business focus
told.
analystsonAnmore
inexample
group
specific
settings
of a metainformation
where that
thereis,
question are isyou
needed.
mind ifToI ask
“Docontradictions be thorough,
in what
you .detailed
the business
about . . ? ” analyst
questions
has should
been told. be framed
Directive around
questions the the
direct five other
Ws: who,
partieswhat,
to anwhere,
area
when,agreement
where and why. As your to
needs questions
be reached become more specific,
and sometimes awayit isfrom
veryan
important
area that istocontentious.
discourage one One- example
word answers, such as yes
of a directive and no.
question An
might
example
be, of the
“What is a detailed
relative question
priority ofis, “Who
this provides you with this
key feature?”
 MIND CHALLENGE # 1

The shipping team at Palmer Divide Vineyards

expressed concern about the reliability of current
inventory data at the winery. Recently, several cases of
a particular wine were sold to a distributor when they
were not currently in stock. Taylor, the IT director, sat
down with Bob, the shipping team lead, to figure out
what was going on.

Supposing you are Taylor, make a script/dialogue

between you and Bob by designing elicitation
questionnaire like a funnel, with the top of the funnel
representing high - level, scoping questions. As you
progress down the funnel toward the ground, your
questions become more and more detailed based on
what you have learned. At the bottom of the funnel, ask
very specific and detailed questions about what your
stakeholders do and what they need from your project.
remaining type ofsuggestedquestionsingathering
You start swith a research question then followed
informatio
by
n. the
 TECHNIQUES FOR ELICITATION

Techniques to Consider

You may use one or more of the following techniques when you are
preparing for the elicitation activities on your project. They are listed for
you here:

 Brainstorming
 Document Analysis
 Focus Groups
 Interface Analysis
 Interviews
 Observation
 Prototyping
 Requirements Workshops
 Survey/Questionnaire

Once you have selected and applied one or more techniques as part of
your preparation efforts, you are ready to conduct the elicitation activity
itself.

This elicitation technique fosters creative

Brainstorming thinking about the capabilities of a new
solution. Brainstorming enables out - of - the -
box thinking in a nonjudgmental environment.
Out - of - the - box thinking is also called
lateral thinking.

You should take the time to identify and define all of

Data Dictionary and the terminology that is being used as part of your
Glossary project. If you are lucky, you work in an organization
that already maintains
a business glossary of terms that apply to your
project efforts. Glossaries allow you to document any
key business terms along with their definitions. It is a
best practice to start your business glossary
immediately during that project’s controlled start and
to keep it updated throughout the project life cycle.
Data dictionaries are a bit more technical in nature. A
data dictionary is used to def ne data elements, their
meanings, and their allowable values. Building a data
dictionary for your project should begin when your
project requirements are being developed.
 Document analysis allows you to elicit,
Document Analysis confirm, or cross - check project requirements
information by studying existing
documentation and other relevant
information. These secondary sources of
information allow the business analyst to
gather details of existing solutions. To conduct
document analysis, you step through three
stages: preparation, review, and wrap - up.

Focus groups provide you with an interactive

Focus Group group environment to elicit ideas and attitudes
from selected stakeholders about a product,
service, or opportunity. The work done in a
focus group may be similar to a brainstorming
session, but a focus group is a more structured
event. Focus groups are a form of qualitative
research in which your participants are
prequalified to address a set of questions
about a particular topic.

Interface Analysis Interface analysis identifies and defines the

requirements for how a new solution and
its components will interact with
everything else that is already out there.
Everything else usually includes existing
solutions and their components. An
interface is a connection between two
components of a system. All external
interfaces should be considered

Interview A good interviewer comes to the table with

a high level of domain understanding,
experience in conducting elicitation
interviews, and the skills to ask relevant
questions and document the interview
results. Requirements elicitation interviews
may be structured or unstructured.
Structured interviews are driven by a
predefined set of questions. Unstructured
interviews are more of an informal, open -
Observation Observation is a great way to study people
while they are performing their jobs.
During requirements elicitation,
understanding what folks are doing now
sets the basis for the new capabilities they
will need in the future. Those new
capabilities are what you are defining in
your project requirements. Observation is
also called job shadowing or simply

Prototyping is a method of obtaining early

Prototyping
feedback on requirements by providing a
working model of the expected product
before building it. Since prototypes are
tangible, stakeholders are able to
experiment with a model of the final
product rather than discussing abstract
representations of the requirements.

Requirements Requirements workshops are structured

Workshop meetings where a selected group of
stakeholders works together to define or
refine a set of project requirement.
Requirements workshops have some very
specific goals. They include scoping,
discovering, defining, prioritizing, and
reaching closure on the requirements that
are being
defined for the new solution

Survey/ Questionnaire These are written sets of questions

designed to quickly accumulate information
from a large number of respondents.
Respondents represent a diverse
population and are dispersed over a wide
geographical areas. You do this by
administering a set of written questions to
your project stakeholders and SMEs. You
should choose whether or not to have your
survey responses returned to you
anonymously.
DEVELOP THE ELICITATION PLAN

An elicitation plan is the devise used by business analyst to help formulate

ideas about how to structure the elicitation activities. The plan is not a
formal document and does not take a lot of time to create. It can be
documented or can be the thought process used to prepare for the
forthcoming elicitation efforts. Some of the elements in the elicitation plan
include but are not limited to:

 What information to elicit.

 Where to find the information.
 How to obtain the information.
 Sequencing the elicitation activities.

Table 5.1 Example of Completed Elicitation Plan

What Information Source Method Sequence

How many employees HR Interview 2
will be moved?
What is the physical Building Documents 1
layout of both plans analysis
building? Facilities Interview
What equipment will IT Meeting 4
be moved? Facilities
Executive
VP
Shall we moved in all HR Interviews 3
at once or in a Executive VP
phased approach?
Is it possible to move Lega Meeting 5
people in before the l HR
building is Facilities
completely done? Building
contractor

Elicitation
PREPARE preparation may be formal or informal. Elicitation preparation is
FOR ELICITATION
the planning performed to conduct an effective elicitation session. The
business analyst may create informal preparation notes to organize and to
help facilitate the session.

 Determine Objectives
To ensure elicitation activities are effectively performed, the
business analyst should set an objective for each session to achieve.
The objective is the reason why the elicitation activity is being
undertaken.

 Determine the Participants

At the completion of stakeholder analysis, the business
analyst should have divided the long list of stakeholders identified
into group or classes. The
 result of stakeholder analysis could be used when selecting the
participants to invite to elicitation session.

 Determine the Question for Session

When the objective of the elicitation activity suggests using
interviews, focus groups, facilitated workshops, or other techniques
used to elicit information directly from stakeholders, the business
analyst may want to prepare some questions prior to conducting the
elicitation in order to ensure the session objectives are achieved.

CONDUCT ELICITATION ACTIVITIES

There are four stages during the actual elicitation activity in which
information is gathered:

1. Introduction. The introduction sets the stage, sets the pace,

and establishes the overall purpose for the elicitation session.

2. Body. The body is where the questions are asked and the answers are
given.

3. Close. The close provides a graceful termination to the particular

session.

4. Follow-up. The follow-up is where the information is consolidated

and confirmed with the participants.

COMPLETE ELICITATION

The following may indicate when sufficient information has been elicited:

 The stakeholder or problem owner approves the results.

 The model on which the information is based can be completed.
 A dry run or successful prototype is completed.
 The objective has been reached.
 The solutions) has been identified.
 All information pertaining to high priority requirements has been
confirmed by at least two independent sources.

MIND CHALLENGE #2

Watch the video linked below and make a personal

review on the realization you have gained from watching
it.

(video is on our FB group account)

 ELICITATION ISSUES AND CHALLENGES

There are a number of difficulties associated with elicitation, for example:

Conflicting viewpoints and needs among different types of users.

Conflicting information and resulting requirements from different
business units.
Unstated or assumed information on the part of the stakeholders.
Stakeholders who are resistant to change and may fail to
cooperate and possibly sabotage the work.
Inability to schedule time for interviewing or elicitation sessions because
stakeholders cannot take time away from their work.
Inability of stakeholders to express what they do or what they would
like to do. Inability of stakeholders to refrain from focusing on a
solution.

The following lists are some elicitation challenges :

The business analyst cannot gain access to the right

stakeholders. Stakeholders do not know what they want.
Stakeholders are having difficulty defining their requirements.
Stakeholders are not providing sufficient detail to develop the
solution

DOCUMENT THE ELICITATION RESULT

The documented results of your elicitation efforts are found in two

deliverables: the stated requirements and the stakeholder concerns. The
stated requirements are the requirements documented that provide the
stakeholder’s point of view of what is needed. Think of this as raw
stakeholder information; your stakeholders tell you what they think is
needed. Stakeholder concerns are any stakeholder issues that arise from
your elicitation activities. They can be many things, such as risks,
assumptions, and constraints that accompany the requirements
information you are gathering. Once these concerns are captured and
documented, they will need to be addressed by the business analysis
team.

Once you have documented the elicitation results, it is time to make sure
you got it right. Your next step will be confirming the elicitation results
with the stakeholders.
 Elicitatio
Document
Elicitation
Results

Brainstorming
Document Analysis
Focus Groups Interface
Stakeholder Confirm Elicitation Results Define Business
Case Define Assumptions and Constraints
Analysis Interviews Concerns Assess Organizational Readiness
Observation Problem
Tracking Prototyping
Requirements
Workshops
Survey/Questionnaire

Confirm Elicitation Results Define Business

Requirements Need Prioritize Requirements
Specify and Model Requirements Define
(Stated) Transition Requirements

Figure 5.1 Task Summary: Document and Elicitation Results

Elicitation Results. This is the information that you have elicited from your
stakeholders using one or more of the 10 common elicitation techniques.
The expectation is that a more formal summary of the elicitation event
will be produced, including the stated requirements and any stakeholder
issues or concerns.

Summarizing a particular elicitation event is typically done using:

 Written documents (such as meeting minutes)

 Visual or audio recordings
 Whiteboards for note taking during the elicitation activity

You may not have a lot of success recording interview sessions with
stakeholders. Many people are uncomfortable with this approach to noting
what was said, so it is best to ask permission to record an elicitation
interview or session as part of your elicitation preparation activities. You
should also have an alternative plan if your request to record an
elicitation session is not approved by the involved parties or not allowed by
the organization.

During the final

CONFIRM task of the
ELICITATION Elicitation knowledge area, you confirm the
RESULTS
stated requirements and stakeholder concerns with your stakeholders.
This important step ensures that you clearly understand the stakeholder
intentions and any related issues that might impact your requirements
and your project. You must make sure that you involve all stakeholders
who participated in the elicitation event.
 MIND CHALLENGE
#3

With the given number of challenges and

difficulties associated with elicitation, in what way
do you think a business analyst must do to
overcome them?

And we’re finally done with Module 5.

Congratulations!
The Elicitation knowledge area guide a business analyst in effectively
gathering and organizing requirements information at any level of detail.
It is difficult to develop complete and correct requirements for your
project if you do not elicit complete and correct information from your
stakeholders. Remember, elicitation is not just asking questions. Effective
communication skills are an underlying competency enabling a business
analyst to do this work. Successful projects start with defining and
agreeing to what is needed. Without the ability to elicit high - quality
requirements information, business analysts will find it difficult to perform
their jobs well.

There are 10 suggested elicitation techniques to elicit requirements

information for projects. You don’t need to be an expert in every
technique, but most experienced business analysts are comfortable using
a representative subset of those techniques. Each elicitation technique
should be approached and applied using the same marching orders:
prepare, conduct, and wrap up.

Your elicitation results must be documented and confirmed in order to be

used in subsequent requirements development activities such as analysis
and specification. The stated, confirmed requirements and any
stakeholder concerns are the building blocks from which the real
requirements for our projects will be derived.
Kupersmith, K. & Mulvey, P., Business Analysis for Dummies

Project Management Institute, Business Analysis For Practitioners: A

Practice Guide

[Link]