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 deberá ejecutarse en una contratación 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, documento que contiene la descripción formal del trabajo; dentro de él, el scope of work es el núcleo que delimita lo que se hará. En proyectos industriales, EPC/EPCM y servicios de Ingeniería Consultiva, esta definición debe ser suficientemente precisa para contratar, medir, controlar cambios y aceptar entregas sin convertir el documento en una prescripción excesiva de cómo deberá trabajar el proveedor.
Un buen SOW reduce ambigüedades antes de la contratación. Explica el objetivo, describe productos y servicios esperados, explicita lo que está incluido y excluido, registra premisas y restricciones, identifica interfaces con terceros, establece datos de entrada y define cómo será verificada y aceptada cada entrega. También crea la referencia contra la cual podrán analizarse cambios de alcance, claims, mediciones y responsabilidades durante la ejecución.
En el contexto brasileño, SOW no debe tratarse automáticamente como sinónimo de Termo de Referência. El Termo de Referência 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 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 continúa siendo válida: el documento debe indicar qué debe entregarse, en qué condiciones y con qué criterios de desempeño y aceptación.
En la práctica empresarial, ambos términos aparecen frecuentemente mezclados. Para 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 gestionable para estimar y controlar costo, esfuerzo, duración y recursos.
Esta distinción evita que una frase genérica llamada “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ántos ciclos de revisión están incluidos?
- ¿quién coordina las interfaces?
- ¿el proveedor debe emitir memorias de cálculo o solo planos?
- ¿el As-Built forma parte del alcance?
- ¿las pruebas y el commissioning 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 únicamente después de la contratación, la negociación deja de ocurrir en un entorno competitivo y pasa a ocurrir 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.
SOW no es solo una lista de actividades
Listar verbos como “diseñar, instalar, probar y entregar” no define un alcance suficiente.
Una contratación debe conectar la actividad con un producto verificable. Por ejemplo:
Débil: desarrollar el diseño ejecutivo de telecomunicaciones.
Más estructurado: desarrollar el diseño 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 comentarios hasta la 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 criterio de aceptación continúa abierto a interpretaciones aunque ocupe muchas páginas.
Estructure la contratación con Consultoría Técnica de Ingeniería
No existe un único sumario 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 el precio y el 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 prueba, Data Book, As-Built o documentación de aceptación. |
| Exclusiones y límites | Explicitar fronteras que razonablemente podrían interpretarse como incluidas. | Relación de exclusiones e identificación del responsable alternativo cuando el elemento 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 operacionales, 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 que solo trabajo formalmente aprobado sea incorporado al proyecto. Aplicado al SOW, esto significa definir desde la contratación no solo “qué hacer”, sino cómo será verificado el resultado y en qué condición podrá considerarse aceptado.
Cuando varios paquetes se encuentran, la Gestión de Interfaces en Proyectos de Ingeniería complementa el SOW al hacer explícitos los handoffs y los responsables entre contratos.
Alcance incluido y alcance excluido
La frontera debe ser explícita.
Considere una contratación para diseño ejecutivo de seguridad electrónica. Puede incluir:
- levantamiento de campo;
- revisión del diseño básico;
- dimensionamiento;
- planos y diagramas;
- especificaciones;
- listas de materiales;
- integración con 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;
- acompañamiento de obra;
- As-Built elaborado por la ejecutora.
Excluir no significa que el elemento sea innecesario. Significa que está fuera de ese paquete y debe tener 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 contratista eléctrico excluye la alimentación de los racks, el gap solo aparece durante la implementación.
Por eso, las exclusiones deben analizarse horizontalmente entre contratos, no solo dentro de cada SOW.
Las premisas deben ser verificables y administrables
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, diseño 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 ofertada.
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 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 debe 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 de PMI define WBS como la descomposición jerárquica del alcance total que debe realizarse para alcanzar objetivos y crear entregables. El SOW puede ser la fuente para 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
O 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 ser estimados y gestionados.
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 pieza de 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 revisiones y futuras modificaciones. Una buena práctica es mantener clara la arquitectura documental: instrucciones de la licitación en un documento, obligación técnica en otro o en una sección claramente identificada.
SOW y Termo de Referência
O Termo de Referência en Ingeniería tiene una finalidad propia y 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, entregas, criterios de aceptación —, pero el encuadre jurídico y procedimental no debe mezclarse.
SOW y especificación técnica
La especificación describe requisitos técnicos del producto, sistema o servicio. El SOW describe el trabajo de la contratista.
Ejemplo:
Especificación: el switch debe tener fuentes redundantes y soportar un determinado protocolo.
SOW: la 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 a 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. Interfaces, normas, seguridad, compatibilidad y criterios obligatorios continúan siendo necesarios.
El equilibrio consiste en evitar especificar 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 el hábito.
Interfaces: dónde fallan más los SOW
Muchos SOW describen bien el trabajo interno de cada proveedor y mal el punto donde un paquete depende de otro. Es en esa frontera donde surgen las preguntas más costosas: ¿quién proporciona 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 commissioning.
| Interfaz | Pregunta que el SOW debe responder | Evidencia de handoff |
|---|---|---|
| Ingeniería ↔ proveedor | ¿Quién proporciona datos, planos y battery limits y en qué revisión? | Transmittal, datasheet aprobado, plano de interfaz o ICD. |
| Civil ↔ electromecánica | ¿Quién dimensiona y ejecuta bases, insertos, anclajes y aberturas? | Plano coordinado, inspección y liberación de 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 proporciona IP, VLAN, puertos, reglas y valida la comunicación? | Matriz de direccionamiento, configuración y prueba end-to-end. |
| Construcción ↔ commissioning | ¿Qué condición hace que el sistema esté listo para pruebas? | Checklist de readiness, documentación, punch list y liberación formal. |
| Contratista ↔ owner | ¿Qué aprobaciones, accesos o información son obligación del contratante? | Fecha requerida, responsable y registro de disponibilidad. |
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 un rol, pero la obligación técnica todavía 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 fecha y condición de suministro cuando esto afecte el plazo.
Contractor Furnished y Owner Furnished
En contratos internacionales, es común separar los ítems suministrados por el contratante y por la contratista.
Un equipo owner-furnished puede seguir exigiendo de la contratista:
- recepción;
- inspección;
- almacenamiento;
- instalación;
- configuració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, commissioning o aceptación.
| Hito posible | Qué demuestra | Precaución 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 status documental aceptado por el contrato. |
| Equipo entregado | El suministro llegó al lugar o condición prevista. | La recepción física no sustituye inspección o pruebas. |
| Instalación concluida | El componente fue montado conforme al alcance. | Todavía pueden faltar pruebas, 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 único 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 solo organizarse 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 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 prueba, 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”
Instalación concluida no significa 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 un 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 error de la 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 corrección de error técnico a “dos revisiones”. El número de ciclos comerciales y la obligación de corregir no conformidades 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 modificación contractual sin análisis formal.
Gestión de cambios de alcance
El 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 ser demostrada 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:
La 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 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 de precio global
El precio global exige un alcance especialmente maduro porque la contratista asume el compromiso por el conjunto definido.
Las ambigüedades pueden generar contingencia en el precio o disputa posterior.
El contratante debe garantizar que los documentos de referencia no se contradigan.
SOW en contratos por precios unitarios
La unidad de medición debe estar claramente definida.
Ejemplo: un “punto de red” puede incluir únicamente 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, mecanismo de autorización, productos y gobernanza.
La hora técnica no sustituye el alcance. Define la unidad comercial de consumo, mientras 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 consistente 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 transformar la consultoría en simple producción documental.
Ejemplos de entregables:
- diagnóstico;
- estudio de alternativas;
- dictamen técnico;
- revisión independiente;
- plan director;
- diseño;
- TBE;
- acompañamiento técnico;
- informe de fiscalización;
- informe de commissioning;
- 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 poseer:
- código;
- revisión;
- status;
- aprobadores;
- fecha;
- lista de referencias;
- historial de cambios.
Los cambios durante la licitación deben comunicarse a todos los proponentes por la misma vía 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 esto, dos exigencias conflictivas pueden permanecer igualmente válidas y generar disputa.
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é inputs serán suministrados?
- ¿qué entregables se producirán?
- ¿qué está excluido?
- ¿qué interfaces existen?
- ¿qué normas se aplican?
- ¿qué cantidades sustentan el precio?
- ¿qué plazo y ventana operacional?
- ¿cómo medir?
- ¿cómo verificar?
- ¿cómo aceptar?
- ¿cómo tratar cambios?
Si estas preguntas no tienen respuesta, la propuesta tiende a contener premisas diferentes entre proveedores.
Ejemplo de falla: diseño “completo” sin lista de entregables
Una contratista puede interpretar un diseño completo como planos y memoria. 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% físico. El contrato, sin embargo, 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 instalación concluida de contrato aceptado.
Ejemplo de falla: interfaz de terceros
Un proveedor entrega el panel; otro ejecuta alimentación; un tercero integra 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 SOW mejor no elimina cambios legítimos, pero mejora la evidencia para distinguir:
- alcance original;
- detalle necesario para cumplir el original;
- error o retrabajo;
- condición imprevista;
- nueva solicitud;
- cambio de requisito;
- cambio de cantidad;
- cambio de interfaz.
Esta clasificación es central para la administración contractual.
Checklist de 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.
La checklist no sustituye la 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;
- igualación técnica;
- 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 de prevención de 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 son 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 o con el Termo de Referência. Cada documento tiene su propia función. Tampoco debe ser una lista genérica de verbos: debe transformar la intención del owner en obligaciones verificables y administrar los puntos donde se encuentran diferentes contratos.
La calidad del alcance aparece durante todo el ciclo. Mejora la TBE, permite una WBS consistente, sustenta work packages, da base a 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 de una actividad administrativa posterior al diseño 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 después de que plazo, proveedor y 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. Disponível em: https://www.abntcatalogo.com.br/
[1] NASA. Statements of Work Handbook — NHB 5600.2. Washington, DC: National Aeronautics and Space Administration. Disponível em: 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. Disponível em: 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. Disponível em: 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. Disponível em: 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 utilizan los términos de forma intercambiable, por lo que la convención debe explicitarse.
Pueden contener elementos similares, pero el Termo de Referência posee un encuadre 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 la contratista debe ejecutar para entregar y demostrar 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, premisas, exclusiones e interfaces originales para determinar si existe un cambio real.
No necesariamente. La entrega indica disponibilidad física o documental; la aceptación exige que los criterios contractuales de verificación y conclusión hayan sido satisfechos.
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
- 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
- Termo de Referência 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
