Project Framing en Proyectos de Capital: cómo 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 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

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í:

1. identificar la necesidad, oportunidad o riesgo;
2. comprender la condición actual y el contexto;
3. formular el problema de manera 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 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

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

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:

1. aceptarla provisionalmente como premisa;
2. investigar antes de seleccionar una alternativa;
3. investigar antes del Business Case;
4. transferirla a una etapa posterior con un plan explícito;
5. tratarla como restricción;
6. 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:

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 desconocidos 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 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

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

¿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 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.

¿Project Framing necesita un workshop?

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.

¿Qué documentos deben resultar del framing?

Normalmente: 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 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