A green technology business case is an approval argument built from evidence, alternatives and controlled assumptions. It should show why action is needed, what credible options exist, what value and risk sit inside each option, and which conditions must be met before the next commitment.
Approval-case anatomy
Problem
Need and baseline
Define the current cost, service, risk or constraint with dated evidence.
Options
Alternatives
Compare the status quo, staged action and credible technical or commercial routes.
Feasibility
Delivery evidence
Test site, utility, integration, safety, data, people and schedule dependencies.
Value
Whole-life effects
Separate cashable, avoided, operational, risk and enabling benefits.
Risk
Uncertainty and controls
Show sensitivity, ownership, mitigations and the point at which the choice changes.
Decision
Recommendation and gate
State the authority requested, approval conditions, owner and next evidence milestone.
What a decision-ready business case contains
- Decision and sponsor. State the approval being requested, the decision owner and the date by which the decision is needed.
- Problem and baseline. Describe the current cost, performance, risk, constraint or missed opportunity using a defined period and evidence.
- Required outcomes. Convert broad goals into measurable operational, financial, environmental or compliance outcomes.
- Alternatives. Include the status quo, deferral, operational changes and credible technology or commercial options.
- Site and delivery feasibility. Identify surveys, permits, interconnection, integration, cybersecurity, construction, training and operational dependencies.
- Economics. Present costs, benefits, cash flows, assumptions, analysis period and sensitivity on a consistent basis.
- Risk and uncertainty. Show what could change the result, who owns each risk and how it could be reduced or transferred.
- Implementation and measurement. Set decision gates, milestones, acceptance criteria and a plan for confirming actual performance.
- Recommendation. Explain why the preferred option is better than the alternatives and what conditions should attach to approval.
| Decision element | Minimum evidence | Common failure | Approval output |
|---|---|---|---|
| Need and baseline | Dated operating, cost, asset, service or risk evidence with an owner | Problem stated only as a preferred product | Defined outcome and no-action reference case |
| Alternatives | Comparable service boundaries and credible implementation routes | Status quo, staging or lower-capital measures omitted | Shortlist with explicit differences |
| Feasibility | Site, utility, integration, code, data and operating dependencies | Vendor budget treated as an executable design | Confirmed, conditional and unresolved assumptions |
| Economics | Whole-life cash flows, analysis period, source dates and sensitivity | Simple payback or supplier savings used alone | Reproducible model and break-even conditions |
| Risk and delivery | Named owners, mitigations, tests, contracts and decision gates | Risk listed without action or acceptance evidence | Conditional recommendation and next gate |
1. Frame the decision around an outcome
“Buy a battery,” “install chargers” or “purchase carbon software” are solution statements. A business case should start with the outcome: reduce peak demand exposure, support a defined fleet duty cycle, improve emissions-data assurance, replace an obsolete control system or meet a resilience requirement.
A useful decision statement identifies the affected sites or operations, the service level required, the deadline, material constraints and the authority being requested. This reduces the risk of evaluating products that solve different problems.
2. Establish a credible baseline
The baseline is the reference against which costs and benefits are measured. Depending on the project, it may include energy use, tariffs, maintenance history, failures, downtime, lease obligations, software costs, labor, emissions, production, service demand or planned asset replacement.
Use a period that reflects normal operations. Explain adjustments for unusual weather, occupancy, production, temporary shutdowns or one-off events. State the source, date and owner of each material input.
Decision rule: a benefit that cannot be traced to a baseline, an assumption or a test plan should not be presented as a dependable saving.
3. Compare real alternatives
At minimum, compare the proposed project with continuing the current state. Where practical, include lower-capital operational measures, staged deployment, alternative system sizes, different ownership models and postponement.
Alternatives should use the same outcome, boundary and operating conditions. If one option provides additional resilience, capacity or data services, show that difference explicitly instead of treating unequal systems as directly interchangeable.
4. Translate benefits into measurable effects
Benefits may be financial, operational, strategic or risk-related. Examples include energy and demand savings, reduced maintenance, avoided replacement, improved availability, lower exposure to fuel or tariff volatility, better data quality, faster reporting, improved resilience or capacity for future growth.
Classify each material benefit as:
- Cashable: expected to reduce an identifiable budget or create revenue.
- Avoided cost: expected to prevent or defer a future cost.
- Operational: improves performance, reliability, time or service but may not immediately reduce a budget.
- Risk reduction: reduces the likelihood or consequence of an adverse event.
- Strategic or enabling: creates capability required for a wider program.
Do not add all categories together as though they were equally certain. Use evidence ranges, confidence ratings and conditions.
| Record | What to capture | Decision use |
|---|---|---|
| Observed evidence | Measured load, bills, faults, downtime, labor, asset condition or reporting effort | Defines the baseline and current exposure |
| Quoted commitment | Written scope, price, guarantee, delivery date, warranty or service level | Can be converted into contract and acceptance terms |
| Modeled forecast | Calculation method, input values, boundary, scenario and confidence | Supports economics but requires sensitivity |
| Unresolved assumption | Owner, due date, estimated effect and treatment if not confirmed | Supports conditions, contingency or staged approval |
| Update trigger | Tariff, design, price, schedule, policy, site or performance change | Determines when the case must be recalculated |
5. Build the whole-life economic model
The economic model should cover material acquisition, design, permitting, site work, integration, commissioning, energy, subscriptions, maintenance, service, downtime, replacement, decommissioning and disposal costs, along with incentives, residual value and credible avoided costs.
Use the TCO guide and TCO worksheet. Keep the treatment of inflation, escalation and discounting consistent. State whether cash flows are nominal or real and whether taxes and financing are inside or outside the boundary.
Choose metrics that match the decision
- Simple payback is easy to communicate but ignores cash flows after the payback point and usually ignores the time value of money.
- Net present value compares discounted costs and benefits across the analysis period.
- Internal rate of return may help compare an investment with an organization’s hurdle rate, but can be misleading for unusual cash-flow patterns or mutually exclusive projects.
- Life-cycle cost or TCO is useful where alternatives provide the same required service and the objective is to identify the lowest whole-life cost that meets requirements.
- Cost per unit of outcome can help where alternatives provide different quantities of service, energy, capacity or emissions reduction.
6. Test uncertainty before presenting a recommendation
A base case is not enough when the result depends on forecasts. Test low, base and high cases for the assumptions that matter most, such as utilization, energy prices, project cost, schedule, degradation, performance realization, maintenance, replacement timing, incentives and residual value.
Show the switching point where the preferred option changes. This is often more useful than presenting a wide range without explaining its decision impact.
7. Convert risk into actions and conditions
A risk register should identify the event, cause, consequence, likelihood, impact, owner, mitigation and decision trigger. Important risks may include site conditions, interconnection, permitting, product maturity, vendor capacity, cybersecurity, data rights, supply chain, construction interfaces, operational disruption and performance shortfall.
Where possible, reduce uncertainty before approval through surveys, metering, pilots, reference checks, design development, utility studies or vendor clarifications. Where risk remains, use contingencies, staged approvals, guarantees, acceptance tests, warranties, insurance, liquidated damages or termination rights where legally and commercially appropriate.
8. Define delivery and measurement before approval
The case should explain how the organization will know the project has been delivered and whether the expected outcome occurred. Define design reviews, permits, factory tests, site acceptance, commissioning, training, documentation, cybersecurity checks, measurement boundaries, baseline adjustments and the reporting period.
For savings-based projects, decide whether performance will be estimated, measured, stipulated or guaranteed, and who owns the data and calculation method.
9. Make the recommendation auditable
A concise approval section should state:
- the recommended option and scope;
- the total funding or commercial authority requested;
- the principal assumptions and unresolved dependencies;
- the expected outcome and measurement method;
- the major risks and approval conditions;
- the next decision gate and accountable owner.
Attach detailed calculations and evidence rather than crowding the decision summary. A reviewer should be able to reproduce the conclusion from the source record.
Common business-case failures
- Starting with a favored product and constructing the problem around it.
- Comparing the proposal only with doing nothing, while ignoring lower-cost alternatives.
- Using supplier savings estimates without a documented baseline or independent challenge.
- Presenting incentives as certain before eligibility and timing are confirmed.
- Leaving integration, site work, commissioning, subscriptions or replacement outside the cost boundary.
- Using simple payback as the only economic view.
- Counting operational and strategic benefits as guaranteed cash savings.
- Treating a pilot result as directly scalable without considering different sites and operating conditions.
- Seeking full approval before material site, utility, legal or cybersecurity dependencies are understood.
A practical business-case outline
- Executive decision summary
- Need, baseline and required outcomes
- Scope, constraints and stakeholders
- Alternatives considered
- Technical and site feasibility
- Benefits and measurement basis
- Whole-life costs and financial results
- Sensitivity and uncertainty
- Risk allocation and mitigations
- Procurement and implementation route
- Recommendation, conditions and next gate
Approval checklist and next decision stage
- The decision, sponsor, affected operation and authority requested are explicit.
- The baseline and alternatives use consistent boundaries and evidence dates.
- Whole-life costs, benefit classes, sensitivity and break-even conditions are visible.
- Material technical, site, utility, legal, data and cybersecurity dependencies have owners.
- The recommendation states conditions, contingencies, acceptance evidence and the next gate.
After the case is approved in principle, use Technology Procurement Process to plan the controlled route to market, or use How to Compare Vendor Proposals when comparable offers are already available.
Sources and evidence
Primary and authoritative references used for this page are listed below. Recheck current rules, rates, source editions and organizational requirements before a live decision.
- The Business Case for Energy-Efficient Buildings — ENERGY STAR
- Economic and Financial Calculators — ENERGY STAR
- Cost Estimating and Assessment Guide — U.S. Government Accountability Office
- Building Life Cycle Cost Programs — U.S. Department of Energy FEMP
- Measurement and Verification Options — U.S. Department of Energy FEMP
- EMIS Planning and Procurement — U.S. Department of Energy FEMP
- FAR Part 7 — Acquisition Planning — Acquisition.gov
- FAR 15.304 — Evaluation Factors — Acquisition.gov
- Project Control authority: approved page map, complete page criteria, contextual-linking rules and layout matrix.
These sources support general decision structure, cost-estimating discipline and measurement planning. They do not establish project-specific savings, eligibility, legal compliance, financial advice or approval authority.
Reviewed and updated 29 June 2026. Recheck when financial methods, procurement rules, official guidance, discount and escalation inputs, organizational governance or the page’s material claims change. Organizational author: Future Green Technology, published by Zenith Star Media.