SOW agile vs waterfall : quelle estructura para tus proyectos IT ?

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

En el universo del consulting IT y del 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 de servicios y su cliente. En 2026, la quasi 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, jalones, modalidades de pago, criterios de aceptación y gestión de cambios. Comprender la diferencia entre un SOW agile y un SOW waterfall es evitar los litigios contractuales que cuestan en promedio 15 % del presupuesto del proyecto según las encuestas sectoriales PMI. Este artículo detalla las estructuras, los riesgos y las mejores 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 (definición del alcance, diseño, desarrollo, pruebas, despliegue) se sucede de manera lineal. Un SOW waterfall refleja esta lógica definiendo a priori y de manera exhaustiva la totalidad 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 de un pliego de condiciones anexado.
• Jalones contractuales firmes (milestones) : entrega del prototipo validado, recepción funcional, puesta en producción, período de garantía. Cada jalón está asociado a una fecha calendario y a un porcentaje del presupuesto.
• Un precio global forfaitario (fixed-price) : la contraprestación financiera se determina de antemano. El prestador de servicios 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 los 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 de 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 el 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 45 % de los casos, precisamente debido a la subestimación del perímetro en la firma.

Para saber más sobre la redacción y la firma de este tipo de documento, el hub SOW de Certyneo centraliza modelos, cláusulas tipo y mejores prácticas.

---

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

El SOW agile rompe con la lógica de 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 los roles y equipos : Propietario del Producto del lado del cliente, Scrum Master y desarrolladores del lado del prestador de servicios, con las tarifas diarias o mensuales asociadas (modelo Time & Materials o presupuesto por sprint).
• Un backlog inicial priorizado : no contractualmente congelado, pero sirviendo como 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 (planificación, daily, revisión, retrospectiva).
• Criterios de Definition of Done (DoD) : condiciones técnicas y funcionales que cada historia 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 envolvente 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 adaptado para proyectos exploratorios o fases de ideación.

Presupuesto por sprint (Sprint Box) : el prestador de servicios se compromete a una capacidad de entrega fija por sprint (número de puntos o de 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 mobile.

Los modelos de contratos disponibles en Certyneo incluyen plantillas SOW adaptadas a cada uno de estos modelos de precio, listas para personalizarse y ser firmadas electrónicamente.

---

Tabla comparativa : SOW agile vs waterfall, las diferencias claves

| 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 | | Jalones | Milestones firmes con fechas 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 de servicios (perímetro congelado) | Cliente (T&M) o compartido (sprint box) | | Criterios de aceptación | Recepción formal en jalones definidos | Definition of Done por historia | | Ideal para | Perímetro estable, restricciones reglamentarias | 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, de wireframes finalizados y de 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 descubrimiento, si las necesidades del negocio evolucionan rápidamente o si el cliente desea implicar a usuarios finales en las validaciones iterativas, el SOW agile es estructuralmente más adaptado.

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

Tomar en cuenta el contexto reglamentario 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 sanidad), finanzas (conformidad DORA, auditoría ISO 27001) o compras públicas (Código de Contratación Pública) necesitan a menudo una trazabilidad documental y una validación formal de los entregables más cercana al modelo waterfall, incluso si las metodologías de desarrollo son agile 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 marcos de trabajo SAFe (Scaled Agile Framework) y LeSS.

Asegurar la firma del SOW sea cual sea el modelo retenido

Independientemente del modelo elegido, el valor jurídico del SOW depende de su firma conforme a las reglas. En Francia, la firma electrónica avanzada o calificada conforme al reglamento eIDAS garantiza el valor probante 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 consulting

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

Código Civil y derecho de los contratos

El SOW se incluye en primer lugar en el Código Civil, y más precisamente en las disposiciones resultantes 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 que en ellos se expresa, sino también a todas las consecuencias que les dan 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 de servicios probar que respetó sus obligaciones. Un SOW bien redactado, con criterios de aceptación precisos (DoD o jalones waterfall), invierte prácticamente esta carga.

Firma electrónica y valor probante : eIDAS y Código Civil

La firma electrónica del SOW está enmarcada por el Reglamento europeo eIDAS n°910/2014, cuyo artículo 25 dispone que la firma electrónica calificada 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 probante del escrito electrónico siempre que su autor pueda ser identificado con certeza y que su integridad esté garantizada.

Para un SOW que comprometa montantes superiores a 1 500 € (umbral del artículo 1359 del Código Civil para la exigencia de un escrito), la firma electrónica avanzada (nivel 2 eIDAS) constituye el mínimo recomendado. Para proyectos sensibles o plurianuales, la firma calificada (nivel 3) con certificado entregado por un Proveedor de Servicios de Confianza (PSC) calificado en el sentido del anexo II del reglamento eIDAS se impone.

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 organizacionales, y las condiciones de restitución o destrucción de los datos al término del proyecto.

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

Compra pública y restricciones sectoriales

Para los SOW suscritos en el marco de compras públicas, el Código de Contratación Pública (CCP) impone reglas específicas en materia de contenido, de modificación (artículos L.2194-1 y siguientes) y de resolución de diferendos. Las enmiendas agile deben mantenerse dentro de los umbrales autorizados (generalmente 10 a 15 % del monto inicial) para no constituir una nueva compra sometida a licitación pública.

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

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

Una ESN de aproximadamente 150 consultores gana una convocatoria pública para la refundición del sistema ERP de un grupo industrial. El perímetro funcional está definido 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 jalones contractuales durante 18 meses.

El SOW waterfall firmado electrónicamente vía una solución conforme eIDAS define : las especificaciones funcionales en anexo, los entregables esperados en cada jalón (dossier de diseño, ambiente de recepción, acta de puesta en producción), los criterios de aceptación precisos y las sanciones 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 intervenidas durante el proyecto redujo los plazos de validación de 5 días laborales 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 escalado 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. Como el perímetro es exploratorio y el roadmap de producto evoluciona cada mes, un SOW waterfall sería inadaptado.

El SOW agile firmado contractualiza : los perfiles y tarifas diarias, la duración de los sprints (2 semanas), el presupuesto máximo por trimestre (techo T&M de 85 000 € por trimestre), la Definition of Done aplicable a todas las historias, y las condiciones de revisión del backlog. Después de 6 meses, la startup entregó 3 veces más funcionalidades de lo estimado inicialmente, con un desbordamiento presupuestario de solo 8 % respecto a la envolvente global — rendimiento imposible con un modelo waterfall dadas las 23 repriorisaciones mayores del backlog que intervinieron.

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

Un despacho de consultoría acompaña a un organismo de formación en la migración de su LMS hacia una plataforma cloud. El proyecto está limitado por obligaciones regulatorias Qualiopi (trazabilidad de los itinerarios, accesibilidad RGAA) que imponen una validación formal, pero los itinerarios pedagógicos en sí deben ser co-construidos con los formadores de manera iterativa.

La solución retenida es un SOW híbrido : un perímetro macro waterfall (4 fases contractuales con jalones firmes y montos forfaitarios) enmarcando una ejecución agile interna (sprints quincenales, revisiones con los formadores). Los entregables formales (dossier técnico Qualiopi, acta de recepción de accesibilidad) se contractualizan en jalones, mientras que los contenidos pedagógicos se gestionan vía un backlog agile. Este modelo permitió reducir 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 cambios y el valor probante de tus compromisos en caso de litigio. El waterfall destaca en perímetros estables y proyectos con restricciones reglamentarias 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 el consulting IT en 2026.

Sea cual sea el modelo retenido, la aseguración 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 probante reconocido en toda la Unión Europea.

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