{"id":81583,"date":"2026-09-19T11:17:18","date_gmt":"2026-09-19T14:17:18","guid":{"rendered":"https:\/\/a3aengenharia.com\/?post_type=articles&p=81583"},"modified":"2026-09-19T11:25:23","modified_gmt":"2026-09-19T14:25:23","slug":"project-framing-capital-projects-define-problem-before-solution-3","status":"publish","type":"articles","link":"https:\/\/a3aengenharia.com\/en-us\/content\/technical-articles\/project-framing-capital-projects-define-problem-before-solution-3\/","title":{"rendered":"Project Framing in Capital Projects: defining the problem before the solution"},"content":{"rendered":"\n

Project Framing is the structured process used to correctly define which problem, need, or opportunity justifies a project<\/strong>, 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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

In practical terms, good Project Framing separates the problem from the solution<\/strong>. \u201cWe need to install a new substation,\u201d \u201cwe need to replace the VMS,\u201d or \u201cwe need to build a new Data Center\u201d 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.<\/p>\n\n\n\n

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<\/strong>. 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.<\/p>\n\n\n\n\n

Project Framing within the Capital Project lifecycle<\/h2>\n\n\n\n
\n

When the organization still cannot separate the need, existing condition, and intended solution, there is a definition problem before there is a design problem. A Technical and Economic Feasibility Study can structure alternatives, constraints, and criteria before the project advances toward a single solution.<\/p>\n\n\n\n

Technical and Economic Feasibility Study<\/a><\/p>\n<\/div>\n\n\n\n

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.<\/p>\n\n\n\n

Within the lifecycle of Capital Projects & Infrastructure<\/a>, 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<\/a>, because the Business Case needs to demonstrate why a particular alternative is an appropriate response to the problem \u2014 and that demonstration is weak when the problem itself was poorly defined.<\/p>\n\n\n\n

A logical sequence can be represented as follows:<\/p>\n\n\n\n

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

    This sequence does not mean every project requires a formal workshop called \u201cProject Framing.\u201d 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.<\/p>\n\n\n\n

    The UK government\u2019s Project Set Up Toolkit uses a similar logic by separating the why<\/strong> of the project, the what<\/strong> that must be delivered, and the how<\/strong> 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.<\/p>\n\n\n\n\n

    The most common mistake: turning the solution into the problem<\/h2>\n\n\n\n

    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.<\/p>\n\n\n\n

    Consider three formulations:<\/p>\n\n\n\n

    Initial formulation<\/td>Nature<\/td>Effect on the decision<\/td><\/tr>
    \u201cInstall a new 500 kVA generator\u201d<\/td>solution<\/td>prematurely constrains capacity, technology, and strategy<\/td><\/tr>
    \u201cEliminate power outages at the facility\u201d<\/td>broad problem<\/td>opens the diagnosis but still needs metrics and boundaries<\/td><\/tr>
    \u201cEnsure power to critical loads for 4 hours, with defined minimum availability and without increasing contracted demand\u201d<\/td>structured need<\/td>creates criteria for comparing alternatives<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    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.<\/p>\n\n\n\n

    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<\/a> and field surveys help replace opinion with evidence.<\/p>\n\n\n\n

    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.<\/p>\n\n\n\n\n

    From the current condition to the desired future state<\/h2>\n\n\n\n

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

    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.<\/p>\n\n\n\n

    The desired future state should not be described merely as a list of deliverables. \u201cHave a new electrical room\u201d is a deliverable. \u201cSupport a 30% load increase with selectivity, continuity, and a defined growth margin\u201d describes a performance condition. The second formulation provides a much stronger basis for requirements and acceptance criteria.<\/p>\n\n\n\n

    A good description of the future state usually considers:<\/p>\n\n\n\n