Project Framing en Proyectos de Capital: definir el problema antes de la solución

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 del 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 avanzar hacia estudios más profundos.

En términos prácticos, un buen Project Framing separa el problema de la 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 insuficiencia de capacidad, obsolescencia, indisponibilidad, crecimiento de demanda, no conformidad, riesgo operacional, 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 debe saber qué se está decidiendo, con base en qué evidencias y qué incertidumbres permanecen abiertas. Por ello, 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 inversión trabajen sobre el mismo problema.

Project Framing dentro del ciclo de un Capital Project

Un proyecto de capital comienza antes de que exista un diseño de ingeniería. Su origen puede ser una necesidad operacional, una expansión de capacidad, un requisito regulatorio, una oportunidad de reducción de costos, un cambio tecnológico, una obligación de continuidad, una necesidad de resiliencia o una 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. Antecede el detalle de la solución y se relaciona directamente con el Business Case en Proyectos de Ingeniería, porque el Business Case debe demostrar por qué una alternativa determinada 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í:

1. identificar la necesidad, oportunidad o riesgo;
2. comprender la condición actual y el contexto;
3. formular el problema de forma neutral respecto de la solución;
4. definir objetivos, resultados esperados y criterios de éxito;
5. registrar restricciones, premisas, dependencias e interfaces;
6. identificar stakeholders y autoridad decisoria;
7. mapear decisiones necesarias e información faltante;
8. abrir espacio para alternativas;
9. 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 porqué 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 consiste en evitar que una decisión de implementació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 la decisión previamente elegida.

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 instalación”	problema amplio	abre el diagnóstico, pero todavía 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 cambie la solución.

Esta disciplina es especialmente importante en brownfield. La organización suele conocer bien el problema operacional y, al mismo tiempo, arrastrar interpretaciones históricas sobre la 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 operacional. En estos casos, Due Diligence Técnica de Ingeniería y los levantamientos de campo ayudan a sustituir opinión por evidencia.

El framing debe contener 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 estas dos condiciones es la base para definir el problema.

La condición actual debe describirse con evidencias proporcionales a la decisión. En algunos casos, datos operacionales, 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 únicamente como una lista de entregables. “Tener una nueva sala eléctrica” es una entrega. “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 costo operacional;
• 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 esta cadena se pierde, el proyecto puede concluirse técnicamente y aun así no entregar el resultado que justificó el CAPEX.

Objetivos, outcomes y criterios de éxito

Los objetivos vagos producen proyectos vagos. Expresiones como “modernizar”, “mejorar”, “optimizar” o “aumentar la confiabilidad” deben convertirse en criterios que puedan orientar alternativas y posteriormente verificarse.

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 operacional sin aumentar la exposición a indisponibilidad
outcome esperado	¿qué debe cambiar en el negocio/operación?	aumentar 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 las entregas. Si el framing no puede explicar qué outcome debe habilitar el proyecto, la justificación tiende a depender únicamente de una lista de activos que se adquirirán.

La definición del éxito también reduce conflictos entre stakeholders. Operación puede priorizar disponibilidad; finanzas, límite de CAPEX; mantenimiento, estandarización y acceso; seguridad, mitigación de riesgos; TI, interoperabilidad; ingeniería, desempeño y vida útil. El framing hace explícitas estas prioridades para que los conflictos aparezcan antes de incorporarse al proyecto.

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 generan impactos transversales y, por ello, necesitan reunir perspectivas que normalmente aparecen en momentos diferentes del ciclo.

Los stakeholders relevantes pueden incluir sponsor, operación, mantenimiento, ingeniería, facilities, TI, seguridad, HSE, suministros, 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 modificar requisitos, imponer restricciones o recibir el activo sean consideradas suficientemente temprano.

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 un requisito determinado;
• 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 implementación.

La claridad de estos roles reduce un problema frecuente: que el proyecto sea desarrollado por ingeniería, aprobado por finanzas y recibido por operación 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 fijo.

Restricciones son condiciones que limitan las alternativas: área física, ventana de parada, legislación, capacidad de alimentación, fecha regulatoria, presupuesto máximo, interfaces existentes o imposibilidad de interrumpir una operación determinada.

Givens son decisiones o condiciones consideradas establecidas por la gobernanza en ese momento. Deben probarse, porque muchas veces representan decisiones históricas que perdieron vigencia.

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 las interfaces. El framing debe identificar dependencias que pueden controlar la viabilidad o el plazo incluso antes de existir 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 un 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.

A Gestión de Interfaces se vuelve crítica a medida que madura la solución, 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, faseado, modelo de implementación, plazo, nivel de redundancia, utilización de activos existentes o combinación entre intervención física y cambio operacional.

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

El registro de riesgos no debe comenzar únicamente cuando existe 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 área, interfaces, plazo, costo, operación, recursos internos y dependencias externas.

El artículo de 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:

1. aceptar provisionalmente como premisa;
2. investigar antes de seleccionar alternativa;
3. investigar antes del Business Case;
4. transferir a una etapa posterior con un plan explícito;
5. tratar como restricción;
6. escalar 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 forma 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 alterar el camino
decision roadmap	mostrar qué decisiones todavía deben tomarse y en qué secuencia
information gaps	transformar incógnitas relevantes en acciones de investigación

El valor de estos registros está en la consistencia entre ellos. 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 la 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, en el que 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 diferentes. 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 ser desarrollado?	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 la 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 implementació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 saltar el framing e intentar usar el FEED para descubrir qué problema debería haberse resuelto.

El FEL — Front-End Loading cumple una función complementaria: después de que la oportunidad está correctamente encuadrada, el FEL estructura la maduración progresiva de la solución, viabilidad, ingeniería y criterios para los gates siguientes.

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 de forma consistente:

• qué necesidad u oportunidad está siendo tratada;
• qué evidencias demuestran que existe;
• qué caracteriza el éxito;
• qué outcomes y beneficios se esperan;
• qué restricciones limitan las alternativas;
• qué premisas todavía 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 ser autorizada.

Si el equipo solo puede responder “¿qué solución queremos comprar?”, el framing todavía no cumplió 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 para el próximo 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 los inputs, la facilitación y las decisiones producidas.

Una estructura práctica puede conducirse en siete bloques:

1. Contexto y evidencias: presentar hechos, datos, decisiones anteriores y condición actual.
2. Problem statement: formular el problema sin incorporar una solución.
3. Success statement: describir el estado futuro y los criterios de éxito.
4. Stakeholders e interfaces: identificar quién define, decide, entrega y recibe.
5. Constraints, givens y assumptions: separar límites, decisiones establecidas e hipótesis.
6. Riesgos e information gaps: registrar incógnitas que cambian la decisión.
7. 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 el sesgo de confirmación y a documentar desacuerdos 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 operacionales informales pueden alterar 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 debe levantarse. Puede ser prematuro discutir la 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, estudio técnico preliminar, selección de alternativas, value for money y calidad del problema público que la contratación pretende resolver. La ingeniería consultiva 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 un estudio técnico preliminar y un Diseño Básico sin criterios suficientes para delimitar objeto, desempeño, plazo y riesgos.

La disciplina de framing ayuda a construir continuidad entre necesidad, levantamiento, alternativas, ingeniería, presupuesto, contratación, fiscalización y recepción.

Cómo contratar apoyo para Project Framing

Cuando el framing depende solo 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 para 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 debe partir del problema real y del nivel de evidencia necesario para la decisión. Según el contexto, el framing puede exigir únicamente facilitación y análisis documental o puede necesitar estar precedido por levantamiento, site survey y due diligence.

La lógica de trabajo es progresiva:

Assessment — comprender condición, documentos, riesgos, premisas y brechas; Advisory — estructurar objetivos, alternativas, criterios, interfaces y decisiones; Assurance — verificar si la evidencia disponible es suficiente para avanzar al próximo compromiso.

El servicio no debe anticipar conclusiones que pertenecen a etapas posteriores. El papel de la ingeniería consultiva 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 operacional 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 trasladar 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 es necesaria para avanzar.

La pregunta de cierre no es “¿qué solución vamos a ejecutar?”. Es: ¿el problema está definido de forma suficientemente clara para que las alternativas de ingeniería puedan evaluarse sin sesgo y para que la próxima 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. Genebra: ISO, 2020. Disponível em: https://www.iso.org/standard/74947.html

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

Preguntas frecuentes

¿Qué es Project Framing?

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.

¿Project Framing es igual a FEL?

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.

¿Cuál es la diferencia entre Project Framing y Business Case?

El framing define el problema y lo que caracteriza el éxito. El Business Case utiliza esta base para justificar si la inversión debe realizarse, comparando alternativas, beneficios, costos, riesgos y capacidad de entrega.

¿Project Framing necesita un workshop?

No necesariamente. El workshop es una forma eficiente de alinear stakeholders y hacer visibles las divergencias, pero el proceso puede combinar análisis documental, entrevistas, levantamientos y sesiones estructuradas según la complejidad del proyecto.

¿Qué documentos deben resultar del framing?

Típicamente: problem statement, current state, target state, criterios de éxito, stakeholders, restricciones, premisas, dependencias, riesgos iniciales, information gaps y decision roadmap.

¿Cuándo contratar apoyo especializado?

Cuando la decisión involucra 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 operacional
• 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 sobre Ingeniería Consultiva
• Guía de Gestión de Proyectos