7 Stakeholder Communication & Lifecycle Management (14%) · CCAR-P

What the exam tests: running discovery, explaining trade-offs to different audiences, setting realistic expectations, and carrying a Claude system from idea to steady operation. Official task statements: conduct structured discovery and requirements gathering; communicate architectural decisions and trade-offs; manage feedback loops and expectations, including SLAs; document architectures and provide implementation guidance; support lifecycle phases from discovery through design, handoff, monitoring, and iteration.

Structured discovery

Discovery comes before design. In an exam stem, if requirements are vague, the right first step is almost always to clarify them.

Area Questions to ask

Business What outcome, for whom, how is it measured today, what is it worth?

Users and process Who uses it, at which step, what happens to the output, what is the fallback? Data Which sources, who owns them, how fresh, how sensitive, what permissions apply? Quality What does a good answer look like? What error rate is acceptable, and which errors are unacceptable?

Non-functional Volume, latency, availability, residency, budget, integration points Risk and compli‐

ance

Regulated data? Decisions about people? Who must sign off?

Outputs of discovery: a problem statement, success criteria with baselines, a first evaluation set built with domain experts, constraints, and a list of stakeholders with their decision rights (a RACI).

Communicating decisions and trade-offs

Record significant decisions as architecture decision records (ADRs): context, options considered, decision, consequences, and the evidence (evaluation results, cost model). ADRs let a later team understand why the system looks the way it does.

Tailor the message to the audience.

Executives: outcome, cost, risk, timeline, and the decision you need from them. One page. Product and business owners: what users will experience, error rates in plain terms, where humans stay in the loop.

Security, legal, compliance: data flows, controls, residency, retention, audit trail. Engineers: architecture, interfaces, prompts and evals as code, runbooks.

Explain non-determinism honestly. Say "94% of cases met the standard on our 400-case test set; the other 6% go to review" rather than "it's accurate."

Managing expectations and SLAs

LLM SLAs combine classic and quality measures: availability, p95 latency, throughput, plus quality floors (grader score, escalation rate, critical-error rate). Agree them with the business before launch, base them on evaluation evidence, and include provider dependencies (rate limits, regional outages) with fallbacks such as a secondary region or platform, queueing, or graceful degradation to a human path. When a pilot underperforms, the professional move is to show the data, name the cause, propose options with their cost and timeline, and let the owner choose. Do not quietly widen scope or quietly lower quality bars.

Documentation and handoff

A handoff pack includes the architecture diagram and data flows, ADRs, prompt and tool inventory with versions, the evaluation suite and thresholds, runbooks (incident, rollback, model migration, key rotation), dashboards and alerts, the risk assessment, and named owners. Run a shadow period where the receiving team operates the system with the build team on call.

The lifecycle

Figure 6. The solution lifecycle is a loop, not a line

Discovery: requirements, success criteria, first eval set.

Design: pattern choice, prototype, evaluation against baseline, ADRs, risk review. Build and harden: integration, guardrails, regression suite in CI, load test. Launch: canary, A/B, human review heavier at first.

Handoff: documentation, training, shadow operation.

Monitor: quality, cost, safety dashboards; feedback capture.

Iterate: grow the eval set from failures; tune prompts, retrieval, routing; plan model migrations; retire when value ends.

Deep dive: leading the people side

Decision rights with a RACI

Ambiguous ownership is one of the most common reasons AI projects stall. Agree a RACI (Responsible, Accountable, Consulted, Informed) early. Decision Business owner Architect Security Legal and compliance Platform team Success criteria and targets A R C C I

Architecture and pattern C A C I R
Retire when value ends
Discovery
requirements, first eval
set

Design

pattern, prototype, ADRs

Build and harden
guardrails, CI
regression

Launch
canary, A/B, heavier
review

Handoff
docs, training,
shadowing

Monitor

quality, cost, safety

Iterate

grow evals from failures

STAKEHOLDER COMMUNICATION & LIFECYCLE MANAGEMENT (14%)

Decision Business owner Architect Security Legal and compliance Platform team Data access and permissions C R A C R

Human oversight tier A R C C I
Launch go or no-go A R C C C
Model or prompt change in production I A I I R
Incident response I C R C A

Adapt it to the organization; what matters is that each decision has exactly one accountable person.

Change management for AI adoption

Technology is rarely the limiting factor; adoption is. A proven sequence:

Make the case: a clear problem and a credible benefit for the people who will use the system, not only for leadership. Involve users early: they write evaluation cases, test prototypes, and shape the workflow. Address fears directly: what the system will and will not do, how roles change, and how quality is protected.

Train for judgment: not only how to use the tool, but how to check its output and when to escalate.

Start with champions: a pilot group that shares results and tips with peers.

Measure and share: publish adoption, outcome, and quality metrics; celebrate improvements; fix problems visibly. Embed: update procedures, job aids, and performance expectations so the new way becomes the normal way.

A communication plan

Audience What they need Channel Frequency

Executive sponsor Outcomes, risks, decisions needed One-page update, steering meeting

Architecture, runbooks, changes ADRs, runbooks, change log Continuous

Tracking value after launch

A business case is a forecast; value tracking checks it.

Use the baseline from discovery and the same measurement method after launch. Where possible, compare with a control group (teams or regions not yet using the system). Track leading indicators (adoption, task success rate) and lagging outcomes (cost per case, customer satisfaction, revenue).

Report honestly when value falls short, with the cause and the plan.

Working with vendors and partners

Model providers and platforms: understand service terms, data handling, regional availability, rate limits, support levels, and deprecation policies; plan model migrations. Third-party MCP servers and tools: assess security, maintenance, and data access before adoption.

Systems integrators: define deliverables including evaluation sets, documentation, and knowledge transfer, not only working code.

Exit planning: keep prompts, evaluation sets, and integration code in your own repositories so you can change vendors or models without starting over.

Worked example 7.1: running a discovery workshop

Brief. A national retailer's COO asks for "AI in the stores." You have a half-day workshop with operations, store managers, HR, IT, and legal.

Agenda.

Time Activity Output

min

COO frames goals: which numbers matter this year 2 to 3 target outcomes (for example shrink, staff turnover, time on admin)

min
Store managers walk through a typical day; capture time
sinks and pain points
15 to 25 candidate problems

min
Score candidates on value, feasibility, risk, and data readi‐
ness
A prioritized shortlist

min
For the top 2: who uses it, at what step, what "good" looks
like, data sources, constraints
Draft problem statements

min

Risks and sign-offs: legal, HR, IT security Named approvers and red lines

min

Agree next steps: baselines, sample cases, pilot store Owners and dates Example problem statement produced. "Store managers spend about 6 hours a week answering staff questions about scheduling rules and HR policy. A policy assistant on store tablets should answer 70% of these with correct citations, cutting manager time by 3 hours a week,

STAKEHOLDER COMMUNICATION & LIFECYCLE MANAGEMENT (14%)

without giving advice that contradicts labor law in any province. Pilot in 5 stores in Q1; HR owns policy content; legal approves the escalation rules."

Notice what it contains: user, problem, baseline, target, constraint, scope, owner, and approver. That is what "structured discovery" means on the exam.

Worked example 7.2: one decision, three audiences

Decision. The architecture team chose hybrid retrieval with reranking over vector-only retrieval for a support assistant. It adds about 250 ms latency and some cost, and raised correct-answer rate on the evaluation set from 81% to 90% (illustrative figures). For the executive sponsor (three sentences). "We chose the more accurate search design. It raises the share of correct answers from about 8 in 10 to 9 in 10 in testing, which we estimate cuts escalations to human agents by a third. It adds a quarter of a second to responses and a small increase in running cost, both within budget."

For the support operations lead. Focus on what agents and customers will see: fewer wrong answers, which question types still need escalation, how to flag bad answers, and the review process.

For engineering (ADR).

Context: vector-only retrieval missed exact product codes and error messages. Options: (1) vector-only with larger top-k, (2) hybrid without reranking, (3) hybrid with reranking.

Decision: option 3.

Evidence: retrieval recall at 8 rose from 74% to 91%; answer correctness from 81% to 90%; p95 latency from 2.9 s to 3.15 s; cost per conversation up 6%.

Consequences: reranker becomes a dependency with its own monitoring; index must store keyword fields; revisit if the latency SLA tightens.

Worked example 7.3: resetting expectations mid-project

Situation. Six weeks into a twelve-week build, the business owner has started describing the assistant to customers as "fully automated" and "never wrong." The design includes human review for 15% of cases and measured accuracy is 92%.

Response.

Meet the owner promptly and privately; bring the data.

Restate what was agreed: target accuracy, review rate, scope.

Explain the risk: overpromising harms customer trust and may create legal exposure if customers rely on "never wrong."

Offer accurate language: "answers most questions instantly; complex cases are checked by our specialists."

Agree a communication plan with marketing and legal.

Record the agreement and revisit at the next steering meeting.

Worked example 7.4: a handoff that works

Situation. A consultancy built a claims-triage system and hands it to the client's platform team. Handoff plan.

Week Activity

1 Walkthrough of architecture, ADRs, data flows, risk assessment 2 Client team runs the evaluation suite and makes a small prompt change through the full release process 3 Shadow on-call: client team leads incidents with the build team available 4 Game day: simulate a model-version migration and an ingestion failure using the runbooks 5 Sign-off: client team owns operations; build team on call for questions for 30 days Success test: the receiving team can change, release, monitor, and roll back the system without the builders.

Scenario drills

Two executives disagree: one wants maximum automation, the other maximum control. How do you move forward?

A business owner rejects the evaluation set as "too technical." How do you make it useful to them?

The pilot is a success and five more departments want the same assistant next month. What do you plan before scaling?

A system has run for a year; usage has fallen by half. What lifecycle decision should you raise?

Engineering wants to switch vector databases. What must the change include for the decision to survive staff turnover? A regulator asks how your system reaches its outputs. What documentation should exist? Answers.

Reframe around risk tiers: automate the low-risk segment, keep human control on the highrisk segment, and let data from a pilot set the boundary. Document the decision and owners. Have them write or approve cases in their own words, and report results as business outcomes ("would this answer have been acceptable to send?").

STAKEHOLDER COMMUNICATION & LIFECYCLE MANAGEMENT (14%)

Discovery per department (different data, users, risks), shared platform components, capacity and cost planning, governance approval by risk tier, and a support model. Investigate why (needs changed, quality fell, a better tool appeared), then improve, refocus, or retire it, including data deletion and decommissioning.

An ADR with options and evidence, an updated architecture diagram, migration and rollback runbooks, and re-run evaluations. System documentation (purpose, data flows, models, controls), evaluation results, risk assessment, audit logs, and human oversight procedures.

Common traps

Starting to build when the stem shows unclear requirements.

Promising 100% accuracy or deterministic output.

Briefing executives with architecture detail instead of outcomes and decisions. A handoff with no runbooks or eval suite.

Check yourself

A VP asks for "an AI for our claims team" by next quarter. Your first three actions? What belongs in an ADR?

The pilot hits 88% against a 95% target. How do you report it?

Name four items in a handoff pack.

Answers: (1) Discovery interviews with the claims team, define measurable outcomes and baselines, gather representative cases for an eval set. (2) Context, options, decision, consequences, evidence. (3) Show the data and error categories, the likely cause, options (fix retrieval, add review for a segment, narrow scope) with cost and time, and ask the owner to decide. (4) Any of: architecture and data flow, ADRs, prompt and tool inventory, eval suite, runbooks, dashboards, risk assessment, owners.