Statement of Work (SOW): qué incluir (con plantilla)

Un statement of work (SOW) es el documento que convierte un acuerdo de palabra en un compromiso de proyecto vinculante. Sin uno, tanto el cliente como el proveedor entran en una colaboración con supuestos distintos sobre qué se entrega, cuándo y a qué costo.

Definir bien el SOW desde el inicio ahorra semanas de retrabajo, disputas y costosos debates de alcance más adelante. Esta guía cubre cada sección que necesita un SOW sólido, los tres tipos entre los que elegir, cómo se compara con documentos similares y una plantilla que puede adaptar hoy mismo.

¿Qué es un statement of work (SOW)?

Un statement of work (SOW) es un documento formal de proyecto que define el alcance del trabajo, los entregables, el cronograma, los criterios de aceptación y los términos entre un cliente y un proveedor o equipo de proyecto. Es el complemento a nivel contractual del project charter: el charter autoriza el proyecto internamente; el SOW rige el acuerdo externo o interfuncional que hace posible el trabajo.

El SOW responde cinco preguntas que deben resolverse antes de que comience el trabajo:

• Qué se va a hacer? (alcance y entregables)
• Cómo se va a hacer? (metodología y estándares)
• Cuándo se va a hacer? (cronograma e hitos)
• Dónde se va a hacer? (ubicación y entorno)
• Cuánto va a costar? (términos de pago y tarifas)

Los contratos a menudo adjuntan un SOW como anexo, lo que lo convierte en un documento con referencia legal. Por eso la precisión importa aquí mucho más que en las herramientas de planificación interna.

Datos clave

• Las organizaciones con un proceso formal de SOW reportan una reducción del 28% en disputas de alcance y órdenes de cambio en comparación con aquellas que dependen únicamente de acuerdos verbales (Project Management Institute, 2023).
• El 73% de los proyectos de TI fallidos citó requisitos y alcance poco claros como causa principal (Standish Group CHAOS Report, 2022).
• El SOW promedio ocupa de 3 a 10 páginas para colaboraciones de servicios profesionales; los contratos complejos de construcción o gubernamentales a menudo alcanzan más de 50 páginas (PMI Practice Standard for Project Estimating, 2021).

Qué incluir en un statement of work

Todo SOW debe cubrir las siguientes secciones. Algunas industrias agregan cláusulas especializadas (seguridad, cumplimiento, seguros), pero estas diez forman la base universal.

Las secciones de alcance y entregables tienen el mayor peso legal. El lenguaje vago aquí es el principal impulsor de disputas. "Proporcionar un sitio web" no es un entregable. "Entregar un sitio web de marketing responsivo de cinco páginas con un formulario de contacto, integración de CMS y cumplimiento de accesibilidad WCAG 2.1 AA para el 31 de julio" sí lo es.

La sección de supuestos a menudo se omite, pero es igual de importante. Si su SOW asume que el cliente proporcionará los activos de marca para la semana dos y no lo hace, necesita un registro escrito de que el retraso se originó en el cliente, no en usted.

Tipos de statement of work

Existen tres tipos de SOW, y elegir el correcto depende de qué tan bien pueda definirse el alcance del proyecto desde el principio.

Un SOW de diseño/detalle le da al cliente el máximo control pero requiere el mayor trabajo de especificación previa. Si los requisitos están incompletos, el proveedor se ceñirá precisamente a la letra del documento y el cliente terminará insatisfecho con un resultado técnicamente conforme.

Un SOW basado en desempeño le da al proveedor flexibilidad para innovar, pero exige resultados claros y medibles. Si los criterios de aceptación son débiles, las disputas sobre si se cumplió el estándar se vuelven frecuentes.

La mayoría de los SOW del mundo real combinan tipos. Un proyecto de software podría usar criterios basados en desempeño para la aceptación de funciones mientras especifica la composición exacta del equipo (nivel de esfuerzo) para la dotación de personal.

SOW vs project charter vs scope statement

Estos tres documentos suelen confundir a los equipos porque se superponen. Así se diferencian:

Un proyecto podría tener los tres. El SOW con el cliente define lo que el proveedor debe entregar. El project charter autoriza internamente al PM del proveedor a movilizar recursos. El scope statement desglosa el trabajo para la planificación del equipo interno.

El SOW también se diferencia de un Master Service Agreement (MSA). Un MSA establece los términos legales generales para todo el trabajo entre dos partes (responsabilidad, propiedad intelectual, resolución de disputas). Los SOW luego se emiten bajo el MSA para colaboraciones específicas. Piense en el MSA como el marco y en cada SOW como una orden de tarea dentro de él.

Cómo redactar un statement of work

Paso 1: Alinee el alcance antes de redactar

Hable con cada parte interesada antes de abrir un documento. Realice un taller de alcance con el cliente, los líderes de entrega, legal y finanzas. Use una matriz de trazabilidad de requisitos para capturar y vincular los requisitos con los entregables. La redacción es sencilla una vez que sabe con qué está de acuerdo.

Paso 2: Redacte el resumen del proyecto

Un párrafo, en lenguaje sencillo. Indique quién es el cliente, quién es el proveedor, qué problema de negocio resuelve el proyecto y el resultado de negocio esperado. Evite el lenguaje de marketing. "Mejorar el tiempo de respuesta a leads del cliente de 48 horas a menos de 4 horas" es más útil que "transformar las operaciones de ventas del cliente".

Paso 3: Defina el alcance y los elementos fuera de alcance

Enumere cada tarea y servicio que forma parte de la colaboración. Luego enumere explícitamente lo que está fuera de alcance. Esta segunda lista es igual de importante. Si no dice que algo está fuera de alcance, algunas partes interesadas asumirán que está incluido.

Una estructura de desglose del trabajo (WBS) es una herramienta práctica aquí. Construya primero la WBS y luego úsela para completar la sección de alcance de su SOW. La WBS lo obliga a descomponer el trabajo hasta un nivel donde no sobrevive nada ambiguo.

Paso 4: Defina los entregables y los criterios de aceptación

Para cada entregable, responda: ¿Qué es? ¿Qué formato? ¿Quién lo revisa? ¿Qué estándar de calidad debe cumplir? ¿Cuál es la fecha límite de aprobación?

Conecte los criterios de aceptación con su línea base del proyecto para tener un punto de referencia con el cual medir el progreso durante todo el proyecto.

Paso 5: Construya el cronograma

Mapee los hitos a fechas del calendario. Incluya las dependencias del lado del cliente (entrega de datos, aprobaciones, autorizaciones) con sus fechas de vencimiento. Anote qué hitos son puertas de control: el trabajo en la siguiente fase no puede comenzar hasta que el cliente apruebe la anterior.

Un plan de comunicación encaja naturalmente con este paso. Defina cómo se reportará el progreso, con qué frecuencia y a quién.

Paso 6: Acuerde los términos de pago

Especifique el valor total del contrato, el calendario de pagos (basado en hitos o en el calendario), las instrucciones de facturación y qué activa cada pago. Incluya disposiciones de pago tardío y qué sucede con el trabajo si el pago se retrasa.

Paso 7: Agregue la gestión de cambios y las firmas

Defina el proceso de solicitud de cambios: quién puede presentar un cambio, quién lo evalúa, cuánto tiempo toma la revisión y cómo afectan los cambios al precio y al cronograma. Ambas partes firman. Mantenga las copias firmadas accesibles tanto para el PM como para legal.

Consulte su matriz RACI al asignar la autoridad de aprobación en el proceso de cambios. Esto evita confusión sobre quién es responsable de las decisiones.

Plantilla de statement of work

A continuación, una estructura mínima de SOW que puede copiar y adaptar. Reemplace los campos entre corchetes con los detalles reales de su proyecto.

---

STATEMENT OF WORK

Nombre del proyecto: [Nombre del Proyecto] Cliente: [Organización Cliente] Proveedor/prestador de servicios: [Su Organización] Fecha de vigencia: [Fecha] Referencia de contrato: [Número de MSA o ID de contrato, si aplica]

---

1. Resumen del proyecto

[Nombre del cliente] contrata a [Nombre del proveedor] para [describir qué hace el proyecto y el resultado de negocio que aborda]. Este SOW rige todo el trabajo realizado entre el [Fecha de Inicio] y el [Fecha de Fin].

2. Alcance del trabajo

En alcance:

• [Tarea o servicio 1]
• [Tarea o servicio 2]
• [Tarea o servicio 3]

Fuera de alcance:

• [Elemento excluido 1]
• [Elemento excluido 2]

3. Entregables

4. Cronograma e hitos

5. Criterios de aceptación

Cada entregable se acepta cuando: [describir el estándar medible, p. ej., "todas las pruebas automatizadas pasan sin defectos críticos, el equipo de QA del cliente aprueba dentro de los 5 días hábiles posteriores a la entrega"].

6. Supuestos y restricciones

• El cliente proporcionará [datos o acceso específico] para el [Fecha].
• El trabajo se realiza en [ubicación o entorno].
• Todos los entregables están en [idioma].

7. Términos de pago

Valor total del contrato: [Monto] Calendario de pagos: [p. ej., 30% al ejecutar, 40% al aprobar el hito 2, 30% al aceptar de forma final] Facturación: [Instrucciones para el envío de facturas]

8. Gestión de cambios

Los cambios al alcance, cronograma o costo requieren una Solicitud de Cambio por escrito presentada a [nombre/rol]. El proveedor responderá dentro de [X] días hábiles con una evaluación de impacto. Ningún cambio entra en vigor sin la aprobación por escrito de ambas partes.

9. Firmas autorizadas

---

Errores comunes al redactar un statement of work

Entregables vagos. "Un informe" no es un entregable. "Un análisis escrito de 20 páginas en formato PDF que cubre X, Y y Z, entregado para [fecha]" sí lo es. Cada entregable necesita un formato, un estándar de éxito y una fecha de vencimiento.

Falta la lista de elementos fuera de alcance. Los clientes a menudo asumen que el trabajo relacionado está incluido a menos que se excluya explícitamente. Si no lo escribe, terminará haciéndolo de forma gratuita.

Cronogramas poco realistas sin dependencias del cliente. Los cronogramas que dependen de acciones del cliente (entrega de datos, aprobaciones, provisión de acceso) necesitan mostrar esas dependencias explícitamente. Si el cliente se retrasa dos semanas con una exportación de datos, su fecha de entrega se desplaza. El SOW debería decirlo.

Criterios de aceptación que no se pueden medir. "Alta calidad" no es un criterio de aceptación. "Cero errores SEV-1, tiempo de carga inferior a 2 segundos en una conexión 4G, cumplimiento WCAG 2.1 AA verificado por escaneo automatizado" sí lo es.

Firma de una sola parte. Un SOW firmado por una sola parte no es un acuerdo mutuo. Ambas partes deben firmar antes de que comience el trabajo.

Ignorar la sección de gestión de cambios. Los equipos que se saltan esta sección pasan la segunda mitad del proyecto discutiendo si el alcance cambió y quién debe pagar por ello. Redacte el proceso antes de que llegue la primera solicitud de cambio.

Preguntas frecuentes

¿Cuál es la diferencia entre un SOW y un contrato?

Un contrato es el acuerdo legal que rige la relación entre dos partes, incluida la responsabilidad, la propiedad de la propiedad intelectual y la resolución de disputas. Un SOW típicamente es un anexo o adjunto de un contrato que especifica el trabajo para una colaboración particular. El contrato proporciona el marco legal; el SOW proporciona los detalles del proyecto.

¿Cuándo debe usar un SOW en lugar de un project charter?

Use un SOW cuando necesite un acuerdo mutuo con un proveedor externo o un equipo interno separado que opera como un proveedor. Use un project charter cuando esté iniciando formalmente un proyecto dentro de su propia organización y necesite otorgar a un gerente de proyecto la autoridad para usar recursos. Muchos proyectos necesitan ambos.

¿Qué tan largo debe ser un SOW?

Para colaboraciones de servicios profesionales (consultoría, desarrollo de software, marketing), de tres a diez páginas típicamente cubre todo lo necesario. Los contratos gubernamentales y los proyectos de infraestructura pueden ser mucho más largos porque las regulaciones exigen especificaciones detalladas. Apunte a que sea tan largo como sea necesario y no más. Rellenar un SOW con texto genérico no lo fortalece; hace que las cláusulas críticas sean más difíciles de encontrar.

¿Se puede cambiar un SOW después de firmado?

Sí, mediante el proceso de gestión de cambios definido en el propio SOW. Ambas partes deben acordarlo por escrito. Los acuerdos verbales sobre cambios de alcance crean exactamente las disputas que el SOW se redactó para prevenir. Documente siempre los cambios formalmente, con los cronogramas y costos actualizados reflejados por escrito.

¿Es un SOW legalmente vinculante?

Cuando se incorpora a un contrato firmado, sí. Un SOW independiente firmado por ambas partes también tiene peso legal como documento contractual. Consulte a su equipo legal para obtener orientación específica de su jurisdicción sobre la exigibilidad.

---

Un statement of work bien redactado se paga solo la primera vez que surge una disputa de alcance. Con entregables claros, criterios de aceptación medibles y un proceso de cambios explícito, ambas partes dedican menos tiempo a discutir y más tiempo a construir. Use la plantilla anterior como punto de partida, haga que ambas partes revisen cada sección con cuidado y trate la línea de firma como el momento en que realmente comienza el proyecto.