Overview
This topic is a full, end-to-end practical exercise. You will work through a realistic business scenario — an order management process improvement initiative — and produce a complete, stakeholder-ready business analysis deliverable package using AI assistance at every stage. This is not a simplified illustration; it is the level of rigor and completeness that a professional BA deliverable requires in a real agile organization.
The scenario is deliberately chosen to be representative of the type of BA engagement that mid and senior BAs encounter regularly: a cross-functional process that spans multiple systems, involves stakeholders with conflicting interests, and generates a wide variety of BA artifacts. The worked example gives you a concrete, end-to-end reference that you can adapt to your own project contexts.
The deliverable package produced in this topic covers the full BA scope: a current-state process map, a process improvement analysis with quantified opportunities, a structured requirements document from a simulated stakeholder elicitation, an entity-relationship model, a gap analysis report, acceptance criteria for key features, and a stakeholder-ready delivery presentation. Each section shows the complete prompt sequence, the expected AI output, and the validation and refinement steps that a professional BA would apply.
By working through this exercise completely, you will internalize the end-to-end AI-assisted BA workflow — the input structuring, the prompt sequencing, the output validation, and the stakeholder communication steps — as a muscle memory that you can apply to any future BA engagement. The scenario is order management, but the workflow applies universally.
Map a Business Process and Identify Improvement Opportunities with AI
The worked example scenario for this module is the order management process at a mid-sized B2B wholesale distributor. The company sells industrial consumables to approximately 800 business customers. Orders come in through three channels: phone (40%), email (35%), and a legacy web portal (25%). The process involves five teams: Sales, Order Management, Warehouse, Finance, and Logistics. The company is experiencing growing customer complaints about order accuracy and delivery delays, and leadership has commissioned a business analysis engagement to identify and prioritize improvement opportunities before making a decision about a potential ERP upgrade.
This is the raw material for a current-state process mapping and improvement analysis — a mix of known pain points, multiple channels, cross-functional handoffs, and a strategic technology decision waiting in the background. It is exactly the type of engagement where AI assistance delivers the most value: large scope, multiple stakeholders, time pressure, and a need for rigorous, evidence-based recommendations.
The process mapping and analysis workflow follows the sequence from Topic 01 of this module, but is now executed in full with real worked examples. Each step of the workflow is shown with the actual prompt used, the expected output, and the BA's judgment call at each validation and refinement point.
Hands-On Steps
- Assemble the scenario inputs: the three-channel order receipt process, the five teams involved, the known pain points (order accuracy, delivery delays), and the strategic context (potential ERP decision).
- Run the process documentation prompt with the simulated interview notes and SOP content provided in this section.
- Validate the synthesized process map and identify the conflicts between sources.
- Run the bottleneck, redundancy, and automation analysis prompts sequentially.
- Prioritize the improvement opportunities using the effort-impact scoring prompt.
- Generate structured recommendations using the five-part format.
- Produce the future-state process design and transition plan.
Prompt Examples
Prompt — Step 1: Synthesize Current-State Process from Multiple Sources
You are a senior business analyst documenting the current-state order management process for a B2B wholesale distributor.
I am providing you with three input sources. Synthesize them into a single current-state process description in swim lane format. Apply the following rules:
- Where sources agree: document the step once
- Where sources conflict: flag as [CONFLICT: Source A says X, Source B says Y]
- Where a source describes a workaround or exception: mark as [WORKAROUND: description]
Source 1 — Interview notes from Order Management Team Lead (Maria):
"When we get a phone order, someone on the team writes it up on a paper order form — we still use paper because the system doesn't always work well for complex orders. For email orders, we copy the details manually into the order system. Web portal orders come in automatically, which is great, but they often have wrong product codes because customers can't find the right items. For all orders, we check stock in our ERP — that usually takes a few minutes because the system is slow. If we have stock, we confirm the order to the customer by phone or email and create the pick ticket. If we're out of stock, we check with the supplier but that can take a day or two to get a response. We try to call the customer to let them know, but honestly sometimes that falls through the cracks."
Source 2 — SOP document v2.1 (last updated 18 months ago):
"1. Order received via phone, email, or web portal. 2. Order entry specialist enters order details into the Order Management System (OMS). 3. OMS performs automatic stock check against ERP inventory module. 4. If in stock: system generates pick ticket and sends order confirmation email to customer. 5. If out of stock: Order entry specialist contacts procurement for supplier lead time. 6. Order entry specialist contacts customer with expected delivery date. 7. Pick ticket forwarded to warehouse for picking and packing. 8. Warehouse updates OMS when order is dispatched. 9. Finance generates invoice on dispatch."
Source 3 — Interview notes from Warehouse Manager (Derek):
"We get the pick tickets through the system, but about 30% of them have errors — wrong product codes, wrong quantities, or the customer address is missing. We spend a lot of time sending them back to order management for correction. Sometimes we just fix the obvious errors ourselves, which is probably not the right process but it keeps things moving. The paper forms from phone orders are the worst — the handwriting is sometimes illegible. We're also getting last-minute rush orders that go to the top of the queue, but nobody tells us which are rush and which aren't — we just try to guess from the time."
Produce the swim lane process in the following lanes: Customer, Order Management, Warehouse, Finance, ERP/OMS System. Include all decision points with Yes/No paths.
Expected output: A detailed swim lane process description with 12-15 steps across 5 lanes, including at least three conflict flags (most significantly: the SOP says "OMS performs automatic stock check" but the interview notes say "we check stock manually because the system doesn't always work" — a critical discrepancy that reveals the SOP is out of date), two workaround annotations (paper forms for complex phone orders, warehouse self-correcting pick ticket errors), and several open questions (what defines a "rush order"? who has authority to prioritize? what is the actual failure rate on the automatic stock check?).
Prompt — Step 2: Bottleneck and Automation Analysis
You are a senior business analyst performing a process improvement analysis.
Here is the synthesized current-state order management process:
[Paste synthesized swim lane process]
Additional context:
- Volume: 350 orders per week (140 phone, 123 email, 87 web portal)
- Average end-to-end cycle time (order receipt to dispatch): 2.1 days for in-stock orders, 5-8 days for out-of-stock orders
- Pick ticket error rate: approximately 30% (source: Warehouse Manager interview)
- Known customer complaint categories: incorrect order (42% of complaints), late delivery (35%), no communication about delays (23%)
- Staff: 5 FTEs in Order Management, 8 FTEs in Warehouse, 2 FTEs in Finance
Perform a structured analysis identifying:
Section 1 — Bottlenecks (steps where work accumulates or a single resource is the constraint):
For each bottleneck: step name, description of the constraint, evidence from the data, and estimated impact on cycle time.
Section 2 — Redundancies (steps where work is duplicated, data is re-entered, or approvals are repeated):
For each redundancy: step name, description of the duplication, root cause, and estimated weekly hours wasted.
Section 3 — Top 5 Automation Opportunities (ranked by impact × feasibility):
For each opportunity: step description, automation approach, estimated time saving per order, weekly saving at 350 orders volume, and implementation complexity (Low/Medium/High).
Section 4 — Root Causes of the 30% Pick Ticket Error Rate:
Apply a 5 Whys analysis to identify the root cause chain for the pick ticket error rate finding. Generate 3 candidate root causes and evaluate which is most likely given the available evidence.
Expected output: A comprehensive analysis finding bottlenecks at: the manual stock check (slow ERP slowing all in-stock order processing), the supplier lead time inquiry step (1-2 day wait with no structured follow-up process), and the pick ticket correction loop (30% rework rate creating a hidden queue in the warehouse). Redundancies should include: manual data re-entry of email orders (35% of volume requires full manual entry), double data entry between paper forms and OMS, and the informal parallel confirmation process (some customers receive both a phone call and an email confirmation with different information). The 5 Whys for the pick ticket error rate should trace to: incorrect product codes entered at the order entry step — caused by inconsistent product catalog presentation in the OMS and no validation against the actual ERP product catalog at entry time.
Prompt — Step 3: Improvement Recommendations with Effort-Impact Prioritization
You are a senior business analyst generating structured process improvement recommendations.
Based on the process analysis above, here are the confirmed improvement opportunities:
1. Implement real-time product catalog validation at order entry (addresses incorrect product codes — root cause of 30% pick ticket errors)
2. Build automated email-to-order parsing to eliminate manual re-entry of email orders (addresses email order manual entry redundancy, 123 orders/week)
3. Implement automated stock check integration (replace manual ERP lookup with real-time API call — addresses stock check bottleneck)
4. Create a rush order flag and queue prioritization feature in the OMS (addresses the unmanaged rush order problem in the warehouse)
5. Build automated supplier inquiry workflow with status tracking (addresses the unmanaged out-of-stock follow-up process)
6. Implement automated customer delay notification triggered by out-of-stock status (addresses 23% of customer complaints)
For each recommendation, generate a structured recommendation in this format:
- Current State: precise description of the current problem
- Root Cause: the underlying cause
- Future State: what the process looks like after the improvement
- Implementation Steps: ordered list of concrete actions
- Expected Benefit: quantified where possible
Then run an effort-impact prioritization. Use:
- Impact: 1 (minor) to 5 (transformational) — consider volume affected, complaint reduction, and cycle time improvement
- Effort: 1 (configuration) to 5 (major development) — consider technical complexity and change management
- Priority Tier: Quick Win (Impact ≥3, Effort ≤2), Strategic Investment (Impact ≥4, Effort ≥3), Low Priority (Impact ≤2)
Expected output: Six structured recommendations with full current state/root cause/future state/implementation/benefit content. The prioritization should identify product catalog validation (Quick Win — relatively low technical effort, directly addresses 30% error rate), automated customer delay notification (Quick Win — can be configured in most OMS systems), and automated email-to-order parsing (Strategic Investment — requires NLP or structured email template adoption). The output gives the project sponsor a clear, actionable roadmap with business case for each initiative.
Learning Tip: In a real engagement, run the improvement analysis prompt with the process owner and relevant stakeholders in the room — not as a solo exercise. Share your screen, run the analysis live, and use the AI output as a structured discussion prompt rather than a finished deliverable. The discussion that happens as the team reacts to the AI analysis (agreeing, disagreeing, adding context) is often more valuable than the analysis itself, because it surfaces the organizational knowledge and political context that the AI cannot access.
Elicit and Structure Requirements from Stakeholder Interview Transcripts
With the current-state analysis complete and improvement opportunities prioritized, the next phase is requirements elicitation. In the order management scenario, we have conducted three additional stakeholder interviews: one with the Head of Sales, one with the Finance Manager, and one with a representative group of warehouse staff. The interview transcripts are realistic simulations of the type of inputs a BA receives in a real engagement — unstructured, sometimes contradictory, and full of implicit requirements that need to be surfaced and made explicit.
This section demonstrates the complete elicitation synthesis workflow: from raw interview notes to a structured, categorized requirements document, including gap identification and requirements conflict detection. The goal is to produce a requirements document that is comprehensive enough to scope the solution, specific enough to inform user stories, and organized clearly enough for stakeholder sign-off.
Hands-On Steps
- Review all three interview transcripts and annotate them with structural labels ([CURRENT STATE], [PAIN POINT], [REQUIREMENT], [CONCERN], [CONSTRAINT], [ASSUMPTION]) before running the synthesis prompt.
- Run the requirements extraction prompt for each interview separately, then run a consolidation prompt to merge all three into a single requirements register.
- Run a conflict detection prompt across the full requirements set.
- Run a gap analysis prompt against the project scope.
- Refine ambiguous requirements using targeted precision prompts.
Prompt Examples
Prompt — Full Elicitation Synthesis Sequence
You are a senior business analyst synthesizing requirements from three stakeholder interviews for an order management system improvement project.
Context: The project will implement 6 improvements to the current order management process (listed below). We have conducted three stakeholder interviews.
Project scope improvements:
1. Real-time product catalog validation at order entry
2. Automated email-to-order parsing
3. Automated real-time stock check integration
4. Rush order flag and queue prioritization
5. Automated supplier inquiry workflow
6. Automated customer delay notification
Interview 1 — Head of Sales (Tom):
[CURRENT STATE] Sales reps promise delivery dates verbally to customers without checking stock — they don't have easy access to inventory levels.
[PAIN POINT] We lose repeat orders when customers get wrong delivery promises. "I had a customer tell me they're going to a competitor because we've got the dates wrong three times in a row."
[REQUIREMENT] Sales reps need to see real-time inventory levels when talking to customers — in Salesforce, not in the ERP.
[REQUIREMENT] When a customer calls about a late order, the sales rep needs to see the current status without calling order management.
[CONCERN] Whatever we build shouldn't add steps to the sales process — my team is already spending too much time on admin.
[CONSTRAINT] The team uses Salesforce on mobile — anything we build needs to work on the Salesforce mobile app.
Interview 2 — Finance Manager (Rachel):
[CURRENT STATE] Invoices are generated manually from the OMS dispatch notification — there's a 24-48 hour delay between dispatch and invoice.
[PAIN POINT] Month-end is a nightmare because we're chasing dispatches that haven't been invoiced yet. Last month we had 23 uninvoiced dispatches at month-end.
[REQUIREMENT] Invoice generation must be automated and triggered within 30 minutes of goods dispatch.
[REQUIREMENT] The invoice must include the actual items shipped — if the order was partially dispatched, the invoice must only cover the dispatched items.
[REQUIREMENT] Finance needs a real-time dispatch and invoicing dashboard — how many orders dispatched today, how many invoiced, how many outstanding.
[CONCERN] Any automated invoicing must be validated against the purchase order — we can't invoice for items the customer didn't order.
[CONSTRAINT] Invoicing must integrate with our accounting system (Xero) — we can't migrate our accounting to a new platform.
[ASSUMPTION] Assumed that the Xero API supports automated invoice creation — this needs to be verified with IT.
Interview 3 — Warehouse Staff Focus Group (5 participants):
[PAIN POINT] Pick tickets are often wrong — 30% have errors. "We waste an hour every morning fixing tickets before we can start picking."
[PAIN POINT] We don't know which orders are urgent until the sales manager calls us directly — the system doesn't show priority.
[REQUIREMENT] Pick tickets should show a priority flag with a clear visual distinction between rush and standard orders.
[REQUIREMENT] When we correct a pick ticket error, the correction should be logged and the order entry team should be notified automatically.
[REQUIREMENT] We need to scan barcodes for items as we pick them — to verify we're picking the right items.
[REQUIREMENT] The pick ticket should be accessible on a tablet, not just on the shared computer at the warehouse entrance.
[CONCERN] Some of the team are not comfortable with new technology — training needs to be practical and hands-on, not just a PDF.
[CONSTRAINT] The warehouse runs 6am-10pm in two shifts — the system must be available during all operating hours.
Synthesize all three interviews into a structured requirements document:
1. Functional Requirements — organized by functional area
2. Non-Functional Requirements — performance, availability, usability, integration
3. Constraints — non-negotiable restrictions
4. Assumptions — conditions requiring verification
5. Conflicts — requirements from different stakeholders that cannot both be satisfied as stated
6. Open Questions — items requiring further stakeholder input before requirements can be finalized
For each functional requirement: write in "The system shall..." format with source stakeholder noted.
Expected output: A comprehensive requirements document with 15-20 functional requirements grouped by area (Sales/Inventory Visibility, Order Entry, Warehouse Operations, Finance/Invoicing), 6-8 non-functional requirements (mobile compatibility for Salesforce, tablet support in warehouse, 99.5% availability during 6am-10pm operating hours, 30-minute invoice trigger SLA), 4-5 constraints (Salesforce mobile, Xero integration, availability hours), 3-4 assumptions (Xero API capability, Salesforce ERP inventory integration feasibility), at least 2 conflicts (Sales wants real-time inventory in Salesforce — this requires an ERP-to-Salesforce integration not currently in scope; Warehouse wants barcode scanning — this requires a hardware investment not yet approved), and open questions.
Prompt — Requirements Conflict Resolution Brief
You are a senior business analyst preparing a conflict resolution brief for the project sponsor.
Conflict identified: The Head of Sales (Tom) requires real-time inventory visibility in Salesforce for sales reps. This would require a new ERP-to-Salesforce integration that is not in the current project scope. The IT Director has indicated that this integration would be a 3-month development effort and would require SAP licensing changes.
The current project scope focuses on order management process improvements that are estimated at 4 months total. Adding the Salesforce integration would extend the timeline by 3 months and add approximately $45,000 in development and licensing costs.
Prepare a conflict resolution brief for the project sponsor that includes:
1. Neutral description of the conflict
2. Business case FOR including the Salesforce integration (Tom's perspective, quantified where possible)
3. Business case AGAINST (scope, timeline, cost impact)
4. Four resolution options with trade-offs:
Option A: Include in current project scope
Option B: Phase 2 delivery (post current project go-live)
Option C: Minimal viable version (read-only inventory lookup via Salesforce — reduced scope version)
Option D: Workaround (dashboard or report that Sales can access outside of Salesforce)
5. Decision required from: [who needs to decide]
6. Decision deadline: [when must this be decided to not affect the project timeline]
Expected output: A structured, one-page conflict resolution brief that is ready for sponsor review. The business case for inclusion should quantify Tom's claim (repeat order loss from incorrect delivery promises — if the company has 50 affected customers × average order value, the revenue impact can be estimated). The four options should include realistic trade-off descriptions — Option C (minimal viable version) should note that a read-only inventory lookup in Salesforce could be delivered in 3-4 weeks using Salesforce standard reporting features, at significantly lower cost than the full real-time integration. This option frequently becomes the approved path in real engagements.
Learning Tip: When running multi-stakeholder requirements synthesis, always run the conflict detection as its own prompt pass — separate from the synthesis pass. Give AI the full requirements set and ask it specifically to look for cases where two stakeholders have requirements that cannot both be satisfied with a single design decision. This systematic conflict detection saves the project from discovering these conflicts during solution design, when they are far more expensive to resolve.
Generate Acceptance Criteria, Data Models, and a Gap Analysis Report
With the process analysis and requirements elicitation complete, the third phase of the BA deliverable package focuses on the technical artifacts: acceptance criteria for the prioritized features, a data model covering the key entities introduced by the new capabilities, and a formal gap analysis report covering the full project scope. These three artifacts form the technical backbone of the deliverable package and are the primary reference documents for the solution design and development phases.
This section shows the complete generation workflow for all three artifact types, including the validation steps and the stakeholder-facing summaries that make the technical artifacts accessible to non-technical stakeholders.
Hands-On Steps
- Select the top 3 features from the prioritized improvement list for acceptance criteria generation.
- For each feature, run the full Gherkin criteria generation prompt with all four coverage dimensions specified.
- Run the coverage audit prompt on each generated criteria set.
- Run the data model generation prompt from the requirements narrative.
- Run the gap analysis prompt using the current-state process description and the future-state requirements.
- Generate stakeholder-facing summaries for both the gap analysis and the data model.
Prompt Examples
Prompt — Acceptance Criteria for Rush Order Prioritization Feature
You are a senior business analyst writing acceptance criteria for a feature story.
Story: "As a warehouse team member, I want to see a clear visual priority flag on rush orders in the pick ticket queue, so that I can process urgent customer orders first without waiting for a phone call from the sales manager."
Business rules for this feature:
- Rush order designation is set by the Order Management team at the time of order entry (not automatically)
- Rush orders must be visible at the top of the warehouse pick queue, separated from standard orders
- Rush orders must be visually distinct: a red "RUSH" banner vs. standard orders with no banner
- Once a pick ticket is started (first scan event recorded), rush status cannot be changed
- Rush order designation must be logged: who set it, when, and with an optional reason
- Only Order Management team members and their supervisors can designate an order as rush
- The warehouse team can see but cannot change the rush designation
Generate acceptance criteria in Given/When/Then format covering all four dimensions:
1. Functional behavior (setting rush status, visual display in queue, queue ordering)
2. Data validation (who can set rush, timing constraints, audit logging)
3. Error handling (attempting to set rush after picking has started, unauthorized user attempting to set rush)
4. Permission boundaries (OM team sets, warehouse team views only)
Use AC-[number] format. Generate a minimum of 12 acceptance criteria.
Expected output: 12-15 acceptance criteria covering: AC-01 (OM team member sets rush flag), AC-02 (rush order appears at top of warehouse queue), AC-03 (visual distinction between rush and standard), AC-04 (rush flag audit log entry created), AC-05 (optional reason field), AC-06 (attempt to change rush flag after first scan — error shown), AC-07 (multiple rush orders sorted among themselves — what is the secondary sort?), AC-08 (warehouse team member views rush orders — read-only), AC-09 (warehouse team member attempts to change rush flag — permission denied), AC-10 (supervisor can change rush flag after picking starts — exception to the "no change after scan" rule?), AC-11 (pick queue display when no rush orders are present — zero state), AC-12 (rush order notification to warehouse supervisor when set).
Prompt — Entity-Relationship Model for Order Management Improvements
You are a senior data modeler creating an entity-relationship model from business requirements.
Here are the key entities introduced or modified by the order management improvement project:
From current requirements:
- Orders are received through three channels and have a status lifecycle: Received → Confirmed → In Pick → Dispatched → Invoiced
- Each order has line items referencing product catalog items
- Orders can be designated as Rush (with logging of who set it and when)
- Pick tickets are generated from orders and can have corrections logged against them
- Out-of-stock items trigger supplier inquiries with status tracking
- Dispatches generate automated invoices in Xero (integration)
- Customer delay notifications are sent automatically when orders go out-of-stock
Generate an entity-relationship model with the following entities at minimum:
Order, OrderLineItem, PickTicket, PickTicketLineItem, PickTicketCorrection, RushOrderLog, StockCheckResult, SupplierInquiry, CustomerNotification, Product, Supplier, Customer, WarehouseTeamMember, OrderManagementUser
For each entity:
1. Key attributes (mark PK and FK)
2. Relationships to other entities with cardinality
3. Any business rules embedded in the relationship or attribute
Flag any entities or relationships that are ambiguous and require stakeholder clarification.
Also generate the PlantUML class diagram syntax for this model.
Expected output: A detailed ER model with all 15 entities, their key attributes, and their relationships. Key relationships should include: Order 1:N OrderLineItem, Order 1:1 PickTicket (or 1:N if partial picks are allowed — this should be flagged as an ambiguity), PickTicket 1:N PickTicketCorrection, Order 1:N RushOrderLog (with FK to the OM user who set the flag), Order 1:N SupplierInquiry (one per out-of-stock line item), Order 1:N CustomerNotification. Ambiguities should flag: "Can an order have multiple pick tickets (for partial dispatches)? This affects the PickTicket-to-Dispatch relationship."
Prompt — Gap Analysis Report
You are a senior business analyst producing a gap analysis report for the order management improvement project.
Current State Summary (from process analysis):
- Order entry: manual entry from phone and email, automated for web portal (25% of volume)
- Stock checking: manual ERP lookup (slow, prone to delays)
- Pick ticket generation: manual, 30% error rate
- Rush order management: informal, phone-based only
- Out-of-stock management: unstructured supplier contact, inconsistent customer communication
- Invoicing: manual, 24-48 hour delay after dispatch
- Inventory visibility for Sales: none (no access to ERP data from Salesforce)
Desired State (from validated requirements):
- Order entry: automated parsing for email orders; real-time product catalog validation for all channels
- Stock checking: real-time automated API call to ERP, response within 3 seconds
- Pick tickets: system-generated with validated product codes, tablet-accessible, barcode scan verification
- Rush order management: formal flag in system with visual queue prioritization and audit trail
- Out-of-stock management: automated supplier inquiry with SLA tracking; automated customer delay notifications
- Invoicing: automated within 30 minutes of dispatch, integrated with Xero, partial dispatch handling
- Inventory visibility: read-only inventory lookup available in Salesforce mobile for Sales team
Produce a gap analysis report with these capability areas:
1. Order Capture and Entry
2. Inventory and Stock Management
3. Warehouse Operations and Picking
4. Supplier and Out-of-Stock Management
5. Finance and Invoicing
6. Sales and Customer Communication
7. System Integration and Data Management
For each capability area: current state, desired state, gap description, priority (High/Medium/Low), implementation effort (High/Medium/Low).
Then generate an executive summary version: a 200-word summary of the gap analysis suitable for inclusion in a steering committee presentation, highlighting the top 3 critical gaps and their business impact.
Expected output: A seven-section gap analysis with specific, quantified gap descriptions (e.g., Warehouse Operations: "Pick ticket error rate of 30% — approximately 105 erroneous pick tickets per week — causes rework estimated at 1 hour per morning shift, or 10 hours per week of warehouse labor, and is the primary driver of the 42% of customer complaints attributable to incorrect orders"). The executive summary should be a tight 200 words that gives a steering committee member the three most important things to know without needing to read the full report.
Learning Tip: The executive summary is not an afterthought — it is often the only section a senior stakeholder reads before the presentation. Ask AI to produce the executive summary version of every major BA deliverable as part of the generation step, not as a last-minute add-on. A well-written executive summary that highlights the business impact in plain language dramatically increases the probability that your recommendations will be approved and acted on.
Produce a Stakeholder-Ready BA Deliverable Package
The final step in the BA engagement is assembling the individual artifacts into a coherent, stakeholder-ready deliverable package. The package is not just a compilation of what you produced — it is a communication artifact in its own right, designed to take a diverse set of stakeholders through a logical progression from "here is what we found" to "here is what we recommend you do about it" to "here is what it will look like when it is done."
A stakeholder-ready deliverable package has three qualities: it is complete (all required artifacts are present and internally consistent), it is navigable (structured so that different stakeholders can find the sections relevant to them without reading everything), and it is actionable (ends with a clear set of decisions or next steps that move the project forward). AI can help structure, review, and prepare this package efficiently, but the judgment about what is complete, navigable, and actionable for your specific stakeholder audience is a human responsibility.
Hands-On Steps
- Define the deliverable package structure — the table of contents that reflects the logical narrative from findings to recommendations to design.
- Generate a package cover page and executive summary using AI.
- Run an internal consistency check: ask AI to review all sections and flag any inconsistencies between the process analysis, the requirements, the data model, and the gap analysis.
- Generate a decisions-required section: a structured list of decisions the steering committee must make at the review presentation.
- Generate tailored stakeholder summaries for each key stakeholder audience.
- Run a final completeness review against the BA deliverable checklist.
Prompt Examples
Prompt — Full Package Structure and Review Checklist
You are a senior business analyst finalizing a BA deliverable package for stakeholder review.
The package covers the order management improvement initiative and contains the following sections:
1. Executive Summary (2 pages)
2. Current-State Process Analysis (swim lane maps + bottleneck/redundancy analysis)
3. Improvement Recommendations (6 recommendations with effort-impact prioritization)
4. Stakeholder Requirements Register (functional, non-functional, constraints, assumptions)
5. Gap Analysis Report (7 capability areas)
6. Data Model (ER diagram + entity descriptions)
7. Acceptance Criteria for Top 3 Features (rush order prioritization, automated invoicing, pick ticket validation)
8. Future-State Process Maps (swim lane maps for improved process)
9. Transition Plan (3-phase implementation plan)
10. Decisions Required (for steering committee)
11. Appendices (full interview notes, SOP analysis, open questions register)
Task 1 — Generate a decisions-required section for the steering committee presentation.
List 5-7 specific decisions that the steering committee must make to allow the project to proceed. For each decision:
- Decision statement: the exact question to be answered
- Options: the possible answers
- Dependencies: what other work depends on this decision
- Recommended deadline: when the decision must be made
- Who must decide: the role or individual responsible
Task 2 — Generate a presentation narrative outline for the BA deliverable walkthrough meeting.
The meeting is 90 minutes, attended by: CEO, CFO, Head of Sales, Head of Operations, IT Director, and the Order Management and Warehouse team leads. The BA will present the full package and seek decisions on the items above.
Structure the 90-minute agenda as:
- Introduction and purpose (5 min)
- Current-state findings and pain quantification (20 min)
- Improvement recommendations and prioritization (20 min)
- Solution design overview (gap analysis + data model) (15 min)
- Decisions required (20 min)
- Next steps and timeline (10 min)
For each agenda section: what is the key message, what artifacts are shown, and what is the expected stakeholder reaction or discussion point?
Expected output: A decisions-required section with 5-7 specific decisions including: "Decision 1 — Salesforce inventory integration scope: Include in Phase 1 (extend timeline and budget), defer to Phase 2, or implement minimal viable version? Decision required by [date] to allow IT to begin integration design. Recommended decision-maker: CEO and IT Director jointly." And a 90-minute meeting agenda with clear key messages for each section — for example, the current-state section's key message is "the 30% pick ticket error rate is costing approximately [X] hours of warehouse labor per week and is the primary driver of [Y]% of customer complaints — this is entirely preventable."
Prompt — Tailored Stakeholder One-Pagers
You are a senior business analyst producing tailored communication summaries for a BA deliverable package.
The full deliverable package (described above) needs to be distilled into one-page summaries tailored for three stakeholder audiences. Each summary should be structured for a reader who will spend no more than 5 minutes reading it.
Audience 1 — CFO (Rachel, Finance Manager in this engagement)
Key interests: Cost impact of improvements, invoicing automation benefits, integration with Xero, budget requirements for implementation
One-page format: What is the problem (financial impact), what we recommend (finance-relevant recommendations), what it costs (implementation investment), what you gain (ROI estimate), decisions needed from Finance
Audience 2 — Head of Operations (oversees Warehouse and Order Management)
Key interests: Efficiency improvements, error rate reduction, warehouse team adoption, operational risk during transition
One-page format: What we found (operational findings), what we recommend (operational improvements), implementation impact on current operations, key risks and mitigations, decisions needed from Operations
Audience 3 — IT Director
Key interests: Integration scope, technical complexity, system dependencies, security and data governance
One-page format: Integration requirements summary, technical dependencies (ERP, Salesforce, Xero), recommended implementation approach, open technical questions, decisions needed from IT
For each audience, use plain language appropriate to their role — avoid BA jargon. Use numbers and specifics wherever possible.
Expected output: Three tailored one-page summaries, each written for a different reader's priorities. The CFO summary should quantify the invoicing delay cost (23 uninvoiced dispatches at month-end × average order value = revenue recognition delay of approximately $X), the implementation investment estimate, and the ROI calculation. The Operations summary should use warehouse team language ("pick ticket error rate of 30%" rather than "requirements validation gap") and should address the team adoption concern directly. The IT summary should list the three integration dependencies clearly (ERP API, Salesforce REST, Xero API) with their complexity ratings and open technical questions.
Prompt — Internal Consistency and Final Completeness Review
You are a senior business analyst performing a final quality review of a BA deliverable package before stakeholder presentation.
Here is a summary of the key assertions in each section of the package:
Executive Summary: "Top 3 improvement priorities are: pick ticket validation (Quick Win), automated invoicing (Quick Win), and rush order management (Quick Win)."
Gap Analysis: "Supplier and Out-of-Stock Management is rated as a High priority gap with Medium implementation effort."
Improvement Recommendations: "Automated supplier inquiry workflow is rated as Strategic Investment (high effort)."
Transition Plan: "Phase 1 (months 1-2) includes pick ticket validation and rush order management. Phase 2 (months 3-4) includes automated invoicing and supplier inquiry. Phase 3 (months 5-6) includes email parsing and Salesforce integration."
Acceptance Criteria: "Rush order flag can only be set by Order Management team members."
Requirements Register: "The system shall allow supervisors to override the rush flag after picking has started."
Identify any internal inconsistencies between these sections. For each inconsistency:
1. Identify the conflict (which two sections are inconsistent)
2. Describe the inconsistency precisely
3. Recommend the resolution: which section should be updated, and what should it say
Also run a completeness check against this BA deliverable checklist:
- [ ] Every improvement recommendation has a corresponding requirement in the requirements register
- [ ] Every requirement in the register is addressed by either an acceptance criterion or a gap analysis item
- [ ] Every entity in the data model is referenced in at least one acceptance criterion
- [ ] Every gap in the gap analysis has a corresponding recommendation
- [ ] Every recommendation is reflected in the transition plan
- [ ] The decisions-required section has at least one decision per major open question in the open questions register
Expected output: An internal consistency review flagging at least two issues: (1) the executive summary calls supplier inquiry a Quick Win but the recommendations section rates it as a Strategic Investment — these contradict each other and must be reconciled; (2) the acceptance criteria say only OM team members can set rush flags but the requirements register includes a supervisor override capability — the acceptance criteria are incomplete. The completeness check should identify which gaps are present and exactly which sections need to be updated to close them, giving the BA a precise punch list for the final quality pass before the stakeholder meeting.
Learning Tip: The internal consistency review is the most valuable quality step before any stakeholder presentation. BA deliverable packages are built in pieces over days or weeks, and it is easy for one section to be updated without propagating the change to others. Asking AI to check for consistency across sections catches the contradictions that are invisible when you are looking at each section individually — and nothing damages a BA's credibility more than a steering committee member catching an internal contradiction that you missed.
Key Takeaways
- The end-to-end BA deliverable package is a communication artifact, not just a documentation collection. Structure it to take stakeholders from findings to recommendations to decisions — not as a chronological record of the analysis work.
- Always run the process analysis (bottleneck, redundancy, automation) as three separate, sequential prompts. Each analysis type requires a different frame of attention and produces richer findings when not combined.
- The requirements synthesis prompt should handle multiple input sources simultaneously, with explicit instructions about how to handle conflicts and workarounds. The conflict flags it produces become your follow-up interview agenda.
- Generate executive summary versions of every major artifact (gap analysis, recommendations, decisions-required) as part of the standard generation step. Senior stakeholders read summaries, not full reports.
- Tailor stakeholder one-pagers to each audience's specific interests and language. A CFO one-pager and an IT Director one-pager from the same BA engagement should read like completely different documents.
- Run the internal consistency review before every stakeholder presentation. Cross-section contradictions in a BA deliverable are highly visible to experienced stakeholders and damage the overall credibility of the analysis.
- The decisions-required section is the practical output of the BA engagement from the steering committee's perspective. Make it specific, structured, and time-bounded — vague decision requests produce delayed decisions and stalled projects.
- The quality of every AI output in this workflow is determined by the quality of the inputs. Well-labeled, structured inputs produce specific, actionable outputs. Vague, unstructured inputs produce vague, generic outputs that require extensive rework.