SOW agile vs waterfall : quelle structure 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 desarrollo de software, el Statement of Work (SOW) no es simplemente un documento administrativo : es la columna vertebral contractual que rige la relación entre el proveedor 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 los 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 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 (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, frecuentemente acompañada de especificaciones funcionales generales (SFG) o un documento de requisitos 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 calendario y a un porcentaje del presupuesto.
• Un precio global forfaitario (fixed-price) : la contraprestación financiera se determina de antemano. El proveedor asume el riesgo de sobrecosto 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 para proyectos con perímetro estable : integración ERP, migración de datos estructurados, desarrollo de una aplicación cuyas especificaciones están fijas. 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 frecuentemente 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 debido a la subestimación del perímetro en la firma.

Para profundizar en la redacción y 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 fijo. 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 proveedor, con las tarifas diarias o mensuales asociadas (modelo Time & Materials o presupuesto por sprint).
• Un backlog inicial priorizado : no contractualmente fijo, pero que sirve de base de partida. 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, review, retrospectiva).
• Criterios de Definition of Done (DoD) : condiciones técnicas y funcionales que cada historia debe satisfacer para ser considerada como 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. Se adapta a proyectos exploratorios o fases de ideación.

Presupuesto por sprint (Sprint Box) : el proveedor se compromete sobre una capacidad de entrega fija por sprint (número de puntos o días/persona), 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 contrato 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 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 | Proveedor (perímetro fijo) | Cliente (T&M) o compartido (sprint box) | | Criterios de aceptación | Recepción formal en hitos definidos | Definition of Done por historia | | 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 documento de requisitos 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 discovery, si las necesidades del negocio evolucionan rápidamente o si el cliente desea implicar a usuarios finales en las validaciones iterativas, el SOW agile se adapta estructuralmente mejor.

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

Tomar en cuenta el contexto regulatorio y sectorial

Ciertos sectores imponen restricciones que influyen en la elección del modelo de SOW. Los proyectos en salud (certificación HDS, alojamiento de datos de salud), finanzas (cumplimiento DORA, auditoría ISO 27001) o mercados públicos (Código de contratación pública) requieren frecuentemente una trazabilidad documental y una validación formal de entregables más cercana al modelo waterfall, incluso si los métodos de desarrollo son agile internamente.

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

Asegurar la firma del SOW sea cual sea el modelo elegido

Independientemente del modelo elegido, el valor jurídico del SOW depende de su firma siguiendo los procedimientos. En Francia, la firma electrónica avanzada o cualificada conforme al Reglamento eIDAS garantiza el valor probatorio del documento en caso de litigio. Para enmiendas agile (repriorizaciones formales, extensiones de sprint), la firma electrónica acelera considerablemente los plazos de validación : donde 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 múltiples SOW simultáneamente pueden contar con el generador de contratos por IA de Certyneo para producir SOW adaptados a cada contexto (agile, waterfall, híbrido) en cuestión de 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 en sí mismo, sujeto al derecho común de los contratos así como a las regulaciones sectoriales específicas. En Francia, varios textos encuadran su redacción, validez y ejecución.

Código Civil y derecho de contratos

El SOW es en primer lugar regulado por el Código Civil, y más precisamente por las disposiciones derivadas de la reforma del derecho de contratos de 2016 (Ordenanza n°2016-131, codificada en 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 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 : a falta de cláusula contraria, corresponde al proveedor probar que ha respetado 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á encuadrada por el Reglamento europeo eIDAS n°910/2014, cuyo artículo 25 establece 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 siempre que su autor pueda ser identificado con certeza y su integridad esté garantizada.

Para un SOW que compromete montos 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 entregado por un Proveedor de Servicios de Confianza (PSCo) cualificado conforme al 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 afectados, las obligaciones del subcontratista (el proveedor IT), las medidas de seguridad técnicas y organizacionales, y las condiciones de restitución o destrucción de datos al término del proyecto.

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

Contratación pública y restricciones sectoriales

Para SOW suscritos en el marco de mercados públicos, el Código de Contratación Pública (CCP) impone reglas específicas en materia de 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 mercado sujeto a libre concurrencia.

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 licitación para la refundición del sistema ERP de un grupo industrial. El perímetro funcional se define en un documento de requisitos de 120 páginas, validado por la DSI del cliente. El presupuesto es de 480 000 € IVA incluido, estructurado en 5 hitos 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 hito (expediente de diseño, ambiente de recepción, acta de puesta en producción), los criterios de aceptación precisos y las penalizaciones por atraso. 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 que intervienen durante el proyecto ha reducido los plazos de validación de 5 días hábiles a 18 horas en promedio, esto es un ahorro estimado de 12 000 € en costos de coordinación.

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

Una startup B2B en fase de escalado contrata 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 del 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 (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. Tras 6 meses, la startup ha entregado 3 veces más funcionalidades que las estimadas inicialmente, con un sobrecosto de solo el 8 % respecto a la envoltura global — rendimiento imposible con un modelo waterfall dada las 23 repriorisaciones mayores del backlog que intervinieron.

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

Un gabinete 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á restringido por obligaciones regulatorias Qualiopi (trazabilidad de 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 elegida es un SOW híbrido : un perímetro macro waterfall (4 fases contractuales con hitos firmes y montos forfaitarios) encuadrando una ejecución agile interna (sprints bi-semanales, revisiones con los formadores). Los entregables formales (expediente técnico Qualiopi, acta de recepción de accesibilidad) se contractualizan en hitos, mientras que los contenidos pedagógicos se gestionan vía un 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.

Sea cual sea el modelo elegido, 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 cuestión de 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.