Understand how to structure a Business Case in engineering projects by connecting need, alternatives, CAPEX, OPEX, benefits, risks, feasibility, and decision governance.
Check it out!
A Business Case is the documented justification used to support a decision to commit resources to a project, continue investing in it, or stop it when the justification no longer exists. In engineering projects, it connects a real organizational need to objectives, alternatives, benefits, costs, risks, feasibility, delivery capability, and decision criteria.
The Business Case is not merely a financial spreadsheet, a budget, or a presentation for CAPEX approval. Its function is to demonstrate, with evidence proportionate to the scale and risk of the project, why the organization should act, which alternative should be taken forward, what value is expected to be created, which conditions need to hold true, and which risks could change the recommendation.
It also does not need to be complete from the outset. In complex projects, the justification matures together with Engineering. A preliminary version may support authorization for studies; later versions can incorporate better scope definition, estimates, risks, contracting strategy, and market results before new investment gates.
A technically useful Business Case therefore does not try to prove that a previously selected idea is good. It structures the decision so alternatives can be compared and so the organization can conclude, including when appropriate, that not investing, delaying, resizing, or studying further is the most rational decision at that time.
What a Business Case Needs to Demonstrate
ABNT NBR ISO 21502:2021 defines a business case as documented justification that supports a decision about commitment to a project, program, or portfolio. For projects, the standard positions the Business Case as a governance basis and recommends that it justify undertaking and continuing the project.
In practice, the decision needs to consider several dimensions at the same time. These include objectives, strategic alignment, potential benefits, value metrics, acceptable risk, budget, schedule and quality requirements, resources, capabilities, scope, scenarios, and the ability to sustain the change generated by the project.
This means that a robust Business Case should answer, at minimum, questions such as:
- what need, opportunity, obligation, or risk originated the proposal;
- what happens if the organization does not act;
- what outcomes and benefits are expected;
- which alternatives were considered;
- why some alternatives were rejected;
- which alternative is recommended and under what assumptions;
- how much capital and resources are required;
- what operating and life-cycle costs are expected;
- which risks and uncertainties could change the decision;
- how the solution will be delivered, contracted, and governed;
- which criteria will be used to review whether continued investment remains justified.
CAPEX Management in Engineering Projects addresses the cycle of authorization, definition, control, and protection of the investment. The Business Case sits before and around that governance: it explains why capital should be committed and when that justification needs to be reviewed.
A Business Case Is Not the Same as a Feasibility Study
When the need has not yet been converted into technically comparable alternatives, approving CAPEX too early transfers uncertainty into design, contracting, and implementation. The Business Case needs to grow on a foundation of real feasibility.
The two instruments may overlap in data and analyses, but they have different responsibilities. A Feasibility Study seeks to determine whether a solution or project is technically, operationally and, where applicable, economically feasible. The Business Case uses this evidence — together with strategy, benefits, alternatives, risk, delivery capability, and governance — to support an organizational decision.
In simple terms:
| Instrument | Primary question |
| Feasibility Study | Can the alternative be implemented and does it make sense under the criteria assessed? |
| Business Case | Should we commit resources to this alternative, now, and under what conditions? |
A Business Case can reference a Technical and Economic Feasibility Study without reproducing the entire study. This separation improves traceability: Engineering produces detailed technical evidence; governance uses that evidence in the decision.
A Business Case Is Not a Project Charter Either
The Project Charter formalizes the existence of the project, establishes authority, and records initial elements of objectives, scope, and governance. The Business Case addresses the justification that supports that authorization.
In many organizations, the Business Case exists before the project is formally initiated. After the decision to proceed, the Project Charter turns the decision into a project mandate, according to the governance adopted.
Confusing the documents creates a recurring problem: the project is authorized by a charter that states what will be done, but the organization loses the record of why that alternative was selected and which assumptions justified the investment.
Business Case and ETP Have Different Contexts
In Brazilian public procurement, the Estudo Técnico Preliminar has a function defined by Law 14.133/2021 and the applicable regulations: it characterizes the need, analyzes solutions, and supports the procurement. The Business Case concept is broader and should not be used to automatically replace legally required documents.
The ETP for Engineering Works and Services may share elements such as need, alternatives, feasibility, costs, and risks, but the document architecture must respect the legal regime and the organization’s specific governance.
In private companies, industrial projects, or corporate CAPEX programs, the Business Case may take its own forms. The document name matters less than its decision-making function and the traceability of its justification.
The Decision Starts with the Need, Not the Solution
One of the strongest biases occurs when the Business Case starts with the phrase “buy equipment X” or “implement technology Y.” This turns a need into a solution before alternatives have been evaluated.
The initial formulation should describe the problem or opportunity independently of the solution. For example:
- insufficient electrical capacity for the planned expansion;
- obsolescence that increases the risk of unavailability;
- a regulatory requirement that has not yet been met;
- a bottleneck that limits production or quality;
- an asset-protection risk without adequate controls;
- rising operating cost;
- a need to increase resilience or continuity.
This formulation leaves room for different responses. The solution may involve expansion, retrofit, an operational change, redundancy, outsourcing, technology replacement, structured maintenance, or even a decision not to intervene at that time.
The Base Case Shows What Happens If Nothing Changes
Alternatives can only be compared against a reference. The base case — also called a baseline or business as usual in some methods — describes the plausible trajectory without the proposed intervention.
It may include maintenance costs, failures, capacity constraints, losses, increasing risk, future obligations, replacement needs, or other documented consequences. The base case must not be artificially degraded to make the proposed solution look better.
In projects involving existing assets, a Technical Due Diligence, cadastral survey, or diagnostic assessment may be required before this reference can be estimated correctly. Without understanding the existing condition, the organization risks comparing the proposed alternative against a fictional situation.
Objectives Need to Be Verifiable
Expressions such as “modernize infrastructure,” “improve security,” or “increase efficiency” help express direction, but they are insufficient for a decision. The Business Case needs to convert intent into observable outcomes.
An objective can establish capacity, availability, schedule, exposure reduction, performance, compliance, or another measurable outcome. The definition should avoid turning the indicator itself into the objective. “Install 100 cameras,” for example, is an output; “reduce uncovered areas according to defined technical criteria” is an outcome closer to the underlying need.
Benefits Management in Projects and Programs explores the distinction between output, outcome, and benefit, which is essential to avoid Business Cases that confuse completed delivery with realized value.
Benefits Need an Owner, a Baseline, and Conditions for Realization
A benefit stated in generic terms is difficult to govern. For each material benefit, the Business Case should record who is accountable for realizing it, what the baseline is, what change is expected, when it may occur, and which deliverables or operational changes are required.
This avoids attributing to the project a benefit that depends largely on external factors. New infrastructure may enable higher production, but the economic benefit may also depend on demand, raw materials, people, process, and operations.
This causal chain should be explained. Otherwise, the financial model turns possibilities into certain revenues and creates an overly optimistic justification.
Alternatives Need to Be Genuinely Different
Comparing three versions of the same solution is not the same as exploring alternatives. A mature decision may consider differences in architecture, technology, phasing, capacity, contracting model, make-or-buy, retrofit versus replacement, full versus modular implementation and, where applicable, the alternative of doing nothing or deferring the intervention.
Set-Based Design in Engineering shows how to keep viable alternatives in parallel while evidence is developed, avoiding premature convergence.
An initial longlist can be filtered using knockout criteria. The technically viable alternatives then advance to detailed comparison of performance, risk, cost, and value.
The “Do Nothing Now” Alternative Is Also Information
Not acting may be infeasible because of legal requirements, safety, or operational risk, but the hypothesis needs to be examined where applicable. Even in mandatory projects, the base case helps quantify the cost and risk of delaying the intervention and makes it possible to compare different ways of meeting the obligation.
The Green Book 2026 uses business as usual as a mandatory reference in its public-appraisal methodology. This specific rule does not automatically apply to Brazilian companies, but the analytical principle is useful: an alternative needs to be compared with the plausible consequence of not adopting it.
Technical Feasibility Comes Before Financial Optimization
An alternative that does not meet essential requirements does not become acceptable because it has a higher IRR or shorter Payback. The technical assessment needs to establish limits, performance, interfaces, capacity, implementation conditions, standards requirements, constructability, operations, and maintenance.
Requirements Management in Engineering helps turn needs into verifiable requirements. The Business Case can then compare only alternatives capable of meeting what is actually required.
This sequence avoids a classic problem: selecting the financially most attractive solution only to discover later that it fails a technical condition that should have been a knockout criterion.
CAPEX, OPEX, and Life-Cycle Cost Need to Be Considered Together
The lowest CAPEX does not necessarily represent the highest-value alternative. Operating costs, maintenance, reinvestment, service life, and benefits need to remain visible throughout the comparison.
The lowest initial investment can shift costs into energy, maintenance, licensing, labor, downtime, or future replacements. The Business Case therefore should not treat CAPEX as the alternative’s only economic measure.
TCO and Life-Cycle Cost in Engineering organizes expenses over the service life and helps expose costs that remain hidden in acquisition. Value Engineering complements this analysis by relating functions, performance, and cost.
The decision should explain why the selected economic profile is compatible with the asset strategy and its expected life.
NPV, IRR, Payback, and ROI Are Part of the Financial Justification
When the project produces quantifiable financial flows, economic indicators help compare alternatives. NPV, IRR, Payback, and ROI in Engineering Projects explains the differences among present-value creation, rate of return, recovery time, and a simple return ratio.
These numbers should derive from the same cash-flow basis and use documented assumptions. A Business Case should not present only “IRR 18%” or “Payback 3 years” without a record of CAPEX, OPEX, horizon, benefits, rate, and risks.
Mandatory projects or projects with predominantly non-monetary benefits may not show a positive financial return. In such cases, the economic analysis can compare alternatives for meeting the requirement instead of inventing revenues to justify the intervention.
DCF Makes Time Explicit
Costs and benefits that occur at different dates are not directly comparable. Discounted Cash Flow in Engineering Projects structures flows by period and brings them to present value using a rate consistent with the adopted evaluation methodology.
In the Business Case, the rate should have a defined source and governance. In a corporate environment, hurdle rate, cost of capital, tax criteria, or financial parameters may belong to the finance function. Engineering improves the quality of the technical inputs; it should not silently invent corporate parameters that were not provided.
Risk Needs to Change How the Alternative Is Viewed
A risk register attached to the Business Case is not enough if the risks do not change the analysis. Delay, CAPEX uncertainty, technology availability, supplier dependency, integration, demand, licensing, performance, and implementation capability can change cost, schedule, benefit, and even feasibility.
Risk Management in Engineering Projects provides the structure for identification, assessment, response, and control. When quantitative variables interact, Monte Carlo Simulation can complement deterministic scenarios.
The objective is to show governance not only the expected result, but what could cause that result to stop being true.
Assumptions and Constraints Need to Be Visible
Every investment decision is built on assumptions. Demand growth, energy price, service life, utilization rate, contracting schedule, space availability, connection capacity, productivity, and regulatory stability are examples of assumptions that may be material.
The difference between an assumption and a fact needs to remain clear. A useful practice is to record:
| Field | Control example |
| Assumption | average tariff used in the model |
| Source | contract, history, or approved forecast |
| Responsible party | function that provided or approved the data |
| Data date | time reference |
| Sensitivity | impact if the assumption changes |
| Status | confirmed, provisional, or pending |
Pending critical assumptions can become Engineering actions before the next gate.
The Business Case Should Record Why Alternatives Were Rejected
ABNT NBR ISO 21502:2021 recommends evaluating alternative options and presenting reasons for rejection. This record is valuable because it preserves the decision history.
Without it, a rejected alternative may reappear months later without anyone knowing which requirement failed, which cost made the solution infeasible, or which risk was considered. Traceability also protects against retrospective decisions based only on the final result.
The justification does not need the same level of detail for every option. Alternatives eliminated by an objective criterion may have a concise record; finalists require deeper, comparable analysis.
Governance Defines Who Recommends and Who Decides
The technical team can structure alternatives and recommend a solution, but the investment decision belongs to the authority defined by the organization. A sponsor, investment committee, executive management, board, portfolio board, or another body may hold the final authority.
Decision Governance with Authorities, Committees, and Stage-Gates helps separate analysis, recommendation, approval, and escalation.
This distinction should appear in the Business Case to prevent a technical opinion from being treated as capital authorization or an executive approval from being confused with technical validation of the solution.
The Sponsor Needs to Preserve the Justification Throughout the Project
ABNT NBR ISO 21502 assigns the sponsor responsibility for promoting the Business Case and validating whether the project remains justified throughout its life cycle. This changes how the document should be viewed: it is not merely a form completed before approval.
Significant changes in scope, cost, schedule, context, or benefit may require review. If the need disappears, the alternative is no longer feasible, or the investment grows far beyond the approved case, governance needs to reassess whether continuing still makes sense.
Gates Turn the Justification into a Process
Progressive justification works best when linked to explicit decision points. Stage-Gate in Engineering Projects structures criteria for authorizing the next phase as the project matures.
One possible flow is:
In early phases, the gate may authorize only the next study. Later, it may authorize basic design, FEED, contracting, or implementation. The decision and the capital committed grow together with the quality of the evidence.
FEL Is a Natural Environment for Maturing the Business Case
FEL — Front-End Loading structures project maturation before significant capital is committed. Need, alternatives, technical definition, estimates, risks, schedule, and execution strategy can evolve in an integrated manner.
The Business Case follows this maturation. A preliminary justification can support FEL 1; later versions incorporate stronger evidence for subsequent gates. The objective is not to produce a perfect document too early, but to increase confidence before decisions become expensive or irreversible.
The Business Case Should Connect with the Contracting Strategy
An alternative may be technically sound and financially attractive, yet difficult to contract in the market, dependent on a single supplier, incompatible with the schedule, or excessively complex for the organization’s management capability.
The commercial and contracting strategy needs to be considered before final authorization. Packaging, EPC, EPCM, contracting by lots, direct procurement of critical equipment, or other models can change risk, schedule, CAPEX, and responsibilities.
This dimension does not mean selecting the supplier within the Business Case. It means verifying that there is a viable path for turning the selected alternative into a contract and a delivered solution.
Organizational Capability Is Also Part of Feasibility
Projects fail even when the technology works. Lack of staff to operate the asset, insufficient capability to oversee the contract, inability to maintain systems, low management maturity, or excessive dependence on third parties can compromise the benefit.
The analysis should ask:
- who will be the owner of the asset and the benefits;
- which capabilities will be required;
- how operations will receive the solution;
- which internal resources will be required;
- what external support is required;
- how organizational changes will be implemented;
- whether there is capability to manage the procurement and the project.
This perspective expands feasibility beyond “it is technically possible to build.”
How to Structure a Business Case in Engineering Projects
There is no single universal template, but a functional structure can organize the decision into coherent blocks:
- Executive summary: decision required, recommended alternative, investment, benefits, risks, and key conditions.
- Need and case for change: problem, opportunity, obligation, or risk that originated the proposal.
- Objectives and success criteria: verifiable outcomes and strategic alignment.
- Base case: plausible consequence of not acting.
- Alternatives: longlist, screening criteria, and shortlist.
- Technical assessment: requirements, interfaces, implementation conditions, and feasibility.
- Economic assessment: CAPEX, OPEX, life cycle, DCF, and indicators where applicable.
- Benefits: outputs, outcomes, benefits, owners, baseline, and targets.
- Risks and uncertainties: material risks, sensitivities, scenarios, and responses.
- Delivery and contracting strategy: approach, market, resources, and governance.
- Schedule and gates: phases, dates, future decisions, and incremental capital.
- Recommendation: preferred alternative, rationale, and conditions for proceeding.
- Update plan: events that require the justification to be reviewed.
Proportionality matters. A small project does not need dozens of pages; a high-CAPEX project with substantial uncertainty should not be authorized on the basis of a superficial justification.
The Executive Summary Should Not Hide the Conditions behind the Recommendation
Executives need synthesis, but synthesis does not mean eliminating uncertainty. A good summary presents the decision requested, investment value, preferred alternative, expected benefits, critical risks, key assumptions, and next gates.
If the recommendation depends on an assumption that has not yet been confirmed — connection availability, licensing, structural condition, supplier price, or another point — this should appear in the summary. Governance needs to know whether it is approving a mature solution or only the next stage of investigation.
How to Use the Five Case Model without Uncritically Copying a Foreign Model
HM Treasury updated its Five Case Model-based Business Case guidance in 2026. The model examines five connected perspectives: strategic case, economic case, commercial case, financial case, and management case.
For Brazilian organizations, it can be used as a conceptual reference, not as a general normative obligation. Its main contribution is to reinforce that a decision should not be assessed only by financial return: strategic alignment, choice among options, commercial viability, financial impact, and delivery capability need to be considered together.
The terminology, rates, public-value criteria, and procedures of the UK government should not be transplanted automatically to Brazilian companies or public entities. Applicable legislation, corporate governance, and the contracting organization’s methodology remain decisive.
Project Assurance Can Review Decision Quality
In high-impact projects, a decision may be formally approved and still rest on weak technical assumptions. An independent review before the gate helps the sponsor distinguish real maturity from apparent precision.
High-impact projects can benefit from independent review before critical gates. Project Assurance in Engineering checks whether information, processes, risks, and decisions have sufficient evidence for the level of confidence required by the sponsor or governance.
The review does not need to redo the entire Business Case. It can test points such as coherence between need and solution, estimate maturity, independence of alternatives, traceability of assumptions, critical risks, readiness for contracting, and quality of the recommendation.
Owner’s Engineering Protects the Owner’s Perspective
When the project advances, the function of the Business Case does not disappear. Design, procurement, and implementation decisions can change cost, schedule, performance, and expected benefits.
Owner’s Engineering represents the owner’s technical interests during development and execution, helping verify whether changes and decisions remain consistent with requirements, objectives, and acceptance criteria.
The Owner’s Engineer’s recommendation does not replace the owner’s investment authority; it improves the technical quality of decisions submitted to governance.
When to Hire Support to Build the Business Case
Engineering Consulting tends to add the most value when the organization understands the need but still needs to turn dispersed information into technically comparable alternatives and a structured decision.
This occurs, for example, when:
- the project involves multiple disciplines;
- the existing condition is poorly understood;
- there are relevant technology alternatives;
- CAPEX and OPEX depend on surveys and technical estimates;
- benefits need to be connected to actual performance;
- implementation risks can change attractiveness;
- the supplier market needs to be tested;
- the organization wants an independent review before committing material capital.
Technical Engineering Consulting can structure this technical layer, while corporate financial decisions remain with the contracting organization’s responsible functions and authorities.
What to Require When Contracting a Technical Business Case
The scope needs to define the decision product, not merely “prepare a report.” Depending on complexity, it is appropriate to require:
- collection of input data and documents;
- definition of the problem, objectives, and base case;
- identification and screening of alternatives;
- requirements and knockout criteria;
- technical feasibility assessment;
- CAPEX, OPEX, and life-cycle estimates with their basis stated;
- economic model where applicable;
- benefits analysis;
- risks, assumptions, constraints, and sensitivities;
- preliminary implementation and contracting strategy;
- comparative matrix of alternatives;
- substantiated technical recommendation;
- executive presentation for the decision gate;
- calculation files and source traceability;
- criteria for updates in subsequent phases.
The contracting organization should also define who provides corporate assumptions, who validates estimates, who approves the discount rate, and who has authority to decide.
Signs of a Weak Business Case
Some patterns indicate that the justification is not yet ready for a material capital commitment:
- solution selected before defining the problem;
- absence of a base case;
- only one real alternative;
- benefits without a baseline or owner;
- CAPEX without an estimating basis;
- OPEX treated as a generic percentage without a technical driver;
- IRR, NPV, or ROI without calculation records;
- risks listed without impact on the decision;
- schedule incompatible with permits, engineering, or procurement;
- critical assumptions presented as facts;
- absence of gate criteria;
- recommendation that does not state its conditions of validity.
The purpose of the review is not to make every Business Case longer. It is to determine whether there is enough information for the irreversibility and risk of the decision that will be made.
The Business Case Should Be Controlled as a Living Document
Version, data date, assumptions, estimates, and the approved decision need to be traceable. If the document changes after a gate, the organization should be able to identify what changed and why.
The progressive justification recommended by ABNT NBR ISO 21502 reinforces this logic. Before each relevant decision point, the Business Case can be updated to reflect changes in context and scope.
This discipline prevents procurement or execution from relying on an economic justification based on prices, schedules, or requirements that no longer correspond to the current project.
Final Considerations
An engineering Business Case is not a mechanism for defending a solution. It is a mechanism for making an evidence-based decision about whether a need deserves investment, which alternative offers the best balance among value, risk, and delivery capability, and which conditions need to be preserved throughout the project.
The greater the capital committed, complexity, and irreversibility, the higher the quality of definition should be before the decision. Maturity does not come from adding pages: it comes from converting relevant uncertainties into verifiable information and keeping explicit those that cannot yet be eliminated.
When the project still needs to mature alternatives, estimates, risks, interfaces, and contracting strategy, the next step may be to develop the front end in phases instead of authorizing implementation directly.
Technical references
[1] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO 21502:2021 — Project, programme and portfolio management — Guidance on project management. Rio de Janeiro: ABNT, 2021.
[2] PROJECT MANAGEMENT INSTITUTE. The Standard for Project Management and A Guide to the Project Management Body of Knowledge (PMBOK® Guide). 8th ed. Newtown Square: PMI, 2025. Available at: [https://www.pmi.org/standards/pmbok](https://www.pmi.org/standards/pmbok)
[3] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 21502:2020 — Project, programme and portfolio management — Guidance on project management. Geneva: ISO, 2020. Available at: [https://www.iso.org/standard/74947.html](https://www.iso.org/standard/74947.html)
[4] HM TREASURY. Guidance on developing business cases for projects and programmes. London: HM Treasury, updated June 30, 2026. Available at: [https://www.gov.uk/government/publications/guidance-on-developing-business-cases](https://www.gov.uk/government/publications/guidance-on-developing-business-cases)
[5] HM TREASURY. The Green Book 2026: appraisal and evaluation in central government. London: HM Treasury, 2026. Available at: [https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-government/the-green-book-2026](https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-government/the-green-book-2026)
Frequently asked questions
It is the documented justification that supports a decision to commit resources to a project, continue investing, or stop when the justification no longer exists. It should relate need, objectives, alternatives, value, costs, benefits, risks, and delivery capability.
A Feasibility Study assesses whether a solution or project is viable under the applicable technical, operational, and economic criteria. The Business Case uses this evidence, together with strategy, benefits, alternatives, risks, and governance, to support the investment decision.
No. The Business Case justifies why the investment and alternative make sense. The Project Charter formalizes the project, authority, and initial objective and scope elements after or together with the authorization decision, according to the governance adopted.
Not in every project. When relevant and quantifiable financial flows exist, NPV, IRR, Payback, and ROI can support the decision. Mandatory projects or projects with non-monetary benefits may require other criteria without creating artificial revenues.
Approval belongs to the authority defined by the organization’s governance, such as the sponsor, investment committee, executive management, or board. The technical team may prepare analyses and recommendations but should not assume authority that has not been delegated to it.
Yes, when governance and materiality justify it. Material changes in scope, cost, schedule, context, risks, or benefits may require an update, especially before important gates.
When the decision depends on complex technical alternatives, multiple disciplines, existing-condition surveys, estimates, risks, requirements integration, or independent review before material capital is committed.
Not as a general rule. It is a reference methodology of the UK government and can inspire a multidimensional analysis, but Brazilian organizations should follow their applicable legislation, governance, and methodology.
Complementary technical materials
Related solutions
- Project, Program, and Portfolio Governance
- Process, Workflow, and Technical Approval Management
- Engineering Indicators, Dashboards, and Executive Reports
Related services
- Technical and Economic Feasibility Study
- Technical Engineering Consulting
- FEL — Front-End Loading
- Project Management
- Owner’s Engineering
Core content on this topic
- NPV, IRR, Payback, and ROI in Engineering Projects
- Discounted Cash Flow in Engineering Projects
- CAPEX Management in Engineering Projects
- Benefits Management in Projects and Programs
- TCO and Life-Cycle Cost in Engineering
