AI-Assisted Stakeholder Analysis & Requirements Elicitation

Overview

Stakeholder analysis and requirements elicitation are among the highest-stakes activities a business analyst performs. Getting them wrong — missing a key stakeholder, failing to surface a critical requirement, or misunderstanding the relative influence of competing interests — can cascade through an entire project, resulting in rework, scope changes, delivery delays, and ultimately a product that fails to deliver the expected value. These activities demand not just technical skill but political intelligence, communication sensitivity, and deep organizational knowledge.

AI does not replace this human judgment. What it does is dramatically accelerate the preparation and synthesis work that surrounds stakeholder engagement — building stakeholder maps, designing interview guides, structuring elicitation outputs, and detecting conflicts between stakeholder positions. A skilled BA who uses AI effectively can engage more stakeholders more deeply, produce higher-quality structured requirements from the same raw inputs, and identify conflicts earlier and more systematically than one working without AI assistance.

This topic covers the complete AI-assisted stakeholder analysis and requirements elicitation workflow: from initial stakeholder identification through requirements synthesis and conflict resolution. Each phase includes the specific prompting approaches that produce the highest-quality outputs, and the validation steps that ensure AI-generated artifacts remain grounded in real stakeholder reality rather than generic templates.

The fundamental principle throughout is: AI handles the structural and synthesis work so you can dedicate your human attention to the relationship-building, trust development, and nuanced interpretation that no AI can replicate. Use AI to prepare better questions, structure better interviews, synthesize notes faster, and identify conflicts more systematically — while reserving your irreplaceable human judgment for what those findings mean and what to do about them.

Mapping Stakeholders with AI — Influence, Interest, and Communication Needs

Stakeholder mapping is the foundational activity that determines the quality of everything that follows. A stakeholder map that misses a key influencer, or misclassifies a high-power stakeholder as low-interest, will result in inadequate engagement at critical moments — and the consequent surprises during review, sign-off, or deployment. The traditional approach to stakeholder mapping — interviewing project sponsors, reviewing org charts, and making educated guesses about influence and interest — is time-consuming and systematically biased toward the stakeholders you already know.

AI can accelerate stakeholder identification significantly when given a detailed project description. It applies pattern recognition across organizational structures, common project types, and stakeholder categories to generate a candidate stakeholder list that is typically more complete than what a BA would produce from memory and immediate context alone. The AI-generated list is a starting point, not a final answer — it must be validated against organizational reality — but it surfaces candidate stakeholders (regulatory bodies, downstream data consumers, support teams, legal and compliance functions) that are frequently overlooked in initial mapping exercises.

The power/interest grid is the most widely used stakeholder classification framework, and AI can populate it when given a project description and stakeholder list. The four quadrants produce four distinct communication strategies: high power/high interest stakeholders (key players) require close engagement and co-creation; high power/low interest stakeholders (keep satisfied) require regular briefings and early flagging of issues that might escalate to their level; low power/high interest stakeholders (keep informed) require detailed, frequent updates; low power/low interest stakeholders (monitor) require periodic check-ins. AI can generate specific communication approaches for each stakeholder in each quadrant when prompted correctly.

A stakeholder register is the working document that captures all stakeholder data in a single, maintainable artifact. AI can generate a draft stakeholder register from a project description, including: stakeholder name/role, department, power/interest classification, primary interest in the project, potential concerns, preferred communication style (when specified), and recommended engagement approach. This draft register dramatically reduces the time required to build the initial stakeholder map and ensures consistent coverage across all register fields.

Hands-On Steps

Write a detailed project description that includes: project objective, scope boundaries, impacted systems, impacted business processes, expected organizational changes, and any known constraints or sensitivities.
Run a stakeholder identification prompt to generate a candidate stakeholder list. Include both named individuals (if known) and role categories.
Review the AI-generated list with your project sponsor. Add any stakeholders the AI missed, and remove any who are genuinely out of scope.
For each confirmed stakeholder, gather available context: their organizational role, their relationship to the project deliverables, any known concerns or history with similar projects, and their communication preferences.
Run a stakeholder classification prompt to populate the power/interest grid. Review each classification with your project sponsor — AI classification of political power is inherently approximate and requires human validation.
Run a communication strategy generation prompt to produce a recommended engagement approach for each stakeholder segment.
Compile the outputs into a stakeholder register document. Assign an owner for each stakeholder relationship (typically the PM or BA responsible for that stakeholder's domain).
Schedule the first round of stakeholder engagement based on the register. Prioritize high power/high interest stakeholders for immediate 1:1 conversations.

Prompt Examples

Prompt:

You are a senior business analyst conducting a stakeholder analysis for a new project.

Project description:
We are implementing a new digital procurement platform to replace our current manual purchase order process. The project will affect the way purchase orders are created, approved, and tracked across all business units. Key scope elements include: integration with our existing ERP system (SAP), a new supplier portal for external vendors, automated approval workflows, and real-time spend analytics dashboards for finance and procurement leadership. The project is expected to take 12 months and affect approximately 200 internal users and 85 external supplier organizations.

Organizational context:
- Company size: 1,200 employees
- Industry: Manufacturing
- Key departments: Procurement, Finance, Operations, IT, Legal/Compliance, individual Business Units (Marketing, Sales, R&D, Production)

Generate a comprehensive stakeholder identification list. For each stakeholder, include:
1. Stakeholder name/role (use role titles since we haven't named individuals yet)
2. Department or organization
3. Relationship to the project: directly impacted user, decision-maker, data provider, regulatory stakeholder, or downstream consumer
4. Brief description of their interest in or concern about the project

Organize the output into three sections:
- Internal stakeholders (employees and departments)
- External stakeholders (suppliers, regulators, partners)
- System/process stakeholders (teams who own systems or processes being changed)

Expected output: A comprehensive stakeholder list of 20-30 stakeholders organized by category. Internal stakeholders should include Procurement Manager, CFO/VP Finance, IT Director, ERP System Owner, Business Unit Heads, Legal/Compliance Officer, Accounts Payable team, and department-level PO approvers. External stakeholders should include supplier account managers and any relevant regulatory bodies. System/process stakeholders should include the SAP system owner, the IT integration team, and the current manual process owners. Each with a description of their specific interest or concern.

Prompt:

You are a senior business analyst building a stakeholder engagement plan.

Here is our confirmed stakeholder list for the procurement platform project:
[Paste validated stakeholder list]

For each stakeholder, classify them on the Power/Interest grid:
- High Power / High Interest: Key Players — manage closely
- High Power / Low Interest: Keep Satisfied — keep updated, don't over-communicate
- Low Power / High Interest: Keep Informed — provide regular detailed updates
- Low Power / Low Interest: Monitor — periodic check-ins only

After classifying each stakeholder, generate a specific communication strategy for each quadrant that includes:
1. Communication frequency (weekly, bi-weekly, monthly, as-needed)
2. Communication format (1:1 meeting, email update, dashboard access, steering committee presentation, workshop)
3. Content focus (what topics are most important to communicate to this stakeholder segment)
4. Escalation trigger (what circumstances would require escalating to this stakeholder outside the normal cadence)

Output as a stakeholder register table with columns: Stakeholder Role | Department | Power/Interest | Communication Frequency | Format | Content Focus | Escalation Trigger.

Expected output: A fully populated stakeholder register table with 20-30 rows, each classified into a quadrant with a tailored communication strategy. The CFO and Procurement Director should appear in High Power/High Interest with monthly steering committee presentations plus ad-hoc escalation for budget or timeline risks. Supplier account managers should appear in Low Power/High Interest with regular portal training updates. The ERP System Owner should appear in High Power/Low Interest with focused technical integration updates and early flag of any integration scope changes.

Learning Tip: After generating the stakeholder register with AI, validate every power classification in person with your project sponsor before using it to guide engagement. AI infers power from organizational title and role description, but real organizational influence is political, contextual, and often invisible on an org chart. A department head with low formal authority can have enormous informal influence — and the reverse is equally common. The AI register is your starting draft; human political intelligence finalizes it.

Generating Stakeholder Interview Guides and Question Sets with AI

A well-designed interview guide is the difference between an elicitation session that surfaces the requirements you need and one that produces vague, high-level wish lists. Most BAs spend significant time designing interview guides from scratch for each project — a process that is time-consuming but produces guides that are tailored to the specific stakeholder's role, concerns, and context. AI can accelerate this preparation dramatically while maintaining the role-specific tailoring that makes interview guides effective.

The structure of an effective stakeholder interview guide follows a consistent format regardless of role or project type: an opening that builds rapport and sets expectations for the session, a context-setting section that surfaces the stakeholder's mental model of the current situation (which may differ significantly from the project's formal scope), a core questions section that addresses the primary information needs for this stakeholder, a probing questions section that prepares the interviewer to go deeper when core questions produce incomplete or unexpected responses, and a closing that confirms understanding, identifies follow-up actions, and sets expectations for how the session output will be used.

The key to effective AI-generated interview guides is providing sufficient context about the stakeholder's role, the project's current state, and what you already know (or suspect) about this stakeholder's concerns. Generic interview guides produce generic answers. A guide tailored to a specific role — say, a warehouse operations manager whose team will be directly impacted by a new ERP module — will surface operational requirements that a generic BA interview template will completely miss.

Probing questions are where interview guides most commonly fail. A BA who has prepared core questions but not probing questions will get surface-level answers and not know how to go deeper. AI is very effective at generating probing questions for each core question — questions that are designed to be asked when the initial answer is incomplete, contradictory, or unexpectedly brief.

Hands-On Steps

For each key stakeholder (typically high power/high interest and high power/low interest first), gather context: their role, their team's relationship to the project deliverables, any known concerns or historical context, and what information you specifically need from this session.
Determine the session format: 30-minute discovery call, 60-minute structured interview, 90-minute requirements workshop with multiple stakeholders, or facilitated focus group.
Run an interview guide generation prompt with the stakeholder context and session format as inputs.
Review the generated guide. Customize the opening for your actual relationship with the stakeholder (formal or informal, new relationship or established). Remove any questions that are not relevant to this project.
Add any questions that the AI missed based on your domain knowledge or project-specific information gaps.
Generate probing questions for the 3-5 core questions you expect to generate the most important requirements.
Prepare a brief context document for the stakeholder to review before the session (AI can generate this too): a one-page project overview, the purpose of the interview, and a preview of the main topics to be covered.
After each session, use the interview guide as the structure for note-taking — this makes synthesis significantly easier when you run the synthesis prompt later.

Prompt Examples

Prompt:

You are a senior business analyst designing a stakeholder interview guide.

Project context: We are implementing a new digital procurement platform to replace a manual PO process. The project includes ERP integration, a supplier portal, automated approvals, and spend analytics.

Stakeholder context:
- Role: VP of Operations
- Department: Operations
- Team size: ~80 people across 3 shifts in the manufacturing facility
- Known concerns: Her team currently submits most of the high-volume, low-value POs (consumables, maintenance supplies). She has expressed informal skepticism about new software implementations based on a difficult ERP rollout two years ago.
- Information we need: Current pain points in the PO process for operations, volume and urgency patterns for operations purchases, approval authority levels and who can approve what, any regulatory or safety requirements for specific procurement categories.

Design a 60-minute stakeholder interview guide with the following sections:
1. Opening (5 minutes): rapport-building and session framing
2. Context-setting (10 minutes): understand her current experience and mental model
3. Core questions (30 minutes): 6-8 questions targeting the information we need
4. Probing questions: 3 probing questions per core question (to be used when responses are brief or surface-level)
5. Closing (15 minutes): confirmation, next steps, and expectation-setting

Tailor the questions specifically to the VP of Operations role and her known concerns. Use plain language — avoid BA jargon like "functional requirements" or "use cases."

Expected output: A complete 60-minute interview guide with role-specific questions such as "Walk me through how your team handles an urgent purchase when a machine breaks down and you need a part immediately — what happens from the moment someone identifies the need to the moment the order is placed?" and probing questions like "You mentioned the current process takes 24 hours for urgent orders — what typically causes that delay?" The guide should address her known skepticism by including a context-setting question about her previous ERP experience and how she would define success for a new system.

Prompt:

You are a senior business analyst preparing interview guides for a multi-stakeholder requirements elicitation phase.

We have identified 5 stakeholder groups for the procurement platform project, each requiring a tailored interview approach. For each stakeholder group, generate a set of 8-10 core interview questions tailored to their role and primary concerns.

Stakeholder groups:

1. Finance Leadership (CFO and VP Finance)
Primary concerns: spend visibility, budget control, audit trail, compliance
Information needed: current reporting gaps, spend approval thresholds, audit requirements, integration needs with financial reporting

2. Procurement Team (Category Managers and Procurement Analysts)
Primary concerns: supplier management, contract compliance, process efficiency
Information needed: current workflow steps, supplier onboarding process, contract reference during PO creation, volume by category

3. Business Unit Heads (Marketing, Sales, R&D)
Primary concerns: speed of procurement, autonomy vs. control, user experience
Information needed: current friction points, frequency of urgent purchases, delegation of authority, approval bottlenecks

4. IT Department (ERP System Owner, Integration Architect)
Primary concerns: data integrity, system integration, security, maintainability
Information needed: current SAP architecture constraints, API availability, data governance requirements, security and access control

5. External Suppliers (Key Account Managers for top 10 suppliers)
Primary concerns: payment timeliness, communication clarity, order accuracy
Information needed: current pain points in receiving and responding to POs, preferred communication format, portal adoption appetite

For each stakeholder group, format the questions as:
- Context questions (2-3): understand their current state experience
- Pain point questions (2-3): surface specific frustrations and workarounds
- Requirements questions (3-4): elicit specific needs for the new system

Expected output: Five tailored question sets, each with 8-10 questions organized into context, pain point, and requirements categories. Finance questions should include questions about spend reporting cycle time and what information is currently unavailable or hard to access. IT questions should include questions about the current SAP integration architecture and what data flows exist between procurement and finance. Supplier questions should ask about current invoice and PO discrepancy handling, which is often a major pain point invisible to internal stakeholders.

Learning Tip: Always prepare probing questions before the interview, not during it. In the heat of an elicitation session, when a stakeholder gives an unexpected or particularly interesting answer, the instinct is to move on because you have a list of prepared questions to get through. Prepared probing questions give you permission to go deeper on the most important topics. A rich answer to two questions is worth more than surface answers to ten.

Synthesizing Elicitation Session Outputs into Structured Requirements

Elicitation sessions generate raw, unstructured information: transcripts, notes, whiteboard photos, post-it summaries, and email follow-ups from stakeholders who remembered something important after the session ended. Synthesizing this material into a structured requirements artifact is one of the most time-consuming and mentally demanding steps in the BA's workflow — and it is where AI delivers some of its highest value.

The synthesis workflow has three stages. The first stage is raw notes to structured requirements: AI reads the session notes and extracts discrete requirements, organizing them by category (functional, non-functional, constraint, assumption). This stage eliminates the blank-page problem and produces a draft artifact in minutes rather than hours. The second stage is gap identification: AI reviews the extracted requirements against the project scope and stakeholder map to identify areas where requirements are missing — scope elements that were not addressed in the session, stakeholder concerns that were raised but not resolved into requirements, and dependencies that are implied by the requirements but not explicitly stated. The third stage is requirements refinement: AI iterates on individual requirements to improve precision, testability, and clarity.

The quality of synthesis output depends heavily on note quality. The best note-taking approach for AI-assisted synthesis is structured capture: label each note with the speaker (stakeholder role or name), the topic, and the type of information (current state, pain point, requirement, concern, constraint). Unstructured narrative notes are harder for AI to synthesize accurately. Even a simple formatting convention — using different symbols for different types of captures — significantly improves synthesis quality.

Requirements categories provide the organizational structure for synthesis output. Functional requirements describe what the system must do (behaviors, features, business rules). Non-functional requirements describe how the system must perform (performance, security, reliability, usability, compliance). Constraints are restrictions on design or implementation that are not negotiable (regulatory requirements, technology platform mandates, budget limits). Assumptions are conditions that are believed to be true but have not been verified and must be confirmed (assumed user base, assumed data availability, assumed integration capability).

Hands-On Steps

Immediately after each elicitation session, review and clean your notes while the session is fresh. Add any remembered details, mark quotes you want to preserve verbatim, and flag any topics where you are uncertain about the stakeholder's exact intent.
Format the notes with structure labels: [CURRENT STATE], [PAIN POINT], [REQUIREMENT], [CONCERN], [CONSTRAINT], [ASSUMPTION]. Even partial labeling significantly improves synthesis quality.
Run a requirements extraction prompt with the formatted notes as input.
Review the extracted requirements. Flag any requirement that seems to have been incorrectly categorized (e.g., a constraint classified as a functional requirement).
Run a gap analysis prompt: "Given the project scope [description] and these extracted requirements from the [Role] session, what important requirements areas are not addressed? What open questions remain?"
For each identified gap, determine whether: (a) the topic was covered but not captured clearly — review your notes, (b) the stakeholder genuinely did not address this area — schedule a follow-up, or (c) this area is out of scope for this stakeholder — route to the right stakeholder.
Run individual requirements refinement prompts for any requirement that is ambiguous, untestable, or lacks sufficient detail for development.
Aggregate requirements from all stakeholder sessions into a consolidated requirements register, using AI to detect and flag duplicate requirements from different sources.

Prompt Examples

Prompt:

You are a senior business analyst synthesizing requirements from a stakeholder interview.

Here are the notes from a 60-minute interview with the VP of Operations about the new procurement platform:

[CURRENT STATE] Currently submits ~150 POs per month for maintenance, consumables, and operations supplies. Most are under $500. The current process requires a paper form signed by the operations supervisor, then delivered to procurement physically or by email scan.

[PAIN POINT] Urgent purchases (machine breakdown, safety supplies) are the biggest problem — sometimes waiting 4-6 hours to get PO approved when the supervisor is on the floor or in a meeting. "We've had a line stopped for 2 hours waiting for a PO."

[PAIN POINT] The procurement team often sends back POs because the cost code is wrong. Requires a re-submission. "My team doesn't know the cost code list — it changes and nobody tells us."

[REQUIREMENT] For operations purchases under $500, the system should allow automatic approval — no supervisor signature needed.

[REQUIREMENT] For urgent purchases (any amount), there should be a way to escalate to an alternative approver if the primary approver is unavailable.

[CONCERN] Worried that a new system will be "too complicated" for her team, especially the workers on the second and third shift who are not comfortable with computers.

[CONSTRAINT] Must work on tablets, since operations team uses tablets on the floor — no desktop computers at the workstations.

[CURRENT STATE] Cost codes are currently maintained in a spreadsheet by the Finance team. There is no integration between the spreadsheet and the PO forms.

[REQUIREMENT] The system should automatically populate or suggest the correct cost code based on the purchase category — her team should not need to know cost codes.

[ASSUMPTION] Assumed that the ERP (SAP) contains the correct cost codes and categories.

Synthesize these notes into a structured requirements document with the following sections:
1. Functional Requirements — numbered list of specific system behaviors required
2. Non-Functional Requirements — performance, usability, and access requirements
3. Constraints — non-negotiable restrictions on the solution
4. Assumptions — conditions that must be verified
5. Open Questions — areas where more information is needed before requirements can be finalized

For each functional requirement, write it in the format: "The system shall [action] when/for [condition], so that [business outcome]."

Expected output: A structured requirements document with 5-8 functional requirements (including the auto-approval rule for sub-$500 purchases, the alternate approver escalation capability, and the cost code auto-population), at least 2 non-functional requirements (tablet-compatible interface, appropriateness for non-technical users), the tablet constraint, the SAP cost code assumption, and open questions such as "What defines an 'urgent purchase' in system terms — is it a flag set by the requester, or is it automatic for certain categories?" and "What is the approval authority limit for the automatic approver in the escalation scenario?"

Prompt:

You are a senior business analyst performing a gap analysis on requirements elicitation coverage.

Project scope summary: The procurement platform project covers: (1) digital PO creation and submission, (2) automated approval workflows, (3) ERP integration for budget checking and cost code validation, (4) a supplier portal for order acknowledgment and status updates, (5) spend analytics and reporting dashboards for finance and procurement leadership, and (6) a supplier onboarding process for the portal.

Requirements gathered so far (from 3 stakeholder sessions):
- [Paste requirements from sessions 1-3]

Review the requirements gathered against the 6 scope areas listed above. For each scope area:
1. Rate the coverage: Well-covered (3+ requirements that address this area), Partially covered (1-2 requirements, but gaps remain), Not covered (no requirements for this area yet)
2. List the specific requirements gaps — what aspects of this scope area have not been addressed
3. Identify which stakeholder should be consulted to fill each gap
4. Flag any cross-cutting concerns (security, data governance, performance) that have not been addressed in any session so far

Expected output: A gap analysis matrix showing coverage by scope area. Supplier portal requirements are typically undertovered in early internal stakeholder sessions. Spend analytics is often partially covered (finance requirements captured but procurement reporting needs may be missing). The gap analysis directs the next round of elicitation to the right stakeholders — e.g., "Supplier portal requirements should be gathered from Procurement team and supplier account managers."

Learning Tip: Run the gap analysis after every two or three elicitation sessions, not at the end of the entire elicitation phase. Catching gaps while you are still in active stakeholder engagement allows you to schedule targeted follow-up sessions with the right stakeholders before the project moves into design. A gap analysis done after elicitation is complete often results in requirements being added late — and late requirements are expensive.

Detecting Conflicting Stakeholder Needs and Generating Resolution Options

Conflicting requirements are inevitable in any project that involves multiple stakeholders with different priorities, organizational roles, and success criteria. The challenge for the BA is not just detecting these conflicts — which is often apparent from the requirements themselves — but generating resolution options that can be presented to stakeholders in a structured, politically neutral way. Unresolved conflicts that reach development cause rework, scope changes, and interpersonal friction between development teams and stakeholders.

AI is particularly effective at systematic conflict detection when given requirements from multiple stakeholders simultaneously. Human conflict detection tends to be partial — we notice the conflicts that align with our expectations or that involve stakeholders we know well. AI applies a consistent, comprehensive comparison and surfaces conflicts we might overlook, including indirect conflicts (where two requirements are not directly contradictory but cannot both be satisfied within the same design) and priority conflicts (where two stakeholders have both requested the same feature but with different attributes that cannot be simultaneously satisfied).

Conflict types require different resolution approaches. A direct contradiction (Stakeholder A requires feature X, Stakeholder B explicitly opposes feature X) typically requires escalation to a sponsor or decision-maker. A priority conflict (both stakeholders require similar functionality but with different attributes — e.g., one wants real-time data, another wants batch-mode processing for performance reasons) may be resolvable through a technical design decision. A scope conflict (one stakeholder's requirement expands the scope beyond what another stakeholder considers in-scope) requires scope governance through the project sponsor. A timing conflict (one stakeholder needs capability A before capability B, another has the reverse dependency) may be resolvable through phasing and sequencing design.

Resolution options for each conflict type should be presented as a neutral menu of choices, not as a recommendation from the BA. The BA's role is to surface and structure the conflict, present the options, and facilitate the decision-making process — not to make the call. AI can generate a structured menu of resolution options for each conflict that can be taken directly to stakeholders for discussion.

Hands-On Steps

Compile requirements from all elicitation sessions into a single document, with each requirement labeled by its source stakeholder.
Run a conflict detection prompt across the full requirements set.
Review each detected conflict. Validate that it is a genuine conflict and not a misinterpretation caused by different stakeholders using different terminology for the same concept.
For each genuine conflict, categorize it: direct contradiction, priority conflict, scope conflict, or timing conflict.
Run a resolution options generation prompt for each conflict, specifying the conflict type and the stakeholders involved.
Add each conflict and its resolution options to a conflict register document.
For each conflict, determine the appropriate resolution path: (a) technical design decision (involves only IT), (b) product prioritization decision (involves PM/BA and product sponsor), (c) stakeholder negotiation (involves the conflicting stakeholders directly), or (d) executive escalation (requires sponsor or steering committee decision).
Present the conflict register to the relevant decision-makers with the resolution options clearly structured, and document the decision made for each conflict.

Prompt Examples

Prompt:

You are a senior business analyst performing a requirements conflict analysis.

Below are requirements gathered from four stakeholder groups for the procurement platform project. Each requirement is labeled with its source.

Finance requirements:
- F1: All purchase orders above $1,000 must have a two-person approval — the department manager and a Finance representative. [Finance VP]
- F2: The system must maintain a complete, immutable audit log of all approval actions including the approver's identity, timestamp, and any comments. [Finance VP]
- F3: The system must enforce budget checking before PO approval — if a PO would exceed the department's remaining budget, it must be blocked. [CFO]

Operations requirements:
- O1: For urgent purchases related to equipment breakdown or safety incidents, POs should be approved within 30 minutes regardless of amount. [VP Operations]
- O2: Operations team members should be able to submit a PO from a mobile device without logging into the main system. [VP Operations]
- O3: Cost codes should be auto-populated based on item category — users should not need to know or select cost codes manually. [VP Operations]

Procurement requirements:
- P1: All suppliers must be on the approved supplier list before a PO can be issued to them. [Procurement Director]
- P2: Preferred suppliers (top 20 by spend) should have pre-negotiated pricing loaded in the system, and POs to these suppliers should auto-apply contract pricing. [Procurement Director]
- P3: Procurement team must be notified of any PO over $10,000 for contract compliance review, even if the PO is within budget. [Procurement Director]

IT requirements:
- I1: All system access must use single sign-on through the corporate Azure AD — no separate login credentials. [IT Director]
- I2: Mobile access must be limited to read-only for security reasons — no order creation or approval actions on mobile devices. [IT Director]
- I3: The system must not store any supplier payment data — payment processing must remain in SAP. [IT Director]

Identify all conflicts and contradictions between these requirements. For each conflict:
1. Name the conflicting requirements (e.g., O1 vs F1)
2. Describe the nature of the conflict
3. Classify the conflict type: direct contradiction, priority conflict, scope conflict, or timing conflict
4. Generate 3 resolution options, presented as a neutral menu without recommending one
5. Identify the appropriate decision-maker for resolving this conflict

Expected output: A conflict analysis identifying at least 3-4 significant conflicts: the most obvious being O1 (30-minute urgent PO approval) vs. F1 (two-person approval above $1,000) — a direct contradiction that requires an executive decision about whether safety urgency can override the two-person approval control. A second conflict: O2 (mobile PO submission) vs. I2 (mobile read-only) — a direct contradiction requiring a security risk discussion between IT and Operations with the CISO as the appropriate decision-maker. Resolution options for each conflict should be presented neutrally, e.g., for O1 vs F1: Option A — emergency POs bypass the two-person rule but trigger a mandatory post-hoc audit; Option B — the 30-minute SLA applies only to approved safety categories with pre-authorization; Option C — the two-person rule remains but a designated emergency approver is always available via mobile.

Prompt:

You are a senior business analyst preparing a conflict resolution brief for stakeholder presentation.

We have identified the following conflict between requirements from two stakeholder groups:

Conflict: Requirement O2 (Operations: Users should be able to submit a PO from a mobile device without logging into the main system) vs. Requirement I2 (IT: Mobile access must be limited to read-only for security reasons — no order creation or approval actions on mobile devices.)

Nature of conflict: The Operations team needs mobile PO submission capability for their floor staff. The IT department considers mobile PO creation a security risk and wants to limit mobile to read-only. Both requirements are strongly held and backed by business rationale.

Prepare a conflict resolution brief to be presented to both stakeholders in a joint session. Include:
1. A neutral, factual description of the conflict (no editorial language)
2. The business rationale for each position (without favoring either)
3. Four resolution options, each with: description, advantages, disadvantages, and implementation complexity
4. The information needed to make a decision (e.g., "what specific security risk is IT concerned about?")
5. A proposed decision process: who needs to decide, by when, and what happens if no decision is reached

Format this as a one-page brief suitable for a 30-minute joint stakeholder meeting.

Expected output: A balanced, structured one-page brief that presents both positions respectfully, with four resolution options such as: Option A — secure mobile app with device enrollment requirement (MDM), Option B — mobile read-only with a mobile-optimized urgent-request workflow that triggers a push notification to a designated approver, Option C — risk-tiered mobile access (view and approve on mobile, create only from enrolled corporate devices), Option D — defer mobile creation capability to Phase 2 pending security review. The brief frames the decision clearly without pre-selecting an answer.

Learning Tip: When presenting conflicting requirements to stakeholders, never frame it as one stakeholder being wrong. Frame every conflict as "two legitimate business needs that cannot both be satisfied with the same design decision." This neutral framing preserves relationships and keeps both stakeholders engaged in the resolution process. The moment a stakeholder feels their requirement is being dismissed, they disengage — and disengaged stakeholders become the ones who surface objections at the worst possible moment.

Key Takeaways

AI-generated stakeholder registers are starting drafts, not final artifacts. Every power classification must be validated with your project sponsor — organizational influence is political and often invisible on an org chart.
Stakeholder interview guides should be tailored by role, not generic. Provide AI with the stakeholder's specific role, their team's relationship to the project, and their known concerns for tailored outputs.
Always prepare probing questions before the interview. Prepared probing questions give you permission to go deeper on the most important topics rather than advancing mechanically through a question list.
Use structural labels in your notes ([CURRENT STATE], [PAIN POINT], [REQUIREMENT], [CONCERN], [CONSTRAINT], [ASSUMPTION]) to dramatically improve AI synthesis quality.
Run gap analysis after every 2-3 sessions — not at the end of the elicitation phase. Mid-phase gap analysis allows you to schedule targeted follow-up sessions while stakeholders are still engaged.
Conflict detection should be systematic, not intuitive. Give AI the full requirements set from all stakeholders simultaneously to surface indirect and priority conflicts that human review would miss.
Present conflicts as neutral resolution option menus, not as recommendations. The BA's role is to structure the decision, not to make it.
Document every conflict decision formally. Undocumented conflict resolutions become disputed scope in later project phases.