Stakeholder-Specific Elicitation Planning

Welcome back. In the previous lesson, you turned a requested feature into an evidence-based problem statement with affected users, a measurable target, and explicit assumptions. That work gives elicitation a purpose: you are not simply collecting a list of requested features; you are finding the information needed to understand the problem, define its boundaries, and make sound decisions.

This is the first lesson focused on discovery within the Role Targeting and Cross-Industry Discovery module. You will create a stakeholder-specific elicitation plan: a practical plan that identifies who to involve, what each person can contribute, how much authority they have, and which technique respects their time while producing credible information. This is a portfolio-worthy analyst artifact and a frequent interview topic for Technical Business Analyst and Requirements Analyst roles.

---

Elicitation is planned evidence collection, not meeting scheduling

An elicitation plan is often mistaken for a calendar of workshops. A calendar answers, “When will people meet?” A good elicitation plan answers five more important questions:

1. What must be learned or decided?
2. Which stakeholder, document, system record, or observation can provide that information?
3. What authority does that participant hold?
4. What kind of knowledge do they possess?
5. Which technique will obtain reliable information within their availability constraints?

The distinction matters because authority and knowledge are not the same.

• A business sponsor may approve budget, scope, or priority but have only second-hand knowledge of daily operational problems.
• A frontline user may understand workarounds, exceptions, and pain points in detail but have no authority to approve a solution.
• A compliance officer may be the authoritative source for a policy rule but may only have twenty minutes for a focused review.
• A technical lead may not decide business priority but can identify integration dependencies, data limitations, and implementation risks.

A common elicitation failure is to ask one senior person to answer every question. That produces a fast answer, but not necessarily an accurate one. The analyst instead designs a small system of complementary evidence.

A useful principle is:

Match the technique to the information needed, then adapt it to the stakeholder’s authority, knowledge, and availability.

---

Profile stakeholders before choosing techniques

Before sending invitations, build a stakeholder profile. Start with the problem statement from the previous lesson and identify who is affected, who performs the work, who provides inputs, who controls rules, who owns data, and who can make decisions.

The stakeholder power-interest matrix below helps prioritize engagement. It is not a substitute for analysing knowledge or decision rights, but it prevents a plan from overlooking influential stakeholders.

Use the matrix carefully:

• High power, high interest: involve closely in key decisions and trade-offs. These people may be sponsors, product owners, or accountable operations leaders.
• High power, lower day-to-day interest: keep satisfied through concise decision briefs and well-timed approval checkpoints. Do not consume their time with detailed workflow interviews unless they genuinely own that knowledge.
• Lower power, high interest: keep informed and involve them in discovery when they use, support, or are strongly affected by the process.
• Lower power, lower interest: monitor proportionately. They may still need consultation if they own a dependency or are affected by a particular exception.

For each stakeholder or group, record the following.

Planning dimension	What to capture	Why it matters
Stake and role	What they do, what they gain or lose, and how the change affects them	Clarifies why they belong in the plan
Authority	Decision-maker, approver, policy owner, influencer, contributor, or informed party	Prevents seeking approval from the wrong person
Knowledge type	Operational, policy, technical, customer, data, or strategic knowledge	Determines what they can credibly validate
Availability and access	Shift pattern, location, time zone, workload peak, language, and access constraints	Determines whether workshops, interviews, observation, or asynchronous methods are realistic
Information needed	Current workflow, exception, metric definition, business rule, technical constraint, or decision	Prevents vague meetings
Technique and output	Method, format, expected artifact, and confirmation approach	Makes the activity purposeful and traceable

Knowledge is not all of one kind

It helps to distinguish four common forms of knowledge.

Knowledge type	Typical holder	Strong elicitation approach
Explicit knowledge	Policy owner, process owner, technical architect	Document analysis, focused interview, structured review
Tacit procedural knowledge	Agent, coordinator, technician, operations user	Observation, shadowing, workflow walkthrough, contextual interview
Quantitative knowledge	Data analyst, operations manager, reporting owner	Data analysis, report review, interview to interpret findings
Experiential knowledge	Customer, end user, support representative	Interview, usability feedback, prototype review, survey followed by deeper conversations

For example, a call-centre agent may say, “We just check three systems before answering the customer.” Observation can reveal the actual details: which system is checked first, which status is unreliable, when they switch to a spreadsheet, and which exception requires a supervisor. That is tacit knowledge. It is often missed in sponsor interviews and process documents.

The planning principle is particularly relevant where participants have limited availability. Shift workers, field staff, customer-support agents, and busy approvers should not be forced into a technique that is convenient only for the analyst.

---

Match the technique to the stakeholder and the decision

Elicitation generally combines three approaches:

• Collaborative elicitation: direct interaction with people through interviews, workshops, observation, reviews, and co-design.
• Research elicitation: analysis of documents, policies, tickets, process records, metrics, logs, and existing requirements.
• Experimental elicitation: prototypes, simulations, pilots, or other controlled ways to learn what will work.

A reliable plan uses more than one approach because stakeholders may disagree, documents may be outdated, and operational data may reveal a pattern without explaining its cause.

Choosing the right technique

Technique	Use it when	Stakeholder fit	Main limitation
Document and record analysis	Existing policies, SOPs, tickets, reports, or requirements provide useful context	Busy approvers, policy owners, data owners, technical teams	Documents may be incomplete, outdated, or different from real practice
One-to-one interview	You need rationale, context, rules, priorities, or detailed follow-up	Sponsors, process owners, SMEs, technical leads, compliance owners	One person’s view is not automatically organisational truth
Observation or shadowing	You need to understand actual work, handoffs, workarounds, and exceptions	Frontline users, support teams, coordinators, field staff	Requires time, consent, and representative sampling
Workshop	Multiple teams must align on a workflow, definition, dependency, or trade-off	Cross-functional representatives with sufficient authority	Expensive in participant time; poor preparation can let senior voices dominate
Survey or questionnaire	You need broad input, frequency estimates, or prioritised themes from many people	Large, distributed, shift-based, or externally located groups	Provides breadth rather than depth; question design can bias results
Prototype review	Users need something concrete to react to, especially for screens or interactions	End users, customer-facing teams, product owners	Validates understanding of an option; does not prove that the option solves the root problem
Data analysis	You need to validate scale, trend, baseline, or performance claims	Data owners, reporting leads, operations managers	Explains what is happening, but usually needs interviews to explain why

A technique should never be selected merely because it is familiar. For example:

• A workshop is not automatically appropriate just because several departments are involved. If the team does not yet understand the current process, start with targeted interviews, document review, and observation.
• A survey is not a replacement for speaking to key users. It can identify patterns, but it rarely uncovers exceptions or causes.
• An interview with a sponsor is not a substitute for observing frontline work.
• A prototype is valuable after you have understood the user need sufficiently to test an interaction or workflow assumption.

Authority determines the participant’s role in the plan

Use authority to define what you need from each person.

Authority level	Appropriate role in elicitation	Suitable methods
Accountable decision-maker	Confirm objectives, success measures, priority trade-offs, scope boundaries, and unresolved decisions	Short structured interview, decision review, targeted workshop checkpoint
Approver or control owner	Validate policy, regulatory, security, financial, or governance constraints	Document analysis, focused review, exception-based interview
Process owner	Confirm end-to-end workflow, ownership, KPIs, and escalation paths	Interview, process walkthrough, workshop
Subject-matter expert	Explain rules, terminology, edge cases, data meaning, or technical constraints	Interview, model review, technical walkthrough
Frontline contributor	Reveal real work, pain points, workarounds, and exception handling	Observation, contextual interview, short survey, prototype feedback
External user or customer	Describe needs, outcomes, comprehension, and service experience	Interview, survey, usability or prototype feedback
Influencer	Surface concerns, adoption risks, and informal organisational dynamics	Targeted interview, workshop participation, review of findings

The key distinction is this: people contribute according to their knowledge, and decisions are confirmed according to authority.

---

Worked example: service-request status visibility

Continue the fictional home-services scenario from the previous lesson.

The sponsor’s initial request was:

“Add WhatsApp notifications for every service-request update. Customers keep calling for status.”

The problem statement was broader:

Customers cannot reliably confirm appointment and request status, creating uncertainty and avoidable status-enquiry contacts.

The elicitation objective is not “collect requirements for WhatsApp.” It is:

Understand why customers lack reliable status information, identify the affected workflow and constraints, validate the contact-rate baseline, and agree the scope and success measures for an improvement.

Here is a stakeholder-specific plan.

Stakeholder or group	Authority and knowledge	Availability	Technique and format	Expected output
Customer operations sponsor	High decision authority; strategic view of customer experience and cost	Thirty minutes per week	Structured interview, then a concise decision review	Confirm business outcome, target metric, priorities, and scope trade-offs
Contact-centre manager	Medium authority; strong knowledge of contact reasons, staffing, and operational KPIs	Forty-five-minute session	Interview supported by ticket-category and report review	Validate baseline, contact classification, peak periods, and operational impact
Contact-centre agents	Low formal authority; high tacit knowledge of customer questions and workarounds	Shift-based; difficult to schedule together	Two short observations, contextual interviews, and a brief asynchronous pulse survey	Identify actual lookup steps, recurring uncertainty, and exception scenarios
Scheduling and dispatch lead	Medium authority; strong knowledge of appointment rules and technician-status updates	One-hour scheduled session	Workflow walkthrough using a draft current-state sketch	Clarify status changes, ownership, timing, rescheduling, and data gaps
Technical lead	Authority over technical feasibility; knowledge of integrations and data flow	Forty-five-minute technical session	Existing-interface review followed by targeted interview	Identify data source, update timing, integration constraints, and failure risks
Privacy or compliance owner	Approval authority for customer communications and data handling	Limited time; available for focused review	Policy and consent-record analysis, then a twenty-minute exception review	Confirm communication consent, retention, audit, and channel constraints
Customers with recent open requests	Lived experience; no delivery authority	Distributed and variable availability	Short survey, followed by selected interviews or prototype feedback	Validate whether the issue is confirmation, rescheduling, delay explanation, channel preference, or another concern

Notice several deliberate choices:

• The sponsor is consulted early but is not asked to explain agent workarounds.
• Agents are not placed in a long workshop during shifts. Observation and short follow-ups respect their availability and reveal actual practice.
• Compliance receives focused material rather than a general discovery invitation.
• The customer survey provides breadth, but selected interviews provide context behind the responses.
• The technical lead is involved before a preferred communication channel becomes an assumed solution.
• A cross-functional workshop happens after initial evidence is collected, not as the first activity.

Sequence the activities to reduce confusion

For this scenario, the plan could be organised as follows:

1. Research preparation: review ticket categories, service-request statuses, existing customer communications, consent rules, reports, and prior change requests.
2. Targeted discovery: interview the sponsor, contact-centre manager, dispatch lead, and technical lead; conduct observation with selected agents.
3. Broad validation: issue a short customer or agent survey if the initial evidence needs wider confirmation.
4. Cross-functional alignment: facilitate a focused workshop with representatives from operations, support, dispatch, technology, and compliance.
5. Confirmation and decision: circulate a concise summary of findings, assumptions, conflicts, and proposed scope; obtain confirmation from the appropriate decision-maker and approvers.

The workshop should have a narrow purpose, such as agreeing the status events customers need to understand and identifying ownership for each event. It should not attempt to solve every unknown in one sitting.

---

Build the elicitation plan artifact

For an interview portfolio, create a one-page Stakeholder-Specific Elicitation Plan for a sanitised scenario. You may use the home-services case or a disguised automotive, content-platform, or internal-workflow scenario.

Start with a short header:

Field	Example
Initiative	Improve service-request status visibility
Problem statement	Customers and agents lack timely, reliable request-status information, causing avoidable status enquiries
Elicitation objective	Validate root causes, workflow gaps, rules, constraints, scope, and measurable success criteria
Primary decision owner	Customer Operations Director
Planned completion window	Two weeks
Confirmation method	Findings summary reviewed by process owner, technical lead, compliance owner, and sponsor

Then use this planning table.

Stakeholder / source	Stake and role	Authority	Knowledge needed	Availability constraint	Technique	Planned activity and output	Confirmation owner
[Name or role]	[Why affected]	[Decision / approval / SME / contributor]	[What only they can clarify]	[Time, shift, location]	[Method]	[Session or analysis output]	[Who validates]

A high-quality plan normally includes at least:

• one accountable decision-maker;
• one or more frontline or end-user perspectives;
• a process or domain SME;
• a technical or data perspective where systems are affected;
• policy, security, finance, legal, or compliance input when relevant;
• existing evidence sources such as documents, reports, system records, or tickets.

Final quality check

Before sharing the plan, check the following:

• Every stakeholder has a clearly stated reason for involvement.
• Every planned activity has a defined outcome, not just a meeting title.
• High-authority stakeholders are engaged for decisions, priorities, and approvals rather than assumed to know every operational detail.
• High-knowledge contributors are engaged for the information they actually possess.
• Limited availability has led to a suitable method, such as asynchronous review, observation, brief interviews, or surveys.
• Important claims will be triangulated using more than one source where possible.
• The plan identifies who will confirm each important finding.
• The plan is realistic about time, culture, location, confidentiality, and language.

Do not write “workshop with all stakeholders” unless you can explain who must attend, what decision or artifact the workshop will produce, and why an individual interview or document review would not be sufficient.

---

Key takeaways

An elicitation plan is a deliberately designed approach for obtaining reliable information and decisions. It is more than an agenda: it links an elicitation objective to participants, evidence sources, authority, knowledge, availability, techniques, expected outputs, and confirmation responsibilities.

Use authority to identify who can decide or approve, and use knowledge to identify who can explain reality. Interviews uncover rationale, observation exposes tacit work, surveys provide breadth, workshops enable alignment, documents and data establish context, and prototypes test a tangible interpretation.

Next, you will turn this plan into a structured set of discovery questions for an unfamiliar business domain—questions that uncover goals, workflows, rules, data, exceptions, risks, and success measures without prematurely prescribing a solution.