3.2 Conduct Elicitation

3.2 Conduct Elicitation

Core Purpose and BABOK v3 Context

Task 7: Conduct Elicitation represents the execution phase of the elicitation process. Armed with the Elicitation Activity Plan produced during preparation, the Business Analyst actively engages stakeholders, inspects systems, analyzes documents, and runs experiments to discover business analysis information. Elicitation is an exploratory, dynamic process that requires a blend of interpersonal skill, analytical discipline, technical acumen, and situational adaptability.

The direct output of Task 7 is Elicitation Results (unconfirmed). At this stage, the gathered information represents raw data, notes, audio transcripts, whiteboard sketches, and prototype feedback. It has not yet been cross-referenced, validated against authoritative sources, or formally confirmed by stakeholders.

---

Three Primary Elicitation Categories

BABOK v3 categorizes all elicitation activities into three distinct types: Collaborative, Research, and Experiments. A robust business analysis initiative integrates techniques across all three categories to achieve a 360-degree understanding of business needs.

                    ┌────────────────────────────────────────┐
                    │          CONDUCT ELICITATION           │
                    └───────────────────┬────────────────────┘
                                        │
         ┌──────────────────────────────┼──────────────────────────────┐
         ▼                              ▼                              ▼
┌─────────────────┐            ┌─────────────────┐            ┌─────────────────┐
│  COLLABORATIVE  │            │    RESEARCH     │            │   EXPERIMENTS   │
├─────────────────┤            ├─────────────────┤            ├─────────────────┤
│ • Workshops     │            │ • Document Review│            │ • Prototyping   │
│ • Interviews    │            │ • Benchmarking  │            │ • PoC Trials    │
│ • Focus Groups  │            │ • Data Mining   │            │ • Pilot Runs    │
└────────┬────────┘            └────────┬────────┘            └────────┬────────┘
         │                              │                              │
         └──────────────────────────────┼──────────────────────────────┘
                                        ▼
                    ┌────────────────────────────────────────┐
                    │     Elicitation Results (Unconfirmed)  │
                    └────────────────────────────────────────┘

1. Collaborative Elicitation

Collaborative elicitation involves direct, real-time interaction with human stakeholders. The BA acts as a facilitator, interviewer, or discussion leader to draw out ideas, surface hidden assumptions, and reconcile differing perspectives.

• Workshops (JAD/Requirements Sessions): Highly interactive sessions bringing together cross-functional teams to define business rules, process flows, and solution capabilities.
• Interviews: Structured or semi-structured one-on-one sessions that dive deep into specific subject matter expertise.
• Collaborative Modeling: Real-time drafting of process maps or data flow diagrams alongside stakeholders during a session.

2. Research Elicitation

Research elicitation entails independent discovery of information from secondary sources without requiring active real-time stakeholder involvement. It minimizes stakeholder disruption while establishing objective, factual context.

• Benchmarking: Comparing an organization's business processes, metrics, or software capabilities against industry standards or direct competitors.
• Market Analysis: Studying customer trends, regulatory shifts, and emerging technological capabilities.
• Data Mining & Analytics: Analyzing transactional database logs, error reports, and system traffic to identify empirical operational patterns.

3. Experiments

Experimental elicitation is used when requirements cannot be clearly articulated through conversation or documentation alone. It relies on tangible trials, interactive mockups, and iterative feedback loops to discover unknown requirements.

• Prototyping: Creating visual, interactive representations (throwaway, evolutionary, or wireframe) to let users experience solution workflows.
• Proof of Concept (PoC): Building a limited technical prototype to test feasibility, performance limits, or algorithm accuracy.
• Pilot Runs: Implementing a partial solution within a restricted operational subset to observe real-world performance.

---

Facilitation and Group Dynamics Management

During collaborative elicitation, managing human group dynamics is critical. BAs must foster psychological safety while keeping sessions productive and on-schedule. Key facilitation skills include:

• Managing Dominant Personalities: Senior executives or vocal SMEs may overshadow quieter participants. BAs employ techniques such as Nominal Group Technique (silent writing before verbal sharing) or Round-Robin polling to equalize contribution.
• Active Listening & Probing: BAs must listen for underlying needs rather than immediate feature requests. Utilizing open-ended questions ("What happens when a customer cancels mid-transaction?") and paraphrasing ("What I hear you saying is that authorization must occur within 2 seconds...") ensures accurate comprehension.
• The Parking Lot Technique: Off-topic discussions, while valuable, threaten session schedules. BAs record tangential ideas on a visible "Parking Lot" board, reassuring participants that their input is recognized while steering the group back to the agenda.

---

Unearthing Implicit vs. Explicit Requirements

A central challenge in Task 7 is distinguishing between Explicit and Implicit requirements:

• Explicit Requirements: Stated clearly and directly by stakeholders ("The portal must issue a confirmation email within 5 seconds of order placement").
• Implicit (Tacit) Requirements: Unspoken assumptions, routine habits, and operational workarounds that stakeholders take for granted ("Of course the system automatically adjusts for daylight saving time"). Operational staff often perform critical tasks out of muscle memory without mentioning them.

BAs uncover implicit requirements through Active Observation, 5 Whys Root Cause Analysis, and Scenario-Based Walkthroughs.

---

BACCM Connections in Execution

• Change: Uncover the specific capabilities required to transition the enterprise from current state to future state.
• Need: Probe deeply to expose true root-cause problems rather than superficial symptom complaints.
• Solution: Present experimental models and prototypes to discover user preferences.
• Stakeholder: Facilitate active dialogue and manage group dynamics across diverse organizational roles.
• Value: Focus elicitation probing on high-value business outcomes and customer benefits.
• Context: Capture how environmental factors, regulations, and legacy infrastructure influence operational behavior.

---

Worked Example: E-Commerce Mobile Checkout Redesign

Scenario: A major retail enterprise experiences a 45% drop-off rate on its mobile checkout page. A BA is assigned to conduct elicitation to identify root causes and redesign requirements.

BA Elicitation Execution:

1. Research Stream: The BA analyzes web analytics telemetry (Data Mining) and discovers that 80% of abandonments occur at the address verification step. The BA also conducts competitive benchmarking against top retail apps.
2. Experimental Stream: The BA creates a low-fidelity interactive Figma prototype featuring a 1-click Apple Pay / Google Pay checkout flow.
3. Collaborative Stream: The BA runs three 60-minute usability testing sessions (Focus Groups) where shoppers interact with the prototype while thinking aloud. Concurrently, the BA conducts 1-on-1 interviews with customer service reps to understand daily phone complaints.

Result: Elicitation unearths an implicit requirement: mobile shoppers expect instant address auto-completion via GPS geolocation. Capturing this unconfirmed finding leads directly to a streamlined mobile architecture.

---

CBAP Exam Tips & Common Pitfalls

💡 Exam Tip: On the CBAP exam, carefully identify the category of elicitation described in the scenario. If a BA is reviewing competitor software capabilities, it is Research (Benchmarking). If a BA is testing user reactions to a wireframe mockup, it is an Experiment (Prototyping). If a BA is holding a JAD session, it is Collaborative.

⚠️ Common Trap: Never treat notes gathered during Task 7 as final approved requirements. Remember that the output of Task 7 is Elicitation Results (unconfirmed). The BA must proceed to Task 8 (Confirm Elicitation Results) before modeling or baseline verification can occur.