Conozca cómo estructurar un Business Case en proyectos de ingeniería, conectando necesidad, alternativas, CAPEX, OPEX, beneficios, riesgos, viabilidad y gobernanza de la decisión.
¡Descúbrelo!
Un Business Case es la justificación documentada utilizada para respaldar la decisión de comprometer recursos con un proyecto, continuar invirtiendo en él o interrumpirlo cuando la justificación deja de existir. En proyectos de ingeniería, conecta una necesidad real de la organización con objetivos, alternativas, beneficios, costos, riesgos, viabilidad, capacidad de entrega y criterios de decisión.
El Business Case no es solamente una hoja de cálculo financiera, un presupuesto o una presentación para aprobación de CAPEX. Su función es demostrar, con evidencias proporcionales al porte y al riesgo del proyecto, por qué la organización debería actuar, qué alternativa debe llevarse adelante, qué valor se espera crear, qué condiciones deben ser verdaderas y qué riesgos pueden cambiar la recomendación.
Tampoco necesita nacer completo. En proyectos complejos, la justificación madura junto con la ingeniería. Una versión preliminar puede sustentar la autorización de estudios; versiones posteriores pueden incorporar una mejor definición del alcance, estimaciones, riesgos, estrategia de contratación y resultados del mercado antes de nuevos gates de inversión.
Por lo tanto, un Business Case técnicamente útil no intenta demostrar que una idea previamente elegida es buena. Estructura la decisión para que las alternativas puedan compararse y para que la organización pueda concluir, incluso, que no invertir, postergar, redimensionar o estudiar mejor es la decisión más racional en ese momento.
Qué debe demostrar un Business Case
La ABNT NBR ISO 21502:2021 define business case como una justificación documentada que respalda una decisión sobre el compromiso con un proyecto, programa o portafolio. Para proyectos, la norma posiciona el Business Case como base de gobernanza y recomienda que justifique tanto la realización como la continuidad del proyecto.
En la práctica, la decisión debe considerar varias dimensiones al mismo tiempo. Entre ellas se encuentran objetivos, alineación estratégica, beneficios potenciales, métricas de valor, riesgo aceptable, requisitos de presupuesto, cronograma y calidad, recursos, competencias, alcance, escenarios y capacidad de sostener el cambio generado por el proyecto.
Esto significa que un Business Case robusto debe responder, como mínimo, preguntas como:
- qué necesidad, oportunidad, obligación o riesgo originó la propuesta;
- qué ocurre si la organización no actúa;
- qué resultados y beneficios se esperan;
- qué alternativas fueron consideradas;
- por qué algunas alternativas fueron descartadas;
- qué alternativa se recomienda y bajo qué premisas;
- cuánto capital y recursos son necesarios;
- qué costos de operación y ciclo de vida se esperan;
- qué riesgos e incertidumbres pueden cambiar la decisión;
- cómo se entregará, contratará y gobernará la solución;
- qué criterios se utilizarán para revisar la continuidad de la inversión.
La Gestión de CAPEX en Proyectos de Ingeniería aborda el ciclo de autorización, definición, control y protección de la inversión. El Business Case está antes y alrededor de esa gobernanza: explica por qué el capital debería comprometerse y cuándo esa justificación necesita ser revisada.
Business Case no es sinónimo de Estudio de Viabilidad
Cuando la necesidad todavía no se ha convertido en alternativas técnicamente comparables, aprobar CAPEX demasiado pronto transfiere incertidumbre al diseño, la contratación y la implantación. El Business Case necesita crecer sobre una base real de viabilidad.
Ambos instrumentos pueden superponerse en datos y análisis, pero tienen responsabilidades diferentes. El Estudio de Viabilidad busca determinar si una solución o proyecto es técnica, operativa y, cuando corresponde, económicamente viable. El Business Case utiliza esa evidencia — junto con estrategia, beneficios, alternativas, riesgo, capacidad de entrega y gobernanza — para respaldar una decisión organizacional.
En términos simples:
| Instrumento | Pregunta predominante |
| Estudio de Viabilidad | ¿La alternativa puede implantarse y tiene sentido según los criterios evaluados? |
| Business Case | ¿Debemos comprometer recursos con esta alternativa ahora y bajo qué condiciones? |
Un Business Case puede referenciar un Estudio de Viabilidad Técnica y Económica sin reproducir todo el estudio. Esta separación mejora la trazabilidad: la ingeniería produce evidencias técnicas detalladas; la gobernanza utiliza esas evidencias en la decisión.
Business Case tampoco es Project Charter
El Project Charter formaliza la existencia del proyecto, establece autoridad y registra elementos iniciales de objetivo, alcance y gobernanza. El Business Case responde a la justificación que sustenta esa autorización.
En muchas organizaciones, el Business Case existe antes de que el proyecto se inicie formalmente. Después de la decisión de continuar, el Project Charter transforma la decisión en un mandato de proyecto, de acuerdo con la gobernanza adoptada.
Confundir los documentos crea un problema recurrente: el proyecto se autoriza mediante un charter que dice qué se hará, pero la organización pierde la memoria de por qué eligió aquella alternativa y qué premisas justificaban la inversión.
Business Case y ETP brasileño tienen contextos diferentes
En la contratación pública brasileña, el Estudio Técnico Preliminar (ETP) posee una función definida por la Ley 14.133/2021 y la reglamentación aplicable: caracteriza la necesidad, analiza soluciones y fundamenta la contratación. El concepto de Business Case es más amplio y no debe utilizarse para sustituir automáticamente documentos legalmente exigidos.
El ETP para Obras y Servicios de Ingeniería puede compartir elementos como necesidad, alternativas, viabilidad, costos y riesgos, pero la arquitectura documental debe respetar el régimen jurídico aplicable y la gobernanza específica de la organización.
En empresas privadas, proyectos industriales o programas corporativos de CAPEX, el Business Case puede adoptar formatos propios. El nombre del documento es menos importante que su función decisoria y la trazabilidad de la justificación.
La decisión comienza por la necesidad, no por la solución
Uno de los mayores sesgos aparece cuando el Business Case comienza con la frase “comprar el equipo X” o “implantar la tecnología Y”. Esto transforma una necesidad en solución antes de que las alternativas hayan sido evaluadas.
La formulación inicial debería describir el problema u oportunidad de forma independiente de la solución. Por ejemplo:
- capacidad eléctrica insuficiente para la expansión prevista;
- obsolescencia que aumenta el riesgo de indisponibilidad;
- requisito regulatorio todavía no atendido;
- cuello de botella que limita producción o calidad;
- riesgo patrimonial sin control adecuado;
- costo operativo creciente;
- necesidad de ampliar resiliencia o continuidad.
Esta formulación abre espacio para diferentes respuestas. La solución puede involucrar expansión, retrofit, cambio operativo, redundancia, tercerización, sustitución tecnológica, mantenimiento estructurado o incluso la decisión de no intervenir en ese momento.
El caso base muestra qué ocurre si nada cambia
Las alternativas solo pueden compararse contra una referencia. El caso base — también llamado baseline o business as usual en algunos métodos — describe la trayectoria plausible sin la intervención propuesta.
Puede incluir costos de mantenimiento, fallas, restricción de capacidad, pérdidas, riesgo creciente, obligación futura, necesidad de reposición u otras consecuencias documentadas. El caso base no puede degradarse artificialmente para hacer que la solución parezca mejor.
En proyectos de activos existentes, una Due Diligence Técnica, un levantamiento cadastral o un diagnóstico puede ser necesario antes de estimar correctamente esta referencia. Sin conocer la condición existente, la organización corre el riesgo de comparar la alternativa propuesta con una situación ficticia.
Los objetivos deben ser verificables
Expresiones como “modernizar infraestructura”, “mejorar seguridad” o “aumentar eficiencia” ayudan a expresar dirección, pero son insuficientes para decidir. El Business Case necesita convertir la intención en resultados observables.
Un objetivo puede establecer capacidad, disponibilidad, plazo, reducción de exposición, desempeño, conformidad u otro resultado mensurable. La definición debe evitar transformar el indicador en el propio objetivo. “Implantar 100 cámaras”, por ejemplo, es un entregable; “reducir áreas sin cobertura conforme a un criterio técnico definido” es un resultado más próximo a la necesidad.
La Gestión de Beneficios en Proyectos y Programas profundiza la diferencia entre output, outcome y beneficio, esencial para evitar Business Cases que confundan entrega concluida con valor realizado.
Los beneficios necesitan owner, baseline y condiciones de realización
Un beneficio redactado de forma genérica es difícil de gobernar. Para cada beneficio material, el Business Case debería registrar quién responde por su realización, cuál es la baseline, qué cambio se espera, cuándo puede ocurrir y qué entregables o cambios operativos son necesarios.
Esto evita atribuir al proyecto un beneficio que depende principalmente de factores externos. Una nueva infraestructura puede habilitar un aumento de producción, pero el beneficio económico también puede depender de demanda, materia prima, personas, proceso y operación.
Esta cadena causal debe explicitarse. De lo contrario, el modelo financiero transforma posibilidades en ingresos ciertos y crea una justificación excesivamente optimista.
Las alternativas deben ser realmente diferentes
Comparar tres versiones de la misma solución no es lo mismo que explorar alternativas. Una decisión madura puede considerar diferencias de arquitectura, tecnología, fases, capacidad, régimen de contratación, make-or-buy, retrofit versus sustitución, implantación integral versus modular y, cuando corresponda, la alternativa de no hacer o postergar.
El Set-Based Design en Ingeniería muestra cómo mantener alternativas viables en paralelo mientras se producen evidencias, evitando una convergencia prematura.
Una longlist inicial puede filtrarse mediante criterios eliminatorios. Después, las alternativas técnicamente viables avanzan a una comparación detallada de desempeño, riesgo, costo y valor.
La alternativa “no hacer ahora” también aporta información
No actuar puede ser inviable por exigencia legal, seguridad o riesgo operativo, pero la hipótesis debe examinarse cuando corresponda. Incluso en proyectos obligatorios, el caso base ayuda a responder el costo y el riesgo de postergar la intervención y permite comparar distintas formas de cumplir la obligación.
El Green Book 2026 utiliza business as usual como referencia obligatoria en su metodología de appraisal público. Esa regla específica no es automáticamente aplicable a empresas brasileñas, pero el principio analítico es útil: una alternativa debe compararse con la consecuencia plausible de no adoptarla.
La viabilidad técnica viene antes de la optimización financiera
Una alternativa que no cumple requisitos esenciales no se vuelve aceptable porque tenga mayor TIR o menor Payback. La evaluación técnica debe establecer límites, desempeño, interfaces, capacidad, condiciones de implantación, normas aplicables, constructibilidad, operación y mantenimiento.
La Gestión de Requisitos en Ingeniería ayuda a transformar necesidades en requisitos verificables. El Business Case puede entonces comparar únicamente alternativas capaces de cumplir aquello que realmente se necesita.
Este orden evita un problema clásico: elegir la solución financieramente más atractiva para después descubrir que no cumple una condición técnica que debería haber sido eliminatoria.
CAPEX, OPEX y costo del ciclo de vida deben aparecer juntos
El menor CAPEX no representa necesariamente la alternativa de mayor valor. Costos de operación, mantenimiento, reinversiones, vida útil y beneficios deben permanecer visibles durante la comparación.
La menor inversión inicial puede transferir costo a energía, mantenimiento, licenciamiento, mano de obra, indisponibilidad o sustituciones futuras. Por ello, el Business Case no debe tratar CAPEX como la única medida económica de una alternativa.
El TCO y Costo del Ciclo de Vida en Ingeniería organiza los gastos a lo largo de la vida útil y ayuda a exponer costos ocultos en la adquisición. La Ingeniería de Valor complementa este análisis al relacionar funciones, desempeño y costo.
La decisión debe explicar por qué el perfil económico elegido es compatible con la estrategia del activo y con su vida esperada.
VAN, TIR, Payback y ROI forman parte de la justificación financiera
Cuando el proyecto produce flujos financieros cuantificables, los indicadores económicos ayudan a comparar alternativas. El VAN, TIR, Payback y ROI en Proyectos de Ingeniería explica las diferencias entre creación de valor presente, tasa de retorno, tiempo de recuperación y razón simple de retorno.
Estos números deben derivar de la misma base de flujos y utilizar premisas documentadas. Un Business Case no debería presentar solamente “TIR 18%” o “Payback 3 años” sin memoria de CAPEX, OPEX, horizonte, beneficios, tasa y riesgos.
Los proyectos obligatorios o con beneficios predominantemente no monetarios pueden no presentar un retorno financiero positivo. En estos casos, el análisis económico puede comparar alternativas para atender el requisito, en lugar de inventar ingresos para justificar la intervención.
El DCF hace explícito el tiempo
Los costos y beneficios que ocurren en momentos diferentes no son directamente comparables. El Flujo de Caja Descontado en Proyectos de Ingeniería estructura los flujos por período y los lleva a valor presente mediante una tasa coherente con la metodología de evaluación adoptada.
En el Business Case, la tasa debe tener fuente y gobernanza definidas. En un entorno corporativo, TMA, costo de capital, criterios tributarios u otros parámetros financieros pueden pertenecer al área financiera. La ingeniería aporta calidad a las entradas técnicas; no debe inventar silenciosamente parámetros corporativos que no recibió.
El riesgo debe cambiar la forma de ver la alternativa
Un registro de riesgos adjunto al Business Case no es suficiente si los riesgos no modifican el análisis. Retraso, incertidumbre de CAPEX, disponibilidad de tecnología, dependencia de proveedor, integración, demanda, licenciamiento, desempeño y capacidad de implantación pueden cambiar costo, plazo, beneficio e incluso viabilidad.
La Gestión de Riesgos en Proyectos de Ingeniería proporciona la estructura de identificación, evaluación, respuesta y control. Cuando interactúan variables cuantitativas, la Simulación de Monte Carlo puede complementar escenarios deterministas.
El objetivo es mostrar a la gobernanza no solo el resultado esperado, sino también qué puede hacer que ese resultado deje de ser verdadero.
Las premisas y restricciones deben permanecer visibles
Toda decisión de inversión se construye sobre hipótesis. Crecimiento de demanda, precio de energía, vida útil, tasa de utilización, plazo de contratación, disponibilidad de área, capacidad de conexión, productividad y estabilidad regulatoria son ejemplos de premisas que pueden ser materiales.
La diferencia entre premisa y hecho debe permanecer clara. Una práctica útil es registrar:
| Campo | Ejemplo de control |
| Premisa | tarifa media utilizada en el modelo |
| Fuente | contrato, histórico o proyección aprobada |
| Responsable | área que suministró o aprobó el dato |
| Fecha base | referencia temporal |
| Sensibilidad | impacto si la premisa varía |
| Estado | confirmada, provisional o pendiente |
Las premisas críticas pendientes pueden convertirse en acciones de ingeniería antes del siguiente gate.
El Business Case debe registrar por qué se rechazaron alternativas
La ABNT NBR ISO 21502:2021 recomienda evaluar opciones alternativas y presentar las razones de rechazo. Este registro es valioso porque preserva la memoria de la decisión.
Sin él, una alternativa descartada puede reaparecer meses después sin que nadie sepa qué requisito falló, qué costo volvió inviable la solución o qué riesgo fue considerado. La trazabilidad también protege contra decisiones retrospectivas basadas únicamente en el resultado final.
La justificación no necesita el mismo nivel de detalle para todas las opciones. Las alternativas eliminadas por criterio objetivo pueden tener un registro conciso; las finalistas exigen un análisis comparable y más profundo.
La gobernanza define quién recomienda y quién decide
El equipo técnico puede estructurar alternativas y recomendar una solución, pero la decisión de inversión pertenece a la autoridad definida por la organización. Sponsor, comité de inversiones, dirección, consejo, portfolio board u otra instancia puede poseer la autoridad final.
La Gobernanza de Decisiones con Niveles de Autoridad, Comités y Stage-Gates ayuda a separar análisis, recomendación, aprobación y escalamiento.
Esta distinción debe aparecer en el Business Case para evitar que un parecer técnico sea tratado como autorización de capital o que una aprobación ejecutiva se confunda con la validación técnica de la solución.
El sponsor debe preservar la justificación a lo largo del proyecto
La ABNT NBR ISO 21502 atribuye al sponsor la promoción del Business Case y la responsabilidad de validar si el proyecto continúa justificado durante el ciclo de vida. Esto cambia la forma de ver el documento: no es solamente un formulario completado antes de la aprobación.
Cambios significativos de alcance, costo, plazo, contexto o beneficios pueden exigir revisión. Si la necesidad desaparece, la alternativa deja de ser viable o la inversión crece mucho más allá del caso aprobado, la gobernanza debe reevaluar si continuar todavía tiene sentido.
Los gates transforman la justificación en proceso
La justificación progresiva funciona mejor cuando está vinculada a puntos explícitos de decisión. El Stage-Gate en Proyectos de Ingeniería estructura criterios para autorizar la siguiente fase conforme el proyecto madura.
Un flujo posible es:
En fases iniciales, el gate puede autorizar únicamente el siguiente estudio. Más adelante, puede autorizar proyecto básico, FEED, contratación o implantación. La decisión y el capital comprometido crecen junto con la calidad de las evidencias.
FEL es un entorno natural para madurar el Business Case
El FEL — Front-End Loading organiza la maduración de proyectos antes del compromiso significativo de capital. Necesidad, alternativas, definición técnica, estimaciones, riesgos, cronograma y estrategia de ejecución pueden evolucionar de manera integrada.
El Business Case acompaña esta maduración. Una justificación preliminar puede sustentar FEL 1; versiones posteriores incorporan evidencias más robustas para gates posteriores. El objetivo no es producir un documento perfecto demasiado pronto, sino aumentar la confiabilidad antes de que las decisiones se vuelvan costosas o irreversibles.
El Business Case debe dialogar con la estrategia de contratación
Una alternativa puede ser técnicamente buena y financieramente atractiva, pero difícil de contratar en el mercado, dependiente de un proveedor único, incompatible con los plazos o excesivamente compleja para la capacidad de gestión de la organización.
La estrategia comercial y contractual debe considerarse antes de la autorización final. Empaquetamiento, EPC, EPCM, contratación por lotes, compra directa de equipos críticos u otros modelos pueden modificar riesgo, plazo, CAPEX y responsabilidades.
Esta dimensión no significa elegir el proveedor dentro del Business Case. Significa verificar si existe un camino viable para transformar la alternativa elegida en contratación y entrega.
La capacidad organizacional también forma parte de la viabilidad
Los proyectos fallan incluso cuando la tecnología funciona. Falta de equipo para operar el activo, ausencia de competencias para fiscalizar el contrato, incapacidad de mantener sistemas, baja madurez de gestión o dependencia excesiva de terceros pueden comprometer el beneficio.
El análisis debe preguntar:
- quién será el owner del activo y de los beneficios;
- qué competencias serán necesarias;
- cómo la operación recibirá la solución;
- qué recursos internos serán necesarios;
- qué apoyo externo se requiere;
- cómo se implantarán los cambios organizacionales;
- si existe capacidad para gestionar la contratación y el proyecto.
Esta lectura amplía la viabilidad más allá de “es técnicamente posible construir”.
Cómo estructurar un Business Case en proyectos de ingeniería
No existe un único template universal, pero una estructura funcional puede organizar la decisión en bloques coherentes:
- Resumen ejecutivo: decisión requerida, alternativa recomendada, inversión, beneficios, riesgos y principales condicionantes.
- Necesidad y caso para el cambio: problema, oportunidad, obligación o riesgo que originó la propuesta.
- Objetivos y criterios de éxito: resultados verificables y alineación estratégica.
- Caso base: consecuencia plausible de no actuar.
- Alternativas: longlist, criterios de selección y shortlist.
- Evaluación técnica: requisitos, interfaces, condiciones de implantación y viabilidad.
- Evaluación económica: CAPEX, OPEX, ciclo de vida, DCF e indicadores cuando correspondan.
- Beneficios: outputs, outcomes, beneficios, owners, baseline y metas.
- Riesgos e incertidumbres: riesgos materiales, sensibilidades, escenarios y respuestas.
- Estrategia de entrega y contratación: enfoque, mercado, recursos y gobernanza.
- Cronograma y gates: fases, fechas, decisiones futuras y capital incremental.
- Recomendación: alternativa preferida, justificación y condiciones para continuar.
- Plan de actualización: eventos que exigen revisión de la justificación.
La proporcionalidad es importante. Un proyecto pequeño no necesita decenas de páginas; un proyecto de alto CAPEX y gran incertidumbre no debe autorizarse mediante una justificación superficial.
El resumen ejecutivo no debe ocultar las condiciones de la recomendación
Los ejecutivos necesitan síntesis, pero síntesis no significa eliminar incertidumbre. Un buen resumen presenta la decisión solicitada, el valor de inversión, la alternativa preferida, los beneficios esperados, los riesgos críticos, las principales premisas y los siguientes gates.
Si la recomendación depende de una premisa todavía no confirmada — disponibilidad de conexión, licenciamiento, condición estructural, precio de proveedor u otro aspecto — esto debe aparecer en la síntesis. La gobernanza necesita saber si está aprobando una solución madura o únicamente la siguiente etapa de investigación.
Cómo utilizar el Five Case Model sin copiar acríticamente un modelo extranjero
HM Treasury actualizó durante 2026 su orientación de Business Cases basada en el Five Case Model. El modelo examina cinco perspectivas conectadas: strategic case, economic case, commercial case, financial case y management case.
Para organizaciones brasileñas, puede utilizarse como referencia conceptual, no como obligación normativa general. Su principal contribución es recordar que una decisión no debería evaluarse únicamente por el retorno financiero: alineación estratégica, elección entre opciones, viabilidad comercial, impacto financiero y capacidad de ejecución deben considerarse en conjunto.
La terminología, tasas, criterios de valor público y procedimientos del gobierno británico no deben trasplantarse automáticamente a empresas o entidades públicas brasileñas. La legislación aplicable, la gobernanza corporativa y la metodología del contratante continúan siendo determinantes.
Project Assurance puede revisar la calidad de la decisión
En proyectos de alto impacto, una decisión puede estar formalmente aprobada y aun así apoyarse en premisas técnicas frágiles. Una revisión independiente antes del gate ayuda al sponsor a distinguir madurez real de precisión aparente.
Los proyectos de alto impacto pueden beneficiarse de una revisión independiente antes de gates críticos. El Project Assurance en Ingeniería verifica si información, procesos, riesgos y decisiones poseen evidencia suficiente para el nivel de confianza exigido por el sponsor o la gobernanza.
La revisión no necesita rehacer todo el Business Case. Puede comprobar puntos como coherencia entre necesidad y solución, madurez de las estimaciones, independencia de las alternativas, trazabilidad de las premisas, riesgos críticos, readiness para contratación y calidad de la recomendación.
Owner’s Engineering protege la perspectiva del propietario
Cuando el proyecto avanza, la función del Business Case no desaparece. Las decisiones de diseño, procurement e implantación pueden modificar costo, plazo, desempeño y beneficios esperados.
La actuación de Owner’s Engineering representa el interés técnico del propietario durante el desarrollo y la ejecución, ayudando a verificar si cambios y decisiones continúan siendo compatibles con requisitos, objetivos y criterios de aceptación.
La recomendación del Owner’s Engineer no sustituye la autoridad de inversión del propietario; mejora la calidad técnica de las decisiones sometidas a gobernanza.
Cuándo contratar apoyo para construir el Business Case
La Consultoría de Ingeniería tiende a agregar más valor cuando la organización conoce la necesidad, pero todavía necesita transformar información dispersa en alternativas técnicamente comparables y una decisión estructurada.
Esto ocurre, por ejemplo, cuando:
- el proyecto involucra varias disciplinas;
- la condición existente es poco conocida;
- existen alternativas tecnológicas relevantes;
- CAPEX y OPEX dependen de levantamientos y estimaciones técnicas;
- los beneficios necesitan conectarse con desempeño real;
- los riesgos de implantación pueden cambiar el atractivo;
- el mercado proveedor necesita ser probado;
- la organización desea una revisión independiente antes de comprometer capital relevante.
La Consultoría Técnica de Ingeniería puede estructurar esta capa técnica, mientras las decisiones financieras corporativas permanecen con las áreas y autoridades responsables del contratante.
Qué exigir al contratar un Business Case técnico
El alcance debe definir el producto de decisión, no solamente “elaborar un informe”. Según la complejidad, conviene exigir:
- levantamiento de datos y documentos de entrada;
- definición del problema, objetivos y caso base;
- identificación y selección de alternativas;
- requisitos y criterios eliminatorios;
- evaluación de viabilidad técnica;
- estimaciones de CAPEX, OPEX y ciclo de vida con base declarada;
- modelo económico cuando corresponda;
- análisis de beneficios;
- riesgos, premisas, restricciones y sensibilidades;
- estrategia preliminar de implantación y contratación;
- matriz comparativa de alternativas;
- recomendación técnica fundamentada;
- presentación ejecutiva para gate de decisión;
- archivos de memoria de cálculo y trazabilidad de las fuentes;
- criterios de actualización en fases posteriores.
El contratante también debe definir quién proporciona premisas corporativas, quién valida estimaciones, quién aprueba la tasa de descuento y quién posee autoridad para decidir.
Señales de un Business Case débil
Algunos patrones indican que la justificación todavía no está lista para un compromiso relevante de capital:
- solución elegida antes de definir el problema;
- ausencia de caso base;
- solo una alternativa real;
- beneficios sin baseline u owner;
- CAPEX sin base de estimación;
- OPEX tratado como porcentaje genérico sin driver técnico;
- TIR, VAN o ROI sin memoria de cálculo;
- riesgos enumerados sin impacto en la decisión;
- cronograma incompatible con licencias, ingeniería o procurement;
- premisas críticas presentadas como hechos;
- inexistencia de criterios de gate;
- recomendación que no declara sus condiciones de validez.
El objetivo de la revisión no es hacer que todo Business Case sea más largo. Es identificar si existe información suficiente para la irreversibilidad y el riesgo de la decisión que será tomada.
El Business Case debe controlarse como documento vivo
Versión, fecha base, premisas, estimaciones y decisión aprobada deben ser trazables. Si el documento cambia después de un gate, la organización debe poder identificar qué cambió y por qué.
La justificación progresiva recomendada por la ABNT NBR ISO 21502 refuerza esta lógica. Antes de cada punto relevante de decisión, el Business Case puede actualizarse para reflejar cambios de contexto y alcance.
Esta disciplina evita utilizar, en la contratación o en la ejecución, una justificación económica basada en precios, plazos o requisitos que ya no corresponden al proyecto actual.
Consideraciones finales
Un Business Case de ingeniería no es un mecanismo para defender una solución. Es un mecanismo para decidir con evidencia si una necesidad merece inversión, qué alternativa ofrece el mejor equilibrio entre valor, riesgo y capacidad de entrega y qué condiciones deben preservarse a lo largo del proyecto.
Cuanto mayor sea el capital comprometido, la complejidad y la irreversibilidad, mayor debe ser la calidad de la definición antes de la decisión. La madurez no viene de añadir páginas: viene de transformar incertidumbres relevantes en información verificable y mantener explícitas aquellas que todavía no pueden eliminarse.
Cuando el proyecto todavía necesita madurar alternativas, estimaciones, riesgos, interfaces y estrategia de contratación, el siguiente paso puede ser desarrollar el front end por fases, en lugar de autorizar directamente la implantación.
Referencias técnicas
[1] ASOCIACIÓN BRASILEÑA DE NORMAS TÉCNICAS. ABNT NBR ISO 21502:2021 — Gestión de proyectos, programas y portafolios — Orientación sobre gestión de proyectos. Río de Janeiro: ABNT, 2021.
[2] PROJECT MANAGEMENT INSTITUTE. The Standard for Project Management and A Guide to the Project Management Body of Knowledge (PMBOK® Guide). 8. ed. Newtown Square: PMI, 2025. Disponible en: [https://www.pmi.org/standards/pmbok](https://www.pmi.org/standards/pmbok)
[3] 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](https://www.iso.org/standard/74947.html)
[4] HM TREASURY. Guidance on developing business cases for projects and programmes. Londres: HM Treasury, actualizado el 30 de junio de 2026. Disponible en: [https://www.gov.uk/government/publications/guidance-on-developing-business-cases](https://www.gov.uk/government/publications/guidance-on-developing-business-cases)
[5] HM TREASURY. The Green Book 2026: appraisal and evaluation in central government. Londres: HM Treasury, 2026. Disponible en: [https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-government/the-green-book-2026](https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-government/the-green-book-2026)
Preguntas frecuentes
Es la justificación documentada que sustenta la decisión de comprometer recursos con un proyecto, continuar invirtiendo o interrumpir cuando la justificación deja de existir. Debe relacionar necesidad, objetivos, alternativas, valor, costos, beneficios, riesgos y capacidad de entrega.
El Estudio de Viabilidad evalúa si una solución o proyecto es viable bajo criterios técnicos, operativos y económicos aplicables. El Business Case utiliza esa evidencia, junto con estrategia, beneficios, alternativas, riesgo y gobernanza, para respaldar la decisión de invertir.
No. El Business Case justifica por qué la inversión y la alternativa tienen sentido. El Project Charter formaliza el proyecto, la autoridad y los elementos iniciales de objetivo y alcance después o junto con la decisión de autorización, según la gobernanza adoptada.
No en todos los proyectos. Cuando existen flujos financieros relevantes y cuantificables, VAN, TIR, Payback y ROI pueden apoyar la decisión. Proyectos obligatorios o con beneficios no monetarios pueden exigir otros criterios, sin crear ingresos artificiales.
La aprobación pertenece a la autoridad definida por la gobernanza de la organización, como sponsor, comité de inversiones, dirección o consejo. El equipo técnico puede elaborar análisis y recomendaciones, pero no debe asumir una autoridad que no le fue delegada.
Sí, cuando la gobernanza y la materialidad lo justifiquen. Cambios relevantes de alcance, costo, plazo, contexto, riesgos o beneficios pueden exigir una actualización, especialmente antes de gates importantes.
Cuando la decisión depende de alternativas técnicas complejas, múltiples disciplinas, levantamientos de la condición existente, estimaciones, riesgos, integración de requisitos o revisión independiente antes de comprometer capital relevante.
No como regla general. Es una metodología de referencia del gobierno británico y puede inspirar un análisis multidimensional, pero las organizaciones brasileñas deben seguir su legislación, gobernanza y metodología aplicable.
Materiales técnicos complementarios
Soluciones relacionadas
- Gobernanza de Proyectos, Programas y Portafolios
- Gestión de Procesos, Workflows y Aprobaciones Técnicas
- Indicadores, Dashboards e Informes Ejecutivos de Ingeniería
Servicios relacionados
- Estudio de Viabilidad Técnica y Económica
- Consultoría Técnica de Ingeniería
- FEL — Front-End Loading
- Gestión de Proyectos de Ingeniería
- Owner’s Engineering
Contenidos principales sobre el tema
- VAN, TIR, Payback y ROI en Proyectos de Ingeniería
- Flujo de Caja Descontado en Proyectos de Ingeniería
- Gestión de CAPEX en Proyectos de Ingeniería
- Gestión de Beneficios en Proyectos y Programas
- TCO y Costo del Ciclo de Vida en Ingeniería
