Comprenda 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 apoyar 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 ejecución y criterios de decisión.
El Business Case no es apenas una planilla 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 cumplirse 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 mejor definición de alcance, estimaciones, riesgos, estrategia de contratación y resultados de mercado antes de nuevos gates de inversión.
Por 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, aplazar, 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 sustenta 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 la realización y continuidad del proyecto.
En la práctica, la decisión necesita considerar varias dimensiones al mismo tiempo. Entre ellas están los objetivos, alineamiento estratégico, beneficios potenciales, métricas de valor, riesgo aceptable, requisitos de presupuesto, plazo y calidad, recursos, competencias, alcance, escenarios y capacidad de sostener el cambio generado por el proyecto.
Esto significa que un Business Case robusto responde, como mínimo, a 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 modificar 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 trata del 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é debería comprometerse el capital y cuándo debe revisarse esa justificación.
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 debe crecer sobre una base de viabilidad real.
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, operacional y, cuando corresponda, económicamente viable. El Business Case utiliza esa evidencia — junto con estrategia, beneficios, alternativas, riesgo, capacidad de ejecución y gobernanza — para sustentar una decisión organizacional.
En términos simples:
| Instrumento | Pregunta predominante |
| Estudio de Viabilidad | ¿La alternativa puede implantarse y tiene sentido bajo 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: 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. Tras la decisión de continuar, el Project Charter transforma la decisión en mandato de proyecto, conforme a la gobernanza adoptada.
Confundir los documentos crea un problema recurrente: el proyecto es autorizado por 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 tienen contextos diferentes
En la contratación pública brasileña, el Estudo Técnico Preliminar tiene 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 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 ocurre 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 se hayan evaluado las alternativas.
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 eleva el riesgo de indisponibilidad;
- requisito regulatorio aún no cumplido;
- cuello de botella que limita producción o calidad;
- riesgo patrimonial sin control adecuado;
- costo operacional creciente;
- necesidad de ampliar resiliencia o continuidad.
Esta formulación abre espacio para diferentes respuestas. La solución puede involucrar expansión, retrofit, cambio operacional, 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 sustitució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 catastral 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 una dirección, pero son insuficientes para la decisión. El Business Case debe 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 medible. La definición debe evitar transformar el indicador en el propio objetivo. “Implantar 100 cámaras”, por ejemplo, es una entrega; “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 condición 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 línea base, qué cambio se espera, cuándo puede ocurrir y qué entregas o cambios operacionales son necesarios.
Esto evita atribuir al proyecto un beneficio que depende mayoritariamente 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 explicarse. 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 aplazar.
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 hacia una comparación detallada de desempeño, riesgo, costo y valor.
La alternativa “no hacer ahora” también es información
No actuar puede ser inviable por exigencia legal, seguridad o riesgo operacional, pero la hipótesis debe examinarse cuando corresponda. Incluso en proyectos obligatorios, el caso base ayuda a responder el costo y el riesgo de aplazar la intervención y permite comparar diferentes maneras de cumplir la obligación.
El Green Book 2026 utiliza business as usual como referencia obligatoria en su metodología de appraisal público. Esta 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 los 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, requisitos normativos, 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 solo alternativas capaces de cumplir aquello que realmente es necesario.
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. Los costos de operación, mantenimiento, reinversiones, vida útil y beneficios deben permanecer visibles durante la comparación.
La menor inversión inicial puede transferir costos 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 la alternativa.
El TCO y Costo del Ciclo de Vida en Ingeniería organiza gastos a lo largo de la vida útil y ayuda a exponer costos que quedan 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 retorno financiero positivo. En esos casos, el análisis económico puede comparar alternativas de cumplimiento del requisito, en vez de inventar ingresos para justificar la intervención.
El DCF hace explícito el tiempo
Los costos y beneficios que ocurren en fechas 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 o parámetros financieros pueden pertenecer al área financiera. 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 observar 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 del 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 las variables cuantitativas interactúan, la Simulación de Monte Carlo puede complementar escenarios deterministas.
El objetivo es mostrar a la gobernanza no solo el resultado esperado, sino qué puede hacer que ese resultado deje de ser verdadero.
Las premisas y restricciones deben ser 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 proporcionó o aprobó el dato |
| Fecha base | referencia temporal |
| Sensibilidad | impacto si la premisa varía |
| Status | confirmada, provisional o pendiente |
Las premisas críticas pendientes pueden transformarse 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 hizo 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 un 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. Patrocinador, comité de inversiones, dirección, consejo, portfolio board u otra instancia puede poseer la autoridad final.
La Gobernanza Decisoria con Autoridades, 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 patrocinador debe preservar la justificación a lo largo del proyecto
La ABNT NBR ISO 21502 atribuye al patrocinador la promoción del Business Case y la responsabilidad de validar si el proyecto continúa justificado a lo largo del ciclo de vida. Esto cambia la forma de ver el documento: no es apenas un formulario completado antes de la aprobación.
Los cambios significativos de alcance, costo, plazo, contexto o beneficio pueden exigir revisión. Si la necesidad desaparece, la alternativa deja de ser viable o la inversión crece muy por encima del caso aprobado, la gobernanza debe reevaluar si continuar sigue teniendo sentido.
Los gates convierten la justificación en un 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 madura el proyecto.
Un flujo posible es:
En fases iniciales, el gate puede autorizar solo el siguiente estudio. Posteriormente, 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 de comprometer capital significativo. Necesidad, alternativas, definición técnica, estimaciones, riesgos, cronograma y estrategia de ejecución pueden evolucionar de forma 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 único proveedor, 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, adquisición directa de equipos críticos u otros modelos pueden modificar riesgo, cronograma, CAPEX y responsabilidades.
Esta dimensión no significa elegir al proveedor dentro del Business Case. Significa verificar si existe un camino viable para transformar la alternativa seleccionada 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 para 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 exigidas;
- cómo recibirá operación la solución;
- qué recursos internos serán necesarios;
- qué soporte externo se requiere;
- cómo se implementará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 alineamiento estratégico.
- 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 la incertidumbre. Un buen resumen presenta la decisión solicitada, el valor de inversión, la alternativa preferida, beneficios esperados, riesgos críticos, principales premisas y próximos gates.
Si la recomendación depende de una premisa aún no confirmada — disponibilidad de conexión, licenciamiento, condición estructural, precio del proveedor u otro punto — esto debe aparecer en la síntesis. La gobernanza necesita saber si está aprobando una solución madura o apenas la siguiente etapa de investigación.
Cómo usar el Five Case Model sin copiar de forma acrítica un modelo extranjero
Durante 2026, HM Treasury actualizó 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: alineamiento estratégico, 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 transplantarse automáticamente a empresas o entes públicos brasileños. La legislación, gobernanza corporativa y metodología aplicable al contratante siguen 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 apoyarse en premisas técnicas frágiles. Una revisión independiente antes del gate ayuda al patrocinador 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 la información, los procesos, riesgos y decisiones poseen evidencia suficiente para la confianza exigida por el patrocinador o la gobernanza.
La revisión no necesita rehacer todo el Business Case. Puede probar puntos como coherencia entre necesidad y solución, madurez de las estimaciones, independencia de las alternativas, trazabilidad de las premisas, riesgos críticos, preparación 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 los cambios y decisiones siguen 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 la gobernanza.
Cuándo contratar apoyo para construir el Business Case
La contratación de Ingeniería Consultiva 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 modificar la atractividad;
- 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 apenas “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 el gate de decisión;
- archivos de memoria de cálculo y trazabilidad de las fuentes;
- criterios para actualización en las fases siguientes.
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 listados 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 más largo todo Business Case. Es identificar si existe información suficiente para la irreversibilidad y el riesgo de la decisión que se tomará.
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 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 ejecución 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 proviene de añadir páginas: proviene 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] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO 21502:2021 — Gestión de proyectos, programas y portafolios — Orientación sobre gestión de proyectos. Rio 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. Geneva: 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. London: HM Treasury, actualizado el 30 jun. 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. London: 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 ejecución.
El Estudio de Viabilidad evalúa si una solución o proyecto es viable bajo los criterios técnicos, operacionales y económicos aplicables. El Business Case utiliza esta evidencia, junto con estrategia, beneficios, alternativas, riesgos y gobernanza, para sustentar 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 elementos iniciales de objetivo y alcance después o junto con la decisión de autorización, conforme a 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. Los 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 patrocinador, 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 haya sido delegada.
Sí, cuando la gobernanza y la materialidad lo justifiquen. Los cambios relevantes de alcance, costo, plazo, contexto, riesgos o beneficios pueden exigir actualización, especialmente antes de gates importantes.
Cuando la decisión depende de alternativas técnicas complejas, múltiples disciplinas, levantamiento 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
- Ingeniería del Propietario
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
