Project Framing in Capital Projects: defining the problem before the solution

Project Framing structures the problem, expected value, constraints, and decisions of a capital project before the organization prematurely commits to a solution.

Check it out!

Project Framing is the structured process used to correctly define which problem, need, or opportunity justifies a project, which outcomes need to be achieved, and which boundaries should guide analysis before turning a hypothesis into an engineering solution. In capital projects, this stage exists to prevent a recurring mistake: starting with equipment, technology, construction, or a supplier before there is consensus on the problem the investment needs to solve.

Framing is not a preliminary design, a simplified FEED, or a brainstorming meeting. It structures the initial decision. The team seeks to establish the current situation, desired future state, relevant stakeholders, business objectives, success criteria, constraints, critical assumptions, dependencies, and decisions still to be made. The result is a common reference for developing alternatives, structuring the Business Case, and deciding whether the opportunity should advance to deeper studies.

In practical terms, good Project Framing separates the problem from the solution. “We need to install a new substation,” “we need to replace the VMS,” or “we need to build a new Data Center” are solution statements. The underlying problem may be insufficient capacity, obsolescence, unavailability, demand growth, nonconformity, operational risk, loss of productivity, or inability to meet a future requirement. Until that difference is clear, the organization risks optimizing a solution that does not solve the actual need.

Framing also sets the quality threshold for the next decision. Before authorizing studies, reserving CAPEX, or engaging suppliers, governance needs to know what is being decided, on what evidence, and which uncertainties remain open. Project Framing therefore functions as an ambiguity-reduction stage: it does not eliminate risk or define every detail, but it creates a common basis so that feasibility, FEL, Project Definition, and investment approval all work on the same problem.

Project Framing within the Capital Project lifecycle

A capital project begins before an engineering design exists. It may originate from an operational need, capacity expansion, regulatory requirement, cost-reduction opportunity, technological change, continuity obligation, resilience need, or corporate strategy. The first challenge is to turn that trigger into a definition clear enough to guide investigation and decision-making.

Within the lifecycle of Capital Projects & Infrastructure, framing occupies the transition between recognizing a need and formally structuring the investment. It precedes solution detailing and directly connects with the Business Case in Engineering Projects, because the Business Case needs to demonstrate why a particular alternative is an appropriate response to the problem — and that demonstration is weak when the problem itself was poorly defined.

A logical sequence can be represented as follows:

1. identify the need, opportunity, or risk;
2. understand the current condition and context;
3. formulate the problem in a solution-neutral way;
4. define objectives, expected outcomes, and success criteria;
5. record constraints, assumptions, dependencies, and interfaces;
6. identify stakeholders and decision authority;
7. map required decisions and missing information;
8. create room for alternatives;
9. advance to feasibility, concept development, and project definition.

This sequence does not mean every project requires a formal workshop called “Project Framing.” The principle matters more than the label: before significant resources are committed, there should be a traceable formulation of the problem and a shared understanding of what a successful solution would look like.

The UK government’s Project Set Up Toolkit uses a similar logic by separating the why of the project, the what that must be delivered, and the how delivery capability will be structured. In private or public engineering, this distinction helps prevent an implementation decision from being treated as the investment justification itself.

The most common mistake: turning the solution into the problem

How the opportunity is stated shapes all subsequent reasoning. If the initial statement already contains the solution, alternatives tend to be evaluated merely as variations of a decision already chosen.

Consider three formulations:

Initial formulation	Nature	Effect on the decision
“Install a new 500 kVA generator”	solution	prematurely constrains capacity, technology, and strategy
“Eliminate power outages at the facility”	broad problem	opens the diagnosis but still needs metrics and boundaries
“Ensure power to critical loads for 4 hours, with defined minimum availability and without increasing contracted demand”	structured need	creates criteria for comparing alternatives

In the third case, engineering can study generators, UPS, energy storage, supply redundancy, selectivity, load redistribution, local generation, or combinations of solutions. The need remains stable even if the solution changes.

This discipline is especially important in brownfield projects. The organization often knows the operational pain well while carrying historical interpretations about its cause. An availability problem may be attributed to obsolete equipment when the dominant cause lies in protection, maintenance, capacity, configuration, supporting infrastructure, or operating processes. In these cases, Engineering Technical Due Diligence and field surveys help replace opinion with evidence.

Framing should use language neutral enough to allow investigation. This does not mean ignoring hypotheses. Hypotheses are useful as long as they are recorded as hypotheses and not silently converted into facts.

From the current condition to the desired future state

Robust framing needs to answer two complementary questions: where are we? and what needs to be different?. The gap between those two conditions is the basis for defining the problem.

The current condition should be described with evidence proportionate to the decision. In some cases, operating data, availability indicators, incidents, and existing documentation are enough to begin the analysis. In others, especially when the investment depends on existing infrastructure, inspections, surveys, measurements, or document analyses may be required before framing can be concluded.

The desired future state should not be described merely as a list of deliverables. “Have a new electrical room” is a deliverable. “Support a 30% load increase with selectivity, continuity, and a defined growth margin” describes a performance condition. The second formulation provides a much stronger basis for requirements and acceptance criteria.

A good description of the future state usually considers:

• expected capacity or performance;
• availability and reliability;
• safety and compliance;
• operations and maintenance constraints;
• service-life or expansion horizon;
• continuity requirements;
• service level or quality;
• impacts on operating cost;
• sustainability criteria, where applicable;
• date or window by which the outcome must be available.

This logic helps build the investment’s “golden thread”: need → objective → requirement → solution → test → benefit. When that chain is lost, the project may be technically completed and still fail to deliver the outcome that justified the CAPEX.

Objectives, outcomes, and success criteria

Vague objectives produce vague projects. Terms such as “modernize,” “improve,” “optimize,” or “increase reliability” need to be converted into criteria that can guide alternatives and later be verified.

Framing does not need to turn every objective into a detailed specification, but it should distinguish three levels:

Level	Question	Example
strategic objective	why invest?	support operational expansion without increasing exposure to unavailability
expected outcome	what needs to change in the business/operation?	increase available capacity and reduce unplanned interruptions
success criterion	how do we know it worked?	capacity margin, availability, and recovery time within approved values

This structure connects directly to Benefits Management in Projects and Programs. A benefit needs an owner, metric, time horizon, and causal relationship with deliverables. If framing cannot explain which outcome the project should enable, the justification tends to depend only on a list of assets to be acquired.

Defining success also reduces conflicts among stakeholders. Operations may prioritize availability; finance, a CAPEX limit; maintenance, standardization and access; safety, risk mitigation; IT, interoperability; engineering, performance and service life. Framing makes these priorities explicit so conflicts appear before they are embedded in the project.

Stakeholders: who defines value, who delivers, and who receives the asset

Project Framing cannot be conducted only by the area that identified the need. Capital projects create cross-functional impacts and therefore need to bring together perspectives that would otherwise appear at different points in the lifecycle.

Relevant stakeholders may include the sponsor, operations, maintenance, engineering, facilities, IT, security, HSE, procurement, finance, legal, users, asset management, inspection, regulators, and, in some cases, external partners. The composition depends on the type of project.

The objective is not to expand the forum indefinitely. It is to ensure that functions capable of changing requirements, imposing constraints, or receiving the asset are considered early enough.

A simple matrix can distinguish:

• decision owner: who has authority to approve progression;
• benefit owner: who is accountable for realizing the expected outcome;
• requirement owner: who defines or validates a given requirement;
• asset/operations owner: who will receive the asset into operations;
• technical authority: who protects technical criteria and standards;
• delivery owner: who will lead development and implementation.

Clarity in these roles reduces a common problem: the project being developed by engineering, approved by finance, and received by operations without any party having explicit accountability for continuity among need, requirements, and benefit.

Constraints, givens, and assumptions: they are not the same thing

One of the most practical contributions of framing is organizing what is truly fixed and what only appears to be fixed.

Constraints are conditions that limit alternatives: physical area, shutdown window, legislation, supply capacity, regulatory date, maximum budget, existing interfaces, or inability to interrupt a given operation.

Givens are decisions or conditions considered established by governance at that time. They should be tested because they often represent historical decisions that may no longer be valid.

Assumptions are conditions assumed to be true to enable analysis, although they still require confirmation. They need an owner, expected evidence, and a validation date.

Element	Treatment in framing	Risk if confused
constraint	record source and impact	exclude viable alternatives or ignore real limits
given	confirm authority and validity	perpetuate an old decision without a current basis
assumption	state uncertainty and validation plan	build estimates and designs on unverified information

This distinction prepares the ground for a future Assumptions Register and for constraint management. It also improves the quality of estimates and schedules because it separates known information from hypotheses.

Dependencies and interfaces that need to appear early

A project may appear simple when analyzed in isolation and become complex because of interfaces. Framing should identify dependencies that can control feasibility or schedule even before detailed design exists.

Examples include:

• availability of power, water, telecommunications, or utilities;
• associated civil works;
• permits and approvals;
• shutdown windows;
• integration with existing systems;
• operations-team capability;
• dependency on a specific supplier;
• imports and long-lead items;
• third-party works;
• data or systems migration;
• safety and access constraints;
• organizational changes required to use the asset.

A Interface Management becomes critical as the solution matures, but framing should already identify interfaces capable of changing alternatives, schedule, or cost.

Framing and alternatives: open the decision space before closing the solution

The purpose of framing is not to select the winning alternative. It is to create the conditions for rational comparison.

An alternative may vary by technology, architecture, location, capacity, phasing, implementation model, schedule, redundancy level, use of existing assets, or a combination of physical intervention and operational change.

Framing should avoid two extremes. In the first, the team moves directly to a preferred solution. In the second, it opens such a broad universe of possibilities that analysis loses focus. The role of objectives and constraints is to create a controlled “solution space.”

After framing, techniques such as Multi-Criteria Decision Analysis (MCDA), decision matrices, cost-benefit analysis, and feasibility studies can compare alternatives using explicit criteria. This is very different from requesting three supplier proposals and treating the received proposals as if they were the only alternatives to the problem.

Risk in framing: identify exposure before estimating precision

Risk registration should not begin only when an execution schedule exists. Definition risks appear much earlier and can control the quality of the investment decision.

In framing, analysis is predominantly exploratory. The team seeks to identify uncertainties capable of changing the problem, invalidating an alternative, or requiring additional investigation. Risks may involve future demand, existing condition, technology, permitting, integration capability, area availability, interfaces, schedule, cost, operations, internal resources, and external dependencies.

The article on Risk Analysis in Engineering Projects explores qualitative and quantitative methods in depth. In framing, the central question comes earlier: which uncertainties are relevant enough to change how the opportunity should be studied?

A good practice is to classify each uncertainty into one of the following actions:

1. temporarily accept as an assumption;
2. investigate before selecting an alternative;
3. investigate before the Business Case;
4. defer to a later stage with an explicit plan;
5. treat as a constraint;
6. escalate for governance decision.

The minimum evidence pack for Project Framing

Framing needs to produce enough evidence for another person to understand the reasoning without relying on workshop memory. The package does not need to be extensive, but it must be traceable.

An evidence pack may include:

Document / record	Function
problem statement	record the problem in a solution-neutral way
opportunity statement	explain the opportunity and its potential value
current state	consolidate known facts and baseline
target state / success statement	define the desired future condition
objectives and success criteria	translate value into decision criteria
stakeholder map	identify functions that influence, decide, or receive the asset
constraints and assumptions	separate real limits from hypotheses
dependencies and interfaces	reveal external factors that control the decision
initial risk register	record uncertainties capable of changing the path
decision roadmap	show which decisions still need to be made and in what sequence
information gaps	turn relevant unknowns into investigation actions

The value of these records lies in their consistency. A target state requiring high availability should later appear in requirements, architecture, estimates, testing, and operations. A critical risk identified during framing cannot simply disappear because the project entered FEED.

Decision roadmap: framing must produce decisions, not just information

One of the best outputs of framing is a decision map. Complex projects rarely need a single approval; they need a sequence of decisions, each depending on different information and maturity.

The decision roadmap may indicate, for example:

• confirm the need;
• validate existing-condition data;
• approve alternative criteria;
• select the preferred alternative;
• approve the preliminary Business Case;
• authorize FEL/FEED;
• define the procurement strategy;
• complete Project Readiness;
• perform sanction/FID.

This prevents the organization from trying to resolve everything in a single approval meeting. It also connects to Stage-Gate in engineering projects, in which each gate needs criteria, evidence, authority, and possible outcomes.

Project Framing vs. Opportunity Framing vs. Business Case vs. FEL

The terms overlap in some methodologies, but they carry different semantic responsibilities. The best criterion is to look at the decision each activity needs to support.

Element	Central question	Expected result
Project/Opportunity Framing	which problem or opportunity deserves to be developed?	problem, success, constraints, stakeholders, decisions, and gaps
Business Case	is it worth investing, and why?	strategic, economic, financial, and delivery justification
Feasibility	which alternatives are feasible, and which provides the best balance of benefits, costs, and risks?	supported recommendation and conditions
FEL / Front-End Planning	is the project sufficiently defined to move forward?	progressive maturity of scope, engineering, cost, risk, and execution
FEED	is the selected solution technically defined enough to estimate, procure, and prepare implementation?	engineering package and technical definition

This boundary avoids two problems. The first is requiring framing to have FEED-level detail. The second is skipping framing and trying to use FEED to discover which problem should have been solved.

The FEL — Front-End Loading has a complementary role: once the opportunity is correctly framed, FEL structures the progressive maturation of the solution, feasibility, engineering, and criteria for subsequent gates.

How to know whether framing is sufficiently mature

Maturity does not mean the absence of uncertainty. It means the remaining uncertainty is known, classified, and compatible with the next decision.

Framing is sufficiently mature when governance can consistently answer:

• which need or opportunity is being addressed;
• which evidence demonstrates that it exists;
• what defines success;
• which outcomes and benefits are expected;
• which constraints limit the alternatives;
• which assumptions still need validation;
• which stakeholders have authority or critical requirements;
• which dependencies can control schedule or feasibility;
• which risks may invalidate the opportunity;
• which information is missing;
• which decisions will be made next;
• which engineering or analysis stage needs to be authorized.

If the team can only answer “which solution do we want to buy?”, framing has not yet fulfilled its purpose.

The logic is consistent with Project Readiness in Engineering: being ready does not mean being complete; it means having evidence and conditions appropriate to the next commitment.

How to conduct a Project Framing workshop

Workshops are useful because they make disagreements visible. Their value, however, lies not in the exercise itself but in the quality of inputs, facilitation, and decisions produced.

A practical structure can be conducted in seven blocks:

1. Context and evidence: present facts, data, previous decisions, and current condition.
2. Problem statement: formulate the problem without embedding a solution.
3. Success statement: describe the future state and success criteria.
4. Stakeholders and interfaces: identify who defines, decides, delivers, and receives.
5. Constraints, givens, and assumptions: separate limits, established decisions, and hypotheses.
6. Risks and information gaps: record unknowns that change the decision.
7. Decision roadmap: define decisions, owners, required evidence, and next steps.

In critical projects, independent facilitation may be useful when there are preferred solutions, conflicts among areas, or strong pressure for approval. Independence does not replace sponsor authority; it helps reduce confirmation bias and document dissent before it becomes expensive change.

Framing in brownfield projects

Brownfield projects require additional care because the physical baseline may be less reliable than stakeholder perceptions. Outdated As-Built documentation, installations modified over the years, unknown residual capacity, and informal operational dependencies can completely change the feasibility of an alternative.

In these cases, framing should explicitly distinguish what we know, what we believe we know and what needs to be surveyed. It may be premature to discuss the solution before performing a site survey, as-built survey, or due diligence.

This approach reduces the risk of producing a technically correct design for a condition that no longer exists.

Framing in public-sector projects

In the public sector, framing is closely related to defining the need, planning, preliminary technical studies, alternative selection, value for money, and the quality of the public problem the procurement is intended to solve. Consulting engineering does not replace the public administration’s legal responsibilities, but it can improve the technical basis on which decisions are prepared.

A statement that is excessively solution-oriented may restrict alternatives before feasibility analysis. On the other hand, a need that is too generic may produce preliminary technical studies and Basic Design without sufficient criteria to define scope, performance, schedule, and risks.

Framing discipline helps build continuity among need, surveys, alternatives, engineering, budgeting, procurement, inspection, and acceptance.

How to procure support for Project Framing

When framing depends only on informal internal meetings, there is a risk of recording perceptions without investigating data, conflicts, and constraints. Specialized support makes sense when the decision has material impact, involves multiple disciplines or stakeholders, the existing condition is uncertain, relevant technology alternatives exist, or the investment must pass formal gates.

The contracted scope should make clear that the purpose is not simply to “conduct a workshop.” The engagement should be oriented toward producing a decision basis. Possible deliverables include the problem statement, target state, stakeholder map, assumptions and constraints register, success criteria, initial risk matrix, information gaps, alternatives to investigate, and decision roadmap.

It is advisable to specify:

• input documents and available baseline;
• mandatory stakeholders;
• preparation activities and prior analysis;
• need for surveys or site visits;
• facilitation method;
• method for recording disagreements;
• criteria for considering framing complete;
• responsibilities for validating assumptions;
• interface with Business Case, feasibility, and FEL;
• approval format for the final package.

How A3A Engenharia approaches initial project definition

A3A’s work should start from the actual problem and the level of evidence required for the decision. Depending on the context, framing may require only facilitation and document analysis, or it may need to be preceded by surveys, site survey, and due diligence.

The working logic is progressive:

Assessment — understand condition, documents, risks, assumptions, and gaps; Advisory — structure objectives, alternatives, criteria, interfaces, and decisions; Assurance — verify whether the available evidence is sufficient to advance to the next commitment.

The service should not anticipate conclusions that belong to later stages. The role of consulting engineering is to turn a still-diffuse need into a technically investigable question with clear decisions and responsibilities.

This also means knowing when to stop. If framing shows that the opportunity lacks strategic alignment, the benefits do not justify the effort, or a lower-cost operational alternative exists, the technical recommendation may be not to advance to a capital project at that time.

Technical conclusion

Project Framing is a decision discipline, not a design discipline. Its value lies in organizing the opportunity before the investment becomes constrained by a solution chosen too early. When the problem, objectives, constraints, stakeholders, risks, and decisions are made explicit, engineering can compare alternatives more effectively and the Business Case responds to a real need rather than retrospectively justifying a preference.

In Capital Projects, this stage reduces the risk of carrying ambiguity into FEL, FEED, procurement, and execution. The cost of discovering late that the problem was poorly formulated is far greater than the cost of investing early in definition. Framing should therefore produce a traceable basis: what we know, what we assume, what we need to discover, who decides, and what evidence is required to proceed.

The closing question is not “which solution will we implement?” It is: is the problem defined clearly enough for engineering alternatives to be evaluated without bias and for the next investment decision to be made based on evidence?

Technical references

[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 21502:2020 — Project, programme and portfolio management — Guidance on project management. Genebra: ISO, 2020. Disponível em: https://www.iso.org/standard/74947.html

[2] INFRASTRUCTURE AND PROJECTS AUTHORITY. Overview of the Project Set Up Toolkit. Londres: UK Government, 2022. Disponível em: https://www.gov.uk/government/publications/project-set-up-toolkit/overview-of-the-project-set-up-toolkit

[3] PROJECT MANAGEMENT INSTITUTE. PMBOK® Guide — Eighth Edition. Newtown Square: PMI, 2025. Disponível em: https://www.pmi.org/standards/pmbok

Frequently asked questions

What is Project Framing?

Project Framing is the process of structuring a project’s problem, opportunity, objectives, constraints, stakeholders, assumptions, risks, and decisions before selecting and detailing the engineering solution.

Is Project Framing the same as FEL?

No. Framing defines the problem and establishes the decision basis. FEL progressively develops alternatives, feasibility, technical definition, estimates, risks, and project maturity before larger capital commitments.

What is the difference between Project Framing and a Business Case?

Framing defines the problem and what constitutes success. The Business Case uses that basis to justify whether the investment should proceed by comparing alternatives, benefits, costs, risks, and delivery capability.

Does Project Framing require a workshop?

Not necessarily. A workshop is an efficient way to align stakeholders and make disagreements visible, but the process can combine document analysis, interviews, surveys, and structured sessions according to project complexity.

Which documents should come out of framing?

Typically: problem statement, current state, target state, success criteria, stakeholders, constraints, assumptions, dependencies, initial risks, information gaps, and decision roadmap.

When should specialized support be engaged?

When the decision involves significant CAPEX, multiple disciplines, uncertain existing conditions, stakeholder conflicts, relevant technology alternatives, or a need for formal evidence for gates and investment approval.

Additional technical resources

Related services

• Estudo de Viabilidade Técnica e Econômica
• Engineering Technical Due Diligence
• FEL — Front-End Loading
• Engineering Risk Management

Core content on the topic

• Capital Projects & Infrastructure — HUB
• Capital Project Lifecycle: from opportunity to operational asset
• Business Case in Engineering Projects
• CAPEX Management in Engineering Projects
• Stage-Gate in Engineering Projects
• Project Readiness in Engineering

Related technical content

• Feasibility Study in Engineering
• Multi-Criteria Analysis in Engineering Projects
• Risk Analysis in Engineering Projects
• Benefits Management in Projects and Programs
• PDRI — Project Definition Rating Index
• FEED in Engineering
• Complete Guide to Consulting Engineering
• Project Management Guide