Project Framing for Capital Projects: How to Define the Problem Before the Solution

Project Framing structures the problem, expected value, constraints, and decisions of a capital project before the organization commits prematurely 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 must be achieved, and which boundaries should guide the analysis before turning a hypothesis into an engineering solution. In capital projects, this step exists to prevent a recurring mistake: starting with the equipment, technology, construction work, or supplier before there is agreement on the problem the investment must solve.

Framing is not a preliminary design, a simplified FEED, or a brainstorming meeting. It organizes 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 the decisions that still need to be made. The result is a common reference for developing alternatives, structuring the Business Case, and deciding whether the opportunity deserves deeper study.

In practical terms, good Project Framing separates problem from 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 problem may be insufficient capacity, obsolescence, unavailability, demand growth, noncompliance, operational risk, loss of productivity, or inability to meet a future requirement. Until this difference is clear, the organization risks optimizing a solution that does not address the real need.

Framing also defines the quality of the next decision. Before authorizing studies, reserving CAPEX, or involving suppliers, governance needs to know what is being decided, what evidence supports the decision, and which uncertainties remain open. Project Framing therefore works as an ambiguity-reduction step: it does not eliminate risks or define every detail, but it creates a common basis so that feasibility, FEL, Project Definition, and investment approval address the same problem.

Project Framing within the Capital Project lifecycle

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

Within the Capital Projects & Infrastructure lifecycle, framing sits between recognizing a need and formally structuring the investment. It precedes detailed solution development and is directly connected to the Business Case in Engineering Projects, because the Business Case must demonstrate why a given alternative is an appropriate response to the problem — and that demonstration is weak when the problem itself has been 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 space 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 committing significant resources, there should be a traceable problem statement and a shared understanding of what a successful solution would look like.

The UK Government Project Set Up Toolkit follows a similar logic by separating the why of the project, the what to be delivered, and the how delivery capability will be structured. The value of this distinction in private or public engineering is to prevent an implementation decision from being treated as the investment justification itself.

The most common mistake: turning the solution into the problem

The way an opportunity is written shapes all subsequent reasoning. If the initial statement already contains the solution, alternatives tend to be assessed only as variations of a choice that was made in advance.

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
“Supply critical loads for 4 hours, with a defined minimum availability and without increasing contracted demand”	structured need	creates criteria for comparing alternatives

In the third case, engineering can evaluate generators, UPS systems, 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 environments. The organization often knows the operational pain very well while carrying historical interpretations of its cause. An availability problem may be attributed to obsolete equipment when the dominant cause is protection, maintenance, capacity, configuration, support infrastructure, or an operating process. 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, provided they are recorded as hypotheses rather than silently converted into facts.

From the current condition to the desired future state

Robust framing must answer two complementary questions: where are we? and what needs to be different?. The gap between these 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 sufficient to start the analysis. In others, especially when the investment depends on existing infrastructure, inspections, surveys, measurements, or document reviews may be required before framing can be concluded.

The desired future state, in turn, should not be described only 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 normally 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, when applicable;
• the date or window by which the outcome must be available.

This logic helps build the investment “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. Expressions 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 must 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 the deliverables. If framing cannot explain which outcome the project should enable, the justification tends to rely only on a list of assets to be purchased.

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

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 perspectives that often emerge 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, supervision, 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 advancement;
• 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: engineering develops the project, finance approves it, and operations receives it, yet no party has explicit responsibility for continuity from need to requirements to benefits.

Constraints, givens, and assumptions are not the same thing

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

Constraints are conditions that limit alternatives: physical space, shutdown windows, legislation, supply capacity, regulatory dates, maximum budget, existing interfaces, or the impossibility of interrupting a particular operation.

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

Assumptions are conditions treated as true to enable analysis even though they still require confirmation. They need an owner, expected evidence, and a validation date.

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

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

Dependencies and interfaces that need to appear early

A project may look simple 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 capacity;
• dependence on a specific supplier;
• imports and long lead items;
• third-party works;
• data or system migration;
• safety and access constraints;
• organizational changes required to use the asset.

Interface Management becomes increasingly 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, reuse of existing assets, or a combination of physical intervention and operational change.

Framing should avoid two extremes. In the first, the team moves directly toward a preferred solution. In the second, it opens such a broad universe of possibilities that the analysis loses focus. Objectives and constraints define 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 against explicit criteria. This is very different from asking three suppliers for proposals and treating the responses as if they were the only alternatives to the problem.

Risks 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.

During 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, space availability, interfaces, schedule, cost, operations, internal resources, and external dependencies.

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

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

1. provisionally accept it as an assumption;
2. investigate before selecting an alternative;
3. investigate before the Business Case;
4. transfer it to a later stage with an explicit plan;
5. treat it as a constraint;
6. escalate it for a 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 large, but it must be traceable.

An evidence pack may include:

Document / record	Purpose
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 boundaries 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 that requires high availability should later appear in requirements, architecture, estimates, tests, and operations. A critical risk identified during framing cannot disappear simply because the project entered FEED.

Decision roadmap: framing must produce decisions, not just information

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

The decision roadmap may indicate, for example:

• confirm the need;
• validate existing-condition data;
• approve criteria for alternatives;
• select the preferred alternative;
• approve the preliminary Business Case;
• authorize FEL/FEED;
• define the delivery and contracting 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, where 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 carry different semantic responsibilities. The best criterion is to look at the decision each activity must support.

Element	Central question	Expected result
Project/Opportunity Framing	which problem or opportunity deserves further development?	problem, success, constraints, stakeholders, decisions, and gaps
Business Case	is the investment worthwhile and why?	strategic, economic, financial, and delivery justification
Feasibility	which alternatives are feasible and which offers the best balance of benefits, costs, and risks?	substantiated recommendation and conditions
FEL / Front-End Planning	is the project sufficiently defined to advance?	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 reach the level of detail of FEED. The second is skipping framing and trying to use FEED to discover which problem should have been solved.

FEL — Front-End Loading plays 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 characterizes 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 can invalidate the opportunity;
• which information is missing;
• which decisions come next;
• which engineering or analysis stage needs to be authorized.

If the team can answer only “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, but 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 the inputs, facilitation, and decisions produced.

A practical structure can be organized into seven blocks:

1. Context and evidence: present facts, data, prior decisions, and the 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 can change the decision.
7. Decision roadmap: define decisions, owners, required evidence, and next steps.

In critical projects, independent facilitation can be useful when there are preferred solutions, conflicts among areas, or strong pressure for approval. Independence does not replace the sponsor’s authority; it helps reduce confirmation bias and document disagreements before they become expensive changes.

Framing in brownfield projects

Brownfield projects require additional care because the physical baseline may be less reliable than stakeholder perception. 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 a solution before performing a site survey, record 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 strongly 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. Engineering consulting does not replace the Administration’s legal responsibilities, but it can improve the technical basis used to support decisions.

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 studies and basic design without sufficient criteria to define scope, performance, schedule, and risk.

Framing helps create continuity among the need, surveys, alternatives, engineering, budgeting, procurement, supervision, and acceptance.

How to procure specialized 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, multiple disciplines or stakeholders are involved, 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 “hold a workshop.” The engagement should be designed to produce a decision basis. Possible deliverables include a problem statement, target state, stakeholder map, assumptions and constraints register, success criteria, initial risk matrix, information gaps, alternatives to investigate, and a 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;
• how disagreements will be recorded;
• criteria for considering framing complete;
• responsibilities for validating assumptions;
• interface with the Business Case, feasibility, and FEL;
• approval format for the final package.

How A3A Engenharia approaches early project definition

A3A Engenharia’s approach should start from the real 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 visits, and due diligence.

The working logic is progressive:

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

The service should not anticipate conclusions that belong to later stages. The role of engineering consulting 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, that benefits do not justify the effort, or that 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 explicit, engineering can compare alternatives more effectively and the Business Case can respond to a real need instead of retrospectively justifying a preference.

In Capital Projects, this step reduces the risk of carrying ambiguity into FEL, FEED, procurement, and execution. The cost of discovering late that the problem was poorly formulated is much 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 advance.

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

Technical references

[1] 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

[2] INFRASTRUCTURE AND PROJECTS AUTHORITY. Overview of the Project Set Up Toolkit. London: UK Government, 2022. Available at: 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. Available at: https://www.pmi.org/standards/pmbok

Frequently asked questions

What is Project Framing?

Project Framing is the process of structuring the problem, opportunity, objectives, constraints, stakeholders, assumptions, risks, and decisions of a project 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, risk, and project maturity before larger capital commitments.

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

Framing defines the problem and what characterizes 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 expose disagreements, but the process can combine document analysis, interviews, surveys, and structured sessions according to project complexity.

What documents should come out of framing?

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

When should specialized support be engaged?

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

Complementary technical materials

Related services

• Technical and Economic Feasibility Study
• Engineering Technical Due Diligence
• FEL — Front-End Loading
• Engineering Risk Management

Main 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

• Engineering Feasibility Study
• 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 Engineering Consulting
• Project Management Guide