The missing issues are often not additional engineering detail. They are the conditions that determine whether the organization can approve, contract for, operate, and implement the project.
A familiar sequence plays out in energy projects. A technical team identifies a promising solution. The equipment can meet the load. The efficiency looks good. The capital estimate appears manageable. A financial model shows an acceptable payback or lifecycle return.
At that point, the project can begin to feel decided. It is technically feasible and the numbers work. What else is there to know?
Quite a lot.
Technical feasibility answers an important question: can the proposed solution work? A business case has to answer a larger one: should this organization do it, under what conditions, and what will it actually take to succeed?
WORKING PRINCIPLE
Feasibility is not viability.
Proving that a solution can work answers a technical question; a viable project must also make sense economically, operationally, commercially, and institutionally.
A business case is not a larger feasibility study
The distinction matters because energy-infrastructure decisions rarely belong to a single discipline. A new heating or cooling system, distributed-energy resource, electrification project, microgrid, utility-service change or emerging technology can affect capital planning, maintenance practices, staffing, procurement, utility relationships, reliability, contracts, risk allocation and long-term operating strategy.
A good business case therefore does more than add a few non-financial bullets to a financial model. It begins with the decision itself, evaluates credible alternatives—including the baseline or business-as-usual case—and compares them across the factors that will determine whether the chosen path can actually be implemented.
| Technical feasibility asks | A decision-ready business case also asks |
|---|---|
| Can the technology meet the requirement? | Is this the right requirement and the right alternative? |
| What equipment and infrastructure are needed? | Can the organization fund, procure, operate and maintain them? |
| What is the estimated capital cost? | What are the lifecycle costs, risks and sensitivities? |
| What performance should we expect? | What has to be true for that performance to matter economically and operationally? |
| Can it be built? | Can it be approved, contracted, implemented and sustained? |
The maintenance manager may change the answer
Consider a hypothetical institution evaluating replacement of aging central-plant equipment. An engineering analysis may demonstrate that a new technology can meet the load with significantly better efficiency. A financial model may show a compelling lifecycle cost.
Then someone speaks with the maintenance manager.
- The existing staff has never operated this type of equipment. What training or additional staffing will be required?
- The nearest qualified service provider is several hours away. What does that do to reliability and response time?
- A critical component has a long lead time. What redundancy or spare-parts strategy is required?
- The new system depends on controls integration that the current building-automation platform cannot easily support.
- The modeled savings assume labor reductions that the organization does not intend to make.
None of those observations means the technology is bad. They mean the original analysis was incomplete.
Once the operating reality is included, the preferred alternative may remain the same. But the capital requirement may change. The operating model may change. The contract may need stronger performance protections. A service agreement may become essential. Or another alternative may prove more attractive.
The value of speaking with the maintenance team is not that maintenance should make the investment decision. It is that a sound investment decision cannot ignore the people who will live with the system after the project team is gone.
The important risks often sit between the boxes
Organizations are structured around expertise for good reasons. Engineers should focus on engineering. Finance should focus on finance. Operations should focus on operations. Procurement, legal, sustainability and executive leadership each have legitimate responsibilities.
The problem is that a major infrastructure decision crosses all of those boundaries.
A project can be strong inside every individual workstream and still fail at the handoffs. The engineering design assumes a procurement path that is not available. The financial model assumes an operating practice that facilities will not adopt. The vendor proposal assumes utility capacity that will not arrive on the project schedule. The executive sponsor assumes the project can be financed from a capital budget that has already been committed elsewhere.
Will the equipment work under the way the facility is actually staffed, maintained and operated?
Do modeled savings depend on actions the organization is willing and able to take?
Is the provider’s capability, balance sheet, service network and track record consistent with the risk being assigned to it?
Do ownership, performance guarantees and contract terms match the actual technical dependencies?
Is there a credible sequence of approvals, funding, design, procurement, interconnection and construction?
Have the people who can stop, fund, operate or approve the project been involved early enough?
What a decision-ready business case should do
I think of a business case as a structured decision process rather than a document template. The final report matters, but the real value comes from forcing the right questions to be answered before the organization commits.
- Define the decision. What problem or mission need are we solving? What outcome matters? Who owns the decision?
- Establish credible alternatives. Include the baseline. Do not compare a fully developed preferred solution against a vaguely defined status quo.
- Test the whole case. Integrate technical performance, lifecycle economics, operations, organizational capability, commercial structure and stakeholder requirements.
- Surface assumptions and constraints. Make the hidden conditions visible: staffing, utility capacity, vendor capability, approvals, capital, timing, policy and contractual dependencies.
- Compare risk and sensitivity. Identify where the case breaks and which variables could materially change the recommendation.
- Recommend a pathway. Proceed, do not proceed, or proceed subject to conditions—and specify what must happen next.
A useful distinction
A good business case is allowed to say no.
If the analysis begins with the assumption that a particular technology, vendor or project must be justified, the process becomes an exercise in advocacy. A genuine business case should be capable of reaching an uncomfortable conclusion: the project should not proceed, the baseline is currently better, more information is required, or the preferred alternative only makes sense if specific conditions can be satisfied.
That independence is not anti-project. It is what makes a positive recommendation credible.
The integrator does not replace the specialists
None of this argues for a generalist overruling engineers, operators, financial analysts or other specialists. The opposite is true. Complex infrastructure decisions need deep specialist expertise.
They also need someone—or some process—responsible for integration.
The integrator's job is to make sure the technical case connects to the economic case; the economic case reflects operating reality; the commercial structure matches the technical risks; the organization can actually execute the plan; and the recommendation is grounded in the decision the institution needs to make.
The real question is whether the project works as a whole
Energy infrastructure is becoming more complex, not less. Organizations are simultaneously considering reliability, cost, decarbonization, electrification, distributed resources, new technologies, constrained capital and evolving utility relationships. That complexity creates more opportunities for technically sound ideas to fail for reasons that sit outside the technical analysis.
Technical feasibility is essential. It just is not the finish line.
Before a consequential investment moves forward, leadership should be able to answer a broader set of questions: Does the solution work technically? Does it make sense economically over its full lifecycle? Can the organization operate it? Are the vendors and partners capable? Does the commercial structure allocate risk appropriately? Are the right stakeholders aligned? And is there a realistic sequence for getting from decision to implementation?
When those answers fit together, the organization has more than a feasible project. It has a defensible decision and an executable pathway.