Resolve scope demands against agreed outcomes

Learning objective

Manage scope changes and conflicting demands through governance checkpoints, explicit prioritization, and progress reporting against success criteria.

Core idea

A scope request changes what the service promises, who it serves, or what authority it exercises. Treat it as a decision about benefits, risks, resources, and acceptance, even when implementation appears to be a small prompt edit. Otherwise a team can deliver every requested feature while losing the outcome it was funded to achieve.

NIST AI RMF MAP 3.3 addresses documenting intended application scope; MANAGE 1.2 addresses prioritizing risk treatment by impact, likelihood, and available resources. Use a scope baseline, change register, and decision checkpoint to make those responsibilities actionable. Progress reporting then compares delivered outcomes with the approved success criteria rather than counting completed tickets.

How it works

Establish the baseline a request would change

Record the supported workflows, users, data classes, action authority, success criteria, delivery budget, and operating responsibilities in a scope baseline. Give it a revision and an approving owner. The requirements process identifies these commitments; change governance preserves their meaning when competing requests arrive.

Distinguish a defect from an expansion. Repairing an answer that violates the accepted rubric restores the approved service. Adding a language, population, decision type, or business write can require different evaluation coverage and ownership. A small implementation diff does not establish a small operational change. When classification is disputed, the accountable product owner records the decision instead of letting a developer’s estimate determine scope implicitly.

Create one change register entry per proposed outcome. Include requester, problem, expected benefit, affected success criteria, risk change, implementation and operating cost, dependencies, test plan, accountable owner, and decision date. Mark an estimate as uncertain when it is uncertain. A precise-looking benefit score without a credible basis should not outrank a measured production defect.

Use checkpoints with explicit decision authority

Specify which decisions the delivery lead can make within the approved baseline and which require product, operations, domain, or risk approval. NIST GOVERN 2.1 calls for clear documented responsibilities and communication lines, while GOVERN 2.3 places responsibility for AI risk decisions with executive leadership. A responsibility matrix makes consultation and approval different acts.

Hold a regular checkpoint for ordinary changes and a separate expedited route for urgent containment. For example, a weekly delivery review can decide reversible presentation changes, while a monthly steering review considers expanded authority or sustained operating cost. These intervals are illustrative choices. A harmful production defect should not wait for the steering meeting; the incident owner can use an approved containment procedure and bring its continuing scope implications to review afterward.

Each checkpoint produces an approved, deferred, declined, or investigation decision with rationale, owner, and next action. These are change-register dispositions you define. If leaders disagree about business priorities, escalate a concrete choice with its costs and consequences to the named sponsor. Do not ask the implementation team to resolve conflicting organizational commitments through unrecorded compromises.

Prioritize constraints before discretionary benefits

First identify obligations or risks that constrain what may proceed. Then compare feasible discretionary work by expected contribution to the approved outcome, confidence in that estimate, delivery effort, operating burden, and dependency order. NIST MANAGE 1.2 supports resource-aware prioritization of risk treatment; MANAGE 1.4 addresses documenting residual risks. Record who accepts any residual risk instead of treating a high benefit score as permission to ignore it.

A provider retirement notice creates a dated constraint in the change register. Anthropic’s Deprecated status means the model still functions but has a recommended replacement and a retirement date; requests after retirement fail. Anthropic gives customers with active deployments at least 60 days’ notice before retiring publicly released models. These dates and notices apply to Anthropic-operated platforms (the Claude API, Claude Platform on AWS, and Microsoft Foundry); on Amazon Bedrock and Google Cloud, the platform sets its own retirement schedule, so record the date from the deployment route actually used. Record the affected model identifier, retirement date, migration owner, and acceptance deadline, and prioritize migration before discretionary work that would prevent meeting that date. Migration mechanics belong to 2.1.4.

Require a displacement decision when capacity is fixed. Approving a change must identify what moves later, what budget increases, or what scope is removed. A priority list with every item marked urgent supplies no usable sequencing information. Where one request enables another, show that dependency rather than funding an attractive feature whose prerequisite is absent.

Use Anthropic’s specific, measurable, achievable, and relevant success criteria to test proposed benefits. A request to make answers more persuasive needs an outcome and a rubric before it can compete with a measured reduction in erroneous routing. Where value is uncertain, authorize a bounded investigation with a spending limit and decision date; do not count an unresolved estimate as delivered benefit.

Report progress against the accepted outcomes

Publish a concise status record showing each success criterion’s approved target, comparable baseline, observed result, measurement coverage, trend, and accountable owner. Include approved scope revision, consumed budget, unresolved risks, decisions needed, and the next checkpoint. NIST MANAGE 4.1 includes change management in post-deployment monitoring, and MANAGE 4.2 connects measurable improvement with regular stakeholder engagement.

Distinguish implemented, measured, and accepted work. A feature can be implemented while its benefit remains unmeasured; a metric can improve while a required constraint still fails. Report those states directly. Keep the earlier target when a scope revision changes a criterion so stakeholders can see why the commitment changed instead of mistaking a relaxed target for better performance.

Return decisions through the feedback route in 6.3.1. Tell affected users what changes, why, what behavior they should expect, and when their workflow is affected. The technical release and rollback design belongs elsewhere; this checkpoint decides whether the changed promise is approved and whether affected owners can support it.

Key distinctions and trade-offs

Governance versus consensus: Consultation brings relevant information to the decision. A named decision owner resolves the remaining conflict; unanimous preference is neither necessary nor always possible.

Speed versus accountability: Delegated authority keeps routine work moving. Expanded data access, business authority, or recurring support burden needs the owners who can accept those obligations. Calibrate the checkpoint to the change’s consequences.

Output progress versus outcome progress: More delivered features can consume capacity without improving accepted outcomes. A useful progress report can say that implementation is complete while acceptance remains blocked.

Architecture / decision scenario

A healthcare scheduling service uses Claude to draft patient-facing appointment instructions for staff approval. A five-person team has six weeks remaining and 30 engineer-days of available change capacity. Its approved success criteria require a 25% reduction in staff handling time and at least 98% correct routing on the agreed evaluation population. The observed results are 18% faster handling and 95% correct routing.

The operations director asks for multilingual instructions, estimated at 20 engineer-days. The clinic lead requests routing repairs, estimated at 15 days. A sponsor also asks for automatic message sending, estimated at ten days. Accepting all three consumes 45 days and adds authority that the approved staff-review workflow does not grant.

The architect brings a change record to the weekly checkpoint. The product owner prioritizes the routing repair because it addresses a failing accepted criterion, funds five days to investigate multilingual coverage, and reserves ten days for retesting and operational readiness. Automatic sending is deferred to a steering decision requiring clinical and risk ownership; implementation cost alone does not authorize it.

The report shows the 95% result against the unchanged 98% target, consumed capacity, and the deferred benefits. It does not declare the service ready because several features shipped. The sponsor resolves the competing delivery promises, while the clinical owner accepts routing quality and operations owns staff readiness. The tempting alternative of squeezing all requests into the deadline hides both a capacity shortfall and an unapproved change in business authority.

Common exam traps

• Treating a prompt-sized implementation as automatically within the approved service scope.
• Accepting conflicting requests without naming the decision owner or displaced work.
• Ranking a measured risk violation below a speculative feature benefit because the feature has a senior sponsor.
• Reporting completed tickets while accepted success criteria remain below target.
• Revising targets without preserving the prior commitment and approval rationale.

What to remember

Maintain an approved scope baseline, an owned change register, and checkpoints matched to decision authority. Prioritize required constraints and explicit trade-offs, then report measured outcomes against the criteria stakeholders actually approved.

Knowledge check

References

• NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0)
• Anthropic, Define success criteria and build evaluations
• Anthropic, Model deprecations