Technology Roadmapping

The Roadmap That Was Really a Wish List

Every serious space agency keeps technology roadmaps. Every serious commercial space company has begun to keep them. And almost every roadmap in circulation has the same pathology: a clean arc of capability building from current state to ambitious future state, dated milestones that look precise until they are challenged, and a resource footprint that has either been wished into existence or left unspecified altogether. The roadmap looks like a plan. It is often a forecast dressed up as a plan — a belief about how the future should unfold, rendered in the visual vocabulary of project management to make it feel commensurate with executive decisions.

The consequence is predictable. A program launches on the strength of a roadmap. Three years in, a subordinate technology that the roadmap listed as a parallel stream turns out to be on the critical path rather than adjacent to it, and the schedule slip that follows is not a schedule slip so much as a revelation that the roadmap’s dependencies were asserted rather than analyzed. Executive leadership discovers the structure of the problem by running into it, and the program’s credibility absorbs the damage.

Technology roadmapping, properly practiced, is a discipline designed to prevent this pattern. Its value is not in predicting the future but in making sequencing, dependencies, and resource constraints legible before they bite. Its failure mode is well understood: roadmaps treated as forecasts rather than as structured hypotheses about sequencing become misleading artifacts, and the space sector produces them in abundance.

From Motorola Product Planning to the Cambridge T-Plan

The method’s origin is more prosaic than its current usage suggests. Motorola developed the technology roadmap format in the 1970s as an internal tool for coordinating semiconductor and product planning — a way of linking the evolution of underlying technologies to the product generations that would depend on them, so that R&D investment and product development could be sequenced without surprising either side. The visual language of roadmaps — the layered chart with time on the horizontal axis and market, product, and technology streams stacked vertically — dates from that period, as does the insistence that the layers be linked by explicit dependency arrows rather than merely placed alongside each other.

The method moved from proprietary practice to published methodology in the 1990s and 2000s, primarily through the Cambridge T-Plan approach developed by Robert Phaal and colleagues at the Institute for Manufacturing. Cambridge T-Plan formalized the workshop-driven process by which roadmaps are constructed, the standard layer definitions, and the discipline on dependency mapping that distinguishes analytical roadmaps from aspirational ones. The Cambridge formulation is the one most commonly taught today, and its influence is visible in agency-level practice: NASA’s Technology Taxonomy and ESA’s Harmonisation process both trace their structure through the T-Plan tradition, adapted to the institutional review cycles of government space programs.

Commercial space has adopted the method unevenly. The multi-generation architecture planning that companies with reusable launch vehicles, satellite constellations, and long-horizon exploration ambitions require maps well onto the roadmap format, but the discipline with which roadmaps are actually constructed varies sharply. Agency roadmaps tend to be rigorous on dependency mapping and thin on resource realism; commercial roadmaps tend to be rigorous on resource realism and thin on dependency mapping to the deep technology layer. The best roadmaps combine both disciplines, and those are rarer than the format’s prevalence would suggest.

What a Roadmap Does That a Gantt Chart Does Not

The characteristic analytical gesture of technology roadmapping is the layering of demand, capability, technology, and resources on a shared timeline, with explicit dependency links across the layers. A Gantt chart sequences tasks; a roadmap sequences causal enablement. The distinction matters because the binding constraint on when a capability can be delivered is rarely a schedule constraint on a single development activity — it is a dependency constraint where a specific enabling technology must reach a specific maturity before a dependent technology can even begin its own development cycle.

Cislunar Propulsion on a Shared Timeline

Consider the method applied to a generic planning exercise for cislunar propulsion capability. The demand layer identifies two dated needs: routine cargo to lunar orbit by 2035, and a cislunar tug service capable of transferring payloads between orbits by 2038. These are placed as dated demand nodes on the timeline.

The technology layer traces backward from each demand. Routine cargo to lunar orbit is enabled by a chemical propulsion architecture currently at TRL 8, with a well-understood path to TRL 9 through operational demonstration. The trajectory is confident; the milestones are straightforward. The tug service is the harder problem. Its demand depends on a 100-kilowatt-class solar electric propulsion capability — not kilowatt-class, which has flight heritage, but 100-kilowatt-class, which is currently at TRL 5 with known scaling challenges on power generation, thermal management, and thruster lifetime at the target power level. The propulsion layer itself is not the binding constraint; the power system layer is.

The dependency mapping reveals two linkages that a surface reading would miss. First, the tug service cannot be qualified without access to the cargo delivery infrastructure that the 2035 milestone establishes — the tug depends on upstream cargo capability not just for development testing but for its operational viability. Second, the 100-kilowatt SEP milestone gates the tug directly, which means that if SEP power scaling slips past 2033, the tug misses its 2038 window because the downstream qualification cycle has insufficient schedule margin.

The critical path runs through SEP power scaling. This is the binding constraint. Propulsion chemistry — which executives focus on because it is the headline technology — is not the binding constraint; power system maturity is. The roadmap’s resource layer follows this finding: investment should concentrate on power-system-side scaling rather than on thruster development, because the thruster development path is tractable once the power system supplies the input.

A decision point at 2031 is marked explicitly on the timeline. If SEP power scaling has stalled by that date, the program must commit to either accepting a schedule slip on the tug demand node or pivoting to a nuclear electric propulsion alternative currently at TRL 3. The nuclear alternative bypasses the solar bottleneck but carries substantially higher technology risk and a different regulatory pathway. The decision-point register names the trigger criteria, the options, and the estimated cost of each option at the decision date. No surprises are allowed; if the decision arrives, its structure is already understood.

The stress test applies plausible disruptions. A two-year slip on the 100-kilowatt SEP milestone cascades through the tug program and forces either a demand-node revision or a pivot; the roadmap documents what that cascade would look like and which downstream commitments would be at risk. A successful lateral innovation — say, an alternative power architecture emerging from an unrelated research stream — is treated as an opportunity to revisit the critical path, not as a disruption to be defended against.

The non-obvious insight the roadmap produces, and that a program-level Gantt chart would not, is that the capability most often cited in the program’s external messaging — the tug — depends on a power system program that is not the tug program’s headline. The binding constraint is one layer below the visible layer, and the roadmap is the artifact that makes that binding constraint legible to decision-makers with resource authority.

Where It Earns Its Keep and Where It Falls Short

The method’s strength is coordinated sequencing across multi-stream, multi-generation programs. When a capability depends on several technology streams that must converge on schedule, and when the dependencies cut across organizational and budgetary boundaries, the roadmap is the only method that makes the full structure legible. It is the backbone of strategic technology planning at serious agencies and commercial space ventures for this reason.

Its weaknesses are equally characteristic. Roadmaps create an illusion of predictability that is rarely justified. Long-range technology forecasting is inherently uncertain, and roadmaps presented as forecasts rather than as structured hypotheses about sequencing mislead executive decision-making. The corrective is to present timelines as ranges rather than as points and to update the roadmap on a defined cadence rather than letting it decay into a historical artifact.

The method tends to be linear and incremental, privileging the official trajectory of incumbents and underweighting disruptive lateral innovations that could bypass the mapped path entirely. Pairing with horizon scanning catches disruptive signals that the roadmap itself would not surface; pairing with scenario planning stress-tests the roadmap against alternative futures in which the demand nodes themselves shift. A roadmap that is the product of these pairings is richer than one built in isolation.

Resource realism is routinely shortchanged. A roadmap without a credible resource layer — funding estimates, facility availability, workforce flows — is a wish list with decoration. Conversely, a resource layer that is confident in its estimates but thin on dependency mapping produces the mirror-image failure mode. The method’s full value requires both disciplines applied together, and practitioners who prioritize one at the expense of the other produce analyses with characteristic blind spots.

Roadmaps are less useful for topics where the technology itself is mature and the challenge is political, economic, or regulatory. For those cases, policy cycle analysis, comparative policy analysis, and regulatory impact analysis carry the load. And roadmaps should never be confused with predictions: a roadmap that declares “we will have capability X by date Y” with no decision points, no stress tests, and no alternative paths is engineering in the wrong genre.

The library treats roadmapping as densely connected to its neighbors. Three horizons analysis supplies the temporal framing for H2→H1 and H3→H2 transitions that the roadmap instantiates at the technology layer. Backcasting pathways supply the demand-pull targets that anchor the demand layer. Scenario planning stress-tests the roadmap against alternative futures. Trend analysis informs milestone timing assumptions. TRL assessment populates the technology maturity readings. A roadmap disconnected from these neighbors is either a closed system confident in its own assumptions or an artifact for presentation rather than analysis.

For the Practitioner