Quantum computing pilots are having a moment. Plenty of organisations have run a small experiment on a cloud-accessible quantum service: an optimisation problem, a chemistry simulation, a sampling exercise, often with a vendor or a research partner helping out. These pilots tend to be planned with real enthusiasm. Then the cloud credits run out, the partner moves on, the one engineer who understood the circuits gets pulled back to core work and, a year later, nobody can find the notebooks. If that sounds uncomfortably close to home, this FAQ is for you. It covers the questions to settle about what happens after a quantum pilot, ideally before the experiment even starts, so the effort you put in keeps paying off.

Why does the end of a quantum pilot need planning at all?

Because quantum pilots are unusually easy to lose. They are typically small, exploratory and run by a handful of people. They sit outside normal product roadmaps. Their results are often “promising but not yet practical”, which is honest but makes it tempting to shelve them. And the field moves quickly: the hardware, software kits and access models you used may look quite different in a year or two.

All of that means the value of a pilot depends heavily on what you do afterwards. A well-preserved, well-documented pilot can be picked up again when hardware improves. A forgotten one has to be repeated from scratch.

What should we have in hand when the pilot ends?

Think of it as a closing pack. At minimum, aim for:

• A plain-language summary: what problem you tried, why, what approach you used and what you found, including what did not work.
• The code and notebooks, stored in your normal version control rather than someone’s personal workspace.
• Environment details: which software kit versions, which backend or simulator, and any settings that mattered.
• The classical baseline you compared against, so a future team knows what “better” would have to mean.
• Raw results and how to reproduce them, or at least enough detail that someone could try.

Write the summary for a reader who was not involved. In two years, that is exactly who will read it.

Who should own the pilot once it is over?

Someone named, not “the innovation team”. This person does not need to keep working on quantum full-time. Their job is lighter: keep the closing pack findable, keep an eye on relevant developments in the field and raise a flag when it might be worth revisiting the work. Agree who this is before the pilot starts, so the role is accepted rather than dumped on whoever happens to be around at the end.

If possible, choose someone who was involved in the pilot and is likely to stay with the organisation. Continuity matters more than seniority here.

How do we know when to look at it again?

Revisits are where pilots usually fall through the cracks, which is exactly why they deserve the most care. Before the pilot ends, book a revisit: a short review at a set point in the future, already in calendars. At that review, the owner checks a few simple questions. Has hardware or software in this area changed meaningfully? Have error rates or qubit connectivity moved on enough to matter for our problem? Has the business problem itself changed?

Understanding what to watch for helps. Our explainers on how quantum error correction works and why it matters and on qubit connectivity and hardware layouts cover two of the areas where progress could change the outlook for a shelved pilot.

What about the people who learned the skills?

Good question, and an easy one to overlook. A pilot often leaves behind two or three people who now understand quantum circuits, the relevant software kits and the practical limits of current hardware. That knowledge fades quickly if unused.

A few light-touch ways to keep it alive:

• Give pilot participants a small amount of time to keep following developments, perhaps through a reading group.
• Ask them to run an internal session sharing what they learned, recorded for later.
• Encourage them to pair with newcomers if the work is ever revived.
• Note in the closing pack who has the skills, so future teams know whom to ask.

Should we keep a relationship with the vendor or research partner?

Usually yes, if it went reasonably well. Pilots are often run with a cloud provider, a hardware company or a university group. Before the engagement ends, agree how you will stay in touch: a periodic catch-up, a contact person, perhaps an invitation to their updates. This costs very little and means that when you revisit the pilot, you are not starting a relationship from cold.

Also check what happens to your data and code on their platform when access ends. Download anything you need before credits or accounts expire. People regularly discover, too late, that results stored only on a vendor’s service vanished with the account.

How do we explain a “not yet” result to leadership?

Carefully, and in advance. Many quantum pilots end with a finding along the lines of “this approach does not beat our classical method today, but here is what would need to change for it to”. That is a genuinely useful outcome, yet it can sound like failure to people who expected a breakthrough. Agree with sponsors before the pilot starts that learning where the boundary sits counts as success.

When the pilot ends, frame the summary around three points: what you now know that you did not before, what signals would justify picking the work up again and what the organisation has kept in the form of code, skills and contacts. Leaders tend to respond well to a clear picture of the option they are holding, rather than a vague promise or a quiet shelving.

Is there a handover, even if nobody is continuing the work?

Yes. Even if the pilot is being shelved, there should be a short handover from the active team to the named owner. Walk through the closing pack together. Let the owner try running something from the stored code to make sure it is actually reproducible. Agree the revisit date. It takes an hour or two and dramatically improves the chance that the work survives.

Is this kind of after-planning unique to quantum?

Not at all. It is the same principle that applies whenever a big, carefully planned event is followed by a stretch that gets improvised. A neat example from a very different area is medical travel, where planners such as SurgeryPlanet, which helps people arrange treatment abroad, fold the patient’s accommodation, airport pickups and post-treatment support into the itinerary from the outset. Quantum pilots benefit from the same instinct: the period after the experiment belongs in the plan.

What does a simple after-pilot plan look like?

Here is a lightweight template you can drop into your pilot proposal:

1. Closing pack contents: summary, code, environment, baseline, results.
2. Owner after the pilot: one name, agreed in advance.
3. Handover session: a date near the end of the pilot.
4. Data export: confirm everything is downloaded before access ends.
5. Revisit review: a date in the future, already in calendars, with a short list of questions.
6. Skills retention: who holds the knowledge and how they will keep it fresh.
7. Partner contact: how and how often you will stay in touch.

Fill it in during planning, not in the pilot’s final week, when everyone’s attention is already elsewhere.

What is the one thing to remember?

A quantum pilot is a bet on the future. Its value is not only what it shows today, but what it lets you do later, when the technology has moved on. That later value only exists if someone planned the after-period: who keeps the work, how it is preserved and when you look again. Spend an hour on that plan before you start, and your pilot becomes a foundation rather than a forgotten experiment.