CBAP Elicitation Tutorial

3.2 Elicitation

Hello and welcome to the third module of Certified Business Analysis Professional™ (CBAP) (To be read as C-BAP) certification course offered by Simplilearn. This module deals with the Elicitation phase of the analysis process. In the previous module, we learned about the BA’s preparation for the elicitation phase of the project. In this module, we will learn to use that preparation to dig deeper into the company needs, requirements, and solutions. In preplanning for the elicitation, there was only one interview with the sponsor and the rest of the efforts were focused on studying company documents and reports. The 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 towards rapid development, approval, funding, and implementation. Let us look at the agenda of this module in the next slide.

3.3 Agenda

This slide provides an overview of what will be covered in this module. We will first look into the elicitation techniques. Then we will move on to requirements planning, risk analysis and management, enterprise analysis/business case, elicitation communications, enterprise analysis tasks, preliminary solution scope, and transition requirements. Finally, we will understand the elicitation results. Let us begin with the elicitation techniques.

3.4 Elicitation Techniques

Learning how to conduct the elicitation process becomes a talent for an experience 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 to not give opinions or present solutions prematurely. Elicitation is a detective work to gather the “facts”. Most stakeholders provide opinions but the BA must remain neutral at all times. An experienced BA understands how to rapidly develop credibility and trustworthiness 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 the problems and potential solutions, but also the knowledge of which stakeholders 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 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 ascertain how well the company follows its own rules and procedures. The BA does not want to become tedious by droning on over 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. Also, a person from the team or group should be designated to record the discussion for a later analysis and distribution to the stakeholders. Interface analysis deals with the impacts of 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.5 Elicitation Techniques(contd.)

Interviews are used for individual, one-to-one confidential settings where opinions can be expressed in confidence. The brainstorming and group elicitation techniques are for gathering up-to-date and a broad range of inputs, whereas interviews are for targeted areas of interest. 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 gain an advantage for themselves. In all cases, any important and unexpected information should be cross checked 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 performing as normal. Sometimes the BA will shadow a stakeholder or SME 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. 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 impacts on interfacing activities. Horizontal prototyping is used when a wide view of the solution is needed to see the impact. Vertical prototyping is a simulation focused on the narrow impact of a solution. SDLC prototypes (system development life cycle) are used to elicit requirements across the life cycle of the project. Prototypes are meant for the end user. The throw-away SDLC prototypes are used in a trial and error process in the development of a long term solution. These temporary solutions are discarded once a final solution is developed. Evolutionary prototypes are prototype solutions that are seen as a functional prototype. 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 idea of requirements and potential solutions, as well as prioritize requirements. Requirement 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 on point and avoid 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 providing them with a survey or questionnaire at the least allows them to participate in the discovery process. Surveys and questionnaires use open-ended questions to allow the stakeholder 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 understand requirements planning in the next slide.

3.6 Requirements Planning

During the elicitation activities, it is important to extract a consensus opinion from the stakeholders and SMEs on needs, and requirements to meet those needs within the context of the most probable solutions. Gathering stakeholders is costly and can interrupt daily operations. Hence, the scheduling of the elicitation activities should be planned to leverage the expertise, experience, and minimize the time and cost to the company to obtain important aspects of the requirements. The following are the important aspects: First is to be focused on obtaining consensus agreement from the key stakeholders and SMEs on needs, potential solutions, and requirements. Second is to plan the elicitation with enough time to extract the above. Make sure to optimize the activities around the stated goals. Identifying potential risks and constraints is the third aspect. Document the consensus results is the natural culmination of the elicitation process. It is a good idea to appoint a note taker or use a recording device to capture all the ideas and remarks. However, the participants must be assured of the confidentiality of their statements before recording. Once the meetings are over, the BA can return and transcribe the most salient points and distribute them among the participants to make sure there was an agreement to what was said. Lastly, present a tentative list of needs, potential solutions, and requirements to help launch quickly into the elicitation process. Assess if there are any constraints on the requirements such as adequate funding, company, or governmental rules and regulations, etc. The stakeholders directly involved with the area of concern will provide the most realistic appraisal of the current and post fix situation. As the project progresses, identified key stakeholders, and area SMEs will be valuable resources that help in providing the important information to assure the success of the project. Requirements management and communication will be covered in detail in the next module. Let us understand risk analysis and management in the next slide.

3.7 Risk Analysis and Management

First pass at identifying risk and constraints. Once a consensus on requirements and potential solutions have been obtained from the elicitation activities, if time allows during the elicitation activities, stakeholders and SMEs should voice their concerns about perceived risks and constraints. Although these concerns can be completed in detail later in the process, the BA should get an idea of what the risks and constraints might be, so another elicitation activity can be scheduled to drill down into the subject. The elicitation process is again the first in-depth pass in listening to stakeholders and SMEs define risks and constraints and helping define the project. Elicitation continues throughout the project by using identified key stakeholders and SMEs. Once risks and contingencies have been uncovered and discussed, the stakeholders and SMEs may have a ready solution or idea of what needs to be done. In general, even at this early stage of the project, consensus solutions such as whether or not to bypass (work around the problems), mitigate (fix the problem directly) or assume risks (do nothing) can be proposed at the stakeholder level. Prioritize risks and constraints. Once they are prioritized, determine how risks and constraints can affect the requirements prioritized list. In the next slide let us move on to enterprise analysis and business case.

3.8 Enterprise Analysis Business Case

From the results of the elicitation activities, the BA can start adding meaningful content to the enterprise analysis. The IIBA (International Institute of Business Analysis) defines enterprise analysis as: “enterprise analysis is how Business Analysts identify a business need, refine and clarify the definition of that need, and, define a solution scope that can feasibly be implemented by the business. This knowledge area describes problem definition and analysis, business case development, feasibility studies, and the definition of solution scope. ” During pre-elicitation, the BA should have an idea from the documents analysis and sponsor interview as to what the basic concept of the project might be. After the elicitation activities, the consensus findings can present a more concrete idea of the real situation and can now be put into document form. As the requirements and solutions become more defined, so will the Enterprise Analysis. The enterprise analysis presents the logical development of needs, and the steps to remedy the needs. The analysis is like a road map of how to successfully arrive at solutions. Normally, included in the conclusion or summary of the enterprise analysis, document is a section on the business case ¬¬– -also known as the project justification. Before a project can be approved and funded, the board of directors or another controlling body needs to fully understand the project. The business case is a summary of the enterprise analysis and presents why, how, and, how much the project will benefit the company. The business case often acts as an abstract or executive summary for the enterprise analysis. Let us look into the elicitation communications in the next slide.

3.9 Elicitation Communications

This slide demonstrates the continual ebb and flow of communication between the stakeholders, the BA, and the sponsor. Every time a consensus is reached on a need, requirement, solution or risk, there needs to be a round of cross examination and validation as to the worthiness and utility of the observations. The BA must constantly document the process so as to build traceability of the decision process. For example, if a consensus decision does not work as expected, there will be a paper trail of how the decision was made and where the flaws might be. This process of passing information between all participants and documenting the process forms the backbone of the analysis. The BA guides and documents the process. In the next slide, let us understand enterprise analysis tasks.

3.10 Enterprise Analysis Tasks

This slide lists the tasks required to develop the enterprise analysis. The content of the listed tasks grows as the analysis process develops. However, after the results of the elicitation activities, the BA should have enough information to start all of the listed tasks. Create and maintain the business architecture: as solutions and requirements are defined, the structural organization of the company may have to adapt to accommodate the addition of new solutions. For example, the introduction of new equipment or software may require a new department or new job descriptions and shifting areas of responsibilities. Conduct feasibility study: although the BA may have an idea of what solutions and requirements are needed before the elicitation activities, after analyzing the results of the input from the stakeholders and SMEs, the BA will have a better idea of what the capabilities and assets of the company are. If there are more costs or complexity involved in the project, the BA must check with the sponsor to ensure the company has a chance to respond to any potential added costs or complexities. The project must be able maintain a competitive position in its market segment at all times. Most projects are based on maintaining or improving the company’s competitive advantages. Determine project scope: the results of the elicitation activities should provide enough information for the BA to design the initial project scope, at least from a high level perspective. Prepare the business case: is the act of developing the document that describes why the project makes sense and is a good investment for the company. The business case is an important document that should be held off from presenting until all the information about the project has been identified, confirmed, validated, and a cost-benefit analysis has been completed. Conduct initial risk assessment: once the solutions and requirements have been identified, the potential risks and constraints need to be considered. Some risks may be bypassed and others mitigated or assumed. Mitigation and bypassing risks may have significant costs that can greatly impact the business case. Prepare the requirements package and communication: may be premature at this stage; however, key stakeholders and sponsor should be kept updated on the status of the project on a regular basis. Select and prioritize project tasks: the results of the elicitation activities should provide enough input to form a requirements package that is listed in order of priority. This document is passed to the organization to ensure the requirements are realistic and are within the financial scope of the project. Selecting and prioritizing project tasks are at the heart of the enterprise analysis. This allows an estimated time schedule to be established and assign stakeholder roles and responsibilities. Again, at this stage, everything is subject to change. Managing the project: is an ongoing process but with the post-elicitation activities, the BA will have enough information to move to a proactive state of building motivation and action plans. Tracking the project benefits: is a part of managing the project. The BA must be constantly aware that the proposed deliverables can be achieved within the time and budgetary constraints established. Preliminary solution scope will be discussed in the next slide.

3.11 Preliminary Solution Scope

According to the IIBA, the solution scope is required as a basis of requirements management and is used to determine whether a proposed requirement supports the business goals and objectives. For post-elicitation results, the potential solutions are developed on a high level without going into the due diligence of full investigation. Validated solutions come later in the process. For now, the project solutions and requirements take a general form with enough information to secure confirmation that the project is on the right track. Requirements management is composed of requirements matched to solutions that have been reviewed and approved by key stakeholders as valid. Over time, stakeholders may come up with new iterations of existing solutions which will require review of the requirements to make sure they are suitable for the evolving solutions. If new risks or constraints to solutions are found, requirements may also change. Solution scope management is an ongoing process of updating the solution scope when new solutions or requirements replace prior suggestions. It is important that the BA keep the sponsors and stakeholders updated with the information. Stakeholder roles and responsibilities are assigned for each solution. Stakeholders should be held accountable for helping the BA analyze the best solutions and associated requirements. The BA becomes like the “conductor” of specialists helping to refine and validate solutions and associated requirements. Transition is when a new solution is run in parallel with the existing system. This allows testing and training without interrupting the normal business flow. Stakeholders and end users help design the transition which will accompany a solution. These transitions may have their own requirements. Let us understand transition requirements in the next slide

3.12 Transitition Requirements

Transition requirements arise during the intermediate stage when the solution scope is being implemented at the same time the existing processes are being used. Transition requirements are usually secondary effects of making the primary change requirements. Once the proposed requirements and organizational capabilities have been identified, a transition requirement may or may not be needed if the company has the ability to adapt and make minor adjustments. After stakeholders and SMEs decide on a transition solution, a design and process is developed to define the exact requirements. Often, transition requirements will alter the primary task timetable and can affect the readjustment of the entire project sequence. The slide demonstrates how existing documents are adjusted and refined to redefine the new iteration of the proposed solutions, requirements, and organizational capabilities. In other words, the analysis is an ongoing and fluid process that requires constant evolution through the same process of forming consensus, validation, and documentation. We will discuss elicitation results in the next slide.

3.13 Elicitation Results

The diagram represents the inputs and outputs of the elicitation phase of the project. As a result 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 what the goals of the company. Let us summarize what we have learnt so far in the next slide.

3.15 Summary

We started this module with the discussion of elicitation techniques and how to elicit the broad range of ideas to help form a consensus of opinions between the various stakeholders, SMEs, and sponsor. The results will start the formation of the requirements planning. Once the needs and requirements are identified, the list undergoes an examination of the risks and how risks can be managed. The list is now prioritized and the company analyzed as to its capacity in talent and assets to resolve the proposed problems. The next step for the BA is to start the enterprise analysis document and start to build the business case which is a narrative of how the project is justified. During the entire elicitation phase, there is a constant interchange of information and ongoing communications to help reach a consensus on each need, requirement, and solution. The next step is to form the preliminary solution scope. Stakeholders review the preliminary scope to determine the likely secondary effects that might happen during and after implementation. These are called transition requirements that will need to be clearly identified before any implementation starts. Sometimes, transition requirements become known only after actual implementation has started. At the end of the elicitation process, the BA can start to formalize all the documentation needed to build the pre-implementation project plan. The elicitation phase is where the BA needs to take into account all that makes each company different and subject to variations in solutions to similar problems experienced by other like companies. Now, let us go through a few questions to check your understanding on the concepts discussed. In the next module we will discuss requirements management and communications.

Find our Certified Business Analysis Professional (CBAP®) Online Classroom training classes in top cities:

Name Date Place
Certified Business Analysis Professional (CBAP®) 1 May -23 May 2021, Weekend batch Your City View Details
Certified Business Analysis Professional (CBAP®) 14 May -5 Jun 2021, Weekdays batch Your City View Details
Certified Business Analysis Professional (CBAP®) 17 May -7 Jun 2021, Weekdays batch Your City View Details
  • 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*