Comprenda el alcance contractual en ingeniería: baseline, inclusiones, exclusiones, premisas, interfaces, medición, aceptación y cómo distinguir la obligación original de un cambio de alcance.
¡Descúbrelo!
El alcance contractual es la frontera técnica y comercial de las obligaciones asumidas por las partes en un contrato de ingeniería. Está formado no solo por una descripción resumida del objeto, sino por el conjunto de documentos que define trabajo, entregables, cantidades, requisitos, responsabilidades, premisas, exclusiones, interfaces, criterios de medición, condiciones de aceptación y reglas de cambio. Un análisis del alcance contractual busca responder objetivamente qué fue contratado, en qué condiciones, por quién y con qué evidencias de conclusión.
En proyectos industriales, EPC, EPCM, suministros y servicios de Ingeniería Consultiva, gran parte de los conflictos nace en las fronteras: un ítem no fue incluido explícitamente, pero es necesario para el funcionamiento; una premisa de la propuesta dejó de ser verdadera; un documento de referencia contradice a otro; una interfaz entre proveedores quedó sin responsable; o una solicitud del owner modifica requisito, cantidad, secuencia o plazo. Sin una baseline clara, resulta difícil separar obligación original, detalle normal, retrabajo y cambio genuino.
El alcance contractual no es sinónimo de Scope of Work, aunque el SOW sea una de sus fuentes principales. El contrato puede incorporar propuesta, especificaciones, planos, listas de cantidades, aclaraciones, actas y anexos. La interpretación técnica debe considerar el conjunto y la jerarquía documental aplicable. Tampoco debe confundirse el análisis con asesoramiento jurídico: la Ingeniería Consultiva caracteriza técnicamente hechos, obligaciones e impactos; las cuestiones de interpretación legal deben ser tratadas por los responsables jurídicos cuando sea necesario.
Qué compone el alcance contractual
El alcance contractual es el conjunto de obligaciones de resultado, actividad y soporte incorporadas al acuerdo entre las partes.
Puede estar formado por:
- contrato y condiciones particulares;
- Scope/Statement of Work;
- especificaciones técnicas;
- planos y modelos;
- datasheets;
- listas de materiales o cantidades;
- cronograma contractual;
- propuesta técnica aceptada;
- propuesta comercial aceptada;
- aclaraciones y addenda;
- matriz de responsabilidades;
- requisitos de documentación;
- criterios de prueba y aceptación;
- requisitos de calidad, HSE y ciberseguridad.
La lista real depende de la contratación. El punto central es saber qué documentos fueron efectivamente incorporados y qué regla de precedencia existe entre ellos.
Alcance contractual y Scope of Work
El Scope of Work (SOW) en Ingeniería define la extensión del trabajo y suele ser la principal descripción técnica de la obligación.
El alcance contractual es más amplio porque también considera documentos y condiciones que califican el SOW.
Ejemplo: el SOW exige suministrar un sistema. La especificación define desempeño. El plano define límites físicos. La lista define cantidades. La propuesta registra premisas. El contrato define plazo, medición y change control. Todos pueden influir en la obligación final.
Baseline: la referencia contra la cual se mide el cambio
Sin baseline no existe comparación objetiva del cambio. La primera tarea ante una nueva solicitud es reconstruir qué documentos, revisiones, cantidades, premisas y exclusiones formaban la obligación original.
Estructure la baseline con Consultoría Técnica de Ingeniería
No existe cambio de alcance sin una referencia anterior.
La baseline contractual debe identificar:
- versión de los documentos;
- fecha base;
- documentos incorporados;
- aclaraciones válidas;
- exclusiones aceptadas;
- premisas comerciales;
- responsabilidades;
- cantidades;
- cronograma y milestones.
Sin una baseline versionada, las discusiones pasan a depender de la memoria, correos electrónicos aislados o interpretación retrospectiva.
Inclusiones de alcance
Una inclusión es el trabajo explícitamente cubierto o lógicamente incorporado por los documentos contractuales aplicables. Una buena descripción no se limita al verbo principal: “desarrollar el diseño”, por ejemplo, puede involucrar levantamiento y validación de datos de entrada, cálculos, planos, especificaciones y lista de materiales; también puede exigir coordinación entre disciplinas, reuniones y compatibilización; finalmente, debe dejar claro el ciclo de presentación, tratamiento de comentarios y emisión final.
Esta lectura mediante producción técnica → coordinación → presentación y aceptación es más útil que una relación extensa de tareas porque permite verificar si el alcance cubre el ciclo necesario para transformar información de entrada en un entregable aceptado.
El análisis debe evitar dos extremos: presumir que todo lo necesario está automáticamente incluido o interpretar el contrato de forma tan literal que se ignoren obligaciones inherentes y documentos expresamente referenciados. La baseline debe leerse como un conjunto coherente de documentos, respetando siempre la jerarquía contractual aplicable.
Exclusiones de alcance
Las exclusiones registran lo que no está bajo responsabilidad de esa parte.
Una exclusión útil debe ser específica. “Obras civiles excluidas” puede ser insuficiente si el contrato también exige bases, anclajes, sellados o reposición.
Las exclusiones críticas deben analizarse junto con las interfaces para verificar quién asumió el ítem.
La exclusión no elimina una necesidad del proyecto
Si un ítem está excluido de un contrato, el owner debe confirmar dónde fue asignado.
Un gap entre contratos continúa siendo trabajo necesario, aunque ningún proveedor lo haya cotizado.
Premisas contractuales
Las premisas son condiciones consideradas verdaderas para formar precio, plazo y estrategia de ejecución. No deben quedar ocultas en notas comerciales porque pueden modificar materialmente la obligación cuando dejan de cumplirse.
| Premisa | Influencia en el contrato | Cómo controlar |
|---|---|---|
| Los documentos existentes son confiables | Reduce levantamientos y retrabajos previstos. | Identificar documentos base y el mecanismo para tratar divergencias encontradas. |
| El acceso será liberado en una fecha determinada | Afecta movilización, productividad y cronograma. | Registrar fecha requerida, responsable de la liberación y efecto de la indisponibilidad. |
| Energía, datos o utilities serán suministrados por el owner | Define la frontera de suministro y la condición de prueba. | Especificar punto de entrega, capacidad y plazo. |
| El diseño de terceros estará disponible | Condiciona ingeniería, compras e interfaces. | Tratar como input formal con fecha requerida y revisión aplicable. |
| Las cantidades permanecerán dentro de un rango determinado | Influye en precio unitario, logística y movilización. | Definir rango, fecha base y mecanismo de ajuste cuando corresponda. |
Cuando una premisa material deja de ser verdadera, el efecto debe analizarse técnicamente. Esto no significa automáticamente derecho a costo o plazo; significa que existe un hecho relevante que debe compararse con la baseline y tratarse según el mecanismo contractual.
Premisa versus requisito
Una premisa es una condición utilizada para planificar; un requisito es una obligación que debe cumplirse. La distinción queda clara en un ejemplo simple: considerar que un rack existente dispone de 10U libres es una premisa; exigir que el nuevo equipo sea instalado en ese rack es un requisito. Si la condición real es diferente, es necesario verificar quién era responsable de validar el dato de entrada y qué efectos produce la divergencia.
A Gestión de Requisitos en Ingeniería ayuda a separar obligación verificable de información de contexto, reduciendo discusiones sobre lo que efectivamente debía entregarse.
Restricciones
Las restricciones son límites que condicionan la solución y la ejecución. Pueden ser físicas, operacionales, regulatorias o tecnológicas. Una ventana de parada reducida, un ambiente clasificado, una limitación de espacio o una arquitectura de ciberseguridad obligatoria pueden modificar método, productividad, equipos y secuencia incluso sin cambiar la finalidad del proyecto.
Recomendación de ABNT NBR ISO 21502:2021: las restricciones pueden involucrar duración, financiamiento, presupuesto, disponibilidad de recursos, salud y seguridad, seguridad patrimonial, riesgo aceptable, impactos socioambientales, leyes, reglamentos y requisitos mínimos de calidad. La norma destaca que estas restricciones están interrelacionadas y deben analizarse periódicamente. En contratos, esto significa documentar no solo el límite, sino también su origen y el efecto esperado sobre la ejecución.
Interfaces contractuales
Las interfaces son puntos donde la obligación de una parte depende de la entrega de otra. En proyectos multidisciplinarios, aparecen entre equipo e infraestructura, energía y automatización, red y sistemas, civil y montaje electromecánico, diseño y construcción, proveedor y commissioning, o entre la contratista y los datos proporcionados por el owner.
El punto crítico no es solo reconocer que la interfaz existe, sino definir quién entrega qué, a quién, en qué plazo, en qué formato y con qué criterio de aceptación. Sin esta información, dos paquetes individualmente completos pueden producir un sistema incompleto.
A Gestión de Interfaces en Proyectos de Ingeniería formaliza owners, inputs, outputs y handoffs y debe utilizarse cuando la simple descripción contractual no sea suficiente para gobernar las dependencias entre paquetes.
Gaps de interfaz
Los gaps y overlaps aparecen cuando cada contrato se lee de forma aislada. La revisión debe atravesar las interfaces para verificar si todo trabajo necesario posee exactamente un owner claro.
Un gap ocurre cuando ningún contrato asume una obligación necesaria.
Ejemplo:
- A suministra la cámara;
- B suministra el switch;
- C suministra el cableado;
- nadie configura la VLAN ni ejecuta la prueba end-to-end.
El hecho de que cada contrato esté individualmente “cumplido” no garantiza que el sistema funcione.
Owner’s Engineering debe revisar los paquetes en conjunto.
Overlap de alcance
También puede ocurrir lo contrario: dos proveedores cotizan el mismo trabajo.
El overlap genera:
- costo duplicado;
- conflicto de responsabilidad;
- riesgo de interferencia;
- disputas sobre acceso y secuencia.
Una matriz de interfaces y responsabilidades ayuda a detectar duplicidades antes de la contratación.
Jerarquía documental
Cuando los documentos divergen, es necesario saber cuál prevalece.
Ejemplo:
- el plano muestra 20 unidades;
- la lista de cantidades muestra 18;
- la especificación describe 22;
- la propuesta considera 18.
Sin una regla de precedencia y aclaración previa, la divergencia puede convertirse en disputa.
La Ingeniería Consultiva debe identificar la inconsistencia y registrar el efecto técnico, sin presumir una solución jurídica que el contrato no autorice.
Propuesta técnica y propuesta comercial
La propuesta puede contener premisas y exclusiones relevantes.
Durante la negociación, el owner debe clasificar cada salvedad:
- aceptada;
- rechazada;
- incorporada con ajuste;
- sustituida por aclaración.
Dejar la propuesta anexada sin resolver excepciones puede crear conflicto con el SOW.
Aclaraciones e igualación
A TBE — Technical Bid Evaluation debe registrar desviaciones antes de la contratación.
Una igualación técnica eficaz reduce la probabilidad de descubrir después que:
- el proveedor no incluyó un ítem;
- la cantidad fue interpretada de forma diferente;
- una norma no fue considerada;
- la documentación final fue excluida;
- la prueba estaba fuera del precio;
- el plazo dependía de una condición no informada.
Alcance y medición
El modelo de medición debe reflejar la obligación.
Si el contrato paga casi todo el valor antes de pruebas y documentación, la gobernanza crea un incentivo para finalizar la instalación y dejar el cierre para después.
Los milestones pueden vincularse a:
- ingeniería aprobada;
- suministro;
- montaje;
- pruebas;
- commissioning;
- documentación;
- aceptación.
La estructura depende del régimen comercial.
Alcance y criterios de aceptación
La aceptación debe estar vinculada a evidencia verificable.
Puede exigir:
- requisito cumplido;
- prueba aprobada;
- NCR cerrada;
- punch list tratada;
- documentación final;
- As-Built;
- backups;
- certificados;
- capacitación;
- solicitud formal de aceptación.
La obligación no termina necesariamente cuando finaliza el servicio físico.
Entregado versus aceptado
Esta distinción es esencial en la administración contractual.
Entregado: el contratista puso a disposición el producto, documento o sistema.
Aceptado: el contratante verificó los criterios y formalizó o reconoció la conformidad según el proceso aplicable.
Un plano enviado para revisión está entregado, pero no aprobado. Un sistema instalado puede no estar aceptado si las pruebas y la documentación permanecen pendientes.
Cambio de alcance
AACE define change de forma amplia como una alteración o variación en el scope of work, servicio, costo, precio o cronograma. En EPC, los cambios pueden surgir por instrucción del owner, condición encontrada, revisión de requisito, interferencia, legislación, proveedor o desarrollo de la ingeniería.
La pregunta inicial siempre es: ¿el nuevo trabajo difiere de la baseline?
Si no difiere, puede ser una obligación original. Si difiere, entra en el análisis formal.
Cambio dirigido por el owner
El owner puede solicitar:
- nueva funcionalidad;
- cantidad adicional;
- cambio de ubicación;
- cambio de tecnología;
- nueva secuencia;
- aceleración;
- trabajo en una ventana diferente;
- incremento de documentación.
La solicitud debe registrarse antes de que el efecto desaparezca en el flujo normal de la ejecución.
Constructive change
Las prácticas de contract change management también reconocen constructive changes: actos u omisiones que, aunque no emitidos formalmente como change order, hacen que el contratista ejecute un trabajo diferente del previsto.
La caracterización depende de los hechos y del contrato. La Ingeniería puede demostrar técnicamente qué cambió; la consecuencia contractual exige evaluación conforme al instrumento y la legislación aplicable.
Cambio de cantidad
En contratos unitarios, el aumento o la reducción de cantidad puede tener un mecanismo previsto.
Aun así, cantidades muy diferentes pueden modificar:
- productividad;
- movilización;
- logística;
- economía de escala;
- secuencia;
- plazo.
El análisis no debe considerar únicamente la multiplicación del precio unitario cuando el contrato o la realidad técnica exigen una revisión más amplia.
Cambio de calidad o especificación
Sustituir un requisito por un desempeño superior puede modificar:
- proveedor;
- lead time;
- ingeniería;
- pruebas;
- costo;
- garantía;
- interfaces.
El cambio debe compararse con la especificación baseline.
Cambio de secuencia
El alcance físico puede permanecer igual mientras cambia la forma temporal de ejecución.
Ejemplo: ejecutar un área después de otra en lugar de simultáneamente puede aumentar la movilización y el plazo.
Change management debe considerar secuencia y acceso cuando sean contractualmente relevantes.
Aceleración
Solicitar el mismo trabajo en un plazo menor puede ser un cambio con impacto en recursos.
Posibles efectos:
- horas extra;
- turnos;
- equipos adicionales;
- flete expreso;
- menor productividad;
- riesgo de calidad;
- superposición de disciplinas.
El análisis debe separar la aceleración dirigida de la recuperación de retraso imputable al propio contratista.
La corrección de errores no es automáticamente alcance adicional
Cuando un entregable no cumple el requisito original, la corrección puede formar parte de la obligación de conformidad.
Ejemplos:
- cálculo incorrecto;
- plano incompatible;
- instalación fuera de especificación;
- prueba rechazada por falla de ejecución.
El contratante no debería pagar como cambio aquello que solo corrige una no conformidad, salvo disposición específica en contrario.
El detalle no es automáticamente un cambio
Durante el diseño ejecutivo, los conceptos se detallan. No todo aumento de información es un aumento de alcance.
La cuestión es si el detalle era necesario para entregar el requisito ya contratado o si surgió un nuevo requisito.
Esta distinción es crítica en proyectos contratados en fases de madurez diferentes.
Scope creep
Scope creep es el crecimiento no controlado del alcance sin evaluación y aprobación formal.
Puede ocurrir por:
- solicitudes informales;
- “pequeños favores” acumulados;
- decisiones de reunión sin change request;
- revisión de plano utilizada para insertar un requisito nuevo;
- ausencia de baseline;
- cultura de ejecutar primero y discutir precio después.
El efecto acumulado puede ser material incluso cuando cada solicitud aislada parece pequeña.
Gold plating
Gold plating ocurre cuando el propio equipo agrega funcionalidad o calidad no requerida.
Esto también puede generar costo y riesgo y no debe confundirse con creación legítima de valor.
El proveedor no debe modificar unilateralmente el alcance solo porque considera la solución “mejor”.
Proceso de change control
Change control no debe impedir cambios legítimos; debe impedir que se vuelvan invisibles. Registrar, analizar el impacto, aprobar y actualizar la baseline preserva la memoria técnica y comercial del proyecto.
Como se trata de una secuencia de gobernanza, aquí una lista numerada es más clara que una tabla. El proceso puede consolidarse en cinco etapas:
- Identificar y registrar: describir la solicitud, origen, fecha, documentos y condición de baseline afectada.
- Caracterizar: comparar con la baseline y separar obligación original, corrección, detalle o cambio potencial.
- Evaluar impactos: analizar ingeniería, cantidades, interfaces, riesgo, costo, productividad y cronograma.
- Decidir e instruir: someter a la autoridad prevista en el contrato, registrar aprobación o rechazo y formalizar la instrucción.
- Implementar y cerrar: actualizar documentos, presupuesto y cronograma autorizados, rastrear la ejecución y preservar el historial del cambio.
Recomendación de ABNT NBR ISO 21502:2021: solo deben implementarse cambios autorizados y la documentación del proyecto debe actualizarse según sea necesario. La norma recomienda acompañar las solicitudes hasta su cierre y evaluar los impactos de forma integrada, incluyendo alcance, cronograma, costo, calidad y riesgos.
Cuando la discusión evoluciona hacia impacto contractual o claim, el servicio de Análisis Técnico de Adendas, Cambios de Alcance y Claims puede organizar la baseline, los hechos y la causalidad técnica antes de la negociación.
Change log
El registro de cambios debe contener:
- identificador;
- origen;
- fecha;
- descripción;
- documentos afectados;
- status;
- estimación de costo;
- impacto de plazo;
- responsable;
- decisión;
- referencia de la autorización.
Un cambio no registrado tiende a reaparecer como disputa en el cierre.
Alcance y cronograma
Un cambio de alcance puede afectar el camino crítico incluso cuando el nuevo trabajo es pequeño en costo.
Ejemplo: un equipo adicional de bajo valor puede exigir revisión de panel, compra con largo lead time y repetición de pruebas del sistema.
El análisis debe utilizar lógica de cronograma, no una regla proporcional al valor.
Alcance y costo
Un cambio de alcance puede generar costo mediante mecanismos diferentes. El impacto más evidente es la variación de cantidad directa de ingeniería, materiales o equipos, pero el análisis no termina ahí. Dependiendo del momento y de la forma del cambio, también pueden surgir removilización, supervisión adicional, reprogramación de subcontratos, repetición de pruebas, revisión documental o extensión de la permanencia del equipo.
También existen impactos de productividad: una modificación ejecutada fuera de la secuencia originalmente planificada puede consumir más HTE u horas de campo incluso cuando la cantidad física adicional sea pequeña. Por eso, costo directo, costo de prolongación y pérdida de productividad no deben mezclarse sin demostrar causalidad.
El análisis técnico debe reconstruir la cadena evento → obligación afectada → cambio en el método o cantidad → recurso adicional → efecto económico. Los costos indirectos solo se vuelven defendibles cuando esta relación puede demostrarse y cuando el contrato admite el tratamiento correspondiente.
Alcance y productividad
Cambiar la secuencia o fragmentar frentes puede reducir la productividad sin modificar cantidades.
Ejemplo: 1.000 metros instalados en un frente continuo no equivalen económicamente a 1.000 metros distribuidos en decenas de movilizaciones.
El análisis debe preservar el contexto de ejecución.
Alcance y plazo
El cambio debe relacionarse con las actividades afectadas.
Preguntas:
- ¿qué actividad recibió el nuevo trabajo?
- ¿existe float?
- ¿cambió el camino crítico?
- ¿hubo concurrencia con retraso de otra causa?
- ¿el impacto podría haberse mitigado?
El cluster de Claims profundizará métodos de delay analysis sin duplicar este artículo de alcance.
Alcance y Work Package
O Work Package en Proyectos de Ingeniería ayuda a localizar cambios en la WBS.
Una modificación puede crear:
- nuevo WP;
- aumento de un WP existente;
- cambio de interfaz;
- cambio de milestone;
- revisión de presupuesto.
Esta estructura mejora la trazabilidad.
Alcance y RACI
La responsabilidad debe diferenciarse de la obligación de alcance.
A Matriz RACI explica quién participa; el contrato describe lo que cada parte debe entregar.
Utilizar solo RACI para resolver el alcance puede dejar obligaciones técnicas vagas.
Owner Furnished Items
Los ítems suministrados por el owner necesitan responsabilidades asociadas.
Defina quién:
- compra;
- transporta;
- recibe;
- almacena;
- inspecciona;
- instala;
- configura;
- prueba;
- garantiza.
La simple expresión “suministrado por el cliente” no cierra la interfaz.
Datos suministrados por el owner
Los proyectos dependen de inputs:
- planos;
- topografía;
- cargas;
- listas;
- arquitectura;
- datos de proceso;
- parámetros de red;
- credenciales;
- documentación de equipos existentes.
El alcance debe indicar responsabilidad y timing.
Dependencia de terceros
Licencias, compañías de servicios, fabricantes y otros contratos pueden condicionar la ejecución.
La obligación de coordinar no significa necesariamente asumir el plazo de decisión del tercero. Esta frontera debe definirse.
Alcance en contrato de Ingeniería Consultiva
Los servicios intelectuales requieren atención especial porque parte del valor está en el análisis y el juicio profesional.
Defina:
- cuestión técnica;
- productos;
- cantidad de reuniones/visitas cuando corresponda;
- datos de entrada;
- responsabilidades;
- criterios de conclusión;
- límites de autoridad;
- horas o HTE cuando ese sea el régimen;
- mecanismo para nuevas demandas.
“Asesoría técnica según sea necesario” sin gobernanza puede convertirse en alcance ilimitado.
Contratos por demanda
Un contrato marco puede definir un universo de servicios y utilizar Órdenes de Servicio para detallar cada demanda.
La OS puede registrar:
- objetivo;
- alcance;
- entregables;
- HTE o valor;
- plazo;
- responsable;
- premisas;
- aceptación.
Esto preserva flexibilidad sin abandonar el control.
Precio global y madurez del alcance
El precio global es más adecuado cuando la obligación posee una definición suficiente para que el proveedor cotice el riesgo de forma responsable.
Un alcance inmaduro puede generar:
- contingencia elevada;
- muchas exclusiones;
- claims;
- baja comparabilidad de propuestas.
FEL y la ingeniería de definición ayudan a reducir esta incertidumbre.
Precio unitario
En precio unitario, la definición de la unidad forma parte del alcance.
Una unidad debe responder qué está incluido en su precio.
Ejemplo: ¿un metro de bandeja portacables incluye soporte, fijación, accesorios, puesta a tierra e identificación? La respuesta debe estar documentada.
Contrato reembolsable
Incluso cuando el costo es reembolsado, el alcance y la autorización siguen siendo necesarios.
Sin límites, la organización pierde control de finalidad, productividad y prioridades.
Alcance y documentación final
La documentación de cierre debe estar en la baseline desde el inicio.
Puede incluir:
- As-Built;
- Data Book;
- certificados;
- informes de prueba;
- backups;
- licencias;
- inventario;
- manuales;
- capacitación;
- punch list final.
No es “papelería después de la obra”; es parte de la entrega técnica.
Alcance y calidad documental
El contrato puede definir formato, codificación, workflow y status documental.
“Entregar planos” no aclara si son necesarios:
- archivos editables;
- PDF firmados;
- modelos nativos;
- revisión As-Built;
- metadatos;
- control de revisión.
Esta definición evita gaps en el handover.
Alcance y commissioning
Si commissioning es responsabilidad de una parte, defina:
- sistemas;
- fronteras;
- procedimientos;
- instrumentos;
- registros;
- criterios;
- witnessing;
- tratamiento de fallas;
- retests.
Si participan varias contratistas, una debe coordinar la integración global.
Alcance y substantial completion
Los conceptos de substantial completion dependen del contrato aplicable. No deben presumirse solo porque la instalación esté operacional.
Pendientes documentales, pruebas o defectos pueden influir en el status según los criterios definidos.
La organización debe evitar lenguaje informal que sustituya el proceso contractual.
Auditoría de alcance antes de la contratación
Una revisión independiente puede verificar:
- documentos conflictivos;
- gaps;
- overlaps;
- premisas ocultas;
- exclusiones críticas;
- interfaces sin owner;
- cantidades inconsistentes;
- criterios de aceptación ausentes;
- documentación final olvidada;
- change control insuficiente.
Esta revisión suele ser mucho más barata antes de la firma.
Auditoría de alcance durante la ejecución
Cuando surgen disputas, reconstruya la baseline:
- contrato original;
- documentos incorporados;
- propuesta y aclaraciones;
- revisiones autorizadas;
- change orders;
- correspondencia relevante;
- planos e instrucciones;
- evidencias de ejecución.
El análisis debe ser cronológico y documental.
Matriz de alcance
Una matriz puede mapear paquetes y responsables:
| Ítem | Owner | Contratista A | Contratista B | Evidencia |
| Diseño | Aprueba | Ejecuta | Consultada | AFC |
| Energía | Suministra fuente | Conecta | — | prueba |
| Red | Proporciona IP | Instala | Configura core | ping/SAT |
| As-Built | Aprueba | Actualiza | proporciona redlines | revisión final |
La matriz debe complementar, no sustituir, el texto contractual.
Cómo analizar una nueva solicitud
Haga cinco preguntas:
- ¿el requisito ya existía?
- ¿la cantidad ya estaba prevista?
- ¿la responsabilidad estaba asignada?
- ¿cambió la condición de baseline?
- ¿existe un impacto medible en costo o plazo?
Las respuestas organizan la investigación antes de cualquier conclusión comercial.
Evidencia contemporánea
Los registros producidos en el momento de los hechos tienden a ser más útiles que las reconstrucciones tardías.
Ejemplos:
- RFI;
- transmittal;
- acta;
- change request;
- diario;
- cronograma actualizado;
- informe fotográfico;
- correo electrónico formal;
- revisión de plano.
La gobernanza debe crear evidencia mientras el proyecto ocurre.
No ejecutar cambios informalmente sin trazabilidad
En entornos de urgencia, puede ser necesario actuar antes de concluir la negociación. Aun así, la instrucción y la reserva de derechos/impactos deben seguir el contrato y la gobernanza aplicable.
Ejecutar durante meses sin registrar el cambio reduce la capacidad de demostrar causalidad después.
Alcance y claims
Un claim es una reclamación contractual basada en hechos, obligaciones e impactos. No todo cambio se convierte en claim; los cambios pueden acordarse mediante el proceso normal.
El próximo cluster específico de Claims tratará la estructura de reclamaciones, reequilibrio y delay analysis. Este artículo se limita a la caracterización de la baseline y del cambio de alcance.
Errores comunes en la gestión del alcance contractual
Los errores más graves rara vez derivan de una única frase deficiente. Surgen cuando documento, responsabilidad, medición y cambio dejan de formar un sistema coherente. La tabla siguiente resume fallas recurrentes y el control técnico correspondiente.
| Falla | Efecto típico | Control recomendado |
|---|---|---|
| Contratar con documentos contradictorios | Cantidades, requisitos o responsabilidades diferentes solo aparecen durante la ejecución. | Igualación técnica, aclaraciones formales y regla de precedencia antes de la firma. |
| Aceptar exclusiones sin owner alternativo | Crea un gap entre contratos: el trabajo sigue siendo necesario, pero nadie lo cotizó. | Matriz de alcance y Gestión de Interfaces. |
| Usar “turnkey” como sustituto del alcance | El régimen se trata como autorización para dejar implícitos requisitos, límites y aceptación. | Scope of Work, criterios de desempeño y entregables verificables. |
| Modificar el plano sin change control | Una revisión incorpora una nueva obligación sin evaluación de costo, plazo o interfaces. | Change request trazable y análisis integrado de impacto. |
| Medir la instalación y olvidar la documentación | El pago y el progreso financiero avanzan más rápido que la conclusión técnica. | Vincular la medición a pruebas, Data Book, As-Built y aceptación. |
| Tratar el error como alcance adicional | El retrabajo por no conformidad se confunde con un cambio legítimo. | Comparación objetiva con el requisito y la baseline originales. |
| Tratar toda nueva información como obligación original | Los requisitos realmente nuevos desaparecen dentro del detalle normal. | Trazabilidad entre requisito, revisión, origen de la solicitud y baseline. |
| No mantener un change log | Pequeños cambios se acumulan sin una visión consolidada del impacto. | Registro único de cambios, status, decisión y autorización. |
Recomendación de ABNT NBR ISO 21502:2021: los cambios deben identificarse, evaluarse, autorizarse, implementarse y cerrarse de forma controlada. La evaluación debe considerar impactos sobre alcance, recursos, cronograma, costo, calidad, riesgos y expectativas de las partes interesadas. Este principio es particularmente útil en contratos de ingeniería porque impide que una modificación se analice únicamente por su costo directo, ignorando efectos sistémicos.
Checklist para revisar el alcance contractual
Confirme:
- documentos incorporados;
- orden de precedencia;
- baseline y revisiones;
- inclusiones;
- exclusiones;
- premisas;
- restricciones;
- cantidades;
- entregables;
- interfaces;
- owner-furnished items;
- datos de entrada;
- medición;
- aceptación;
- documentación final;
- mecanismo de change control;
- plazo y milestones;
- matriz de responsabilidades;
- registros de aclaración.
Cuándo la Ingeniería Consultiva agrega valor
A Ingeniería del Propietario puede actuar antes y durante la contratación para proteger las interfaces y los objetivos del owner.
A Consultoría Técnica de Ingeniería puede apoyar:
- revisión de la baseline;
- matriz de alcance;
- análisis de gaps y overlaps;
- revisión del SOW;
- igualación de propuestas;
- trazabilidad de requisitos;
- change control;
- análisis de impacto;
- soporte técnico a negociaciones;
- preparación de memoria factual para claims.
El objetivo es separar técnicamente qué fue contratado, qué cambió y qué efectos derivaron de ese cambio.
Consideraciones finales
El alcance contractual es una baseline técnica y comercial, no una frase de objeto. Nace de la combinación controlada de SOW, requisitos, planos, cantidades, propuesta, aclaraciones, responsabilidades, criterios de medición y aceptación. Cuanto más clara sea esta arquitectura antes de la firma, menor será el espacio para gaps, overlaps e interpretaciones contradictorias.
Durante la ejecución, la baseline permite distinguir obligación original, detalle normal, corrección de no conformidad y cambio genuino. Esta distinción es la base del change control y, cuando existe controversia, del análisis técnico de claims. Los cambios de cantidad, calidad, secuencia, plazo o interfaz deben registrarse y evaluarse antes de que desaparezcan dentro del flujo cotidiano del proyecto.
La gestión madura del alcance no busca impedir todo cambio. Los proyectos de ingeniería cambian. El objetivo es hacer visible el cambio, evaluar el impacto, decidir con autoridad y actualizar la baseline sin perder el historial. Esta trazabilidad protege al contratante y al contratista y mejora la capacidad de concluir el proyecto con obligaciones, costos y responsabilidades claramente demostrables.
La Ingeniería del Propietario agrega independencia al revisar interfaces, documentos conflictivos y nuevas solicitudes antes de que la interpretación del alcance se transforme en costo o retraso de difícil reversión.
Referencias técnicas
[6] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO 21502:2021 — Gerenciamento de projetos, programas e portfólios — Orientação sobre gerenciamento de projetos. Rio de Janeiro: ABNT, 2021. Disponível em: https://www.abntcatalogo.com.br/
[1] AACE INTERNATIONAL. Recommended Practice 100R-19: Contract Change Management — As Applied in Engineering, Procurement, and Construction. Morgantown: AACE International, 2020. Disponível em: https://web.aacei.org/docs/default-source/toc/toc_100r-19.pdf
[2] AACE INTERNATIONAL. Cost Engineering Terminology — 10S-90. Morgantown: AACE International. Disponível em: https://library.aacei.org/terminology/
[3] FIDIC. Selection, Engagement and Remuneration of Consulting Engineers — Change in Work Scope. Geneva: International Federation of Consulting Engineers. Disponível em: https://fidic.org/node/754
[4] NASA. Guidance for Writing Work Statements — NPG 5600.2B. Washington, DC: National Aeronautics and Space Administration. Disponível em: https://www.hq.nasa.gov/office/procurement/newreq1.htm
[5] 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. Disponível em: https://www.pmi.org/standards/pmbok
Preguntas frecuentes
Es el conjunto de obligaciones técnicas y comerciales incorporadas al contrato, incluyendo trabajo, entregables, requisitos, cantidades, premisas, exclusiones, interfaces, medición y criterios de aceptación.
Scope of Work es una fuente central de definición del trabajo. El alcance contractual es más amplio y también considera especificaciones, planos, propuesta aceptada, aclaraciones, cantidades y demás documentos incorporados.
Son trabajos o responsabilidades que las partes registraron como fuera de la obligación de un contrato determinado. Deben revisarse para garantizar que el ítem tenga otro responsable cuando sea necesario para el proyecto.
Cuando la condición utilizada para formar precio, plazo o solución deja de ser verdadera y produce un efecto material. El hecho debe registrarse y analizarse según el change control aplicable.
No. Una revisión puede únicamente detallar o corregir la obligación original. Es necesario comparar la nueva exigencia con la baseline para verificar si existe un requisito, cantidad o condición realmente nueva.
No automáticamente. Si el trabajo corrige una no conformidad con un requisito ya contratado, tiende a pertenecer a la obligación original, según las disposiciones del contrato.
Es el crecimiento no controlado del alcance sin análisis y aprobación formal, normalmente por solicitudes informales o cambios incorporados directamente a la ejecución.
Mantenga una baseline versionada, change log, análisis técnico, evaluación de costo y plazo, aprobación formal y actualización trazable de los documentos afectados.
Materiales técnicos complementarios
Soluciones relacionadas
- Gestión de Contratos, Alcance y Entregables
- Gobernanza de Proyectos, Programas y Portafolios
- Gestión de Procesos, Workflows y Aprobaciones Técnicas
- Implementación y Estructuración de PMO de Ingeniería
- Gestión de Documentos de Ingeniería: GED, EDMS, revisiones y trazabilidad
Servicios relacionados
- Ingeniería del Propietario
- Consultoría Técnica de Ingeniería
- Análisis Técnico de Adendas, Cambios de Alcance y Claims
- Gestión de Proyectos de Ingeniería
- Recepción Técnica de Obras y Servicios de Ingeniería
- Auditoría Técnica de Data Book y Documentación Final de Ingeniería
Contenidos principales sobre el tema
- Scope of Work (SOW) en Ingeniería
- Work Package en Proyectos de Ingeniería
- TBE — Technical Bid Evaluation
- RFP en Ingeniería
- Gestión de Requisitos en Ingeniería
- Gestión de Interfaces en Proyectos de Ingeniería
- Adenda Contractual en Obras y Servicios de Ingeniería
- Estrategia de Contratación en Ingeniería
Contenidos técnicos relacionados
- Matriz RACI en Proyectos de Ingeniería
- Data Book en Ingeniería
- Art. 140 de la Ley 14.133: recepción de obras y servicios de ingeniería
- Project Assurance en Ingeniería
- Guía Completa sobre Licitaciones y Contratos de Obras y Servicios de Ingeniería
- Guía Completa sobre Ingeniería Consultiva
- Owner’s Engineering: framework ejecutivo para contratación, gobernanza y aceptación
- Framework de Handover Técnico de Obras y Sistemas
