Comprenda Scope of Work y SOW en ingeniería: cómo definir alcance de trabajo, entregables, exclusiones, premisas, interfaces, medición y criterios de aceptación en contratos.
¡Descúbrelo!
Scope of Work es la definición estructurada del trabajo que debe ejecutarse dentro de un contrato o paquete de ingeniería, estableciendo límites, entregables, responsabilidades, requisitos, interfaces y criterios de conclusión. En muchos entornos empresariales, la sigla SOW se utiliza para Statement of Work, el documento que contiene la descripción formal del trabajo; dentro de él, el scope of work es el núcleo que define qué se hará. En proyectos industriales, EPC/EPCM y servicios de Ingeniería Consultiva, esta definición debe ser suficientemente precisa para sustentar contratación, medición, control de cambios y aceptación sin convertir el documento en una prescripción excesiva de cómo el proveedor debe ejecutar el trabajo.
Un buen SOW reduce ambigüedades antes de la contratación. Explica el objetivo, describe productos y servicios esperados, explicita lo incluido y excluido, registra premisas y restricciones, identifica interfaces con terceros, establece datos de entrada y define cómo cada entrega será verificada y aceptada. También crea la referencia contra la cual podrán analizarse cambios de alcance, reclamaciones, mediciones y responsabilidades durante la ejecución.
En el contexto brasileño, el SOW no debe tratarse automáticamente como sinónimo de Término de Referencia. El Término de Referencia tiene una función propia, especialmente en contrataciones públicas y bajo la Ley 14.133. El SOW tratado aquí es el instrumento de definición del trabajo utilizado en entornos privados, industriales, EPC, EPCM, suministros y contratos de servicios técnicos. Los documentos pueden compartir elementos, pero pertenecen a contextos de gobernanza diferentes.
¿Qué es Scope of Work y qué significa SOW?
Scope of Work significa literalmente alcance del trabajo. Describe la frontera del trabajo contratado: qué tareas, productos, servicios y resultados forman parte de la obligación del proveedor y cuáles no.
Statement of Work es una expresión más amplia. La orientación histórica de la NASA define el SOW como la descripción de las tareas, productos y servicios que serán adquiridos y enfatiza que el requisito debe expresarse de forma completa, clara y precisa, sin especificar más de lo necesario. En contratos de ingeniería, esta lógica sigue siendo válida: el documento debe indicar qué necesita entregarse, bajo qué condiciones y con qué criterios de desempeño y aceptación.
En la práctica empresarial, ambos términos aparecen mezclados con frecuencia. Para fines de gobernanza, es mejor establecer una convención explícita:
- Statement of Work — SOW: documento contractual o precontractual que organiza el trabajo;
- Scope of Work: sección o núcleo que define la extensión y los límites del trabajo;
- WBS: descomposición jerárquica del alcance total del proyecto;
- Work Package: nivel más bajo de la WBS que puede gestionarse para estimar y controlar costo, esfuerzo, duración y recursos.
Esta distinción evita que una frase genérica denominada “alcance” se utilice para sustituir todo el paquete de contratación.
¿Por qué un SOW es crítico en proyectos de ingeniería?
La ambigüedad de alcance se convierte en costo durante la ejecución. Cuando el contrato no define claramente la obligación, surgen preguntas como:
- ¿quién proporciona los datos de entrada?
- ¿quién realiza el levantamiento de campo?
- ¿cuántas revisiones están incluidas?
- ¿quién coordina las interfaces?
- ¿el proveedor debe emitir memoria de cálculo o solamente un dibujo?
- ¿el As Built forma parte del alcance?
- ¿las pruebas y el comisionamiento están incluidos?
- ¿la capacitación es una obligación contractual?
- ¿debe entregarse documentación del fabricante?
- ¿qué caracteriza la conclusión y la aceptación?
Si estas respuestas aparecen solamente después de la contratación, la negociación deja de ocurrir en un entorno competitivo y pasa a desarrollarse bajo presión de plazo, movilización y dependencia técnica.
El SOW en la cadena de contratación
El SOW debe nacer antes de la solicitud de propuestas y permanecer trazable hasta la aceptación.
La RFP en Ingeniería utiliza el alcance como una de las bases para solicitar propuestas comparables. La TBE — Technical Bid Evaluation verifica cómo cada proponente cumple los requisitos técnicos. Si el SOW es vago, ambas etapas pierden calidad.
Un SOW no es solamente una lista de actividades
Enumerar verbos como “proyectar, instalar, probar y entregar” no define un alcance suficiente.
Una contratación necesita conectar cada actividad con un producto verificable. Por ejemplo:
Débil: ejecutar el proyecto ejecutivo de telecomunicaciones.
Más estructurado: desarrollar el proyecto ejecutivo de telecomunicaciones para los sistemas definidos, incluyendo planos, diagramas, listas, detalles constructivos, memorias de cálculo, especificaciones, interfaces y matriz de cables, sometiendo los documentos al flujo de revisión e incorporando los comentarios hasta su emisión aprobada para construcción.
La segunda redacción todavía necesita requisitos específicos, pero ya indica contenido, entregables y proceso de conclusión.
Estructura recomendada de un SOW de ingeniería
El SOW debe transformar una necesidad en una obligación verificable. Un alcance sin entregables, interfaces y criterios de aceptación sigue abierto a interpretaciones incluso cuando ocupa muchas páginas.
Estructure la contratación con Consultoría Técnica de Ingeniería
No existe un índice único aplicable a todos los contratos. La estructura debe reflejar el objeto, el régimen de contratación, el nivel de madurez de la ingeniería y la forma de medición. En lugar de tratar cada componente como una lista aislada, es más útil entender el SOW como una cadena de definición: contexto y requisitos establecen la base; alcance, entregables e interfaces traducen esa base en trabajo; medición y aceptación demuestran la conclusión.
| Elemento del SOW | Función técnica | Evidencia esperada |
|---|---|---|
| Objetivo y contexto | Explicar por qué existe el trabajo, en qué proyecto y bajo qué condiciones. | Descripción del problema, fase del proyecto, sistemas existentes y documentos de referencia. |
| Alcance incluido | Definir actividades y obligaciones cubiertas por precio y plazo. | Verbos verificables asociados a resultados concretos. |
| Entregables | Transformar el trabajo en productos físicos, documentales o digitales identificables. | Planos, memorias, modelos, informes, cálculos, registros de pruebas, Data Book, As Built o documentación de aceptación. |
| Exclusiones y límites | Explicitar fronteras que podrían razonablemente interpretarse como incluidas. | Lista de exclusiones e identificación del responsable alternativo cuando el ítem siga siendo necesario para el proyecto. |
| Premisas y restricciones | Registrar condiciones utilizadas para formar precio, plazo y solución, y límites que condicionan la ejecución. | Premisas verificables, ventanas operativas, normas, requisitos de seguridad, interoperabilidad y condiciones de acceso. |
| Interfaces | Definir dependencias entre contratista, contratante y terceros. | Owner de cada interfaz, input, output, plazo y condición de handoff. |
| Medición | Establecer cómo se reconocerá el avance para control y pago. | Hitos, unidades o criterios asociados a progreso verificable. |
| Aceptación | Definir la condición objetiva de conclusión. | Requisitos cumplidos, pruebas aprobadas, documentación aceptada, pendientes tratados y formalización correspondiente. |
Recomendación de ABNT NBR ISO 21502:2021: la gestión del alcance debe partir del alcance aprobado, reflejar requisitos y criterios de aceptación y mantener trazabilidad hasta la confirmación de la entrega. La norma también recomienda incorporar al proyecto únicamente trabajo formalmente aprobado. Aplicado al SOW, esto significa definir desde la contratación no solo “qué hacer”, sino cómo se verificará el resultado y bajo qué condición podrá considerarse aceptado.
Cuando varios paquetes se encuentran, la Gestión de Interfaces en Proyectos de Ingeniería complementa el SOW haciendo explícitos los handoffs y responsables entre contratos.
Alcance incluido y alcance excluido
La frontera debe ser explícita.
Considere una contratación para el proyecto ejecutivo de seguridad electrónica. Puede estar incluido:
- levantamiento de campo;
- revisión del proyecto básico;
- dimensionamiento;
- planos y diagramas;
- especificaciones;
- listas de materiales;
- integración con la red;
- reuniones de coordinación;
- revisiones hasta aprobación.
Pueden estar excluidos, si esa es la estrategia:
- suministro de equipos;
- instalación;
- licenciamiento de software;
- obras civiles;
- pruebas de fábrica;
- seguimiento de obra;
- As Built elaborado por la empresa ejecutora.
Excluir no significa que el ítem sea innecesario. Significa que está fuera de ese paquete y necesita otro responsable.
Exclusiones mal definidas crean gaps contractuales
Si el proyectista excluye el levantamiento y la constructora presume que los documentos existentes son confiables, nadie verifica la condición real.
Si el integrador excluye la infraestructura eléctrica y el electricista excluye la alimentación de los racks, el gap solo aparece durante la implantación.
Por eso, las exclusiones deben analizarse horizontalmente entre contratos, no solamente dentro de cada SOW.
Las premisas deben ser verificables y gestionables
Una premisa de propuesta puede modificar materialmente el costo.
Ejemplo:
“Se considera que todos los planos existentes están actualizados.”
Si esta condición no es verdadera, habrá impacto en levantamiento, proyecto y plazo. El SOW debe indicar quién valida la información y qué ocurre si la premisa falla.
Las premisas críticas pueden convertirse en condicionantes contractuales o gatillos de cambio.
Las restricciones deben aparecer antes de la propuesta
Una restricción descubierta después de la contratación puede invalidar la solución ofrecida.
Ejemplos:
- trabajo únicamente en ventana nocturna;
- área clasificada;
- el equipo debe caber en un rack existente;
- el sistema no puede detenerse;
- uso de un protocolo específico;
- prohibición de cloud;
- plazo impuesto por un outage anual.
Si la restricción modifica recursos, tecnología o planificación, pertenece al paquete de contratación.
Los entregables deben ser identificables
“Documentación completa” es una expresión débil porque cada empresa puede interpretarla de forma diferente.
Un deliverable register o lista maestra contractual puede contener:
| Código | Entregable | Formato | Revisión | Responsable | Criterio de aceptación |
| DOC-001 | Memoria Descriptiva | PDF/DOCX | AFC | Contratista | comentarios cerrados |
| DWG-001 | Plano de implantación | DWG/PDF | AFC | Contratista | revisión técnica aprobada |
| REP-001 | Informe de pruebas | Final | Contratista | resultados dentro de los límites |
La codificación real depende de la gobernanza documental del proyecto.
SOW y Gestión de Requisitos
El SOW no debe repetir de forma desordenada todas las especificaciones.
La Gestión de Requisitos ayuda a estructurar lo que el producto o servicio necesita satisfacer. El SOW define quién ejecutará el trabajo necesario para producir y demostrar ese cumplimiento.
Una relación útil es:
Requisito → trabajo → entregable → verificación → aceptación.
Si un requisito no tiene trabajo asociado, puede no ser implementado. Si un trabajo no conduce a un requisito o producto necesario, puede ser desperdicio o alcance excesivo.
SOW y WBS
La Work Breakdown Structure descompone el alcance total del proyecto en componentes orientados a entregables.
El léxico del PMI define WBS como la descomposición jerárquica del alcance total del trabajo que debe realizarse para alcanzar objetivos y crear entregables. El SOW puede ser la fuente de la WBS contractual o puede estructurarse utilizando una WBS ya definida.
La regla del 100% es una referencia importante: la descomposición debe cubrir el trabajo necesario sin duplicarlo.
SOW y Work Package
El Work Package en Proyectos de Ingeniería es la unidad en el nivel más bajo de la WBS donde costo, esfuerzo, duración y recursos pueden estimarse y gestionarse.
El SOW establece la obligación global o contractual; los work packages permiten descomponer esa obligación en unidades controlables.
SOW y Requisición Técnica
La Requisición Técnica en Ingeniería organiza el paquete técnico enviado al mercado.
Puede incluir o referenciar:
- SOW;
- especificaciones;
- datasheets;
- planos;
- listas;
- criterios de TBE;
- requisitos documentales;
- instrucciones técnicas.
El SOW es una parte del procurement, no todo el paquete.
SOW y RFP
La RFP solicita una propuesta y define cómo debe responder el proponente.
El SOW define el trabajo que será contratado.
Mezclar ambos en un único texto sin estructura dificulta las revisiones y cambios futuros. Una buena práctica es mantener clara la arquitectura documental: instrucciones de la competencia en un documento y obligación técnica en otro, o en una sección claramente identificada.
SOW y Término de Referencia
El Término de Referencia en Ingeniería tiene una finalidad propia y una fuerte aplicación en procesos de contratación pública.
El SOW de este artículo está orientado a la gestión del trabajo en contratos privados, industriales e internacionales. En ambos casos existen temas comunes — alcance, entregables, criterios de aceptación —, pero el marco jurídico y procedimental no debe mezclarse.
SOW y especificación técnica
La especificación describe los requisitos técnicos del producto, sistema o servicio. El SOW describe el trabajo del contratista.
Ejemplo:
Especificación: el switch debe contar con fuentes redundantes y soportar determinado protocolo.
SOW: el contratista deberá suministrar, instalar, configurar, integrar y probar los switches conforme a la especificación X.
Separar “lo que el producto debe ser” de “lo que el contratista debe hacer” mejora el control de cambios.
SOW orientado al desempeño
Cuando sea posible, el contratante debe especificar resultados y criterios en lugar de controlar innecesariamente el método del proveedor.
Un enfoque de performance-based work statement busca describir resultados y niveles de desempeño, dejando espacio para que el contratista defina los medios de ejecución.
Esto no significa eliminar requisitos de ingeniería. Las interfaces, normas, seguridad, compatibilidad y criterios obligatorios siguen siendo necesarios.
El equilibrio consiste en evitar prescribir el método cuando el objetivo puede definirse mediante un resultado verificable.
Cuándo es necesario prescribir el método
Existen situaciones en las que el método forma parte de la obligación:
- una norma exige un procedimiento específico;
- el sistema existente exige un protocolo definido;
- la inspección depende de un método acreditado;
- la seguridad exige una secuencia determinada;
- el cliente necesita una herramienta corporativa específica;
- la integración depende de un estándar fijo.
La prescripción debe justificarse por la necesidad, no por costumbre.
Interfaces: donde más fallan los SOW
Muchos SOW describen bien el trabajo interno de cada proveedor y mal el punto en que un paquete depende de otro. Es en ese límite donde surgen las preguntas más costosas: ¿quién suministra el dato? ¿quién ejecuta la conexión? ¿quién libera el acceso? ¿quién integra? ¿quién prueba el conjunto? Una interfaz sin owner puede permanecer invisible hasta el comisionamiento.
| Interfaz | Pregunta que el SOW debe responder | Evidencia de handoff |
|---|---|---|
| Ingeniería ↔ proveedor | ¿Quién suministra datos, planos y límites de batería y en qué revisión? | Transmittal, datasheet aprobado, plano de interfaz o ICD. |
| Civil ↔ electromecánica | ¿Quién dimensiona y ejecuta bases, insertos, pernos de anclaje y aberturas? | Plano coordinado, inspección y liberación del frente. |
| Energía ↔ automatización/telecom | ¿Quién entrega alimentación, puesta a tierra, protección y punto de conexión? | Diagrama, identificación, prueba eléctrica y registro de energización. |
| Red ↔ sistema | ¿Quién suministra IP, VLAN, puertos, reglas y valida la comunicación? | Matriz de direccionamiento, configuración y prueba end-to-end. |
| Construcción ↔ comisionamiento | ¿Qué condición hace que el sistema esté listo para prueba? | Checklist de readiness, documentación, punch list y liberación formal. |
| Contratista ↔ owner | ¿Qué aprobaciones, accesos o informaciones son obligación del contratante? | Fecha requerida, responsable y registro de la puesta a disposición. |
La Gestión de Interfaces en Proyectos de Ingeniería profundiza precisamente este control. En el SOW, el objetivo es garantizar que cada dependencia material tenga input, output, owner, plazo y condición de aceptación identificables.
Matriz de responsabilidades en el SOW
La Matriz RACI puede complementar el SOW cuando varias partes participan en un mismo entregable.
Sin embargo, RACI no sustituye una cláusula de alcance. “Responsible” identifica el rol, pero la obligación técnica aún debe describirse.
Datos e ítems suministrados por el contratante
Liste la información y los recursos que proporcionará el cliente:
- planos existentes;
- modelos BIM;
- licencias;
- credenciales;
- acceso a áreas;
- energía temporal;
- equipos existentes;
- bases de datos;
- información de proceso;
- ventanas de parada.
Defina también la fecha y condición de suministro cuando ello afecte el plazo.
Contractor Furnished y Owner Furnished
En contratos internacionales, es común separar los ítems suministrados por el contratante y por el contratista.
Un equipo owner-furnished puede seguir exigiendo al contratista:
- recepción;
- inspección;
- almacenamiento;
- instalación;
- parametrización;
- integración;
- prueba.
“Equipo suministrado por el cliente” no resuelve automáticamente las responsabilidades asociadas.
Criterios de medición
La medición debe acompañar un resultado verificable, no una percepción subjetiva de avance. En contratos de ingeniería, el hito de medición debe indicar qué estado del producto está siendo reconocido: emisión, aprobación, entrega física, prueba, comisionamiento o aceptación.
| Hito posible | Qué demuestra | Cuidado contractual |
|---|---|---|
| Documento emitido | El entregable fue sometido al flujo de análisis. | No equivale a aprobación. |
| Documento aprobado | Los comentarios y requisitos aplicables fueron tratados. | Definir el estado documental aceptado por el contrato. |
| Equipo entregado | El suministro llegó al lugar o condición prevista. | La recepción física no sustituye inspecciones o pruebas. |
| Instalación concluida | El componente fue montado conforme al alcance. | Aún pueden faltar prueba, configuración y documentación. |
| Prueba aprobada | El requisito funcional o de desempeño fue verificado. | Registrar procedimiento, resultado y eventuales pendientes. |
| Sistema comisionado | La integración y el desempeño fueron demostrados al nivel previsto. | Definir fronteras y criterios de readiness. |
| Data Book / documentación final aceptada | La evidencia de ejecución fue consolidada y aprobada. | No dejar todo el valor documental para un hito sin gobernanza intermedia. |
Esta lógica evita medir el 100% de una actividad cuando pruebas, As Built o registros esenciales todavía permanecen pendientes. El Data Book en Ingeniería muestra por qué la documentación debe producirse durante la ejecución y no organizarse solo al cierre.
Criterios de aceptación
La aceptación debe estar prevista desde el SOW. Un criterio de aceptación bien redactado combina requisito, método de verificación, evidencia y autoridad para aceptar. Así, la conclusión deja de depender de frases genéricas como “servicio ejecutado satisfactoriamente”.
Recomendación de la ABNT NBR ISO 21502:2021: los requisitos y criterios de aceptación deben estar asociados a la definición del alcance, y la confirmación de la entrega debe verificar y validar requisitos y estándares de calidad antes de la transferencia. En términos contractuales, esto refuerza que la aceptación debe diseñarse junto con el alcance, no improvisarse al final.
En la práctica, la aceptación puede depender del cumplimiento de requisitos, aprobación documental, resultados de pruebas, cierre de pendientes impeditivos, As Built, backups, capacitación y documentación del fabricante. El Término de Aceptación Técnica en Proyectos de Ingeniería profundiza la formalización de esta etapa.
“Entregado” no es igual a “aceptado”
Una instalación concluida no significa un contrato aceptado. Documentación, pruebas, As Built, backups y cierre de pendientes pueden ser entregables contractuales tan obligatorios como el trabajo físico.
El proveedor puede haber enviado un documento o instalado un sistema. Esto constituye entrega física o documental, pero no necesariamente aceptación.
La aceptación depende de los criterios definidos y de la verificación por parte del contratante.
Esta diferencia debe aparecer en el SOW para evitar la interpretación de que el protocolo de envío cierra automáticamente la obligación.
Revisiones y comentarios
En servicios de ingeniería, el SOW debe prever el ciclo de revisión.
Preguntas importantes:
- ¿cuántos ciclos se esperan?
- ¿los comentarios derivados de un error del contratista cuentan como alcance adicional?
- ¿un cambio de requisito por parte del cliente es un cambio de alcance?
- ¿cuál es el plazo de respuesta de cada parte?
- ¿cómo se resuelven comentarios conflictivos?
No es recomendable limitar la responsabilidad por corregir un error técnico a “dos revisiones”. El número de ciclos comerciales y la obligación de corregir una no conformidad deben tratarse de forma coherente.
Baseline de alcance
Después de la contratación, el SOW y los documentos referenciados forman parte de la baseline contra la cual se evalúan los cambios.
La baseline debe tener versión, fecha y jerarquía documental claras.
Sin esto, una nueva presentación o correo electrónico puede interpretarse como una modificación contractual sin análisis formal.
Gestión de cambios de alcance
Todo cambio debe compararse con la baseline.
Un proceso puede evaluar:
- requisito nuevo o modificado;
- origen del cambio;
- impacto técnico;
- impacto en costo;
- impacto en plazo;
- interfaces afectadas;
- decisión de la autoridad competente;
- actualización documental.
El servicio de Análisis Técnico de Adendas, Cambios de Alcance y Claims actúa cuando la frontera contractual necesita demostrarse técnicamente.
Qué no debe tratarse como cambio
La corrección de errores, el retrabajo por no conformidad o el cumplimiento de una obligación ya prevista no deben clasificarse automáticamente como alcance adicional.
Del mismo modo, el contratante no debe exigir trabajo genuinamente nuevo bajo la justificación genérica de que “forma parte de la solución”.
El análisis debe volver al texto contractual, los requisitos y las evidencias.
Cómo redactar requisitos de trabajo
Una estructura útil es:
Responsable + verbo de acción + objeto + condición/referencia + evidencia esperada.
Ejemplo:
El Contratista deberá ejecutar pruebas de certificación de los enlaces ópticos instalados, conforme a los criterios definidos en la especificación aplicable, y entregar los archivos nativos de los instrumentos y un informe consolidado por enlace.
La frase identifica acción y evidencia.
Evite verbos vagos
Términos como apoyar, colaborar, acompañar y auxiliar pueden ser necesarios, pero necesitan límites.
“Dar soporte al commissioning” puede significar dos horas de reunión o semanas de trabajo en campo.
Defina:
- actividad;
- duración o evento;
- lugar;
- cantidad;
- entregable;
- condición de cierre.
Cantidades y premisas de volumen
Si el precio depende de la cantidad, el SOW debe registrar la base:
- número de sitios;
- puntos;
- equipos;
- documentos;
- reuniones;
- visitas;
- horas;
- km de red;
- interfaces.
Cuando la cantidad es estimada, defina un mecanismo para la variación.
SOW en contratos a precio global
El precio global exige un alcance especialmente maduro porque el contratista asume el compromiso por el conjunto definido.
Las ambigüedades pueden generar contingencia en el precio o disputas posteriores.
El contratante debe garantizar que los documentos de referencia no se contradigan.
SOW en contratos por precios unitarios
La unidad de medición debe definirse claramente.
Ejemplo: “punto de red” puede incluir solo la conectorización o todo el conjunto entre patch panel, cable, toma, identificación, certificación y documentación.
La composición de la unidad debe estar explícita.
SOW en contratos por horas o HTE
Los contratos de Ingeniería Consultiva por horas deben definir el tipo de servicio, el mecanismo de autorización, los productos y la gobernanza.
La hora técnica no sustituye el alcance. Define la unidad comercial de consumo, mientras que cada Orden de Servicio puede detallar objetivo, entregables, responsables, plazo y límite de horas.
SOW en EPC y EPCM
En EPC, la frontera entre ingeniería, procurement, construcción, pruebas y entrega debe ser coherente con las responsabilidades globales del contrato.
En EPCM, el contratista de gestión puede coordinar paquetes sin asumir suministro o construcción. El SOW debe separar claramente gestión, revisión, fiscalización, administración contractual y responsabilidad de los ejecutores.
SOW para Ingeniería Consultiva
Los servicios intelectuales necesitan productos claros sin convertir la consultoría en una simple producción documental.
Ejemplos de entregables:
- diagnóstico;
- estudio de alternativas;
- dictamen;
- revisión independiente;
- plan director;
- proyecto;
- TBE;
- seguimiento técnico;
- informe de fiscalización;
- informe de comisionamiento;
- memoria de decisión.
El valor está en el contenido técnico y en la responsabilidad profesional, no solo en el número de páginas.
Control documental del SOW
El documento debe contar con:
- código;
- revisión;
- estado;
- aprobadores;
- fecha;
- lista de referencias;
- historial de cambios.
Los cambios durante la licitación deben comunicarse a todos los proponentes por el mismo canal de gobernanza.
Jerarquía documental
Los contratos pueden contener SOW, especificaciones, planos, propuesta, aclaraciones y anexos.
La jerarquía o regla de precedencia debe definirse en el contrato. Sin ello, dos exigencias conflictivas pueden permanecer igualmente válidas y generar disputas.
Auditoría de completitud del SOW
Antes de emitir una RFP, revise si existe respuesta para:
- ¿qué se hará?
- ¿dónde?
- ¿por quién?
- ¿qué entradas serán suministradas?
- ¿qué entregables se producirán?
- ¿qué está excluido?
- ¿qué interfaces existen?
- ¿qué normas se aplican?
- ¿qué cantidades sirven de base al precio?
- ¿cuál es el plazo y la ventana operativa?
- ¿cómo medir?
- ¿cómo verificar?
- ¿cómo aceptar?
- ¿cómo tratar los cambios?
Si estas preguntas no tienen respuesta, la propuesta tenderá a contener premisas diferentes entre proveedores.
Ejemplo de falla: proyecto “completo” sin lista de entregables
Un contratista puede interpretar proyecto completo como planos y memoria descriptiva. El owner puede esperar también cálculos, detalles, lista de materiales, especificaciones, modelo BIM, matriz de interfaces y As Built.
La expresión “completo” no resuelve la diferencia.
La lista de entregables hace observable la obligación.
Ejemplo de falla: instalación sin documentación de cierre
Un integrador instala todos los equipos y declara 100% de avance físico. Sin embargo, el contrato también exige pruebas, informes fotográficos, archivos de configuración, backups, As Built y solicitud formal de aceptación.
Si el SOW estructuró estos entregables, la gestión puede diferenciar una instalación concluida de un contrato aceptado.
Ejemplo de falla: interfaz de terceros
Un proveedor entrega el panel; otro ejecuta la alimentación; un tercero integra la automatización. Si nadie tiene la obligación de ejecutar la prueba end-to-end, el sistema puede permanecer sin validación global.
El SOW debe asignar la integración y la prueba sistémica a un responsable.
SOW y riesgo de claims
Un mejor SOW no elimina los cambios legítimos, pero mejora la evidencia para distinguir:
- alcance original;
- detalle necesario para cumplir el alcance original;
- error o retrabajo;
- condición imprevista;
- nueva solicitud;
- cambio de requisito;
- cambio de cantidad;
- modificación de interfaz.
Esta clasificación es central para la administración contractual.
Checklist del SOW antes de la contratación
Verifique:
- objetivo claro;
- contexto suficiente;
- alcance incluido;
- exclusiones;
- premisas;
- restricciones;
- requisitos trazables;
- entregables identificados;
- interfaces asignadas;
- owner-furnished items;
- cantidades base;
- normas y referencias;
- plazo y milestones;
- medición;
- verificación;
- aceptación;
- documentación final;
- change control;
- jerarquía documental;
- revisión y aprobación.
El checklist no sustituye una revisión multidisciplinaria.
Cuándo la Ingeniería Consultiva agrega valor
La Consultoría Técnica de Ingeniería puede transformar una necesidad comercial genérica en un paquete técnico contratable.
La actuación puede involucrar:
- levantamiento de la necesidad;
- definición de requisitos;
- estructuración del SOW;
- revisión de interfaces;
- definición de entregables;
- criterios de TBE;
- criterios de medición y aceptación;
- RFP/RFQ;
- evaluación técnica comparativa;
- soporte a la negociación;
- gestión de cambios durante la ejecución.
La Ingeniería del Propietario también puede revisar el SOW producido por contratistas EPC o proyectistas para proteger los objetivos de ciclo de vida del owner.
Consideraciones finales
Scope of Work es una de las principales herramientas para prevenir ambigüedades en contratos de ingeniería. Define la frontera del trabajo y conecta requisitos con actividades, entregables, interfaces, medición y aceptación. Cuando estas relaciones están claras antes de la licitación, los proveedores cotizan sobre bases más comparables y el contratante reduce el espacio para gaps e interpretaciones contradictorias.
El SOW no debe confundirse con toda la RFP, con la especificación técnica ni con el Término de Referencia. Cada documento tiene una función propia. Tampoco debe ser una lista genérica de verbos: necesita transformar la intención del owner en obligaciones verificables y administrar los puntos en que se encuentran diferentes contratos.
La calidad del alcance se refleja durante todo el ciclo. Mejora la TBE, permite una WBS consistente, sustenta work packages, proporciona base para la medición, organiza el change control y define lo que debe ocurrir para que una entrega sea efectivamente aceptada. En proyectos complejos, redactar el SOW forma parte de la ingeniería de contratación, no es una actividad administrativa posterior al proyecto técnico.
Antes de la licitación, revisar el SOW, las interfaces y los criterios de medición cuesta mucho menos que negociar gaps de alcance cuando el plazo, el proveedor y la movilización ya están comprometidos.
Referencias técnicas
[5] 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. Disponible en: https://www.abntcatalogo.com.br/
[1] NASA. Statements of Work Handbook — NHB 5600.2. Washington, DC: National Aeronautics and Space Administration. Disponible en: https://ntrs.nasa.gov/api/citations/19750015297/downloads/19750015297.pdf
[2] NASA. Guidance for Writing Work Statements — NPG 5600.2B. Washington, DC: National Aeronautics and Space Administration. Disponible en: https://www.hq.nasa.gov/office/procurement/newreq1.htm
[3] PROJECT MANAGEMENT INSTITUTE. PMI Lexicon of Project Management Terms. Version 5.0. Newtown Square: PMI, 2026. Disponible en: https://www.pmi.org/-/media/pmi/documents/registered/pdf/pmbok-standards/pmi-lexicon-pm-terms.pdf
[4] 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
Preguntas frecuentes
Es la definición de la extensión y los límites del trabajo contratado, incluyendo actividades, entregables, interfaces, premisas, exclusiones y criterios de conclusión.
La sigla SOW se utiliza formalmente con frecuencia para Statement of Work. Scope of Work es el núcleo de definición del trabajo y puede ser una sección de ese documento. Las empresas también usan los términos de forma intercambiable, por lo que la convención debe explicitarse.
Pueden contener elementos similares, pero el Término de Referencia posee un marco propio, especialmente en contrataciones públicas. El SOW se utiliza ampliamente en contratos privados, industriales e internacionales para definir el trabajo.
Objetivo, alcance incluido, exclusiones, premisas, restricciones, entregables, interfaces, requisitos aplicables, cantidades, plazo, medición, verificación y criterios de aceptación.
La especificación define requisitos del producto, sistema o servicio. El SOW define el trabajo que el contratista debe ejecutar para entregar y demostrar el cumplimiento.
No. El SOW describe el trabajo contratado. La WBS descompone jerárquicamente el alcance en componentes y work packages gestionables.
Integra la baseline contractual. Una nueva solicitud puede compararse con el alcance, las premisas, las exclusiones y las interfaces originales para determinar si existe una modificación real.
No necesariamente. La entrega indica disponibilidad física o documental; la aceptación exige que se hayan satisfecho los criterios contractuales de verificación y conclusión.
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
- Implantación y Estructuración de PMO de Ingeniería
- Gestión de Documentos de Ingeniería: GED, EDMS, revisiones y trazabilidad
Servicios relacionados
- Consultoría Técnica de Ingeniería
- Ingeniería del Propietario
- Gestión de Proyectos de Ingeniería
- Análisis Técnico de Adendas, Cambios de Alcance y Claims
- 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
- RFP en Ingeniería: alcance, requisitos y criterios de selección
- Requisición Técnica en Ingeniería
- TBE — Technical Bid Evaluation
- Work Package en Proyectos de Ingeniería
- Alcance Contractual en Ingeniería
- Estrategia de Contratación en Ingeniería
Contenidos técnicos relacionados
- Término de Referencia en Ingeniería
- Gestión de Requisitos en Ingeniería
- Gestión de Interfaces en Proyectos de Ingeniería
- Matriz RACI en Proyectos de Ingeniería
- Data Book en Ingeniería
- Guía Completa sobre Ingeniería Consultiva
- Gestión de Ingeniería: guía de procesos, gobernanza y desempeño
- Owner’s Engineering: framework ejecutivo para contratación, gobernanza y aceptación
- Framework de Handover Técnico de Obras y Sistemas
