Project Framing estructura el problema, el valor esperado, las restricciones y las decisiones de un proyecto de capital antes de que la organización se comprometa prematuramente con una solución.
¡Descúbrelo!
Project Framing es el proceso estructurado utilizado para definir correctamente qué problema, necesidad u oportunidad justifica un proyecto, qué resultados deben alcanzarse y qué límites deben orientar el análisis antes de transformar una hipótesis en una solución de ingeniería. En proyectos de capital, esta etapa existe para evitar un error recurrente: comenzar por el equipo, la tecnología, la obra o el proveedor antes de que exista consenso sobre el problema que la inversión debe resolver.
El framing no es un anteproyecto, un FEED simplificado ni una reunión de brainstorming. Organiza la decisión inicial. El equipo busca establecer la situación actual, el estado futuro deseado, los stakeholders relevantes, los objetivos de negocio, los criterios de éxito, las restricciones, las premisas críticas, las dependencias y las decisiones que aún deben tomarse. El resultado es una referencia común para desarrollar alternativas, estructurar el Business Case y decidir si la oportunidad merece estudios más profundos.
En términos prácticos, un buen Project Framing separa problema de solución. “Necesitamos instalar una nueva subestación”, “necesitamos sustituir el VMS” o “necesitamos construir un nuevo Data Center” son formulaciones de solución. El problema puede ser capacidad insuficiente, obsolescencia, indisponibilidad, crecimiento de la demanda, incumplimiento, riesgo operativo, pérdida de productividad o incapacidad para atender un requisito futuro. Mientras esta diferencia no esté clara, la organización corre el riesgo de optimizar una solución que no resuelve la necesidad real.
El framing también delimita la calidad de la siguiente decisión. Antes de autorizar estudios, reservar CAPEX o involucrar proveedores, la gobernanza necesita saber qué se está decidiendo, con base en qué evidencias y qué incertidumbres permanecen abiertas. Por eso, Project Framing funciona como una etapa de reducción de ambigüedad: no elimina riesgos ni define todos los detalles, pero crea una base común para que viabilidad, FEL, Project Definition y aprobación de la inversión trabajen sobre el mismo problema.
Project Framing dentro del ciclo de un Capital Project
Cuando la organización aún no logra separar necesidad, condición existente y solución pretendida, existe un problema de definición antes de existir un problema de proyecto. Un Estudio de Viabilidad Técnica y Económica puede estructurar alternativas, restricciones y criterios antes de que el proyecto avance hacia una solución única.
Un proyecto de capital comienza antes de que exista un proyecto de ingeniería. Su origen puede ser una necesidad operativa, expansión de capacidad, requisito regulatorio, oportunidad de reducción de costos, cambio tecnológico, obligación de continuidad, necesidad de resiliencia o estrategia corporativa. El primer desafío es transformar ese estímulo en una definición suficientemente clara para orientar investigación y decisión.
Dentro del ciclo de Capital Projects & Infrastructure, el framing ocupa la transición entre la percepción de una necesidad y la estructuración formal de la inversión. Precede al detalle de la solución y se conecta directamente con el Business Case en Proyectos de Ingeniería, porque el Business Case debe demostrar por qué determinada alternativa representa una respuesta adecuada al problema — y esa demostración se debilita cuando el propio problema fue mal definido.
Una secuencia lógica puede representarse así:
- identificar la necesidad, oportunidad o riesgo;
- comprender la condición actual y el contexto;
- formular el problema de manera neutral respecto de la solución;
- definir objetivos, resultados esperados y criterios de éxito;
- registrar restricciones, premisas, dependencias e interfaces;
- identificar stakeholders y autoridad decisoria;
- mapear decisiones necesarias e información faltante;
- abrir espacio para alternativas;
- avanzar hacia viabilidad, concepción y definición del proyecto.
Esta secuencia no significa que todo proyecto requiera un workshop formal llamado “Project Framing”. El principio es más importante que la nomenclatura: antes de comprometer recursos significativos debe existir una formulación trazable del problema y una comprensión común de lo que sería una solución exitosa.
El Project Set Up Toolkit del gobierno británico trabaja con una lógica similar al separar el por qué del proyecto, el qué debe entregarse y el cómo se estructurará la capacidad de entrega. La utilidad de esta distinción en ingeniería privada o pública es evitar que una decisión de implantación sea tratada como si fuera la propia justificación de la inversión.
El error más común: transformar la solución en problema
La forma en que se redacta la oportunidad condiciona todo el razonamiento posterior. Si el enunciado inicial ya contiene la solución, las alternativas tienden a evaluarse únicamente como variaciones de una decisión elegida previamente.
Considere tres formulaciones:
| Formulación inicial | Naturaleza | Efecto sobre la decisión |
| “Instalar un nuevo generador de 500 kVA” | solución | restringe prematuramente capacidad, tecnología y estrategia |
| “Eliminar cortes de energía en la unidad” | problema amplio | abre el diagnóstico, pero aún necesita métricas y límites |
| “Garantizar alimentación de las cargas críticas durante 4 horas, con disponibilidad mínima definida y sin ampliar la demanda contratada” | necesidad estructurada | crea criterios para comparar alternativas |
En el tercer caso, la ingeniería puede estudiar generador, UPS, almacenamiento, redundancia de alimentación, selectividad, redistribución de cargas, generación local o combinaciones de soluciones. La necesidad permanece estable aunque la solución cambie.
Esta disciplina es especialmente importante en brownfield. La organización suele conocer bien el dolor operativo y, al mismo tiempo, cargar interpretaciones históricas sobre su causa. Un problema de indisponibilidad puede atribuirse a equipos obsoletos cuando la causa dominante está en protección, mantenimiento, capacidad, configuración, infraestructura de soporte o proceso operativo. En estos casos, la Due Diligence Técnica de Ingeniería y los levantamientos de campo ayudan a sustituir opinión por evidencia.
El framing debe utilizar un lenguaje suficientemente neutral para permitir investigación. Esto no significa ignorar hipótesis. Las hipótesis son útiles siempre que se registren como hipótesis y no se conviertan silenciosamente en hechos.
De la condición actual al estado futuro deseado
Un framing robusto debe responder dos preguntas complementarias: ¿dónde estamos? y ¿qué debe ser diferente?. La distancia entre ambas condiciones constituye la base para definir el problema.
La condición actual debe describirse con evidencias proporcionales a la decisión. En algunos casos, datos operativos, indicadores de disponibilidad, incidencias y documentación existente son suficientes para iniciar el análisis. En otros, especialmente cuando la inversión depende de infraestructura existente, puede ser necesario realizar inspecciones, levantamientos, mediciones o análisis documentales antes de concluir el framing.
El estado futuro deseado, a su vez, no debe describirse solamente como una lista de entregables. “Tener una nueva sala eléctrica” es un entregable. “Soportar una expansión del 30% de carga con selectividad, continuidad y margen de crecimiento definido” describe una condición de desempeño. La segunda formulación ofrece una base mucho mejor para requisitos y criterios de aceptación.
Una buena descripción del estado futuro normalmente considera:
- capacidad o desempeño esperado;
- disponibilidad y confiabilidad;
- seguridad y conformidad;
- restricciones de operación y mantenimiento;
- horizonte de vida útil o expansión;
- requisitos de continuidad;
- nivel de servicio o calidad;
- impactos sobre el costo operativo;
- criterios de sostenibilidad, cuando correspondan;
- fecha o ventana en que el resultado debe estar disponible.
Esta lógica ayuda a construir el “golden thread” de la inversión: necesidad → objetivo → requisito → solución → prueba → beneficio. Cuando este encadenamiento se pierde, el proyecto puede completarse técnicamente y aun así no entregar el resultado que justificó el CAPEX.
Objetivos, outcomes y criterios de éxito
Cuando la condición existente es incierta, las decisiones de inversión pueden estar siendo tomadas sobre una baseline incorrecta. La Due Diligence Técnica de Ingeniería combina documentación, inspección, condición, conformidad y riesgos para establecer una referencia técnica antes de definir el camino de inversión.
Objetivos vagos producen proyectos vagos. Expresiones como “modernizar”, “mejorar”, “optimizar” o “aumentar la confiabilidad” deben convertirse en criterios capaces de orientar alternativas y, posteriormente, ser verificados.
El framing no necesita transformar todos los objetivos en especificaciones detalladas, pero debe distinguir tres niveles:
| Nivel | Pregunta | Ejemplo |
| objetivo estratégico | ¿por qué invertir? | soportar expansión operativa sin aumentar la exposición a indisponibilidad |
| outcome esperado | ¿qué debe cambiar en el negocio/operación? | aumentar la capacidad disponible y reducir interrupciones no programadas |
| criterio de éxito | ¿cómo reconocer que funcionó? | margen de capacidad, disponibilidad y tiempo de recuperación dentro de los valores aprobados |
Esta estructura se conecta directamente con la Gestión de Beneficios en Proyectos y Programas. Un beneficio necesita owner, métrica, horizonte y relación causal con los entregables. Si el framing no logra explicar qué outcome debe habilitar el proyecto, la justificación tiende a depender únicamente de una lista de activos a adquirir.
La definición de éxito también reduce conflictos entre stakeholders. Operaciones puede priorizar disponibilidad; finanzas, límite de CAPEX; mantenimiento, estandarización y acceso; seguridad, mitigación de riesgos; TI, interoperabilidad; e ingeniería, desempeño y vida útil. El framing hace explícitas estas prioridades para que los conflictos aparezcan antes de incorporarse al diseño.
Stakeholders: quién define valor, quién entrega y quién recibe el activo
Project Framing no puede ser conducido únicamente por el área que identificó la necesidad. Los proyectos de capital crean impactos transversales y, por ello, necesitan reunir perspectivas que normalmente aparecen en momentos distintos del ciclo.
Los stakeholders relevantes pueden incluir sponsor, operación, mantenimiento, ingeniería, facilities, TI, seguridad, HSE, procurement, finanzas, jurídico, usuarios, gestión de activos, fiscalización, reguladores y, en determinados casos, socios externos. La composición depende del tipo de proyecto.
El objetivo no es ampliar indefinidamente el foro. Es garantizar que las funciones capaces de cambiar requisitos, imponer restricciones o recibir el activo sean consideradas con suficiente anticipación.
Una matriz simple puede distinguir:
- decision owner: quién posee autoridad para aprobar el avance;
- benefit owner: quién responde por la realización del resultado esperado;
- requirement owner: quién define o valida determinado requisito;
- asset/operations owner: quién recibirá el activo en operación;
- technical authority: quién protege criterios técnicos y estándares;
- delivery owner: quién conducirá el desarrollo y la implantación.
La claridad de estos roles reduce un problema frecuente: el proyecto es desarrollado por ingeniería, aprobado por finanzas y recibido por operaciones sin que ninguna de las partes haya tenido responsabilidad explícita por la continuidad entre necesidad, requisitos y beneficio.
Restricciones, givens y premisas: no son lo mismo
Una de las contribuciones más prácticas del framing es organizar lo que realmente es fijo y lo que solo parece serlo.
Restricciones son condiciones que limitan las alternativas: espacio físico, ventana de parada, legislación, capacidad de alimentación, fecha regulatoria, presupuesto máximo, interfaces existentes o imposibilidad de interrumpir determinada operación.
Givens son decisiones o condiciones consideradas establecidas por la gobernanza en ese momento. Deben comprobarse, porque con frecuencia representan decisiones históricas que perdieron validez.
Premisas son condiciones asumidas como verdaderas para permitir el análisis, aunque todavía dependan de confirmación. Necesitan owner, evidencia esperada y fecha de validación.
| Elemento | Tratamiento en el framing | Riesgo si se confunde |
| restricción | registrar origen e impacto | excluir alternativas viables o ignorar límites reales |
| given | confirmar autoridad y validez | perpetuar una decisión antigua sin fundamento actual |
| premisa | indicar incertidumbre y plan de validación | construir estimaciones y diseños sobre información no comprobada |
Esta distinción prepara el terreno para un futuro Assumptions Register y para la gestión de restricciones. También mejora la calidad de estimaciones y cronogramas porque permite separar información conocida de hipótesis.
Dependencias e interfaces que deben aparecer temprano
Un proyecto puede parecer simple cuando se analiza de forma aislada y volverse complejo por sus interfaces. El framing debe identificar dependencias capaces de controlar viabilidad o plazo incluso antes de que exista un diseño detallado.
Ejemplos incluyen:
- disponibilidad de energía, agua, telecomunicaciones o utilities;
- obras civiles asociadas;
- licencias y aprobaciones;
- ventanas de desconexión;
- integración con sistemas existentes;
- capacidad del equipo de operación;
- dependencia de proveedor específico;
- importación y long lead items;
- obras de terceros;
- migración de datos o sistemas;
- condicionantes de seguridad y acceso;
- cambios organizacionales necesarios para utilizar el activo.
La Gestión de Interfaces se vuelve crítica a medida que la solución madura, pero el framing ya debe identificar las interfaces capaces de modificar alternativas, plazo o costo.
Framing y alternativas: abrir el espacio de decisión antes de cerrar la solución
La finalidad del framing no es seleccionar la alternativa ganadora. Es crear las condiciones para que la comparación sea racional.
Una alternativa puede variar por tecnología, arquitectura, ubicación, capacidad, fases, modelo de implantación, plazo, nivel de redundancia, utilización de activos existentes o combinación entre intervención física y cambio operativo.
El framing debe evitar dos extremos. En el primero, el equipo parte directamente hacia una solución favorita. En el segundo, abre un universo tan amplio de posibilidades que el análisis pierde foco. La función de los objetivos y restricciones es crear un “solution space” controlado.
Después del framing, técnicas como Análisis Multicriterio (MCDA), matriz de decisión, costo-beneficio y estudios de viabilidad pueden comparar alternativas con criterios explícitos. Esto es muy diferente de solicitar tres propuestas a proveedores y tratar las propuestas recibidas como si fueran las únicas alternativas del problema.
Riesgos en el framing: identificar exposición antes de estimar precisión
Un riesgo identificado sin owner, acción o decisión continúa siendo solamente una preocupación documentada. La Gestión de Riesgos de Ingeniería conecta incertidumbres con responsables, tratamiento, contingencia, cronograma, presupuesto y riesgo residual.
El registro de riesgos no debe comenzar únicamente cuando existe un cronograma ejecutivo. Los riesgos de definición aparecen mucho antes y pueden controlar la calidad de la decisión de inversión.
En el framing, el análisis es predominantemente exploratorio. El equipo busca identificar incertidumbres capaces de modificar el problema, invalidar una alternativa o exigir investigación adicional. Los riesgos pueden involucrar demanda futura, condición existente, tecnología, licenciamiento, capacidad de integración, disponibilidad de espacio, interfaces, plazo, costo, operación, recursos internos y dependencias externas.
El artículo sobre Análisis de Riesgos en Proyectos de Ingeniería profundiza métodos cualitativos y cuantitativos. En el framing, la pregunta central es anterior: ¿qué incertidumbres son suficientemente relevantes para cambiar la forma en que debe estudiarse la oportunidad?
Una buena práctica es clasificar cada incertidumbre en una de las siguientes acciones:
- aceptarla provisionalmente como premisa;
- investigar antes de seleccionar una alternativa;
- investigar antes del Business Case;
- transferirla a una etapa posterior con un plan explícito;
- tratarla como restricción;
- escalarla para decisión de la gobernanza.
El evidence pack mínimo de un Project Framing
El framing debe producir evidencia suficiente para que otra persona pueda comprender el razonamiento sin depender de la memoria del workshop. El paquete no necesita ser voluminoso, pero debe ser trazable.
Un evidence pack puede incluir:
| Documento / registro | Función |
| problem statement | registrar el problema de manera neutral respecto de la solución |
| opportunity statement | explicar la oportunidad y su valor potencial |
| current state | consolidar hechos y baseline conocidos |
| target state / success statement | definir la condición futura deseada |
| objectives and success criteria | traducir valor en criterios de decisión |
| stakeholder map | identificar funciones que influyen, deciden o reciben el activo |
| constraints and assumptions | separar límites reales de hipótesis |
| dependencies and interfaces | revelar factores externos que controlan la decisión |
| initial risk register | registrar incertidumbres capaces de cambiar el camino |
| decision roadmap | mostrar qué decisiones aún deben tomarse y en qué secuencia |
| information gaps | transformar desconocidos relevantes en acciones de investigación |
El valor de estos registros está en su consistencia. Un target state que exige alta disponibilidad debe aparecer después en requisitos, arquitectura, estimación, pruebas y operación. Un riesgo crítico identificado en el framing no puede desaparecer simplemente porque el proyecto entró en FEED.
Decision roadmap: el framing debe producir decisiones, no solo información
Uno de los mejores resultados de un framing es un mapa de decisiones. Los proyectos complejos rara vez necesitan una única aprobación; necesitan una secuencia de decisiones en la que cada una depende de información y madurez diferentes.
El decision roadmap puede indicar, por ejemplo:
- confirmar la necesidad;
- validar datos de la condición existente;
- aprobar criterios de alternativas;
- seleccionar la alternativa preferida;
- aprobar el Business Case preliminar;
- autorizar FEL/FEED;
- definir estrategia de contratación;
- concluir Project Readiness;
- realizar sanction/FID.
Esto evita que la organización intente resolver todo en una única reunión de aprobación. También se conecta con el Stage-Gate en proyectos de ingeniería, donde cada gate necesita criterios, evidencias, autoridad y resultados posibles.
Project Framing vs. Opportunity Framing vs. Business Case vs. FEL
Los términos se superponen en algunas metodologías, pero tienen responsabilidades semánticas distintas. El mejor criterio es observar la decisión que cada actividad debe soportar.
| Elemento | Pregunta central | Resultado esperado |
| Project/Opportunity Framing | ¿qué problema u oportunidad merece desarrollarse? | problema, éxito, restricciones, stakeholders, decisiones y gaps |
| Business Case | ¿vale la pena invertir y por qué? | justificación estratégica, económica, financiera y de entrega |
| Viabilidad | ¿qué alternativas son viables y cuál presenta mejor relación entre beneficios, costos y riesgos? | recomendación fundamentada y condicionantes |
| FEL / Front-End Planning | ¿el proyecto está suficientemente definido para avanzar? | madurez progresiva de alcance, ingeniería, costos, riesgos y ejecución |
| FEED | ¿la solución seleccionada está técnicamente definida para estimar, contratar y preparar la implantación? | paquete de ingeniería y definición técnica |
Esta frontera evita dos problemas. El primero es exigir que el framing tenga el nivel de detalle de un FEED. El segundo es omitir el framing e intentar usar el FEED para descubrir qué problema debería haberse resuelto.
El FEL — Front-End Loading posee una función complementaria: una vez que la oportunidad está correctamente encuadrada, el FEL estructura la maduración progresiva de la solución, viabilidad, ingeniería y criterios para los siguientes gates.
Cómo saber si el framing está suficientemente maduro
Madurez no significa ausencia de incertidumbre. Significa que la incertidumbre remanente es conocida, clasificada y compatible con la siguiente decisión.
Un framing está suficientemente maduro cuando la gobernanza puede responder consistentemente:
- qué necesidad u oportunidad se está tratando;
- qué evidencias demuestran que existe;
- qué caracteriza el éxito;
- qué outcomes y beneficios se esperan;
- qué restricciones limitan las alternativas;
- qué premisas aún deben validarse;
- qué stakeholders poseen autoridad o requisitos críticos;
- qué dependencias pueden controlar plazo o viabilidad;
- qué riesgos pueden invalidar la oportunidad;
- qué información falta;
- qué decisiones se tomarán a continuación;
- qué etapa de ingeniería o análisis debe autorizarse.
Si el equipo solo puede responder “¿qué solución queremos comprar?”, el framing todavía no ha cumplido su función.
La lógica es compatible con Project Readiness en Ingeniería: estar listo no significa estar completo, sino disponer de evidencias y condiciones adecuadas al siguiente compromiso.
Cómo conducir un workshop de Project Framing
Los workshops son útiles porque hacen visibles las divergencias. Sin embargo, el valor no está en la dinámica en sí, sino en la calidad de las entradas, de la facilitación y de las decisiones producidas.
Una estructura práctica puede conducirse en siete bloques:
- Contexto y evidencias: presentar hechos, datos, decisiones anteriores y condición actual.
- Problem statement: formular el problema sin incorporar una solución.
- Success statement: describir el estado futuro y los criterios de éxito.
- Stakeholders e interfaces: identificar quién define, decide, entrega y recibe.
- Constraints, givens y assumptions: separar límites, decisiones establecidas e hipótesis.
- Riesgos e information gaps: registrar desconocidos que cambian la decisión.
- Decision roadmap: definir decisiones, owners, evidencias necesarias y próximos pasos.
En proyectos críticos, la facilitación independiente puede ser útil cuando existen soluciones favoritas, conflictos entre áreas o fuerte presión por aprobación. La independencia no sustituye la autoridad del sponsor; ayuda a reducir sesgo de confirmación y a documentar disensos antes de que se conviertan en cambios costosos.
Framing en proyectos brownfield
Los proyectos brownfield exigen cuidado adicional porque la baseline física puede ser menos confiable que la percepción de los stakeholders. As-Built desactualizado, instalaciones modificadas a lo largo de los años, capacidad residual desconocida y dependencias operativas informales pueden cambiar completamente la viabilidad de una alternativa.
En estos casos, el framing debe distinguir explícitamente lo que sabemos, lo que creemos saber y lo que necesita levantarse. Puede ser prematuro discutir una solución antes de ejecutar site survey, levantamiento cadastral o due diligence.
Este enfoque reduce el riesgo de producir un diseño técnicamente correcto para una condición que ya no existe.
Framing en proyectos públicos
En el sector público, el framing tiene una fuerte relación con la definición de la necesidad, planificación, estudios técnicos preliminares, selección de alternativas, value for money y calidad del problema público que la contratación pretende resolver. La consultoría de ingeniería no sustituye las competencias legales de la Administración, pero puede mejorar la base técnica sobre la que se instruyen las decisiones.
Un enunciado excesivamente orientado a la solución puede restringir alternativas antes del análisis de viabilidad. Por otro lado, una necesidad demasiado genérica puede producir estudios preliminares y Proyecto Básico sin criterios suficientes para delimitar objeto, desempeño, plazo y riesgos.
La disciplina de framing ayuda a construir continuidad entre necesidad, levantamientos, alternativas, ingeniería, presupuesto, contratación, fiscalización y recepción.
Cómo contratar apoyo para Project Framing
Project Framing no debe terminar en una presentación atractiva; debe terminar en una base utilizable para decidir y desarrollar el proyecto. FEL — Front-End Loading estructura la etapa siguiente cuando la organización necesita evolucionar alternativas, ingeniería, estimaciones, riesgos y madurez antes del compromiso de capital.
Cuando el framing depende únicamente de reuniones internas informales, existe riesgo de registrar percepciones sin investigar datos, conflictos y restricciones. La contratación de apoyo especializado tiene sentido cuando la decisión posee impacto material, existen múltiples disciplinas o stakeholders, la condición existente es incierta, hay alternativas tecnológicas relevantes o la inversión debe pasar por gates formales.
El alcance contratado debe dejar claro que la finalidad no es simplemente “realizar un workshop”. El objeto debe estar orientado a producir una base de decisión. Entre los entregables posibles están problem statement, target state, mapa de stakeholders, registro de premisas y restricciones, criterios de éxito, matriz inicial de riesgos, information gaps, alternativas a investigar y decision roadmap.
Es recomendable especificar:
- documentos de entrada y baseline disponible;
- stakeholders obligatorios;
- actividades de preparación y análisis previo;
- necesidad de levantamientos o visitas;
- método de facilitación;
- forma de registro de divergencias;
- criterios para considerar el framing concluido;
- responsabilidades por validar premisas;
- interfaz con Business Case, viabilidad y FEL;
- formato de aprobación del paquete final.
Cómo A3A Engenharia aborda la definición inicial del proyecto
La actuación de A3A Engenharia debe partir del problema real y del nivel de evidencia necesario para la decisión. Dependiendo del contexto, el framing puede requerir solamente facilitación y análisis documental o puede necesitar ser precedido por levantamiento, site survey y due diligence.
La lógica de trabajo es progresiva:
Assessment — comprender condición, documentos, riesgos, premisas y gaps; Advisory — estructurar objetivos, alternativas, criterios, interfaces y decisiones; Assurance — verificar si la evidencia disponible es suficiente para avanzar al siguiente compromiso.
El servicio no debe anticipar conclusiones que pertenecen a etapas posteriores. El papel de la consultoría de ingeniería es transformar una necesidad todavía difusa en una cuestión técnicamente investigable, con decisiones y responsabilidades claras.
Esto también significa saber detenerse. Si el framing revela que la oportunidad no posee alineación estratégica, que los beneficios no justifican el esfuerzo o que existe una alternativa operativa de menor costo, la recomendación técnica puede ser no avanzar hacia un proyecto de capital en ese momento.
Conclusión técnica
Project Framing es una disciplina de decisión, no de diseño. Su valor está en organizar la oportunidad antes de que la inversión quede condicionada por una solución elegida demasiado pronto. Cuando problema, objetivos, restricciones, stakeholders, riesgos y decisiones se hacen explícitos, la ingeniería puede comparar alternativas con mayor calidad y el Business Case pasa a responder a una necesidad real, en lugar de justificar retrospectivamente una preferencia.
En Capital Projects, esta etapa reduce el riesgo de llevar ambigüedad a FEL, FEED, procurement y ejecución. El costo de descubrir tarde que el problema estaba mal formulado es muy superior al costo de invertir temprano en definición. Por ello, el framing debe producir una base trazable: qué sabemos, qué asumimos, qué necesitamos descubrir, quién decide y qué evidencia se necesita para avanzar.
La pregunta de cierre no es “¿qué solución vamos a ejecutar?”. Es: ¿el problema está definido con suficiente claridad para que las alternativas de ingeniería puedan evaluarse sin sesgo y para que la siguiente decisión de inversión se tome sobre evidencias?
Referencias técnicas
[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 21502:2020 — Project, programme and portfolio management — Guidance on project management. Ginebra: ISO, 2020. Disponible en: https://www.iso.org/standard/74947.html
[2] INFRASTRUCTURE AND PROJECTS AUTHORITY. Overview of the Project Set Up Toolkit. Londres: UK Government, 2022. Disponible en: 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. Disponible en: https://www.pmi.org/standards/pmbok
Preguntas frecuentes
Project Framing es el proceso de estructurar el problema, la oportunidad, los objetivos, las restricciones, los stakeholders, las premisas, los riesgos y las decisiones de un proyecto antes de seleccionar y detallar la solución de ingeniería.
No. El framing encuadra el problema y establece la base de decisión. FEL desarrolla progresivamente alternativas, viabilidad, definición técnica, estimaciones, riesgos y madurez del proyecto antes de compromisos mayores de capital.
El framing define el problema y qué caracteriza el éxito. El Business Case utiliza esa base para justificar si la inversión debe realizarse, comparando alternativas, beneficios, costos, riesgos y capacidad de entrega.
No necesariamente. El workshop es una forma eficiente de alinear stakeholders y hacer visibles divergencias, pero el proceso puede combinar análisis documental, entrevistas, levantamientos y sesiones estructuradas según la complejidad del proyecto.
Normalmente: problem statement, current state, target state, criterios de éxito, stakeholders, restricciones, premisas, dependencias, riesgos iniciales, information gaps y decision roadmap.
Cuando la decisión implica CAPEX relevante, múltiples disciplinas, condición existente incierta, conflictos entre stakeholders, alternativas tecnológicas relevantes o necesidad de evidencia formal para gates y aprobación de inversión.
Materiales técnicos complementarios
Servicios relacionados
- Estudio de Viabilidad Técnica y Económica
- Due Diligence Técnica de Ingeniería
- FEL — Front-End Loading
- Gestión de Riesgos de Ingeniería
Contenidos principales sobre el tema
- Capital Projects & Infrastructure — HUB
- Capital Project Lifecycle: de la oportunidad al activo operativo
- Business Case en Proyectos de Ingeniería
- Gestión de CAPEX en Proyectos de Ingeniería
- Stage-Gate en Proyectos de Ingeniería
- Project Readiness en Ingeniería
Contenidos técnicos relacionados
- Estudio de Viabilidad en Ingeniería
- Análisis Multicriterio en Proyectos de Ingeniería
- Análisis de Riesgos en Proyectos de Ingeniería
- Gestión de Beneficios en Proyectos y Programas
- PDRI — Project Definition Rating Index
- FEED en Ingeniería
- Guía Completa de Consultoría de Ingeniería
- Guía de Gestión de Proyectos
