Proof-of-Concept Evaluation Scorecard
A scorecard for judging whether a proof of concept succeeded, against criteria you write before it starts, with a verdict and the conditions for going live.
Free to use, and no email step stands in the way.
What the workbook holds
- Settings: the credit for Yes, Partly and No, and the limits at which a weighted result counts as a success or as mixed
- Scorecard: for each criterion, how it is measured, the target, a weight and whether it is a must-have, all filled in before the work starts
- Result and target met for each criterion, recorded when the proof of concept ends
- A weighted result and a verdict, with a rule that a must-have rated No overrides the arithmetic
- Go-live conditions: an owner, a run on live data, risk sign-off, a redrawn process, a tested fallback and a stop date for the old route, each with evidence
- A space for what was learned and what changes
Order of use
- 01
Write the first columns before the work starts
Criterion, measure, target, weight and must-have go in first. Save a dated copy, so the criteria cannot drift to fit the result.
- 02
Score at the end, not along the way
Record each result and mark Yes, Partly or No after the proof of concept ends.
- 03
Then fill in the conditions
A success shows the idea works. The conditions ask whether the business can run it.
What the verdict is not
The verdict limits are examples you can change, not a standard. The scorecard judges against your own criteria and cannot say whether they were the right ones. For the step after a success, use the AI-to-Production Readiness Playbook.
On this page
A proof of concept scored after the fact gets argued, and the loudest reading wins.
So the criteria are written first and kept.
What do people ask before using the proof-of-concept scorecard?
When should I fill in the proof-of-concept scorecard?
Before the proof of concept starts, write the criterion, how it is measured, the target, its weight and whether it is a must-have, then save a dated copy. When the work ends, record the results. Writing the criteria first stops them drifting to fit the outcome.
What makes a good criterion for a proof of concept?
One you can measure under production conditions. For example, run the work on live data through the route production will use, set the target at no manual clean-up, and mark it a must-have. A pilot that only ran on a tidy extract has proved the extract.
How does the scorecard reach its verdict?
It gives credit for Yes, Partly or No, weights each criterion, and compares the total with limits you can change. A must-have rated No overrides the arithmetic. A must-have rated Partly does not, so read those rows yourself before accepting a success.
What should I do after the proof of concept succeeds?
Complete the go-live conditions below the scorecard. A success shows the idea works, not that the business can run it. The conditions ask for an owner, a run on live data, risk sign-off, a redrawn process, a tested fallback and a stop date for the old route.
Judging a real proof of concept?
Describe what you are weighing in a few lines. A senior practitioner replies with a suggested first conversation.