Part III
Elicitation in Practice
Historically, organizations have not understood the value of investing significant amounts of time and cost to involve the customer, end-user, and business process owner throughout the project life cycle. Indeed, the pressure to deliver projects faster has never been greater. However, we are beginning to understand the consequences of abbreviated requirements activities. Hooks and Farry1 state that more than 80 percent of all product defects are introduced in the requirements phase. Professional business analysts employ targeted elicitation practices to improve requirements quality and eliminate requirements defects early in the project life cycle.
The business analyst needs to select elicitation activities that provide the best opportunity for information exchange. There are several considerations that influence the choice of elicitation techniques, including project cost and time constraints, the availability of participants, the culture of the organization, and the requirements deliverables to be produced. The goal is to right size the amount of rigor used for requirements elicitation for each project. Although mature organizations provide tools and templates to guide requirements elicitation sessions, the project team needs to consider tailoring the approach to the unique needs of the project. Scheduling too many elicitation sessions is a process and resource waste. Too few sessions may result in missing, incomplete, or inaccurate requirements that are identified later in the project life cycle. In this case, the project schedule and budget are at risk because planning for the adequate number of sessions was not considered earlier.
To be successful in this endeavor, the business analyst needs to become knowledgeable and skilled in all elicitation techniques, understanding their strengths and weaknesses, and plan for just the right amount of rigor.
Talking to project stakeholders is mandatory. Talking to them with a purposeful elicitation plan is a learned skill.
The elicitation process can be referred to as requirements gathering, requirements definition, or requirements discovery. The best practice is to define the terms used in the environment and consistently use the same term with all stakeholders in formal and informal communication. This part of the book discusses elicitation, but there are some key considerations to mention first:
When conducting elicitation sessions, the business analyst starts the meeting by reviewing the importance of the project; its strategic alignment; the objectives, scope, assumptions, and constraints; and expected business benefits so that all participants understand the significance and urgency of the endeavor. Inputs to the elicitation process that provide this information may include:
Business case
Project charter
Feasibility study
Stakeholder analysis
User analysis
Approved requirements management plan (RMP)
Elicitation activities are performed concurrently with the initiation and planning processes described in The PMBOK® Guide.
The output of elicitation is the first iteration of the business requirements document (BRD) accompanied by supporting information that is further elaborated and decomposed during requirements analysis and specification.
Design, construction, and test activities have not begun, although a high-level solution concept was developed during Enterprise Analysis activities.
Elicitation does not occur only in the requirements phase, but continues throughout the business solution life cycle as additional requirements are derived or discovered and formally added through the change management process.
The elicitation process is dependent on access to the user groups. Some dispersed global groups may be accessible only through a survey. Other groups will be involved minimally if they have been deemed of low importance or are peripheral to the business area undergoing change. Others may be involved in multiple elicitation sessions and feedback loops. Refer to the figure on the next page, which demonstrates the iterative interaction between the business analyst and user groups.
Many elicitation techniques are available for use by the business analyst; however, only a few are generally recognized as the most effective and appropriate for general use. In this part, we discuss the most commonly used techniques. For each technique we present common variations, key rules for effective use of the technique, and guidelines for tailoring the technique to the project characteristics.
In Chapter 7 we present the most commonly used requirements elicitation technique, brainstorming.
In Chapter 8 we discuss how the business analyst plans and facilitates the most rigorous requirements elicitation techniques, facilitated workshops and discovery sessions.
In Chapter 9 we present interviewing techniques.
In Chapter 10 we discuss the value and usefulness of surveys.
In Chapter 11 we discuss documentation reviews.
In Chapter 12 we discuss the importance of analyzing interfaces.
In Chapter 13 we discuss the techniques for identifying supplemental requirements.
Refer to The Art and Power of Facilitation: Running Powerful Meetings, another volume in the Business Analysis Essential Library series, for a detailed presentation of tools and techniques that can be used to successfully prepare for and facilitate requirements elicitation sessions.
Endnote
1. Ivy F. Hooks and Kristin A. Farry. Customer Centered Products: Creating Successful Products Through Smart Requirements Management, 2000. New York: American Management Association.