Why Good Projects Die, Part 1: 6 Things We Learned From 302 Bioeconomy Projects

For years, we have watched promising bioeconomy projects disappear.

Some had celebrated technologies. Some had strong management teams, blue-chip partners, government support, attractive markets and hundreds of millions of dollars of announced investment. Many had favorable techno-economic analyses. Many had technologies judged sufficiently mature to proceed.

And yet they failed. Others, facing apparently formidable obstacles, survived. Why?

That question eventually became the starting point for a research program at Hudson River Company, a sister company to The Daily Digest created to develop and apply new systems for understanding project persistence, uncertainty and value. The Digest had spent years observing the bioeconomy and accumulating an unusually deep record of projects, companies, technologies, markets and outcomes. Hudson River Company was formed to turn observations from that history into formal tools that could be tested, improved and ultimately put to work on live projects. We assembled a corpus of 302 bioeconomy projects and began reconstructing what actually happened to them.

We weren’t looking for another list of reasons projects fail. There are plenty of those. We wanted to know whether there was an underlying structure to failure—and, more importantly, whether understanding that structure could tell us what to do before a project failed.

What emerged surprised us.

Observation 1: Failure is not a condition. It is a trajectory.

We are accustomed to assessing projects by taking snapshots.

What is the technology readiness level? What is the projected IRR? How much equity has been committed? Is there an offtake agreement? Has the permit been issued?

These are important observations. But they describe where a project is, not necessarily where it is going.

A project isn’t a snapshot in an album; it’s a vehicle moving through weather. Where it is matters—but so do its direction, the road ahead, and the options still available when conditions change.

When we reconstructed project histories, failure looked different.

Projects encountered events. Conditions changed. Management responded. Counterparties responded to those responses. Some options disappeared and others opened. A project that looked strong at one moment could enter a sequence from which recovery became increasingly difficult.

Failure wasn’t simply an attribute of the project.

Projects failed along paths.

Position mattered. But to understand persistence, we also had to understand trajectory.

Observation 2: Problems interact.

The second discovery was that the familiar categories of project risk were less independent than they appeared. Imagine a permitting delay: it looks like regulatory risk. But the delay moves construction. The construction delay increases cost. Higher cost consumes contingency. Reduced contingency concerns lenders. Financing is delayed. An offtaker becomes nervous about delivery and seeks different terms.

What killed the project? Permitting? Construction? Capital? Offtake? The question itself may be wrong. Each event changed the conditions under which the next event occurred.

Problems interact.

A disturbance that is easily survivable in one state can become devastating in another. That meant we could not adequately understand projects as collections of independent risk factors. We needed to understand the relations among them.

Observation 3: Failed projects still had futures.

This may have been the most useful discovery.

Looking backward makes failure appear inevitable. It rarely was. At earlier points in their histories, many failed projects still had multiple viable trajectories available. A different response to an event, another source of information, a changed commercial relationship or an intervention at the right moment could preserve pathways that subsequently disappeared.

That changed the question again. Instead of asking: How risky is this project?, we began asking: What action now preserves access to viable future trajectories? This is a fundamentally different problem. It moves us away from scoring and prediction and toward intervention.

Observation 4: Sequence matters.

Then we discovered that knowing what to do wasn’t enough. We needed to know what to do next.

Two sensible interventions performed in one sequence could preserve a project trajectory. The same interventions performed in the opposite sequence could arrive too late. Secure the feedstock agreement before a financing milestone and one future becomes available. Miss the milestone while pursuing something else and the same agreement may no longer rescue the financing.

In formal terms:

U_B U_A(X) ≠ U_A U_B(X)

The operations do not commute.

In plain English: sequence is a structural variable.

Same project. Same two actions. Different order. Different state. Different available futures. This was important because much conventional project advice produces lists: fix A, B, C, D and E. But projects live in time. The question isn’t simply what must be done? It is what must be done next?

Observation 5: This isn’t just a metaphor. There is mathematics underneath it.

At this point, it would be reasonable to say that trajectories, interactions, sequence and viable futures are simply useful ways of talking about project development.

We found something more interesting.

These are not simply metaphors about project development. They can be represented within a formal mathematical system of states, events, relations, interventions and trajectories. A project history can begin very simply:

X₀ → X₁ → X₂ → … → X_n

with interventions and timing represented as the operators that move the project from one state to the next. A project occupies a state, X. Something happens. An intervention, U, acts upon it at a particular point in sequence, t. The project enters another state.

Repeat.

Reality, of course, is considerably more complicated. Events recur. Actors engage with one another. Context changes what an intervention means. Available futures expand and contract. Different operations interact, and their sequence matters. To represent these effects, we developed a system for analyzing recurrence, engagement blocks, operators, viable trajectory spaces, contextual moduli and cooperative convergence, culminating in what we called Pumori, our operator treatment for representing how interventions transform project trajectories.

The practical consequence is much simpler than the mathematics. Uncertainty is not merely something we can describe. It has structure that can be analyzed—and, under the right conditions, acted upon.

That opens an extraordinary possibility. If an uncertainty can be located within the structure of a project trajectory, we can ask what operation acts upon it, what evidence establishes that the operation occurred, and what sequence of operations preserves the largest useful set of viable futures.

The objective is no longer to become better at predicting doom. It is to remove the things producing it.

Observation 6: We were looking in the wrong place.

Then the historical evidence gave us perhaps the biggest surprise of all. The bioeconomy devotes enormous attention to technology. We measure technology readiness. We perform techno-economic analysis. We debate yields, titers, conversion rates, scale-up and engineering. Those are important questions.

But they weren’t what killed more than 95 percent of the failed projects we examined. Fewer than 5 percent failed for technical reasons—and even those failures involved mixtures of technical and commercial factors.

That finding runs directly against one of the bioeconomy’s deepest habits. It doesn’t mean TRL and TEA are wrong. It means they answer questions that are different from the question we were trying to answer. TRL can tell us whether a technology has reached a particular stage of maturity. TEA can tell us whether a defined technical and economic configuration produces attractive economics under a defined set of assumptions. Neither necessarily tells us whether the project can persist in the world into which it is being introduced.

And increasingly, that was where we found the decisive information.

Feedstock availability and competition. Infrastructure. Product markets. Incumbents and substitutes. Counterparties. Policy. Logistics. Capital conditions. Regional industrial structure. Timing. Other projects competing for the same resources. We had become exceptionally good at examining the project. The evidence was telling us to examine the world around it.

A project does not operate in a spreadsheet. It enters an environment populated by other actors, competing trajectories, changing conditions and finite resources. Understanding the project therefore wasn’t enough. We needed to understand the world through which it was trying to travel.

That discovery led us to develop SWELL, our system for modeling the operating environment surrounding a project—markets, resources, counterparties, infrastructure and other external conditions—and how changes in that environment alter the viable trajectories available to it.

And then came the backtest.

We had started by asking why good projects die. We now had a formal framework for understanding how projects move through uncertainty, and another for examining the operating environment through which they must move.

But theories are cheap. There was an obvious next question:

Did it work?

Fortunately, we had 302 projects with which to find out.

In Part 2, we’ll open the books on that backtest. We’ll show how a live project becomes a machine-readable formal structure; how the Observatory connects it to our galaxy of historical evidence; and how uncertainty removed from a project can be translated into the concepts lenders use to underwrite and price risk.

Because somewhere along the way, our original question changed.

We had begun by asking why projects fail. We ended up asking something potentially far more valuable: What is uncertainty costing the projects that haven’t failed yet?

Category: Top Stories