{"id":80835,"date":"2026-09-17T14:38:13","date_gmt":"2026-09-17T17:38:13","guid":{"rendered":"https:\/\/a3aengenharia.com\/?post_type=articles&p=80835"},"modified":"2026-09-17T14:38:13","modified_gmt":"2026-09-17T17:38:13","slug":"project-framing-capital-projects-define-problem-before-solution-2","status":"publish","type":"articles","link":"https:\/\/a3aengenharia.com\/en-us\/content\/technical-articles\/project-framing-capital-projects-define-problem-before-solution-2\/","title":{"rendered":"Project Framing for Capital Projects: How to Define 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 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.<\/p>\n\n\n\n

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

In practical terms, good Project Framing separates problem from 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 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.<\/p>\n\n\n\n

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

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

When an organization still cannot separate the need, the existing condition, and the intended solution, there is a definition problem before there is a project problem. A Technical and Economic Feasibility Study can structure alternatives, constraints, and criteria before the venture 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 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.<\/p>\n\n\n\n

Within the Capital Projects & Infrastructure<\/a> 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<\/a>, because the Business Case must demonstrate why a given alternative is an appropriate response to the problem \u2014 and that demonstration is weak when the problem itself has been 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 space 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 committing significant resources, there should be a traceable problem statement and a shared understanding of what a successful solution would look like.<\/p>\n\n\n\n

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

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

    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.<\/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>
    \u201cSupply critical loads for 4 hours, with a 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 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.<\/p>\n\n\n\n

    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<\/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, provided they are recorded as hypotheses rather than silently converted into facts.<\/p>\n\n\n\n

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

    Robust framing must answer two complementary questions: where are we?<\/strong> and what needs to be different?<\/strong>. The gap between these 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 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.<\/p>\n\n\n\n

    The desired future state, in turn, should not be described only 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 normally considers:<\/p>\n\n\n\n