Proof of Concept Plan Template

Before writing any criterion, agree who will decide and by what date. Ask what the date is tied to, usually a budget cycle or a contract renewal. It's the date least likely to move, so plan everything else backward from it.

Keep the window short. Microsoft, in a playbook for customers testing its own Azure Synapse analytics service, calls a POC a scoped, time-bounded exercise with specific, measurable goals¹. It suggests narrowing the scope of any POC that would run past 4 weeks.

Put the frame at the top of the plan:

• The window, with real dates
• The team in scope, its named users and its weekly volume
• The decision maker, by name
• The decision date, and what it's tied to

Then write down what happens on a pass, a partial result and a fail, and agree that a partial gets decided on the day. A cautious buyer reads the fail branch to judge whether the pilot is safe to start.

Go back through everything the buyer has said: call notes, their requirements list, any scoring matrix and the champion's emails. List every condition of buying in their words. Don't tidy them yet: vague wording shows you where the buyer still has to decide what they mean.

Then check four places the formal list often misses:

• The problem the champion described first
• Any question asked on two different calls
• What their last vendor got wrong
• Who else must approve: security, legal, IT or procurement

A stakeholder map shows who those approvers are, and a few discovery questions fill the gaps in thin notes.

For each criterion, note who cares about it and what they'd accept as proof. Then ask for the number that's rarely in the notes: how much work the team in scope handles in a week. A rough figure from their manager is fine.

Specific and measurable isn't enough. Check each criterion against the observations the pilot will actually produce:

1. 1

   Name one observation

   A quote, a ticket, an onboarding, a named user. No unit, no verdict.

2. 2

   Count what the window produces

   The weekly rate of the team in scope times the pilot's length, not the company's volume.

3. 3

   Find the floor

   The smallest change that many observations can separate from noise.

4. 4

   Compare the target

   Above the floor, it's decidable. Below it, rewrite it. Not about the product? It's a dependency.

NIST's handbook of statistical methods explains what drives the count for an average: your tolerance for false alarms and missed changes, and the spread of what you measure². By its formula, halving the difference you want to detect takes four times the observations.

Evan Miller, who writes about A/B testing statistics, gives a rule of thumb for the sample size³. For each side, take 16 times the variance and divide by the square of the difference you want to detect. The variance is the standard deviation squared for an average, and p × (1 − p) for a rate.

Cutting rework from 12% to 8% puts p near 0.1, so you need 16 × 0.1 × 0.9 ÷ 0.04², or 900 quotes a side. Turned around, the floor is 4 times the standard deviation, divided by the square root of the count per side. For 420 quotes a side and a standard deviation of 4.2 hours, that's about 49 minutes.

For zero-error targets, a short paper in The BMJ gives a simple rule for events that haven't happened yet⁴. After more than 30 cases with none, the upper 95% confidence limit on the true rate is 3 divided by the number of cases. After 50 clean cases, the rate could still be 6%. Six clean onboardings prove almost nothing.

Don't drop a criterion that fails. Rewrite it into something the window can decide, and keep the original beside it so the change is visible:

• A rate becomes a back-test: rerun known past failures and count how many no longer fail.
• A rare event becomes a replay: require every past record with the fault to be caught.
• A percentage of a small group becomes a count: seven of nine named users doing the task unaided by day 21.

If the buyer prefers the original, widen the scope: three desks over the same 30 days handle about 1,260 quotes, enough for the rework test.

In the signed agreement, give each criterion an absolute pass mark, such as 4.88 hours or less rather than 25% faster. Then say how it will be checked: unit, count, sourced baseline and verdict date. US federal rules ask for the same two things in performance-based service contracts: measurable performance standards and the method of assessing performance against them⁵. Leave pricing out, or the agreement becomes a negotiation.

During the pilot, log each observation the day it happens: what was seen, who saw it, who from the buyer was there and where to find it. Count awkward cases, like a record that couldn't be run, as failures.

Treat weekly readings as trends, not verdicts. Stopping early on a good number inflates false positives, so Miller's advice is to decide on a sample size in advance and wait until the experiment is over³.

Two working days before the decision meeting, send an exit note giving each criterion's requirement, result, verdict and evidence.

After a pass, plan the steps to a signed contract in a mutual action plan and turn the results into a business case. For a faster start, open this template with Edit with AI, and River will check each criterion against your team's weekly volume.