Elicitation Tutorial

3.1 Elicitation

Hello and welcome to the third lesson of the Certification of Competency in Business Analysis™ (CCBA®) course offered by Simplilearn. This lesson deals with the Elicitation phase of the analysis process. In the previous lesson, we learned about the BA’s preparation for the elicitation phase of the project. In this lesson, we will learn to use that preparation to delve further into the company needs, requirements, and solutions. In preplanning for the elicitation, there was only one interview conducted with the sponsor and the rest of the efforts were focused on studying company documents and reports. Elicitation moves from the abstract phase to a more concrete phase by eliciting the planned information from key stakeholders, subject matter experts (SMEs), and any resource or person associated with the project. Once the elicitation phase is complete, the project will proceed toward rapid development, approval, funding, and implementation. Let us look at the objectives of this lesson in the next slide.

3.2 Objectives

After completing this lesson, you will be able to: Describe the elicitation knowledge area Learn the tasks associated with Elicitation Explain the concept of Document Analysis Describe the types of elicitation techniques Describe how to document requirements Let us begin with an introduction to Elicitation.

3.3 Introduction to Elicitation

Elicitation defines the tasks associated with the 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 for their business. There are many different techniques used for elicitation that we will cover in detail in this lesson. Let us look at the Elicitation Knowledge Area diagram.

3.4 Elicitation Knowledge Area Diagram

The following are the inputs, which are derived from planning and monitoring. (Note: most of the inputs, outputs, and techniques have been discussed in lesson 2): Business Case is the assessment of the costs and benefits associated with a proposed initiative. Business Need Organizational Process Assets Requirements Management Plan Solution Scope is the set of capabilities a solution must deliver to meet the business need. Stakeholder List, Roles, and Responsibilities The following are the outputs: Elicitation Result is the information that was captured by the business analyst from the stakeholders. Scheduled Resources include the participants, the location in which the elicitation activity will occur, and any other resource that may be required. Stakeholder Concerns are the issues, risks, assumptions, constraints, and other relevant information collected by the business analyst. Supporting Materials are required to help explain the techniques used or to perform them. The next slide will cover the prepare for elicitation diagram task.

3.5 Prepare for Elicitation Diagram

The following are the inputs: Business Need Solution Scope and Business Case Stakeholder List, Roles, and Responsibilities The following are the outputs: Scheduled Resources Supporting Materials The following are the techniques: Brainstorming Document Analysis Focus Groups Interface Analysis Interviews Observation Prototyping Requirements Workshops Survey/Questionnaire In the next slide, we will be discussing document analysis.

3.6 Document Analysis

Once a potential client expresses interest in a project, the BA should ask for documentation to understand the business. Most companies will require a Non-Disclosure Agreement (NDA) for confidentiality before sending or communicating any important or proprietary information or documentation. Once the BA reviews the documentation, it helps to facilitate an in-depth elicitation from the sponsor and stakeholders. An effective BA should be able to ask the right questions. Studying the documentation is the first step in elicitation. The following are the standard documents for review. At this stage, the BA tries to review the documents without disturbing the potential client. In general, a business plan is an important document that is developed to help the company document its goals, strategies, and tactics to reach those stated goals. Some business plans are very detailed and cover many areas that would be found in separate documentation. The business plan should be the first document to be reviewed. Usually, the business plan will be for the current year. It is also important to find out if the business plan is being used to benchmark the actual performance toward stated goals. A strategic plan is about the strategies the company plans to use to compete in the market place, as well as to position products in certain market segments, penetrate into new markets, or introduce new products or services and for defensive competitive positioning. A marketing plan focuses on sales and marketing activities. It strategizes on gaining new customers and retaining the existing customer base. Larger companies are structured into Strategic Business Units (SBUs) and each unit has its own marketing plan for its market segment. Importantly, the marketing plan contains budgeting, and important benchmarks and metrics to monitor performance constantly. We will continue our discussion on the documents to be reviewed in the next slide.

3.7 Document Analysis(contd.)

The following are the standard documents to be reviewed: Business rules, procedures, and policies are usually found in the company policies and procedures manual where there is a detailed description of standard operating procedures (SOPs) and acceptable parameters for day-to-day operations. Process flow is often difficult to understand if it is not clearly explained in the policies and procedures, usually in the form of a process flow chart. However, an experienced BA should have an idea of industry-specific functions and it is up to the BA to understand the process flows in the client’s industry. Enterprise architecture is another name for company organization chart. This helps to detail the processes, the chain of command, and the areas of responsibility and accountability. However, what is on paper may not be the reality. Enterprise architecture is one of the first findings to be looked for once the BA is in the elicitation phase of the project. The BA has to assess the company assets and abilities to be able to make the required changes; otherwise, an outside vendor may be required. We will look into some more documents to be reviewed in the following slide.

3.8 Document Analysis(contd.)

The following are the standard documents to be reviewed: Job descriptions are a more detailed aspect of the organization. In a fully documented organization plan, job descriptions should match each category of employees along with their responsibilities and accountabilities. Job descriptions will help the BA identify the subject matter experts and other stakeholders. Financial reports are generally the most confidential and are not disclosed without a signed NDA unless the company’s CFO is tasked with providing performance metrics. In case of some less sophisticated companies, the BA might have to develop quantitative measures for benchmarking and performance analysis. These metrics will require information from the operating statements and balance sheets of the company. IT system description schematic is important for a specific software requirement and solution. Even if the project is not software related, the BA should have a good understanding of how internal IT and communications function. Let us move on to the conduct elicitation diagram in the next slide.

3.9 Conduct Elicitation Activity Diagram

The outputs of the planning processes become the inputs and are as follows: Business Need Organizational Process Assets Requirements Management Plan Scheduled Resources Solution Scope and Business Case Supporting Materials The output on the right is: Elicitation Results The common BA techniques, which are used in elicitation, are: Brainstorming Document Analysis Focus Groups Interface Analysis Interviews Observation Prototyping Requirements Workshops Survey/Questionnaire In the next slide, we will be discussing more about elicitation techniques.

3.10 Elicitation Techniques

Learning how to conduct the elicitation process becomes a talent for an experienced BA. The BA has learned how to prepare the proper format and type of “interrogation” to draw out the important information without presenting a biased agenda. The BA learns to follow the information to where it leads. During the elicitation phase, the BA must always be aware of the need of not giving opinions or presenting solutions prematurely. Elicitation is like a detective’s work to gather the “facts”. Most stakeholders provide opinions, but the BA must remain neutral at all times. An experienced BA understands how to develop credibility and trustworthiness rapidly by being a good listener rather than a good speaker. The key to the elicitation process is the knowledge of what questions to ask and how to follow a thread of information to its essence. Brainstorming is an excellent way to get a group to overcome inhibitions and participate in a meaningful way. Brainstorming not only provides insight on problems and potential solutions, but also reveals the knowledge of the stakeholders who are communicative and knowledgeable about certain topics or areas of interest. This knowledge will help the BA to drill down during interviews and develop the selection of stakeholder roles and responsibilities. The BA or a designated person should take notes of all the brainstorming sessions in order to record traceability. Brainstorming also helps with promoting diverse thinking for exploring multiple options of a solution; exploring solutions to problems within the project; revealing possible risks and constraints; exploring business opportunities; encouraging stakeholder participation; and fostering team building. Document analysis is done as a preparation for pre-elicitation; however, the BA should have identified the pertinent areas in documentation that would apply to the needs, requirements, and solutions. The preparation from pre-elicitation research will allow the BA to use documentation analysis to help guide the elicitation, as well as to ascertain how well the company follows its own rules and procedures. The BA does not want to become tedious by droning on about the documentation. However, the BA should be able to use the existing documentation to promote the elicitation of ideas. The BA will usually present an appropriate portion of a document and “wrap it up” with a collection of ideas from the stakeholders. Using focus groups is an efficient way to gather a wide range of information and consensus from a large, qualified group for an identified topic from the appropriate stakeholder and SME group. Focus groups require a moderator to keep the group from wandering off the interested topics. In addition, a person from the team or group should be designated to record the discussion for later analysis and distribution to the stakeholders. Interface analysis deals with the impact that a particular need, requirement, and solution can have on other surrounding or connected activities. Normally, this is a good topic for a focus group—drawn from the cluster of tasks and processes that surround a new solution or change to the existing operations. This is important in case of new software applications. The potential for interface problems should be detected as early as possible into the project. We will continue our discussion on the elicitation techniques in the next slide.

3.11 Elicitation Techniques(contd.)

Interviews are used for individual, one-on-one confidential settings where opinions can be expressed in confidence. The brainstorming and group elicitation techniques are for gathering a broad, up-to-date range of inputs, whereas interviews are for targeted areas of interest. The results are documented. There are structured interviews where the analyst has specific questions and there are unstructured interviews, which can be used to build trust between the analyst and interviewee before focusing on a key area of interest. During an interview, the analyst should refrain from taking notes until the interviewee has left. All interviews should be carried out in a place that provides privacy and puts the interviewee at ease. An experienced BA will be aware that some stakeholders/employees may try to further their own agendas, which they feel will provide them an advantage. In all cases, any important and unexpected information should be crosschecked carefully with other sources before coming to any conclusion. There are two types of observation: The first one is open and visible observation, where there is no concern of the BA’s presence influencing what is being observed. For example, when employees know they are being watched, they may perform differently than normal. The second form of observation is invisible, where the BA’s presence is not visible to those performing the task and can be observed as normal. Sometimes the BA will shadow a stakeholder or SMEs during their normal tasks or even pretend to be an apprentice in a particular situation to get a better understanding of a process or procedure. Due to insurance restrictions, most companies prefer passive observation to active observation where a non-company employee/person is not protected by a proper insurance. The results are documented. Problem Tracking provides an organized approach to the tracking, management, and resolution of defects, issues, problems, and risks throughout business analysis activities. Management of these issues is important so that they can be resolved in a timely manner to ensure success. Prototyping is a good way to test a potential solution by performing a simulation of what would happen when a particular solution is tried. In other words, prototyping can provide validation that a solution works properly. This can be important in testing for impact on interfacing activities. Prototyping integrates user interface requirements with use cases, data, and business rules through storyboarding, dialog hierarchy, screen prototypes, or screen mockups. Requirements workshops are structured meetings where a selected group of stakeholders work together to define or refine a set of project requirements. Remember, a requirement is a condition or capability needed by a stakeholder or solution to solve a problem or need. During the workshops, the stakeholders are provided with a preliminary list of requirements. The goal of the workshops is to promote consensus of requirements and potential solutions, as well as prioritize requirements. Requirements workshops also allow the BA to choose the key stakeholders and SMEs to drill down into the requirements and solutions if needed. In most group activities, a moderator or host is used to help keep the workshop to the point and avoid it from being deviated too far off the subject. After these workshops are concluded, the BA should document and communicate the findings with the appropriate stakeholders. Surveys/questionnaires are a good approach to gather anonymous input from a wide range of stakeholders and employees. Some stakeholders may not be able to attend the elicitation activities and therefore, providing them with a survey or questionnaire at the least allows them to participate in the discovery process. The best practice for surveys is to have a large group of users complete the survey so that you get different perspectives in a short time. It should contain closed or open-ended questions, be sent to a targeted audience, and should limit branching. Surveys and questionnaires use open-ended questions to allow the stakeholders to choose how they wish to provide an answer. However, close-ended questions ask for specific answers to questions. Close-ended questions need to be designed to elicit a specific response, whereas open-ended questions elicit general answers, which allow room for information that may be important. Let us discuss documenting the results in the following slide.

3.12 Document Elicitation Results Diagram

The inputs conducting elicitation activities are Elicitation Results. The outputs on the right are Requirements [Stated]. These requirements have not been prioritized or organized in any way. The following are the common elicitation techniques that were just reviewed, in the order of presence from the bottom of the diagram: Brainstorming Document Analysis Focus Groups Interface Analysis Interviews Observation Problem Tracking Prototyping Requirements Workshops Survey/Questionnaire In the next slide, we will be discussing confirming results.

3.13 Confirm Elicitation Results Diagram

The following are the inputs on the left: Requirements are a condition or capability needed by a stakeholder to solve a problem or achieve an objective. These are stated requirements that have not been confirmed. Stakeholder Concerns include issues identified by the stakeholder, risks, assumptions, constraints, and other relevant information. These concerns have not been confirmed. The confirmation will happen in this task and will be an output as Stakeholder Concerns [confirmed] shown below. The following are the outputs: Requirements [stated, confirmed] which were validated during this process. Stakeholder Concerns [confirmed] which were also validated during this process. The following are the techniques: Interviews Observation In the next slide, we will be discussing elicitation results.

3.14 Elicitation Results

The diagram represents the inputs and outputs of the elicitation phase of the project. Because of the execution of the pre-planned elicitation activities, valuable information in depth and breadth has been gathered to form the foundation for the enterprise analysis and project definition. The purposes of the elicitation are two-fold: first, to gather detailed information and to build the sequence of documented steps that are needed to build a consensus of needs and requirements that will meet the stated company goals. The second purpose of elicitation is to identify and confirm the stakeholder needs and concerns to make sure they are aligned with the goals of the company. Now, let us go through a few questions to check your understanding on the concepts discussed.

3.16 Summary

In this lesson, we have learned that the Elicitation knowledge area denotes a continual ebb and flow of communication between the stakeholders, the BA, and the sponsor. Once a potential client expresses interest in a project, the BA should ask for documentation to understand the business. The standard documents for review are the business plan, strategic plan, marketing plan, business rules, procedures, and policies, process flow, enterprise architecture, job descriptions, financial reports, and IT system description schematic. The elicitation techniques are brainstorming, document analysis, focus groups, interface analysis, interviews, observation, problem tracking, prototyping, requirements workshops, and surveys/questionnaires.

3.17 Thank You

In the next lesson, we will discuss requirements management and communications.

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Request more information

For individuals
For business
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Work Email*
Phone Number*
Job Title*