A technically feasible energy project is not necessarily a viable project. Viability depends on whether several different conditions can hold together at the same time—and whether any one of them is weak enough to stop the project from moving.
Energy and infrastructure decisions are usually evaluated through disciplines. Engineers test technical performance. Finance examines economics. Commercial teams structure terms. Operations considers maintenance and staffing. Executives look at strategic fit. Procurement, legal, and project teams each add another layer of scrutiny.
Those perspectives are necessary, but the project experiences them as one system. A strong technical solution with weak institutional fit can fail. Excellent economics with an unworkable operating model can fail. A well-structured contract attached to a problem nobody urgently needs to solve can fail.
WORKING PRINCIPLE
A project is only as viable as the conditions that have to hold together.
The useful question is not simply whether the project works. It is what must be true—technically, economically, commercially, institutionally, operationally, and organizationally—for the project to move and remain workable.
The stack describes conditions, not job titles
It is useful to distinguish the Viability Stack from the roles involved in building a decision-ready business case. The project manager, analyst, stakeholder mapper, investigator, communicator, and other roles help the organization do the work. The Viability Stack describes what the work must ultimately establish about the project itself.
In other words: the roles help investigate the project. The stack describes the conditions the project has to satisfy.
1. Need — is there a problem important enough to solve?
Projects often begin with a technology, a capital plan, an incentive, or an aging asset. But none of those automatically creates a compelling project.
There has to be a sufficiently important underlying need: reliability, capacity, cost, asset condition, resilience, staffing, emissions, growth, risk, or another problem that justifies attention and organizational effort.
If the need is weak, the project will struggle no matter how attractive the solution appears.
2. Technical Fit — can the solution work here?
Technical feasibility asks whether something can work. Technical fit asks whether it works in this particular setting.
Loads, site constraints, distribution systems, equipment condition, controls, redundancy requirements, constructability, utility interfaces, and future growth can all change the answer.
A technology that performs well in one environment can be a poor fit in another. Viability depends on matching the solution to the actual physical and operating system.
3. Economics — does the project create enough value?
A viable project must justify the resources it consumes. That requires more than an attractive simple payback or a favorable unit-energy comparison.
Capital requirements, lifecycle cost, avoided capital, maintenance, staffing, reliability, risk, financing, flexibility, and the value of alternatives may all belong in the decision.
The economic question is not simply whether the project saves money. It is whether the project creates sufficient value relative to the other ways the organization could respond to the same need.
4. Commercial Structure — can the parties make the arrangement work?
The same technical solution can create very different value depending on how ownership, payment, risk, performance, fuel exposure, maintenance, capital responsibility, and contract duration are structured.
Commercial structure determines who pays, who performs, who carries which risks, and what happens when conditions change.
If those responsibilities cannot be allocated in a way that works for the parties involved, technical and economic value may never become a real transaction.
5. Institutional Fit — can the organization actually decide to do it?
Organizations are not financial models. They have governance, capital cycles, procurement rules, competing priorities, internal incentives, risk tolerances, and decision rights.
A project can make sense analytically and still fail because it does not fit the institution expected to approve it.
Institutional fit asks whether the project can move through the customer's real decision system—not the decision process the project team wishes existed.
6. Operational Fit — can someone live with this for years?
Every project creates an operating reality. Equipment has to be monitored, maintained, controlled, repaired, staffed, and integrated with other systems. Responsibilities continue long after construction is complete.
A project that depends on skills the organization does not have, staffing it cannot sustain, or maintenance practices it is unlikely to perform may be technically successful on paper and operationally unsuccessful in practice.
Operational fit asks whether the future operating model is credible.
7. Implementation — can the organizations involved actually deliver it?
Even a project that is attractive across the first six dimensions still has to survive design, approvals, procurement, financing, construction, commissioning, handoffs, and changing conditions.
Implementation capacity includes the organizations, people, processes, timing, and ownership required to move from decision to operating asset.
A project without a credible path to execution is still an opportunity, not yet a viable project.
THE VIABILITY QUESTION
Which condition is most likely to break the chain?
A project does not have to be equally mature in every dimension at every moment. But the team should know where the uncertainty sits, which gaps are material, and what has to become true before greater commitment is justified.
The weakest layer can dominate the decision
One reason complex projects are difficult is that strength in one area cannot always compensate for weakness in another.
Exceptional engineering does not solve a nonexistent customer need. Strong economics do not create procurement authority. A well-connected executive sponsor does not eliminate an operational problem. A grant does not create a workable commercial structure.
That does not mean every layer has to be perfect. It means material weakness has to be understood rather than averaged away.
The layers mature at different rates
Early in development, the need may be clear while the technical configuration remains uncertain. Later, engineering may be well defined while commercial terms remain unresolved. A project approaching contract execution may still have implementation questions that deserve serious attention.
That unevenness is normal. Project development is the process of reducing uncertainty across the stack until the remaining risks are understood well enough to support a decision.
The purpose is not to create another checklist
The value of the Viability Stack is not that complex projects can be reduced to seven boxes. They cannot.
Its value is that it keeps the project team from mistaking progress in one discipline for readiness of the whole project. It provides a common way to ask whether the problem, solution, economics, transaction, institution, operations, and implementation path are converging—or whether one of them remains capable of stopping the project.
Technical feasibility is necessary. A viable project requires more.