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

This is lesson six of Foundations of Forward Deployed Engineering. Write down the pilot's users, its outcome and measurement, included and excluded work, prerequisites and the decision process. Circulate it for factual corrections, and obtain the required approvals separately. Later changes need explicit effects on scope, evidence and resources.

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

Use six sections without hiding the dependencies. The failure this document prevents shows up at the release review.

Everyone has seen the scope, nobody has approved the data use, and the one measurement everybody remembers turns out to have had no baseline. Six sections, written in order, are how those three gaps stay visible.

A concise summary helps people review the proposal, and 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.

The first section is the problem, where you describe the workflow and its evidenced consequence, using the customer's terminology, but distinguish their estimate from your observation. A precise sentence can still state that the cost or cause is unknown. Next come the users. Name a specific user group, its affected workflow and relevant roles, though personal names aren't required for every scope, and a department can contain several distinct user groups. State who tests usability, and who accepts operating responsibility.

Success means a primary outcome with a baseline definition, an eligible population and an observation window, plus quality, completeness and safety conditions, so that speed can't hide wrong or missing results. If the baseline is unavailable, make obtaining credible evidence part of the plan, and historical data may help, if it's comparable and valid.

Included work describes a complete user path and its boundaries, and a thin slice can reduce scope while retaining the checks needed for its actual effects. A rule of thumb about starting small doesn't make every scope reduction safe. Excluded work names plausible adjacent requests and the fallback for them. "No write-back" is clearer than "simple integration". And a non-goal is a proposed boundary, not a defense against correcting an actual defect in the agreed work.

The last section holds risks and prerequisites. Record the 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.

Now review a filled-in scope. This fictional proposal keeps the course's portal lookup scenario, while making unresolved approvals and measurements explicit.

The five-person exceptions desk cross-checks shipment and manual records before deciding what to do. The exercise supplies a baseline of 34 completed eligible lookups, with a median of nine elapsed minutes, observed on February 16 and 17. No individual timing data is supplied, and the scope keeps that limitation. The users are the five designated desk operators, and their production grants and review capacity must still be confirmed.

The proposed success rule: a median lookup time of at most three minutes, timed from opening an eligible portal exception until the correct shipment and approved manual section are available. Review at least 34 eligible attempts, report completed and unresolved counts, and stop the trial on any observed wrong-shipment result. These thresholds are proposed pilot rules, not statistical assurance, and a passing median with unresolved attempts doesn't itself approve expansion.

In scope: portal-raised exceptions with a current order reference, for the designated desk users. Missing or ambiguous matches produce a visible unresolved state, and they stay in the attempt denominator. The screen shows source cut time and age, and the pilot may serve the lookup only while age is within the approved 26-hour limit, and the other required checks pass. It only reads, 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. The existing manual process stays available for excluded work. These are explicit scope choices for review, not permission to lose that work.

Prerequisites: the data owner confirms allowed source use, the platform owner grants and tests access, the security owner reviews the actual data path and the caller's allowed access, and operations confirms the current manual and review capacity. An unverified manual can't be presented as authoritative guidance. Failed freshness or identity checks route to the existing process.

The plan targets review on March 28, conditional on the approved prerequisites and sufficient observed cases, and if access or evidence is delayed, the delivery owner recalculates the dependency path and options. Each day of delay doesn't automatically mean one day of schedule slip. The sponsor decides continuation within the business remit, after reviewing the result and unresolved requirements.

Notice what the three-minute target covers. It addresses lookup, not total exception resolution, and a carrier response can still dominate the time until closure. So don't relabel the improvement, or multiply the median difference by volume to claim labor saved.

The scope also mentions a 91% match rate from an earlier sample. It's insufficiently specified, so ask for the numerator, denominator, source period, selection and error definition. Since the proposed path already concerns portal cases, "narrow to portal orders" wouldn't repair its failures. Investigate ambiguous and wrong matches, and make unresolved behavior explicit. A newly defined narrower cohort is a separate proposed scope, with its own evidence.

Next, calculate freshness from the source cut. "Nightly" doesn't by itself guarantee data no more than 26 hours old.

Age depends on the snapshot cut, processing and delivery, the time of use and missed runs, so use the source time that represents the data, not merely the time the file reached your server.

The lesson gives a standard-library fixture with timezone-aware UTC timestamps. Age is now minus the cut. The check passes when age is between zero and the maximum, 26 hours by default, inclusive at both ends. It then tries 2, 26, 27 and 50 hours after the cut. It checks an age rule over supplied times only. Real clock trust, source completeness and access checks are separate.

Two hours passes. Exactly 26 passes too, because the rule is inclusive. At 27 hours it fails, and at 50 it fails. A cut time in the future is rejected, instead of being interpreted as unusually fresh.

So a file arriving at 2 a.m. with a midnight cut is already two hours old. If no new cut is available, it reaches the illustrative limit at 2 a.m. the next day. A missed run can therefore invalidate the claimed freshness, even though yesterday's import succeeded. In production, use the agreed clock and source semantics, and record what happens when freshness can't be established.

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

Now 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 isn't merely another button on the same lookup screen. List the extra work, data and permissions, review effort and schedule dependencies.

Then compare options: defer email, replace another optional deliverable, or revise time and resources, if that's authorized. Keep the manual-panel dependency visible if the original lookup decision needs it, because dropping it may invalidate the promised end-to-end outcome.

A sponsor can choose among feasible business options within their authority, but they can't turn a failed required access control into an acceptable release by choosing a date. After the responsible approvals, update the scope version, affected metrics, non-goals and decision record, and preserve the previous version, so a reviewer can tell changed commitments from missed ones.

Finally, ask for corrections and approvals explicitly. Different readers correct different things.

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, but they don't replace the required decision to proceed.

A quick approval isn't evidence that someone failed to read, and a request for corrections doesn't 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" isn't a shared commitment. Confirm the decisions that matter, rather than relying on silence.

Your turn. Pause the video here. 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, where exactly 24 passes and 26 fails, and add a timezone-naive input to verify an explicit error. For the email change request, write two feasible options and the requirements each adds, and end with a specific decision request and responsible roles. Keep the original scope result distinct from any expanded trial.

To recap. 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 don't waive required behavior. And obtain factual review, required approvals and implementation evidence as separate steps.

That's lesson six. Next in the series, build an evidence map of an unfamiliar system. The full lesson, with its exercise and drill, is on fdeinterviews.com.