A memo for CIO and CTO offices on what to do about quantum computing now, what to defer, and when to reassess.
What a quantum computing strategy needs
Every large organisation needs a quantum computing strategy it can state on one page. That strategy should have four things:
- a named owner;
- a bounded budget;
- a set of review triggers;
- a date on which it will be revisited.
Waiting is a legitimate position when it is chosen deliberately, documented and governed. The position can also differ across the enterprise. A company may lead in a research domain central to its future products, follow in operational optimisation and monitor everything else.
This memo sets out a three-step method for choosing among four postures: lead, follow, prepare and monitor. It closes with three actions the CIO/CTO office can complete within one quarter.
Why the board is asking about quantum
The question reaches the CIO/CTO office from several directions at once:
- An independent director asks about quantum strategy at a quarterly board meeting, and the question is minuted.
- The CEO returns from a conference with a competitor’s announcement.
- A large integrator proposes a proof of concept.
- A business unit has already run an experiment with a university.
Each of these asks the same question: what are we doing about quantum computing? The office must answer with limited evidence. AI programmes already claim most of the technology budget, and published forecasts of commercial usefulness vary by many years.
Why pilots and informal deferral both fail
Two responses are common, and both leave the organisation exposed.
Visible activity. The first response is to launch pilots. Spending begins before the organisation has agreed what it is trying to learn, results are hard to compare, and modest results erode the credibility of the whole subject.
Informal deferral. The second response is to defer: “too early for us.” This is often a reasonable judgement, yet it is frequently recorded nowhere, with no owner, criteria or review date. When a peer announces results, or the board asks again, the office has to reconstruct its reasoning under pressure.
The shared root cause. Both responses treat timing as a technology forecast. Expert forecasts disagree, so a forecast gives management little to act on. Timing is better handled as a capital-allocation decision under uncertainty. Management teams already have well-tested tools for that kind of decision: staged commitments, explicit options and agreed conditions for revisiting a choice.
Resolution: a three-step method
Step 1. Assess exposure
Exposure has three components. They have different owners, so assess each one separately.
- Computational dependence. Do important decisions depend on optimisation, simulation or sampling problems that current methods solve only approximately or slowly? Typical areas are pricing, routing, scheduling, portfolio construction, risk calculation and materials or molecular simulation. The more value that depends on such problems, the higher the exposure.
- Competitive tempo. Are peers, key suppliers or customers building capability? Useful public signals include specialist hiring, consortium membership, research partnerships, patent filings and published results. Little visible activity in a sector is also informative.
- Cryptographic exposure. Does the organisation hold sensitive data with a long confidentiality life? Post-quantum cryptography migration belongs to the CISO and runs on its own regulatory timetable. NIST’s NCCoE migration project is a useful reference for that work (NIST NCCoE: Migration to PQC). It is included in the position memo because boards often merge it with the broader quantum question, and separating it keeps both discussions accurate.
Step 2. Weigh lead time against the cost of learning
The second question is how long the organisation would take to act once evidence justified it. The slow elements are mostly organisational: owned problem formulations, data access, credible classical baselines, people who can translate between business and technical teams, vendor access, and governance that architecture, security and finance accept. For most large organisations, assembling these takes several quarters. Set that lead time against two costs:
- The cost of learning now. This includes external spend, management attention and time taken from scarce data and architecture teams.
- The cost of being late. This is what the business loses if a competitor adopts first, or if a credible result appears and the organisation needs a year to respond.
A long lead time combined with a high cost of being late justifies early, inexpensive preparation, even where exposure is moderate. The test that matters throughout is economic: computational value has to exceed the full cost of obtaining it. DARPA’s Quantum Benchmarking Initiative frames “utility scale” in these terms (DARPA QBI). In an enterprise, that cost also includes data preparation, integration and support.
Step 3. Choose a posture for each domain
Combining exposure with lead time gives four postures. Each is the correct choice for a particular combination, and none is a measure of ambition. Apply the matrix domain by domain. A single posture for the whole enterprise usually overstates some areas and neglects others.
Exhibit: Quantum posture matrix
Each posture implies a different commitment. Each also carries triggers that can reduce the commitment as well as increase it.
When a programme narrows, pauses or closes, its findings are kept for the next decision. A documented stop is a useful output.
Three planning horizons for quantum strategy
The chosen posture is easier to govern when commitments follow the organisation’s own planning cycle. Each horizon is a planning scenario with conditions attached. None of them is a prediction.
- Current budget cycle. Approve only work whose purpose and cost can be specified now. Typical items are an inventory of computationally constrained decisions, classical and GPU benchmarking of the most important ones, a named owner and governance path, and confirmation that cryptographic migration is tracked. Each item should produce an output that supports a named decision.
- Next investment period. List the opportunities that become investable when specific evidence appears. That evidence could be a result against a tuned baseline, a hardware performance or cost threshold, or validated adoption by a peer. State what evidence would release funding and who approves it.
- Longer strategic horizon. Record the developments that would change the posture itself, such as fault-tolerant machines at useful scale or a regulatory change affecting the sector. Treat supplier roadmap dates as assumptions to test, and name an owner for each signal.
Scheduled reviews should be combined with these triggers, so that a material development gets attention between meetings.
How to prepare for quantum computing without a dedicated budget
The prepare and monitor postures can be funded almost entirely from existing budgets.
- Problem inventory. Enterprise architecture and business owners list the ten most computationally constrained decisions, with current methods, costs and baselines.
- Continuous benchmarking. These problems are reassessed periodically against improving classical, GPU and AI methods, using existing cloud and HPC budgets. Efficiency gains are reported as classical improvements. They fund themselves and build the evidence history that a future quantum decision will need.
- Governance. Quantum becomes a standing agenda item in an existing forum, such as the architecture board or technology radar.
Each of these assets transfers directly if a domain later moves to follow or lead. A decision to wait stays credible as long as five things are maintained: an owner, a documented rationale, a review date, a short trigger list and a minimal monitoring budget.
Example: a telecoms operator planning network capacity
Consider a telecommunications operator examining network capacity planning. The business owner sees potential value in better capacity allocation. However, the team has no strong baseline on representative network data, and improvements to the existing optimisation process already have an approved business case.
The CIO chooses prepare for this domain. During the next quarter, the planning and data teams build a representative dataset, document the current baseline and identify the interfaces a future evaluation would need. A named technology owner tracks relevant external evidence.
Management agrees a trigger for moving to follow: a credible external result that makes a specific approach worth testing under the operator’s own constraints. At that point, a capped evaluation tests whether the approach adds value after data handling, execution and integration costs.
The operator now has a reasoned position, useful work for the quarter and a defined route to its next decision. The preparation also strengthens its existing optimisation programme.
Quantum strategy actions for the next quarter
- Draft a one-page position memo. Owner: CIO/CTO office. For each domain, cover exposure, chosen posture, budget envelope, triggers and review date. State the main alternative considered. Agree it with business owners, finance and architecture before presenting it at the executive committee. If the question was minuted, file the memo with the board secretary.
- Build the problem inventory. Owner: enterprise architecture with business owners. List the ten most computationally constrained decisions, with current baselines and owners. This underpins every posture.
- Separate the cryptographic track. Owner: CISO. Confirm that post-quantum migration is planned and reported on its own track, and include a status line in the position memo.
Success after one quarter is easy to recognise. When anyone asks “what are we doing about quantum?”, the organisation answers with a documented position, an owner and a date.
Part of the QuantumOps executive series by QCentroid: practical guidance for leaders building a repeatable, governed approach to advanced computing.