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 proveedor y su cliente. En 2026, casi la totalidad de los proyectos IT oscilan 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 modificaciones. Entender 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 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 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 de calendario y a un porcentaje del presupuesto.
• Un precio global de forfait (fixed-price) : la contraprestación financiera se determina por adelantado. El proveedor asume el riesgo de sobrecostos 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 predictibilidad presupuestaria total para el cliente, lo que lo convierte en la opción preferida 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 en el transcurso del proyecto. Toda 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 45 % de los casos, precisamente por la subestimación del perímetro en la firma.

Para ir más lejos en la redacción y 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 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 : Product Owner del lado del cliente, Scrum Master y desarrolladores del lado del proveedor, con las tasas diarias o mensuales asociadas (modelo Time & Materials o presupuesto por sprint).
• Un backlog inicial priorizado : no contractualmente congelado, pero sirviendo como base de partida. Evoluciona en cada sprint review con 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 tasas diarias contractualizadas. Este modelo maximiza la flexibilidad pero transfiere el riesgo presupuestario al cliente. Es adecuado para proyectos exploratorios o fases de ideación.

Presupuesto por sprint (Sprint Box) : el proveedor se compromete en 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 predictibilidad financiera del waterfall y la flexibilidad del backlog agile. Es actualmente 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 | | Jalones | 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 | Proveedor (perímetro congelado) | Cliente (T&M) o compartido (sprint box) | | Criterios de aceptación | Recepción formal en jalones definidos | Definition of Done por story | | 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 discovery, si las necesidades del negocio evolucionan rápidamente o si el cliente desea involucrar a usuarios finales en las validaciones iterativas, el SOW agile es estructuralmente más adecuado.

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 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 sanidad (certificación HDS, alojamiento de datos de salud), finanzas (conformidad DORA, auditoría ISO 27001) o mercados públicos (Código de Compras Públicas) requieren frecuentemente una trazabilidad documental y una validación formal de entregables más cercana al modelo waterfall, incluso si las metodologías de desarrollo son 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 retomado

Independientemente del modelo elegido, el valor jurídico del SOW depende de su firma conforme a las normas. 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, para enviarlos luego a firma en flujo integrado.

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

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

Código civil y derecho de contratos

El SOW depende en primer lugar del Código civil, y más precisamente de las disposiciones derivadas de la reforma del derecho de 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 expresamente contienen, 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 proveedor probar que ha cumplido sus obligaciones. Un SOW bien redactado, con criterios de aceptación precisos (DoD o jalones 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 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 siempre que su autor pueda ser identificado con certeza y que su integridad esté garantizada.

Para un SOW comprometiendo montos 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 cualificada (nivel 3) con certificado entregado por un Proveedor de Servicios de Confianza (PSC) cualificado al sentido del anexo II del reglamento eIDAS se impone.

Protección de datos y RGPD en proyectos IT

Todo SOW incluyendo 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 la finalidad de los tratamientos, las categorías de datos concernidas, las obligaciones del subcontratista (el proveedor IT), las medidas de seguridad técnicas y organizacionales, y las condiciones de devolución o destrucción de los datos al término del proyecto.

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

Compra pública y restricciones sectoriales

Para los SOW concluidos en el marco de contratos públicos, el Código de Compras Públicas (CCP) impone reglas específicas en materia de contenido, modificación (artículos L.2194-1 y siguientes) y regulación de diferencias. Las enmiendas agile deben permanecer dentro de los umbrales autorizados (generalmente 10 a 15 % del monto inicial) para no constituir un nuevo contrato sometido a puesta en concurrencia.

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

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

Una ESN de aproximadamente 150 consultores gana una licitación para la refonte del sistema ERP de un grupo industrial. El perímetro funcional se define en un pliego de 120 páginas, validado por la DSI cliente. El presupuesto es de 480 000 € IVA incluido, estructurado en 5 jalones contractuales en 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, proceso verbal de puesta en producción), los criterios de aceptación precisos y las penalizaciones por retardo. 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 sucedidas en el transcurso del 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 aceleración recruta 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 el roadmap de producto evolucionando cada mes, un SOW waterfall sería inadecuado.

El SOW agile firmado contractualiza : los perfiles y tasas 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 stories, y las condiciones de revisión del backlog. Al cabo de 6 meses, la startup entregó 3 veces más funcionalidades que estimadas inicialmente, con un sobrecosto de solo 8 % respecto a la envoltura global — desempeño imposible con un modelo waterfall dadas las 23 repriorisaciones mayores del backlog que interviniéron.

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 a una plataforma cloud. El proyecto está limitado por obligaciones reglamentarias Qualiopi (trazabilidad de recorridos, accesibilidad RGAA) que imponen una validación formal, pero los recorridos pedagógicos en sí deben co-construirse con los formadores de manera iterativa.

La solución retomada es un SOW híbrido : un perímetro macro waterfall (4 fases contractuales con jalones firmes y montos de presupuesto) encuadrando una ejecución agile interna (sprints quinzenales, 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 en 35 % el número de enmiendas formales en comparación 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 repartición de riesgos, la gestión de modificaciones y el valor probatorio de tus compromisos en caso de litigio. El waterfall excele 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 la consultoría IT en 2026.

Cualquiera que sea el modelo retomado, 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.