Knowledge areas BABOK Guide v3, chapter 4

Elicitation and Collaboration

In short This knowledge area covers how you draw out information from stakeholders and other sources, confirm that you understood it correctly, share analysis results, and keep people working with you. It is not a phase: you elicit and collaborate in almost every analysis task.

Based on: IIBA, BABOK® Guide v3, chapter 4 “Elicitation and Collaboration”; business analysis training materials (task reference cards and course slides).

On this page

Purpose#

Elicitation means getting information out of people, documents, data and systems. The BABOK® Guide deliberately pairs it with collaboration: most of what you learn comes from working with stakeholders, and the quality of that relationship decides the quality of what you get.

Two points shape how you should think about this area:

  • Elicitation is continuous. It happens throughout the initiative, not only at the start. It can be planned (a scheduled workshop), unplanned (a hallway conversation that reveals a new rule) or partly planned.
  • Elicitation includes your own research. Not everything comes from asking. Studying documents, analyzing data and running experiments are elicitation too.

Through the lens of the Business Analysis Core Concept Model, you use elicitation to understand the change and stakeholder concerns, build understanding of needs step by step, learn which solution characteristics matter, judge the relative value of the information you collect, and take account of context that could affect the change.

Tasks#

The BABOK Guide defines five tasks.

4.1 Prepare for Elicitation. You decide what information you need, from whom or from which sources, and with which techniques. You make sure participants know what is expected of them, arrange logistics, and gather background material or set up an experiment if needed. You produce: an elicitation activity plan.

4.2 Conduct Elicitation. You run the planned activities: talk to stakeholders, study sources, run experiments. You produce: elicitation results that are not yet confirmed.

4.3 Confirm Elicitation Results. You check that you and the stakeholders understood the same thing, that your records are accurate and complete, and you compare results with other information to spot inconsistencies. You produce: confirmed elicitation results.

4.4 Communicate Business Analysis Information. You get the right information to the right people at the right time, in a format and vocabulary they understand. You produce: business analysis information that has been communicated.

4.5 Manage Stakeholder Collaboration. You keep stakeholders engaged in the analysis process over time, deal with collaboration problems early, and make sure you can still get the contributions you need. You produce: stakeholder engagement.

Key inputs and outputs#

Task What goes in (simplified) What comes out
4.1 Prepare The needs being addressed; the stakeholder engagement approach from planning Elicitation activity plan
4.2 Conduct The activity plan Unconfirmed elicitation results
4.3 Confirm Unconfirmed results Confirmed results, used by strategy analysis and requirements analysis
4.4 Communicate Any analysis information; the engagement approach Information that stakeholders have received and understood
4.5 Manage collaboration The engagement approach; the analysis performance assessment Ongoing stakeholder engagement

Techniques you will use most#

The training materials group elicitation activities into three kinds. Use this grouping to make sure you are not relying on one kind only.

Also useful across the tasks:

Practical tips#

Plan around gaps, not around techniques. Start the elicitation plan with the questions you cannot yet answer, then pick the cheapest technique that answers each one. A plan that lists only “interviews” is usually a sign of habit, not design.

Combine sources to cross-check. What people say, what documents say and what actually happens often differ. Pair a collaborative technique with a research or experimental one on important topics.

Confirm quickly. Send a short summary of each session within a day or two and ask participants to correct it. The longer you wait, the more both sides “remember” differently.

Separate confirmation from approval. Confirming results (task 4.3) checks that you captured what people meant. Approving requirements belongs to Requirements Life Cycle Management. Mixing the two makes stakeholders reluctant to confirm drafts.

Match the format to the audience. An executive sponsor and a developer need different views of the same information. Decide format, level of detail and terminology per audience; a shared Glossary helps.

Watch collaboration as a risk. Missed meetings, slow answers and silent participants are early warning signs. Raise them with the sponsor before they turn into missing requirements.

Example: planning elicitation at The Workshop#

The Workshop (a fictional chain of 12 bike-repair shops) wants online booking and repair-status notifications. A first elicitation plan might combine:

  • interviews with the owner and two workshop managers about goals and constraints;
  • observation of the front desk during a busy Saturday morning to see how bookings and status calls are really handled;
  • document analysis of paper job cards and the parts supplier’s order forms;
  • a short customer survey about preferred booking times and notification channels;
  • a workshop with managers, mechanics and front-desk staff to walk through the future booking flow.

After each activity, the analyst sends a one-page summary for confirmation and logs open questions in an item list.

Sources and further reading#

  • IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Chapter 4 “Elicitation and Collaboration”.
  • Business analysis training materials (practice examples and templates): task reference cards for chapter 4; course slides on elicitation and collaboration (collaborative, research and experimental elicitation activities).