Most institutions do not make one energy decision. They make a sequence of connected decisions—often in different rooms, on different calendars, with different standards of evidence.
A facilities team may agree that an aging plant needs attention. Finance may still need to determine whether the capital belongs in this year's plan. Procurement may need a contracting path. Legal and risk may need to understand performance obligations. Operations may need confidence that the proposed system can be supported. Executive leadership may need to decide whether the project is more important than other demands on scarce capital.
None of those steps means the project is weak. They mean the institution has a decision process. The mistake is treating that process as something that begins after the technical and economic work is finished.
WORKING PRINCIPLE
The approval pathway is part of the project design.
If the institution cannot see who must decide what, in what order, with what evidence, and within which budget or governance window, the project is not yet decision-ready.
Approval is not a single gate
It is tempting to imagine approval as a moment: a committee meeting, a board vote, a signed capital request, or an executive decision. In practice, consequential infrastructure projects usually pass through several forms of approval before that final moment arrives.
The institution may first need to agree that the underlying problem is real. Then it may need to agree on the alternatives worth evaluating. Someone must accept the technical basis. Someone must own the economics. Someone must determine where the capital comes from. Operations must be willing to live with the result. Procurement and legal must be able to support the commercial structure. Only then does a final authorization have a stable foundation.
A project team that focuses only on the final approver can miss the earlier decisions that actually determine whether the project is ready to reach that person.
Map the decision before the business case is finished
A strong business case should be built around the decision process it needs to support. That means understanding the institutional pathway early enough that the analysis can answer the questions different decision owners will actually ask.
The objective is not to customize the facts for different audiences. The facts should remain consistent. The objective is to understand which facts matter to which decision and what unresolved issues could prevent the next step.
AN APPROVAL-PATH MAP
Six questions make the institutional pathway visible.
Decision authority. Who can approve the next step, and what exactly are they being asked to decide?
Budget ownership. Which budget carries the cost, what planning cycle governs it, and what competes for the same capital?
Operating ownership. Who will operate, maintain, manage, or live with the outcome after the project team leaves?
Risk review. Which technical, financial, legal, reliability, or performance risks require independent review before commitment?
Commercial pathway. Can procurement, contracting, financing, and vendor structure support the economics and risk allocation assumed by the project?
Timing. What budget windows, shutdowns, funding deadlines, utility dependencies, or governance calendars shape when a decision can actually be made?
Different decision makers need different evidence
The engineering team may need confidence that the system can meet the load. Operations may care more about maintainability, redundancy, staffing, and service response. Finance may focus on capital requirements, lifecycle economics, uncertainty, and the baseline. Procurement may need a scope that can actually be sourced. Legal may need clarity on guarantees, liabilities, and remedies. Leadership may need to understand strategic importance, alternatives, timing, and what the institution is committing itself to over the long term.
Those are not competing versions of the project. They are different dimensions of the same decision.
Confusion grows when one form of evidence is treated as if it settles every question. A compelling lifecycle model cannot answer whether the operating team can support the equipment. A technically elegant design cannot answer whether the contracting structure protects the owner from the risks embedded in that design. A strong sustainability benefit cannot answer whether the project fits the institution's capital plan.
Budget timing is a project constraint
Infrastructure projects often have physical schedules, but they also have institutional schedules. Capital plans are developed months in advance. Boards and committees meet on set calendars. Grant or incentive windows open and close. Utility upgrades have lead times. Academic institutions may avoid certain construction periods. Hospitals, manufacturers, data centers, and other critical facilities may have narrow shutdown windows.
A technically ready project that misses the budget cycle may effectively be a year away from authorization. A project with a modest return may become urgent because an asset is nearing failure. A funding opportunity may justify accelerating analysis. Another project may need to happen first to preserve optionality.
These are not administrative details surrounding the project. They shape the project itself.
A sponsor is not the same as an owner
Complex projects benefit from an executive sponsor, but sponsorship alone does not create institutional readiness. A sponsor can provide visibility, remove barriers, and reinforce strategic importance. Someone still has to own the operating outcome, the budget, the implementation plan, and the unresolved decisions.
Projects become fragile when support is broad but accountability is vague. Everyone likes the concept, but no one owns the next action. Finance assumes facilities will resolve the scope. Facilities assumes procurement will define the delivery model. Procurement assumes leadership has already accepted the commercial risk. Leadership assumes the project team has worked through the details.
INSTITUTIONAL TEST
Can the team name the next three decisions?
If the answer is only “get approval,” the pathway is probably not defined well enough. A decision-ready project should be able to identify the next decision, its owner, the evidence required, and what becomes possible once that decision is made.
Formal approval should not be the first time concerns surface
Good institutional alignment does not mean bypassing formal governance or manufacturing consensus in advance. It means using the development process to surface legitimate concerns before the organization is asked to make an irreversible commitment.
Operations should have a chance to challenge maintenance assumptions before the investment committee sees the economics. Finance should understand uncertainty before a capital request is presented as final. Procurement should identify sourcing constraints before the model assumes a commercial structure that cannot be executed. Legal and risk should see material guarantees or liabilities before they become last-minute obstacles.
A formal approval process works better when it confirms that important questions have been addressed rather than discovering them for the first time.
Procurement and contracting can change the project
The approval pathway is also commercial. A project may be modeled around a performance guarantee, long-term service arrangement, energy-services agreement, utility contract, equipment purchase, or developer-financed structure. If the institution cannot or will not use that structure, the economics and risk allocation may change materially.
This is one reason procurement should not be treated as a transaction that begins after the project has already been justified. The contracting path can affect capital treatment, schedule, competition, performance obligations, ownership, warranties, financing, and who carries uncertainty.
A business case built around a commercial structure that the institution cannot execute is not decision-ready, even if the spreadsheet is correct.
A practical way to build the pathway
- Define the decision, not just the project. Be explicit about what the institution is being asked to authorize now and what remains for later.
- Map the decision owners. Identify who owns technical acceptance, economics, budget, operations, risk, procurement, and final authorization.
- Match evidence to the decision. Determine what each decision owner reasonably needs to know without creating different versions of the facts.
- Sequence the gates. Clarify which decisions depend on others and what must be resolved before the project can advance.
- Expose unresolved conditions. Make assumptions, dependencies, and open risks visible rather than allowing approval to imply certainty that does not exist.
- Align the operating owner. Confirm that the people responsible after implementation understand and accept the operating model being proposed.
- Preserve the logic of the decision. Record what was approved, under what assumptions, and what conditions would require the organization to revisit the decision.
The goal is not easier approval. It is a better decision.
A well-designed approval pathway should not make weak projects easier to push through an institution. It should make it easier to distinguish strong projects from weak ones, identify what remains unresolved, and understand what the organization is actually committing to.
That discipline matters because infrastructure decisions endure. The operating consequences can last decades. Contracts can outlive the people who negotiated them. Capital committed to one project is unavailable for another. A project that fits the technology but not the institution can create years of friction after approval.
The approval process therefore belongs inside the project, not around it.
When the decision pathway is explicit, leadership is not simply being asked whether a project sounds good. It is being given a defensible basis for deciding whether the institution is ready to act, what conditions the decision depends on, and what must happen next.