{"id":80789,"date":"2026-09-17T10:59:27","date_gmt":"2026-09-17T13:59:27","guid":{"rendered":"https:\/\/a3aengenharia.com\/?post_type=articles&p=80789"},"modified":"2026-09-17T10:59:27","modified_gmt":"2026-09-17T13:59:27","slug":"project-framing-capital-projects-define-problem-before-solution","status":"publish","type":"articles","link":"https:\/\/a3aengenharia.com\/en-us\/content\/technical-articles\/project-framing-capital-projects-define-problem-before-solution\/","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 scope, 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, the 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 to advance to deeper studies.<\/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, productivity loss, or inability to meet a future requirement. Until this distinction 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 of the next decision. Before authorizing studies, reserving CAPEX, or involving suppliers, governance needs to know what is being decided, based on which evidence, 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 feasibility, FEL, Project Definition, and investment approval all work from 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 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 any engineering design exists. Its origin may be an operational need, a capacity expansion, a regulatory requirement, a cost-reduction opportunity, a technology change, a continuity obligation, a resilience need, or a 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 at the transition between recognizing a need and formally structuring the investment. It precedes solution detailing and connects directly with the Business Case in Engineering Projects<\/a>, because the Business Case must demonstrate why a particular alternative is an appropriate response to the problem\u2014and that demonstration becomes 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 manner;<\/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 committing significant resources, 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’s Project Set Up Toolkit uses a similar logic by separating the why<\/strong> of the project, what<\/strong> must be delivered, and how<\/strong> delivery capability will be structured. The usefulness of this distinction in private or public engineering is to avoid treating an implementation decision as if it were 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 evaluated only as variations of a decision that has effectively already been made.<\/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 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 study a generator, UPS, energy storage, supply redundancy, protection 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. Organizations usually know the operational pain well while also 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. That does not mean ignoring hypotheses. Hypotheses are useful as long as 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 now?<\/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 using evidence proportional to the decision. In some cases, operational data, availability indicators, incident records, and existing documentation are enough to start the reasoning. 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 30% load growth with defined selectivity, continuity, and growth margin\u201d describes a performance condition. The second formulation provides a much better 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