A company becomes curious about quantum computing, reads a few headlines and decides to commission a small study. It contacts a researcher or a specialist team with a message like “We want to explore quantum for our logistics.” What comes back is enthusiasm, a long reading list and an open-ended engagement. Months later, nobody can say whether anything was learned. This how-to walks through the steps for writing a brief for a quantum computing proof-of-concept, so that whoever you ask can respond with a testable plan and you can judge the answer honestly.

Step 1: Describe the problem without naming the technology

Begin with the business or research problem in ordinary words. “We assign delivery vehicles to routes each night, and the current method takes hours and leaves unused capacity” is a problem. “We want to apply quantum optimisation” is a solution in search of one. Leave the technology out of the first paragraph on purpose. If quantum methods turn out to suit the problem, a good specialist will say so; if a classical method suits it better, you want to hear that too.

For readers who need background on why optimisation tasks attract attention, a clear account of how quantum algorithms approach hard optimisation problems sets the scene without overpromising.

Step 2: Record the classical baseline

This is the step most often skipped, and yet nothing else keeps the exercise honest. Write down how the problem is solved today, how long that takes, what quality of result it produces and what it costs. Without a baseline, any result from a prototype can be made to sound impressive. With one, the comparison is concrete: better, equal or worse than what you already have.

If you do not have measurements, say so, and make “measure the current method” the first task in the brief. That is a perfectly valid outcome for a first phase.

Step 3: Define the question the study must answer

A proof-of-concept is an experiment, so give it a question rather than a deliverable. Good questions look like these: “On a small, representative sample of our routes, does a quantum or hybrid approach find solutions comparable to our current method within the same time?” or “Which parts of this workload are plausible candidates for quantum acceleration, and which clearly are not?” A question can be answered “yes,” “no” or “not yet.” That is what makes it useful.

It helps to keep expectations grounded in current hardware. Pieces such as an overview of how quantum approaches could speed up searching are valuable partly because they explain the conditions under which an advantage appears, which are often narrower than headlines imply.

Step 4: Supply the inputs you can share

List the data, models and constraints you can provide. Say whether data can leave your premises, whether it needs anonymising and who must approve sharing. Provide a small, clean example dataset if you can. A researcher who receives realistic inputs in the first week can start experimenting; one who must wait a month for access will lose momentum.

Step 5: Set the acceptance test

Write, before any work begins, what result would count as success and what would count as an informative failure. For instance: “Success: a prototype produces routes within an agreed margin of our current plan on the sample set, with the method and parameters documented. Informative failure: a written explanation, with evidence, of why the problem size or structure does not suit current devices.” Both outcomes are worth paying for. The only unacceptable outcome is an ambiguous one.

Where machine learning is the focus rather than optimisation, the same discipline applies; a discussion of how quantum ideas might reshape machine learning is a useful reminder to separate what is demonstrated from what is hoped for.

Step 6: State the timeline and checkpoints

Short and staged works best. A common shape is three checkpoints: a first review where the baseline and the plan are agreed, a midpoint where early results are shown and a final review against the acceptance test. Put dates beside each. Give a total time limit, because open-ended research tends to expand to fill whatever time exists.

Step 7: Give a budget range and limits

Write a bracket for the whole study, along with practical limits: which cloud platforms or simulators may be used, whether paid device time is included, who owns any code produced, and what must remain confidential. If hardware access has a cost that varies, ask for it to be shown separately so you can see where money goes.

Step 8: Specify the hand-over

Decide what you will receive at the end: a short report with methods and caveats, code in a repository, the datasets used in the experiments and a recorded briefing for colleagues. Ask for the “what we tried and why it did not work” section explicitly. Negative results are often the most valuable part of an early study.

Step 9: Review the brief with a sceptical colleague

Before sending the page, hand it to someone who was not involved and ask them to restate, in their own words, what the study will deliver. If they cannot, the brief has gaps. This takes ten minutes and often catches an ambiguous phrase that would otherwise cost weeks.

Step 10: Send it to people who can respond

Universities, research groups, cloud providers and independent consultants all work in this field. Some teams also browse listings of independent specialists. ProfessNow works from a profession and a city, lists profiles for you to read and lets you submit a booking request, which can be a way to reach technology professionals near you, and the brief you wrote can be pasted straight in. Always weigh what a respondent tells you against your own baseline and test, rather than against promises.

A compressed example

Problem: nightly assignment of vehicles to delivery routes; current heuristic takes several hours and leaves some capacity unused.

Baseline: current method’s runtime and cost per route, measured over the last month.

Question: on a sample of representative nights, does a hybrid approach match the current quality in comparable time?

Inputs: anonymised route data for the sample, constraints document.

Acceptance: results within an agreed margin, or a written explanation of why not.

Timeline and budget: three checkpoints over a fixed period, within a stated bracket.

Hand-over: report, code, data and a short recorded briefing.

Mistakes to avoid

• Beginning with the technology instead of the problem.
• Skipping the classical baseline.
• Writing deliverables that assume success.
• Leaving the end date open.
• Failing to say who owns the results.

Conclusion

Quantum computing is an area where claims run ahead of evidence, which makes a written brief more valuable than usual. It forces you to say what you are testing, how you will compare it and what you will do with an unexpected answer. Follow the steps in order, keep the page short and treat the outcome, whichever way it falls, as information. A study that returns a clear “not yet” with reasons is a success by the standard you wrote down at the start.