SOW agile vs waterfall : qué estructura para tus proyectos IT

Introducción: por qué el modelo de SOW condiciona el éxito contractual

En el universo de la consultoría IT y el desarrollo de software, el Statement of Work (SOW) no es un simple documento administrativo: es la columna vertebral contractual que rige la relación entre el prestador y su cliente. En 2026, la práctica totalidad de los proyectos IT oscila entre dos filosofías radicalmente diferentes — agile y waterfall — y esta distinción tiene repercusiones concretas en la redacción de cada cláusula del SOW: entregables, hitos, modalidades de pago, criterios de aceptación y gestión de modificaciones. Comprender la diferencia entre un SOW agile y un SOW waterfall es evitar litigios contractuales que cuestan en promedio el 15 % del presupuesto del proyecto según las encuestas sectoriales del PMI. Este artículo detalla las estructuras, los riesgos y las buenas prácticas para cada enfoque.

---

¿Qué es un SOW waterfall y cómo estructurarlo?

El modelo waterfall —o ciclo en V— se basa en una lógica secuencial: cada fase (encuadre, diseño, desarrollo, pruebas, despliegue) se sucede de manera lineal. Un SOW waterfall refleja esta lógica definiendo a priori y de manera exhaustiva el conjunto del perímetro.

Características estructurales del SOW waterfall

Un SOW waterfall típico comprende:

• Una descripción detallada del perímetro funcional: cada funcionalidad se describe, a menudo acompañada de especificaciones funcionales generales (SFG) o un pliego de condiciones anexado.
• Hitos contractuales firmes (milestones): entrega del prototipo validado, recepción funcional, puesta en producción, período de garantía. Cada hito se asocia a una fecha de calendario y a un porcentaje del presupuesto.
• Un precio global forfaitario (fixed-price): la contrapartida financiera se determina con anterioridad. El prestador asume el riesgo de desbordamiento si el perímetro está mal calibrado.
• Criterios de aceptación precisos: las condiciones de validación de cada entregable se definen contractualmente, reduciendo litigios en la recepción.

Ventajas y limitaciones del SOW waterfall para proyectos IT

El modelo waterfall ofrece una previsibilidad presupuestaria total para el cliente, lo que lo convierte en la opción privilegiada para proyectos con perímetro estable: integración ERP, migración de datos estructurados, desarrollo de una aplicación cuyas especificaciones están congeladas. En cambio, se adapta mal a las evoluciones de necesidades durante la ejecución del proyecto. Cualquier modificación debe ser objeto de una enmienda contractual (Change Request), proceso a menudo lento y fuente de tensión. Según los datos del Standish Group Chaos Report 2024, los proyectos waterfall superan su presupuesto inicial en el 45 % de los casos, precisamente por la subestimación del perímetro en la firma.

Para profundizar en la redacción y la firma de este tipo de documento, el hub SOW de Certyneo centraliza modelos, cláusulas tipo y buenas prácticas.

---

¿Qué es un SOW agile y en qué difiere estructuralmente?

El SOW agile rompe con la lógica del perímetro congelado. Contractualiza una capacidad de entrega (velocidad de un equipo, número de sprints, perfiles puestos a disposición) más que una lista exhaustiva de funcionalidades.

Los pilares de un SOW agile: sprints, backlog y criterios de valor

Un SOW agile estructurado alrededor de Scrum o Kanban integra típicamente:

• Una descripción de roles y equipos: Product Owner del lado del cliente, Scrum Master y desarrolladores del lado del prestador, con las tarifas diarias o mensuales asociadas (modelo Time & Materials o presupuesto por sprint).
• Un backlog inicial priorizado: no contractualmente congelado, pero sirviendo de base de inicio. Evoluciona en cada sprint review con el acuerdo de ambas partes.
• Sprints como unidad de facturación: cada sprint (2 a 4 semanas) constituye un ciclo facturable, con sus ceremonias agile definidas (planning, daily, review, retrospectiva).
• Criterios de Definition of Done (DoD): condiciones técnicas y funcionales que cada story debe satisfacer para considerarse entregada, reemplazando los criterios de aceptación monolíticos del waterfall.
• Una cláusula de revisión presupuestaria periódica: después de N sprints, las partes pueden revisar el perímetro global sin enmienda formal, dentro de los límites de una envoltura presupuestaria global definida.

Modelos de precio en un SOW agile: Time & Materials vs presupuesto por sprint

Dos modelos coexisten en la práctica:

Time & Materials (T&M): el cliente paga el tiempo efectivamente consumido por los equipos, según tarifas diarias contractualizadas. Este modelo maximiza la flexibilidad pero transfiere el riesgo presupuestario al cliente. Es apropiado para proyectos exploratorios o fases de ideación.

Presupuesto por sprint (Sprint Box): el prestador se compromete sobre una capacidad de entrega fija por sprint (número de puntos o días/hombre), por un precio fijo. Este modelo híbrido combina la previsibilidad financiera del waterfall y la flexibilidad del backlog agile. Es hoy el modelo dominante en las ESN francesas para proyectos de desarrollo web y móvil.

Los modelos de contratos disponibles en Certyneo incluyen templates SOW adaptados a cada uno de estos modelos de precio, listos para ser personalizados y firmados electrónicamente.

---

Tabla comparativa: SOW agile vs waterfall, las diferencias clave

| Criterio | SOW Waterfall | SOW Agile | |---|---|---| | Perímetro | Fijo y exhaustivo desde la firma | Evolutivo, gestionado vía backlog priorizado | | Entregables | Definidos contractualmente y fechados | Definidos por sprint, validados continuamente | | Hitos | Milestones firmes con fechas de calendario | Revisiones de sprint periódicas | | Precio | Presupuesto global fijo | T&M o presupuesto por sprint | | Gestión de cambios | Enmienda formal (Change Request) | Repriorización del backlog | | Riesgo presupuestario | Prestador (perímetro congelado) | Cliente (T&M) o compartido (sprint box) | | Criterios de aceptación | Recepción formal en hitos definidos | Definition of Done por story | | Ideal para | Perímetro estable, restricciones regulatorias | Evolución continua, innovación |

---

Cómo elegir entre SOW agile y waterfall para tu proyecto IT consulting

Analizar la estabilidad del perímetro y la madurez del cliente

El primer criterio de elección es la estabilidad de la necesidad expresada. Si el cliente dispone de un pliego de condiciones validado, wireframes finalizados y una DSI capaz de conducir una recepción formal, el SOW waterfall minimiza el riesgo contractual. En cambio, si el proyecto está en fase de discovery, si las necesidades de negocio evolucionan rápidamente o si el cliente desea implicar usuarios finales en las validaciones iterativas, el SOW agile es estructuralmente más apropiado.

Un indicador concreto: si el pliego de condiciones inicial supera el 80 % de estabilidad funcional estimada, opta por waterfall. Por debajo del 60 %, el enfoque agile reducirá significativamente las enmiendas y los desbordamientos.

Tener en cuenta el contexto regulatorio y sectorial

Ciertos sectores imponen restricciones que influyen en la elección del modelo de SOW. Los proyectos en sanidad (certificación HDS, alojamiento de datos de salud), finanzas (conformidad DORA, auditoría ISO 27001) o contratación pública (Código de la Contratación Pública) necesitan a menudo una trazabilidad documental y una validación formal de entregables más cercana al modelo waterfall, aunque los métodos de desarrollo sean agiles internamente.

En este contexto híbrido, un SOW llamado ScrumFall —o Agile at Scale— combina un perímetro macro contractualmente congelado (fases del proyecto, presupuesto global) con una ejecución agile interna. Este enfoque está hoy ampliamente documentado en los frameworks SAFe (Scaled Agile Framework) y LeSS.

Asegurar la firma del SOW independientemente del modelo retido

Independientemente del modelo elegido, la validez jurídica del SOW depende de su firma conforme a las reglas. En Francia, la firma electrónica avanzada o cualificada conforme al Reglamento eIDAS garantiza el valor probatorio del documento en caso de litigio. Para las enmiendas agile (repriorisaciones formales, extensiones de sprint), la firma electrónica acelera considerablemente los plazos de validación: mientras que una firma manuscrita requiere 3 a 7 días, una solución como Certyneo permite cerrar la validación en menos de 24 horas, sin desplazamientos.

Los equipos de consultoría que gestionan numerosos SOW simultáneamente pueden apoyarse en el generador de contratos por IA de Certyneo para producir SOW adaptados a cada contexto (agile, waterfall, híbrido) en pocos minutos, luego enviarlos a firma en flujo integrado.

Marco legal aplicable a los SOW en proyecto IT y consultoría

El Statement of Work es un contrato completo, sujeto al derecho común de los contratos así como a las regulaciones sectoriales específicas. En Francia, varios textos regulan su redacción, su validez y su ejecución.

Código civil y derecho de los contratos

El SOW se rige en primer lugar por el Código civil, y más precisamente por las disposiciones de la reforma del derecho de los contratos de 2016 (ordenanza n°2016-131, codificada en los artículos 1101 y siguientes). El artículo 1194 del Código civil recuerda que los contratos obligan no solo a lo expresado en ellos, sino también a todas las consecuencias que les da la equidad, el uso o la ley — lo que incluye las prácticas reconocidas del sector IT (Agile Manifesto, estándares PMI/PMBOK).

El artículo 1353 rige la carga de la prueba en caso de litigio: en ausencia de cláusula contraria, corresponde al prestador probar que ha cumplido sus obligaciones. Un SOW bien redactado, con criterios de aceptación precisos (DoD o hitos waterfall), prácticamente invierte esta carga.

Firma electrónica y valor probatorio: eIDAS y Código civil

La firma electrónica del SOW está regulada por el Reglamento europeo eIDAS n°910/2014, cuyo artículo 25 dispone que la firma electrónica cualificada tiene el mismo valor jurídico que una firma manuscrita en todos los Estados miembros. En Francia, los artículos 1366 y 1367 del Código civil transponen este principio reconociendo el valor probatorio del escrito electrónico cuando su autor pueda ser identificado con certeza y su integridad esté garantizada.

Para un SOW que compromete montantes superiores a 1.500 € (umbral del artículo 1359 del Código civil para la exigencia de escrito), la firma electrónica avanzada (nivel 2 eIDAS) constituye el mínimo recomendado. Para proyectos sensibles o plurianuales, la firma cualificada (nivel 3) con certificado otorgado por un Proveedor de Servicios de Confianza (PSC) cualificado conforme al anexo II del Reglamento eIDAS es imprescindible.

Protección de datos y RGPD en proyectos IT

Todo SOW que incluya tratamientos de datos personales debe integrar una cláusula de subcontratación conforme al artículo 28 del RGPD n°2016/679. Esta cláusula debe detallar: la naturaleza y finalidad de los tratamientos, las categorías de datos concernidas, las obligaciones del subcontratista (el prestador IT), las medidas de seguridad técnicas y organizativas, y las condiciones de restitución o destrucción de datos al término del proyecto.

En proyectos agile, donde los perímetros evolucionan, es recomendable anexar al SOW un registro de tratamientos provisional actualizado a cada sprint mayor, conforme a las recomendaciones de la CNIL.

Contratación pública y restricciones sectoriales

Para los SOW celebrados en el marco de contratos públicos, el Código de la Contratación Pública (CCP) impone reglas específicas sobre contenido, modificación (artículos L.2194-1 y siguientes) y resolución de diferencias. Las enmiendas agile deben mantenerse dentro de los umbrales autorizados (generalmente 10 a 15 % del monto inicial) para no constituir un nuevo contrato sujeto a licitación.

Escenarios de uso: SOW agile vs waterfall en la práctica

Escenario 1 — ESN de tamaño intermedio, proyecto de renovación ERP (modelo waterfall)

Una ESN de aproximadamente 150 consultores gana una licitación pública para la renovación del sistema ERP de un grupo industrial. El perímetro funcional se define en un pliego de condiciones de 120 páginas, validado por la DSI cliente. El presupuesto es de 480.000 € IVA incluido, estructurado en 5 hitos contractuales sobre 18 meses.

El SOW waterfall firmado electrónicamente mediante una solución conforme eIDAS define: las especificaciones funcionales en anexo, los entregables esperados en cada hito (dosier de diseño, ambiente de recepción, acta de puesta en producción), los criterios de aceptación precisos y las penalizaciones por retraso. Gracias a este nivel de detalle, la recepción final se cierra con solo 3 reservas menores. La firma electrónica de las 7 enmiendas Change Request ocurridas durante la ejecución redujo los plazos de validación de 5 días hábiles a 18 horas en promedio, es decir un ahorro estimado de 12.000 € de costos de coordinación.

Escenario 2 — Startup SaaS y squad externa en modelo agile (Sprint Box)

Una startup B2B en fase de escalamiento recluta una squad externa de 5 personas (2 desarrolladores fullstack, 1 diseñador UX, 1 QA, 1 Scrum Master) para acelerar el desarrollo de su plataforma. El perímetro siendo exploratorio y la hoja de ruta de producto evolucionando cada mes, un SOW waterfall sería inadecuado.

El SOW agile firmado contractualiza: los perfiles y tarifas diarias, la duración de los sprints (2 semanas), el presupuesto máximo por trimestre (tope T&M de 85.000 € por trimestre), la Definition of Done aplicable a todas las stories, y las condiciones de revisión del backlog. Después de 6 meses, la startup ha entregado 3 veces más funcionalidades que las estimadas inicialmente, con un desbordamiento presupuestario de solo el 8 % respecto a la envoltura global — rendimiento imposible con un modelo waterfall dado las 23 repriorisaciones mayores del backlog ocurridas.

Escenario 3 — Firma de consultoría en transformación digital, enfoque híbrido ScrumFall

Una firma de consultoría acompaña a un organismo de formación en la migración de su LMS a una plataforma cloud. El proyecto está restringido por obligaciones regulatorias Qualiopi (trazabilidad de recorridos, accesibilidad RGAA) que imponen validación formal, pero los recorridos pedagógicos deben co-construirse con los formadores de manera iterativa.

La solución retida es un SOW híbrido: un perímetro macro waterfall (4 fases contractuales con hitos firmes y montos forfaitarios) enmarcando una ejecución agile interna (sprints bisemanales, revisiones con los formadores). Los entregables formales (dosier técnico Qualiopi, acta de recepción de accesibilidad) se contractualizan en hitos, mientras que los contenidos pedagógicos se gestionan vía backlog agile. Este modelo permitió reducir en un 35 % el número de enmiendas formales comparado con un proyecto LMS similar conducido en waterfall puro el año anterior.

Conclusión

La elección entre un SOW agile y un SOW waterfall no es una cuestión de preferencia metodológica: es una decisión contractual estructurante que determina la distribución de riesgos, la gestión de modificaciones y el valor probatorio de tus compromisos en caso de litigio. El waterfall destaca en perímetros estables y proyectos con restricciones regulatorias fuertes; el agile maximiza el valor en proyectos evolutivos e innovadores. El modelo híbrido ScrumFall responde a contextos intermedios, cada vez más frecuentes en la consultoría IT en 2026.

Cualquiera sea el modelo retido, la seguridad jurídica del SOW pasa por una firma electrónica conforme eIDAS. Certyneo te permite generar, personalizar y hacer firmar tus SOW en pocos minutos, con un valor probatorio reconocido en toda la Unión europea.

👉 Prueba Certyneo gratuitamente y firma tu primer SOW en menos de 10 minutos.