Learn how to structure a Business Case for engineering projects by connecting needs, 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.
A Business Case is not merely a financial spreadsheet, a budget, or a presentation for CAPEX approval. Its purpose is to demonstrate, with evidence proportionate to the scale and risk of the project, why the organization should act, which alternative should move forward, what value is expected, which conditions must be true, and which risks could change the recommendation.
It also does not need to be complete from the beginning. In complex projects, the justification matures together with engineering. A preliminary version may support authorization for studies; later versions may incorporate better scope definition, estimates, risks, contracting strategy, and market feedback before subsequent 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 may conclude that not investing, postponing, 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 a documented justification supporting a decision about commitment to a project, programme, or portfolio. For projects, the standard positions the Business Case as a governance basis and recommends that it justify both undertaking and continuing the project.
In practice, the decision must 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 organization’s ability to sustain the change created by the project.
This means that a robust Business Case should answer, at a minimum, questions such as:
- what need, opportunity, obligation, or risk originated the proposal;
- what happens if the organization does not act;
- which outcomes and benefits are expected;
- which alternatives were considered;
- why some alternatives were rejected;
- which alternative is recommended and under which assumptions;
- how much capital and resources are required;
- which operating and lifecycle 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 continued investment.
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, procurement, and implementation. The Business Case needs to grow from a real feasibility basis.
The two instruments may overlap in data and analysis, but they have different responsibilities. A Feasibility Study seeks to determine whether a solution or project is technically, operationally and, when 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 which conditions? |
A Business Case may 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 also not a Project Charter
The Project Charter formally establishes the project, assigns 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 model adopted.
Confusing the documents creates a recurring problem: the project is authorized by a charter that states what will be done, while the organization loses the record of why that alternative was selected and which assumptions justified the investment.
Business Case and Brazilian ETP have different contexts
In Brazilian public procurement, the Preliminary Technical Study (ETP) has a function defined by Law 14.133/2021 and 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 applicable legal regime and the organization’s specific governance.
In private companies, industrial projects, or corporate CAPEX programmes, the Business Case may take proprietary forms. The document’s name matters less than its decision function and the traceability of its justification.
The decision begins with the need, not the solution
One of the strongest biases occurs when the Business Case begins 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 planned expansion;
- obsolescence increasing the risk of unavailability;
- a regulatory requirement not yet met;
- a bottleneck limiting production or quality;
- asset risk without adequate control;
- rising operating cost;
- a need to increase resilience or continuity.
This formulation opens the door to different responses. The solution may involve expansion, retrofit, 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 restrictions, 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, record survey, or diagnostic assessment may be necessary before this reference can be estimated correctly. Without knowing the existing condition, the organization risks comparing the proposed alternative with a fictional situation.
Objectives need to be verifiable
Expressions such as “modernize infrastructure,” “improve security,” or “increase efficiency” help express direction but are insufficient for a decision. The Business Case needs to convert intent into observable outcomes.
An objective can establish capacity, availability, schedule, reduced exposure, performance, compliance, or another measurable outcome. The definition should avoid turning the indicator itself into the objective. “Install 100 cameras,” for example, is a deliverable; “reduce uncovered areas according to defined technical criteria” is an outcome closer to the underlying need.
Benefits Management in Projects and Programs examines 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, baseline, and realization conditions
A benefit written in generic terms is difficult to govern. For each material benefit, the Business Case should record who is accountable for its realization, the baseline, the expected change, when it can occur, and which deliverables or operational changes are required.
This avoids attributing to the project a benefit that depends mainly on external factors. New infrastructure may enable higher production, but the economic benefit may also depend on demand, raw materials, people, processes, and operations.
This causal chain should be explicit. Otherwise, the financial model turns possibilities into certain revenues and creates an excessively 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 option not to proceed or to postpone.
Set-Based Design in Engineering shows how viable alternatives can remain open in parallel while evidence is produced, avoiding premature convergence.
An initial longlist can be filtered using elimination criteria. The technically feasible alternatives can 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 should be examined where applicable. Even in mandatory projects, the base case helps quantify the cost and risk of delaying intervention and enables comparison among different ways of meeting the obligation.
The 2026 Green Book uses business as usual as a mandatory reference in its public appraisal methodology. That specific rule does not automatically apply to Brazilian companies, but the analytical principle is useful: an alternative should 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. Technical evaluation needs to establish limits, performance, interfaces, implementation conditions, applicable standards, 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: choosing the most financially attractive solution and then discovering that it fails a technical condition that should have been an elimination criterion.
CAPEX, OPEX, and lifecycle 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 may transfer cost to energy, maintenance, licensing, labor, downtime, or future replacements. The Business Case should therefore not treat CAPEX as the only economic measure of an alternative.
TCO and Lifecycle Cost in Engineering organizes expenditure over the asset life and helps expose costs 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 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 simple return ratios.
These numbers should derive from the same cash-flow basis and use documented assumptions. A Business Case should not present only “18% IRR” or “3-year Payback” without the underlying CAPEX, OPEX, horizon, benefits, rate, and risks.
Mandatory projects or projects with predominantly non-monetary benefits may not show a positive financial return. In these cases, economic analysis can compare alternatives for meeting the requirement rather than inventing revenue to justify the intervention.
DCF makes time explicit
Costs and benefits occurring at different times are not directly comparable. Discounted Cash Flow in Engineering Projects structures flows by period and discounts 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 rates, cost of capital, tax criteria, or other financial parameters may belong to the finance function. Engineering should improve the quality of technical inputs; it should not silently invent corporate parameters it was not given.
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 delivery capability can change cost, schedule, benefit, and even feasibility.
Risk Management in Engineering Projects provides a 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 outcome but also what could make that outcome cease to be true.
Assumptions and constraints need to be visible
Every investment decision is built on assumptions. Demand growth, energy prices, service life, utilization rate, contracting lead time, space availability, connection capacity, productivity, and regulatory stability are examples of assumptions that may be material.
The difference between assumption and fact must remain clear. A useful practice is to record:
| Field | Control example |
| Assumption | average tariff used in the model |
| Source | contract, history, or approved forecast |
| Owner | function that provided or approved the data |
| Base date | time reference |
| Sensitivity | impact if the assumption changes |
| Status | confirmed, provisional, or pending |
Critical pending assumptions may become engineering actions before the next gate.
The Business Case should record why alternatives were rejected
ABNT NBR ISO 21502:2021 recommends assessing alternative options and presenting the reasons for rejection. This record is valuable because it preserves the memory of the decision.
Without it, a rejected alternative may reappear months later without anyone knowing which requirement failed, which cost made the solution unviable, or which risk was considered. Traceability also protects against retrospective decisions based only on the final outcome.
The justification does not need the same level of detail for every option. Alternatives eliminated by an objective criterion can have a concise record; finalists require a 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 board, board of directors, portfolio board, or another body may hold final authority.
Decision Governance with Authority Levels, Committees, and Stage-Gates helps separate analysis, recommendation, approval, and escalation.
This distinction needs to appear in the Business Case to avoid treating a technical opinion as capital authorization or confusing executive approval with technical validation of the solution.
The sponsor needs to preserve the justification throughout the project
ABNT NBR ISO 21502 assigns the sponsor a role in promoting the Business Case and validating whether the project remains justified throughout the lifecycle. 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 benefits may require review. If the need disappears, the alternative becomes infeasible, or the investment grows far beyond the approved case, governance needs to reassess whether continuing still makes sense.
Gates turn 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, a gate may authorize only the next study. Later, it may authorize basic design, FEED, procurement, or implementation. The decision and committed capital grow together with the quality of the evidence.
FEL is a natural environment for maturing the Business Case
FEL — Front-End Loading organizes project maturation before significant capital commitment. Need, alternatives, technical definition, estimates, risks, schedule, and execution strategy can evolve in an integrated way.
The Business Case follows this maturation. A preliminary justification may support FEL 1; later versions incorporate stronger evidence for subsequent gates. The objective is not to create a perfect document too early, but to increase reliability before decisions become expensive or irreversible.
The Business Case should align with the contracting strategy
An alternative may be technically sound and financially attractive but difficult to procure 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, multiple contracts, direct purchase 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 a viable path exists to convert the chosen alternative into procurement and delivery.
Organizational capability is also part of feasibility
Projects fail even when the technology works. Lack of staff to operate the asset, insufficient capability to supervise 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 own the asset and the benefits;
- which capabilities will be required;
- how operations will receive the solution;
- which internal resources will be needed;
- what external support is required;
- how organizational changes will be implemented;
- whether there is capacity to manage the procurement and the project.
This expands feasibility beyond “it is technically possible to build.”
How to structure a Business Case for 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, lifecycle cost, 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 to proceed.
- Update plan: events that require review of the justification.
Proportionality matters. A small project does not need dozens of pages; a high-CAPEX project with major uncertainty should not be authorized by 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 requested decision, investment value, preferred alternative, expected benefits, critical risks, key assumptions, and next gates.
If the recommendation depends on an assumption not yet confirmed — connection availability, licensing, structural condition, supplier pricing, or another issue — that should appear in the summary. Governance needs to know whether it is approving a mature solution or only the next investigation stage.
How to use the Five Case Model without uncritically copying a foreign model
HM Treasury updated its Five Case Model 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 regulatory requirement. Its main contribution is the reminder that a decision should not be assessed solely on financial return: strategic alignment, option selection, 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 law, corporate governance, and the client’s methodology remain decisive.
Project Assurance can review decision quality
In high-impact projects, a decision may be formally approved while still relying on weak technical assumptions. An independent review before the gate helps the sponsor distinguish real maturity from apparent precision.
High-impact projects may benefit from independent review before critical gates. Project Assurance in Engineering verifies 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 recreate the entire Business Case. It can test issues such as consistency between need and solution, estimate maturity, independence of alternatives, traceability of assumptions, critical risks, procurement readiness, and the quality of the recommendation.
Owner’s Engineering protects the owner’s perspective
When the project advances, the role 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 compatible 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 engage support to build the Business Case
Engineering Consulting tends to add more value when the organization understands the need but still needs to turn scattered information into technically comparable alternatives and a structured decision.
This occurs, for example, when:
- the project involves several disciplines;
- the existing condition is poorly understood;
- relevant technology alternatives exist;
- CAPEX and OPEX depend on surveys and technical estimates;
- benefits need to be connected to actual performance;
- implementation risks may 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 client’s responsible functions and authorities.
What to require when procuring a technical Business Case
The scope should define the decision product, not merely “prepare a report.” Depending on complexity, it may be appropriate to require:
- collection of input data and documents;
- definition of the problem, objectives, and base case;
- identification and screening of alternatives;
- requirements and elimination criteria;
- technical feasibility assessment;
- CAPEX, OPEX, and lifecycle estimates with a stated basis;
- 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 updating in subsequent phases.
The client should also define who supplies 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;
- no base case;
- only one real alternative;
- benefits without baseline or owner;
- CAPEX without an estimate basis;
- OPEX treated as a generic percentage without a technical driver;
- IRR, NPV, or ROI without calculation support;
- risks listed without impact on the decision;
- schedule inconsistent with permits, engineering, or procurement;
- critical assumptions presented as facts;
- no gate criteria;
- a recommendation that does not state its conditions of validity.
The objective of the review is not to make every Business Case longer. It is to determine whether enough information exists for the irreversibility and risk of the decision being taken.
The Business Case should be controlled as a living document
Version, base 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 evidence-based decision-making about whether a need deserves investment, which alternative offers the best balance of value, risk, and delivery capability, and which conditions need to be preserved throughout the project.
The greater the capital commitment, complexity, and irreversibility, the higher the quality of definition required before the decision. Maturity does not come from adding pages; it comes from turning relevant uncertainties into verifiable information and keeping explicit those that still cannot 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 stages rather than directly authorize implementation.
Technical references
[1] BRAZILIAN ASSOCIATION OF TECHNICAL STANDARDS. 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 supporting a decision to commit resources to a project, continue investing, or stop when the justification no longer exists. It should connect need, objectives, alternatives, value, costs, benefits, risks, and delivery capability.
A Feasibility Study assesses whether a solution or project is feasible under applicable technical, operational, and economic criteria. The Business Case uses that evidence together with strategy, benefits, alternatives, risk, and governance to support the investment decision.
No. The Business Case explains why the investment and alternative make sense. The Project Charter formally establishes the project, authority, and initial objectives and scope after or together with authorization, depending on governance.
Not for every project. When relevant and quantifiable financial flows exist, NPV, IRR, Payback, and ROI can support the decision. Mandatory projects or those with non-monetary benefits may require other criteria without creating artificial revenues.
Approval belongs to the authority defined by organizational governance, such as the sponsor, investment committee, executive board, or board of directors. The technical team can prepare analyses and recommendations but should not assume authority that was not delegated.
Yes, when governance and materiality justify it. Relevant 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, surveys of existing conditions, estimates, risk, requirements integration, or independent review before committing material capital.
Not as a general rule. It is a UK Government reference methodology and can inspire multidimensional analysis, but Brazilian organizations should follow applicable law, 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
- Engineering Project Management
- Owner’s Engineering
Main content on the 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 Lifecycle Cost in Engineering
