Part 6 — Domain 6: Stakeholder Communication & Lifecycle Management (14%)
Prep-course lesson: Stakeholder Engagement, Lifecycle & GTM (178 min). Official tasks: structured discovery and requirement gathering · communicate decisions and trade-offs · feedback loops and expectation alignment (incl. SLAs) · document architectures and implementation guidance · lifecycle phases (discovery, design, handoff, monitoring, iteration).
Topics: 6.1 Structured discovery · 6.2 Communicating decisions, trade-offs, and business cases · 6.3 Expectations, SLAs, objections, and approvals · 6.4 Documentation, handoff, and lifecycle ownership
Note: "Go-to-market and solution positioning" appears in the prep-course lesson title but is not called out in the Exam Guide's D6 task statements. It is included here as supplemental (6.2) — study it lightly relative to discovery, trade-off communication, SLAs, documentation, and lifecycle.
6.1 Structured discovery and requirement gathering
1. Objectives. Run discovery that yields measurable requirements, constraints, and acceptance criteria; find hidden stakeholders and blockers.
2. Prerequisites. D1.1.
3. Beginner. Discovery = asking the right people the right questions before designing. People describe solutions ("we need a chatbot"); you uncover problems, constraints, and success measures.
4. Advanced. Map stakeholders: sponsor (funds, owns outcome), users (daily workflow), domain experts (ground truth), IT/platform (integration, ops), security/privacy/legal/compliance (approval gates), finance/procurement, support/ops (will run it). Capture: business objective and baseline; users and workflow; data (sources, quality, owners, sensitivity); systems and integrations; volume, latency, availability needs; error cost and tolerance; regulatory constraints; budget/timeline; success metrics and acceptance criteria; change-management readiness. Translate vague goals into measurable requirements ("fast" → "p95 < 3 s"; "accurate" → "≥ 92% on golden set; zero critical violations"). Separate requirements from assumptions and open risks; get sign-off on scope and non-goals. Look for conflicting requirements (instant + perfect + cheap) and surface them early as trade-offs.
5. Sample discovery questions. - Outcome: What decision or task are we improving, for whom? What does it cost or delay today? What would make you call this a success in 6 months? - Workflow: Walk me through the last case end to end. Where do people wait, rework, or escalate? - Data: Where does the knowledge live? Who owns it? How often does it change? What can't leave your environment? - Risk: What's the worst thing this could do wrong? Who is harmed? What must a human always decide? - Constraints: Which regulations, internal policies, or contractual terms apply? Who must approve before launch, and what do they need to see? - Systems: Which systems must it read/write? Who administers them? What are the auth models and rate limits? - Operations: Who will run it after launch? What are your uptime/SLA expectations? How will you measure value? - Adoption: Who might resist, and why? What training is needed?
6. Diagram.
flowchart LR
S[Stakeholder map] --> I[Interviews / workshops]
I --> R[Requirements: functional, NFR, compliance]
R --> C{Conflicts?}
C -- yes --> T[Trade-off decision with sponsor]
C -- no --> A[Acceptance criteria + scope + non-goals]
T --> A
A --> SO[Sign-off]
7. Scenario. Sponsor: "Make support instant and perfect." Discovery shows refunds >$200 need a manager; knowledge base is outdated; security requires EU data residency. Requirements recorded as measurable targets with a phased scope.
8. Recommended/alternatives. Structured, multi-stakeholder discovery with written acceptance criteria. Alternative: build from the sponsor's first description (rework, late security blocks).
9. Governance. Identify approvers (security, legal, privacy, risk) in discovery, not at launch week.
10. Cost/latency. Elicit volumes to size cost; elicit SLAs to choose architecture.
11. Mistakes. Talking only to the sponsor; accepting solutions as requirements; no baseline; no non-goals; discovering compliance blockers late.
12. Scenario question. The sponsor asks for "an AI agent" but gives no metrics. → Ask about the outcome, baseline, and error cost; convert to measurable acceptance criteria before choosing a pattern.
13. Revision. Stakeholder map; problem not solution; measurable requirements; surface conflicts; sign-off.
14. Docs. Prep Lesson 4; Exam Guide §6 D6.
6.2 Communicating decisions, trade-offs, and business cases
1. Objectives. Present architecture trade-offs in business language; build a defensible business case; communicate risk plainly.
2. Prerequisites. 6.1; D1 ADRs.
3. Beginner. Executives decide on outcomes, risks, cost, and time — not model names. Show options, what each costs, what each risks, and your recommendation.
4. Advanced. Structure: context → options → trade-offs → recommendation → risks/mitigations → decision needed → next steps. Express trade-offs as business levers: faster vs. cheaper vs. more accurate; autonomy vs. control; build vs. buy; phased vs. big-bang. Use a decision matrix with weighted criteria agreed with stakeholders. Cost estimate: requests × (input + output tokens) × price, adjusted for caching/batch, plus retrieval/infra, evaluation, people, and ops; present ranges and sensitivities (volume, prompt length). Benefit: hours saved × loaded cost, deflection, cycle-time, revenue lift — tied to baseline measurements; avoid inflated ROI. Risk language: "1 in N drafts may contain an error; a human reviews before sending; residual risk is X" instead of "hallucination". Tailor per audience: executives (outcome, risk, cost), security (controls, evidence), engineers (design details), operations (runbooks, SLAs).
5. Executive summary template.
Title: Claims Coverage-Summary Assistant — Decision Request
Problem: Adjusters spend ~40% of handling time reading notes/policies (baseline: 52 min/claim).
Recommendation: Deploy a draft-only assistant for adjusters (human decides), phase 1 in two regions.
Expected value: 15–20 min/claim saved (pilot-based range), ~$X/yr; cost ~$Y/yr at current volume.
Options considered: (A) draft-only assistant [recommended]; (B) autonomous decisions [rejected: regulatory/error cost]; (C) status quo.
Key risks & controls: inaccurate summaries → citations + adjuster review; data exposure → least-privilege access + audit logs; cost drift → budgets/alerts.
Evidence so far: pilot eval 94% fidelity on 300 claims; 0 critical violations in red-team set.
Decision needed by: <date> — approve phase 1 budget and security review start.
6. Architecture review presentation outline (10–12 slides). (1) Problem & goals (2) Success criteria (3) Constraints (4) Architecture overview with trust boundaries (5) Key decisions & alternatives (6) Safety/compliance controls (7) Evaluation evidence (8) Cost & latency model (9) Risks & mitigations (10) Rollout plan & ownership (11) Decisions requested.
7. GTM/positioning (supplemental). For partners/consultancies: position the offer around a business outcome and a repeatable delivery pattern (e.g., "knowledge assistant in 8 weeks with eval gates"), sized pilot → scale, with reference architectures, clear scope/exclusions, and measurable value; avoid overclaiming capabilities.
8. Recommended/alternatives. Outcome-first communication with evidence. Alternative: tech-first deep dives (lose decision-makers).
9. Governance. Document risk acceptances with the named accountable executive.
10. Cost. Provide ranges and what drives them; show how caching/batch/model-tiering change costs.
11. Mistakes. Jargon; single option; ROI without baseline; hiding risks; promising "100% accuracy".
12. Scenario question. A VP asks why the assistant can't be both instant and perfect. → Explain levers: latency vs. accuracy vs. cost; offer options (faster tier for simple cases, review step for high-stakes) with measured numbers.
13. Revision. Context→options→trade-offs→recommendation→risks→decision; business levers; honest ranges.
14. Docs. Prep Lesson 4; Messages pricing pages for cost inputs.
6.3 Managing expectations, SLAs, stakeholder feedback, objections, and approvals
1. Objectives. Align expectations, define SLAs/SLOs honestly for probabilistic systems, handle objections, and obtain security/legal/operational approval.
2. Prerequisites. 6.1–6.2; D3.6.
3. Beginner. LLM systems aren't deterministic. Promise outcomes you can measure, define what happens when it's wrong, and set up feedback loops.
4. Advanced. SLAs/SLOs: availability (depends on provider and your stack), latency percentiles, quality targets on defined test sets (an SLO, not a guarantee per response), escalation time, support hours, data-retention commitments. Be explicit about dependencies (model provider availability, rate limits, downstream systems) and degradation modes. Feedback loops: in-product ratings, reviewer corrections, escalation reasons → feed eval sets and backlog; share a monthly scorecard (quality, latency, cost, incidents, adoption). Objection handling: "It might hallucinate." → controls + measured rates + human review. "Data privacy?" → data flow diagram, minimization, retention, vendor terms, tests. "Too expensive." → cost model, caching/batch/tiering, phased scope. "Will it replace us?" → augmentation framing, role changes, training. Approvals: prepare a package per approver — security (threat model, control register, pen-test/red-team results), legal/privacy (data map, DPIA, vendor terms), operations (runbooks, monitoring, on-call), finance (cost model). Start early; track findings to closure.
5. Steps. (1) Define SLOs with measurement methods. (2) Publish expectations ("what it does, doesn't do, and how errors are handled"). (3) Set feedback cadence. (4) Build approval packages. (5) Track objections and decisions.
6. Diagram.
flowchart LR
P[Pilot results + control evidence] --> SEC[Security review]
P --> LEG[Legal/privacy review]
P --> OPS[Ops readiness review]
SEC & LEG & OPS --> G{All approvals?}
G -- findings --> FIX[Remediate + re-review]
G -- yes --> GO[Production go-live]
GO --> FB[Scorecard + feedback loop]
7. Scenario. Legal blocks launch two days before go-live for lack of a data-flow diagram and retention policy. Prevention: involve legal in discovery; supply the package with the design.
8. Recommended/alternatives. Early, parallel approvals with evidence packages. Alternative: sequential approvals at the end (schedule risk).
9. Governance. Keep decision logs: who approved what, based on which evidence.
10. Reliability. Never promise availability above your weakest dependency without redundancy/fallbacks.
11. Mistakes. Promising deterministic accuracy; SLA without measurement; ignoring operations/support; late security engagement.
12. Scenario question. Stakeholders demand a 99.99% availability SLA. → Clarify scope (feature vs. platform), analyze dependencies, propose tiered SLOs with fallback modes, and price the redundancy.
13. Revision. Honest SLOs; scorecards; objection→evidence; approval packages; early engagement.
14. Docs. Prep Lesson 4; Exam Guide §6 D6.
6.4 Documentation, handoff, and lifecycle ownership
1. Objectives. Produce architecture documentation and implementation guidance; run lifecycle phases (discovery → design → handoff → monitoring → iteration); design a handoff that survives your absence.
2. Prerequisites. 6.1–6.3; D7 enablement.
3. Beginner. The system must outlive you. Document what it does, why it's built this way, how to run it, and who owns what.
4. Advanced — lifecycle: Discovery (requirements, risks) → Design (architecture, ADRs, eval plan) → Build & pilot (evals, controls) → Production approval (readiness review) → Handoff (training, runbooks, ownership matrix) → Monitoring (scorecards, incidents) → Iteration (feedback → backlog → gated releases) → Retirement/migration (model deprecations, data deletion). Documentation set: solution overview; architecture diagrams with trust boundaries; ADR log; data-flow and data-classification; control register and risk register; prompt/config catalog with versions; eval plan and latest results; runbooks; cost model; SLOs and escalation paths; ownership (RACI); change/release process; known limitations. Handoff: shadowing, runbook drills, a "break-glass" scenario test, and a defined hypercare period; ownership is named people/teams, not "the AI team".
5. Production-readiness checklist. - [ ] Acceptance criteria met on held-out eval (quality, latency, cost) - [ ] Safety/security tests passed; red-team findings closed or risk-accepted - [ ] AuthZ verified with low-privilege and cross-tenant tests - [ ] Observability: dashboards, alerts, audit logs, cost alerts - [ ] Rollback tested; prompt/model/config versions pinned - [ ] Rate-limit, timeout, retry, fallback behaviors load-tested - [ ] Data protection: minimization, retention, deletion process verified - [ ] Approvals recorded (security, legal/privacy, operations, business owner) - [ ] Runbooks, on-call rota, escalation paths in place - [ ] Training delivered; support team can reproduce/triage - [ ] Monitoring/improvement cadence scheduled; model-deprecation plan noted
6. Diagram.
flowchart LR D[Discovery] --> DS[Design + ADRs] --> B[Build + pilot + evals] --> RR[Readiness review] RR --> H[Handoff + hypercare] --> M[Monitor] --> IT[Iterate via gated releases] IT --> M M --> RT[Migrate/retire]
7. Scenario. The architect leaves; the system breaks when a model version is deprecated and nobody owns the migration. Prevention: ownership matrix, deprecation calendar, runbook, eval suite to validate migration.
8. Recommended/alternatives. Documented handoff with owners and drills. Alternative: wiki dump with no ownership.
9. Governance. Keep ADRs, approvals, and evaluations versioned as audit evidence.
10. Cost. Include ongoing run costs (eval runs, monitoring, review labor) in the business case.
11. Mistakes. Handoff = a meeting; no named owner; no runbook testing; ignoring deprecations; no iteration budget.
12. Scenario question. Production go-live is next week; the team has never executed the rollback. → Not ready: rehearse rollback and incident response before launch.
13. Revision. Lifecycle phases; documentation set; readiness checklist; named owners; drills; hypercare.
14. Docs. Prep Lessons 4–5; Model deprecations page (platform docs).