Write a scope that can be tested, approved and changed deliberately

TL;DR: Write the pilot's users, outcome, measurement, included and excluded work, prerequisites and decision process. Circulate it for factual corrections and obtain the required approvals separately; later changes need explicit effects on scope, evidence and resources.

Where you are. Discovery has a candidate workflow problem and a decision register. This lesson turns them into a scope before the premium lab gives you a separate packet to solve from scratch.

Use six sections without hiding the dependencies

A concise summary helps people review the proposal. One page is a useful target, not a rule that overrides necessary detail. Link a measurement appendix and prerequisite register when needed, and make sure the intended readers can access them.

Problem. Describe the workflow and evidenced consequence. Use the customer's terminology, but distinguish their estimate from your observation. A precise sentence can still state that the cost or cause is unknown.

Users. Define a specific user group, affected workflow and relevant roles. Personal names can help coordinate work but are not required for every scope, and a department can contain several distinct user groups. State who tests usability and who accepts operating responsibility.

Success. Choose a primary outcome with a baseline definition, eligible population and observation window. Include quality, completeness and safety conditions so speed cannot hide wrong or missing results. If the baseline is unavailable, make obtaining credible evidence part of the plan; historical data may help if comparable and valid.

Included work. Describe a complete user path and its boundaries. A thin slice can reduce scope while retaining the checks needed for its actual effects. A rule of thumb about starting small does not make every scope reduction safe or every complex design impossible.

Excluded work. Name plausible adjacent requests and the fallback for them. “No write-back” is clearer than “simple integration.” A non-goal is a proposed boundary, not a defense against correcting an actual defect in the agreed work.

Risks and prerequisites. Record required evidence, owners, resources, dependencies and the response if they fail. A scope document can link these details rather than treating them as a short list of generic concerns.

Review the filled-in scope

The following fictional proposal retains the course's portal lookup scenario while making unresolved approvals and measurements explicit.

scopesynthetic scope · draft for correction and required decisions

Proposed scope: portal exception lookup for the transport desk

Problem: the five-person exceptions desk cross-checks shipment and manual records before deciding what to do. This exercise supplies a baseline of 34 completed eligible lookups, median nine elapsed minutes, observed on 16 and 17 February. No individual timing data is supplied in this scope; retain that limitation and do not treat it as the later lab dataset. [1]

Users: the five designated desk operators, with the desk lead coordinating workflow review. Their production grants and review capacity must be confirmed; a named user group alone does not establish authorization.

Proposed success rule: median lookup time at most three minutes, measured from opening an eligible portal exception until the correct shipment and approved manual section are available. Review at least 34 eligible attempts under the same proposed measurement plan, report completed and unresolved counts, and stop the trial on any observed wrong-shipment result. The example thresholds are proposed pilot rules, not statistical assurance. A passing timing median with unresolved attempts does not itself approve expansion. [2]

In scope: portal-raised exceptions with a current order reference for the designated desk users. A current order is present in the approved transport export. Missing or ambiguous matches produce a visible unresolved state and stay in the attempt denominator. Show source cut time and age; the pilot may serve the lookup only while age is within the approved 26-hour limit and the other required checks pass. Read-only, with no action on the transport system.

Not in scope: email exceptions, the separate southern portal, migrated status-9 orders whose route mapping is unresolved, transport write-back and a management dashboard. Keep the existing manual process available for excluded work. These are explicit scope choices for review, not permission to lose that work. [3]

Prerequisites and risks: data owner confirms allowed source use; platform owner grants and tests access; security owner reviews the actual data path and caller scope; operations confirms the current manual and review capacity. An unverified manual cannot be presented as authoritative guidance. Failed freshness or identity checks route to the existing process. A 91% match rate reported from an earlier sample lacks the count and selection method here; investigate it rather than treating it as production accuracy. [4]

Plan and decision: target review on 28 March, conditional on the approved prerequisites and sufficient observed cases. If access or evidence is delayed, the delivery owner recalculates the dependency path and options; each day of delay does not automatically mean one day of schedule slip. The sponsor decides continuation within the business remit after reviewing the result and unresolved requirements. Changes to data use or operating controls still need their responsible decisions.

1. [1] The baseline summary is supplied for scope practice. It is not evidence that the learner observed these cases, nor a dataset to merge with the following lab.
2. [2] Define the timer, eligible attempts, unresolved work and quality guard together. Lookup time remains distinct from full exception resolution.
3. [3] Non-goals make likely adjacent requests visible and preserve a defined fallback for excluded work.
4. [4] Prerequisites need evidence and responsible decisions. Dates, friendly contacts and warnings on a screen do not replace required controls.

The three-minute target addresses lookup, not total exception resolution. A carrier response can still dominate the time until closure. Do not relabel the improvement or multiply the median difference by volume to claim labor saved.

The earlier 91% matching figure is insufficiently specified. Ask for numerator, denominator, source period, selection and error definition. Since the proposed path already concerns portal cases, “narrow to portal orders” would not repair its failures. Investigate ambiguous and wrong matches, make unresolved behavior explicit, and consider a newly defined narrower cohort only as a separate proposed scope with its own evidence.

Calculate freshness from the source cut

“Nightly” does not by itself guarantee data no more than 26 hours old. Age depends on the snapshot cut, processing and delivery, time of use and missed runs. Use the source time that represents the data, not merely the time the file reached your server.

Run this standard-library fixture with timezone-aware UTC timestamps. It checks an age rule over supplied times only; real clock trust, source completeness and access checks are separate.

from datetime import datetime, timedelta, timezone

def within_age(cut, now, max_hours=26):
    if cut.utcoffset() is None or now.utcoffset() is None:
        raise ValueError('Timezone-aware timestamps required')
    if max_hours < 0:
        raise ValueError('Maximum age must be nonnegative')
    age = now - cut
    return timedelta(0) <= age <= timedelta(hours=max_hours)

cut = datetime(2026, 2, 24, 0, 0, tzinfo=timezone.utc)
for hours in [2, 26, 27, 50]:
    print(hours, within_age(cut, cut + timedelta(hours=hours)))
assert not within_age(cut, cut - timedelta(minutes=1))
# 2 True
# 26 True
# 27 False
# 50 False

A file arriving at 02:00 with a midnight cut is already two hours old. If no new cut is available, it reaches the illustrative limit at 02:00 the next day. A missed run can therefore invalidate the claimed freshness even though yesterday's import succeeded.

At the boundary, state whether the rule is inclusive; this fixture allows exactly 26 hours. A future cut time is rejected instead of being interpreted as unusually fresh. In production, use the agreed clock and source semantics and record what happens when freshness cannot be established.

If operators need a status change within 15 minutes, a 26-hour lookup contract does not meet that requirement. Either establish a suitable approved source or revise the workflow and the promise. Displaying a stale-data warning is useful but does not automatically make stale information acceptable for the decision.

Change scope with a visible tradeoff

A fictional change request adds email exceptions from two large customers. Those emails may lack order references, so the work needs a separate identification path and evaluation. It is not merely another button on the same lookup screen.

List the extra work, data and permissions, review effort and schedule dependencies. Compare options: defer email, replace another optional deliverable, or revise time/resources if authorized. Keep the manual-panel dependency visible if it is required for the original lookup decision; dropping it may invalidate the promised end-to-end outcome.

A sponsor can choose among feasible business options within their authority. They cannot turn a failed required access control into an acceptable release by choosing a date. Update the scope version, affected metrics, non-goals and decision record after the responsible approvals. Preserve the previous version so a reviewer can distinguish changed commitments from missed ones.

Ask for corrections and approvals explicitly

Ask operators to correct workflow details, data owners to confirm semantics, reviewers to identify requirements and delivery owners to check resources. These are useful reviews. They do not replace the required decision to proceed.

A quick approval is not evidence that someone failed to read, and a request for corrections does not guarantee careful review. Make the exact requested decision and unresolved conditions clear. Record who approved what scope and when, and keep implementation verification separate from approval of a plan.

If readers disagree, retain the disagreement with its effect on the pilot. “Everyone has seen the document” is not the same as a shared commitment. Confirm the decisions that matter rather than relying on silence.

The spine below puts the six sections in the order you write them and then separates the two things people routinely merge: asking for corrections and asking for a decision.

Do this before moving on

Write the six sections for the observed workflow from the first discovery lesson. Add a measurement appendix with timer boundaries, eligibility, unresolved cases and a quality guard. If a needed baseline is missing, specify how to obtain it instead of inventing one.

Run the freshness fixture, then reduce the maximum age to 24 hours. Exactly 24 passes and 26 fails. Add a timezone-naive input and verify an explicit error. Explain which source and clock assumptions the function does not verify.

For the email change request, write two feasible options and the requirements each adds. End with a specific decision request and responsible roles. Keep the original scope result distinct from any expanded trial. The following lab supplies new timings and a freshness change so you can apply these habits without customer access.

Go deeper

• Scope from evidence provides observation notes and timed cases so you can practise without a customer.

• Scoping ambiguous problems covers how to choose the slice that goes into the in-scope section.

• Explaining trade-offs is the skill the non-goals list turns into a conversation rather than a refusal.

• Proof of concept to production is where this document gets tested against reality.

• AI cost and unit economics is often the missing constraint behind a success criterion nobody can state.

• Shipped in days what should take months is the interview version of defending a scope under pressure.

Key takeaways

• A scope links a user path to measurement, boundaries, prerequisites and a decision.
• Keep lookup, resolution, elapsed time and labor claims distinct.
• Compute freshness from the agreed source cut and handle missed or uncertain updates.
• Non-goals support deliberate changes; they do not waive required behavior.
• Obtain factual review, required approvals and implementation evidence as separate steps.

Check yourself

Answer before you look. Recalling it is what makes it stick; recognising it does not.

1. 1A nightly export arrives successfully. Does that alone prove a 26-hour maximum data age?

   Yes, nightly always means under 26 hoursNo; source cut, time of use and missed updates determine ageYes, if the file has today’s name

2. 2The scope already covers portal cases, but matching performs poorly. Does “narrow to portal cases” mitigate the risk?

   Answer it, then reveal

3. 3Stakeholders send factual corrections. Has the pilot necessarily received all required approvals?

   Yes, participation implies approvalNo; record the actual scope decisions and prerequisites separatelyYes, unless someone explicitly objects