The purpose is a decision, not a prototype
A feasibility study exists so you can decide whether to commit to a build. It is not a small version of the project, and judging it on how impressive the demo looks is the wrong test.
The measure of a good one is that afterwards you know something you did not know before, precisely enough to act on.
What it should contain
- A data assessment. What exists, its quality, what is missing, and whether outcomes are recorded reliably enough to learn from.
- A measured baseline. How well the current method performs, measured properly. Without this nothing later can be judged.
- An early performance indication. A rough model on real data, with an honest statement of what it achieved and under what conditions.
- The value estimate. What an improvement of that size would be worth, using your numbers.
- Risks and unknowns. What could still go wrong, and which questions remain open.
- A recommendation. Proceed, proceed differently, or stop - with reasoning.
The baseline is the part most often skipped
Measuring how well the existing process performs is unglamorous and frequently omitted, and it is what makes every later number meaningful.
It also sometimes ends the project usefully. A business convinced its forecasting is poor occasionally discovers the planner's spreadsheet is performing well, and that the money is better spent elsewhere. That is a valuable outcome from a small spend.
A good study can recommend stopping
| Finding | Honest recommendation |
|---|---|
| Outcomes not reliably recorded | Fix recording first, revisit in a year |
| Model barely beats the baseline | Do not proceed as specified |
| Improvement real but worth little | Not a priority; consider a different problem |
| Data exists but cannot be joined | Solve the data problem first |
| Clear improvement, clear value | Proceed, with defined scope |
A supplier who never recommends stopping is not assessing feasibility. The willingness to deliver bad news is most of what the stage is for, and it is reasonable to ask a prospective supplier when they last told a client not to proceed.
Scope and duration
A feasibility stage should be short and fixed price - weeks, not months. Its purpose is to reduce uncertainty enough to decide, not to build anything durable.
Expect the deliverable to be a written assessment with evidence, not a working system. Anything produced during it is exploratory and should be treated as such - reusing feasibility code as production code is a recognisable way to accumulate problems.
A feasibility study that could only ever conclude 'yes' was not a study.