Scoping a POC That Cannot Drift
Write the scope, definition of done and success criteria before building, so the proof of concept ends in a decision.
Scoping a POC That Cannot Drift
A proof of concept exists to support a decision: build this for real, change it, or stop. Everything in the scope serves that decision. A good scope names:
The out-of-scope list matters as much as the in-scope one. It is where you write down the things everyone will want to add later, so that adding them is a visible choice rather than a quiet assumption.
Why it matters
POCs without a written scope grow until they become unfinished products. Every new request feels small; together they delay the decision, blur the result and exhaust the team. Six weeks become twelve, and the final demo shows something different from what was agreed, so nobody can say whether it worked.
A scope also protects the customer. It makes them name the outcome they care about, find the baseline numbers they will be judged against, and commit their experts' time. If they cannot do those three things, it is better to learn it in week one than in week eight.
Finally, a scope with numbers turns the end of the POC from an opinion into a fact. "It felt promising" rarely gets a production budget; "handling time fell from 9 to 6 minutes on 200 sampled tickets, against a target of 7" usually does.
How to do it
Draft the scope from your discovery notes, using the template below.
Agree it with the sponsor in a 30-minute meeting; walk through the out-of-scope list and the decision owner line by line.
Send the written version the same day and ask for a reply confirming it. Silence is not agreement.
Keep a visible parking list. When a new request arrives, add it and state the trade-off: what moves, or what comes out, if it goes in. Let the sponsor choose.
Report weekly against the scope's metrics, not against a feature list.
Close with a one-page recommendation memo against the original criteria, even if the criteria turned out to be wrong. Say so in the memo.
A scope the sponsor signs
poc: Claims triage assistant
decision_owner: Head of Claims Operations # one named person
decision_date: 2026-12-04
user_group: Motor claims handlers, Sydney team (14 people)
task: Classify new motor claims and draft the first-contact summary
in_scope:
data: Motor claims lodged 2025-07-01 to 2026-06-30 (claims system export)
channels: Web and email claims only
out_of_scope:
- Home and travel claims
- Phone claims (no transcripts available)
- Settlement decisions or amounts
- Integration with the payments system
success_metrics:
- metric: Average triage time per claim
baseline: 9.0 min (time study, 200 claims, Oct 2026)
target: 6.0 min or less
- metric: Triage category accuracy
baseline: n/a
target: 92% overall, 100% on fraud-flag category
evaluation:
sample: 200 claims drawn at random from Oct 2026, held out from development
judged_by: Two senior handlers; disagreements go to the team lead
pass_mark_agreed_on: 2026-10-14
customer_commitment:
- Two senior handlers, 3 hours a week for labelling and review
- Claims system export within 5 working days
parking_list: [] # new requests go here, with their trade-offWorked example: a scope request in week three
Three weeks into a six-week POC, the sponsor asks to add home insurance claims "since we are already set up".
The reply: "Happy to. Home claims need a different category set and a new labelled sample, which is about two weeks of work. We can add them and move the decision date to 18 December, or keep 4 December and put home claims first on the list for the production phase. Which would you prefer?"
The request goes on the parking list with both options. The sponsor chooses to keep the date. The scope held, the relationship held, and home claims became the first item of the production plan instead of a quiet delay.
In a real engagement
Put the success criteria in numbers with a baseline: "reduce average handling time from 9 to 6 minutes on 200 sampled tickets", not "make support faster". If the customer has no baseline, measuring one is week one's task, not an assumption.
Name the person who decides. If no one will own the decision, the POC is not ready to start, however enthusiastic the team is.
Agree the pass mark before anyone sees results. A target set after the first run tends to move to wherever the results landed, and everyone notices.
Keep the scope short enough to read in two minutes. A ten-page scope is not read, and an unread scope does not stop drift.
Challenge
Three weeks into a six-week POC the sponsor asks for two new data sources. Write the two-sentence reply that keeps the relationship and the scope intact.
Checklist
Production checklist
0 of 7 checked
Knowledge check
What is the main purpose of a POC?
Complete
You have finished “Scoping a POC That Cannot Drift”. Continue to the next chapter or practise in the FDE simulator.
Mark this chapter as complete
Track your progress and unlock the next chapter.