SOW agile vs waterfall: which structure for your IT projects?

Introduction: why the SOW model determines contractual success

In the world of IT consulting and software development, the Statement of Work (SOW) is not a simple administrative document: it is the contractual backbone that governs the relationship between the service provider and its client. In 2026, nearly all IT projects oscillate between two radically different philosophies — agile and waterfall — and this distinction has concrete repercussions on the drafting of every clause in the SOW: deliverables, milestones, payment terms, acceptance criteria, and change management. Understanding the difference between an agile SOW and a waterfall SOW means avoiding costly contractual disputes for the project budget. This article details the structures, risks, and best practices for each approach.

---

What is a waterfall SOW and how to structure it?

The waterfall model — or V-cycle — is based on a sequential logic: each phase (scoping, design, development, testing, deployment) follows one another in a linear manner. A waterfall SOW reflects this logic by defining a priori and exhaustively the entire scope.

Structural characteristics of a waterfall SOW

A typical waterfall SOW includes:

• A detailed description of the functional scope: each feature is described, often accompanied by general functional specifications (GFS) or an attached requirements document.
• Fixed contractual milestones: delivery of the validated mockup, functional acceptance, production release, warranty period. Each milestone is associated with a calendar date and a percentage of the fixed price.
• A global fixed price (fixed-price): the financial consideration is determined in advance. The service provider assumes the risk of cost overruns if the scope is poorly estimated.
• Precise acceptance criteria: the conditions for validating each deliverable are defined contractually, reducing disputes at acceptance.

Advantages and limitations of the waterfall SOW for IT projects

The waterfall model offers total budget predictability for the client, making it the preferred choice for projects with a stable scope: ERP integration, structured data migration, development of an application whose specifications are fixed. On the other hand, it adapts poorly to changes in requirements during the project. Any modification must go through a contractual amendment (Change Request), a process that is often slow and a source of tension. When the scope is underestimated at signing, a waterfall project easily exceeds its initial budget.

To learn more about the drafting and signing of this type of document, the Certyneo SOW hub centralizes templates, standard clauses, and best practices.

---

What is an agile SOW and how does it differ structurally?

The agile SOW breaks with the logic of a fixed scope. It contractualizes a delivery capacity (team velocity, number of sprints, available profiles) rather than an exhaustive list of features.

The pillars of an agile SOW: sprints, backlog, and value criteria

An agile SOW structured around Scrum or Kanban typically incorporates:

• A description of roles and teams: Product Owner on the client side, Scrum Master and developers on the service provider side, with associated daily or monthly rates (Time & Materials model or sprint-based fee).
• A prioritized initial backlog: not contractually fixed, but serving as a starting basis. It evolves at each sprint review with the agreement of both parties.
• Sprints as a billing unit: each sprint (2 to 4 weeks) constitutes a billable cycle, with its defined agile ceremonies (planning, daily, review, retrospective).
• Definition of Done (DoD) criteria: technical and functional conditions that each story must satisfy to be considered delivered, replacing the monolithic acceptance criteria of waterfall.
• A clause for periodic budget review: after N sprints, the parties can revise the overall scope without formal amendment, within the limits of a global budget envelope defined.

Price models in an agile SOW: Time & Materials vs sprint-based fee

Two models coexist in practice:

Time & Materials (T&M): the client pays for the time actually consumed by the teams, according to contractualized daily rates. This model maximizes flexibility but transfers budget risk to the client. It is suited for exploratory projects or ideation phases.

Sprint-based fee (Sprint Box): the service provider commits to a fixed delivery capacity per sprint (number of points or person-days), for a fixed price. This hybrid model combines the financial predictability of waterfall and the flexibility of the agile backlog. It is today the dominant model in French ESNs for web and mobile development projects.

The contract templates available on Certyneo include SOW templates adapted to each of these price models, ready to be customized and signed electronically.

---

Comparison table: agile SOW vs waterfall, key differences

---

How to choose between agile and waterfall SOW for your IT consulting project?

Analyze scope stability and client maturity

The first selection criterion is the stability of the expressed need. If the client has a validated requirements document, finalized wireframes, and a DSI capable of conducting formal acceptance, the waterfall SOW minimizes contractual risk. Conversely, if the project is in discovery phase, if business needs evolve rapidly, or if the client wishes to involve end-users in iterative validations, the agile SOW is structurally better suited.

A concrete indicator: if the initial requirements document exceeds 80% estimated functional stability, opt for waterfall. Below 60%, the agile approach will significantly reduce amendments and overruns.

Take into account regulatory and sectoral context

Certain sectors impose constraints that influence the choice of SOW model. Projects in healthcare (HDS certification, health data hosting), finance (DORA compliance, ISO 27001 audit), or public procurement (Public Procurement Code) often require documentary traceability and formal deliverable validation closer to the waterfall model, even if development methods are agile internally.

In this hybrid context, a so-called ScrumFall SOW — or Agile at Scale — combines a contractually fixed macro scope (project phases, global budget) with internal agile execution. This approach is today widely documented in SAFe (Scaled Agile Framework) and LeSS frameworks.

Secure SOW signature regardless of the model chosen

Regardless of the model chosen, the legal value of the SOW depends on its signature in due form. In France, advanced or qualified electronic signature compliant with the eIDAS regulation guarantees the probative value of the document in case of dispute. For agile amendments (formal reprioritizations, sprint extensions), electronic signature significantly accelerates validation times: whereas a handwritten signature requires 3 to 7 days, a solution like Certyneo allows you to complete validation in less than 24 hours, without travel.

Consulting teams managing many SOWs simultaneously can rely on Certyneo's AI-powered contract generator to produce SOWs adapted to each context (agile, waterfall, hybrid) in minutes, then send them for signature in an integrated workflow.

Legal framework applicable to SOWs in IT and consulting projects

The Statement of Work is a contract in its own right, subject to the common law of contracts as well as to specific sectoral regulations. In France, several texts govern its drafting, validity, and execution.

Civil Code and contract law

The SOW falls under the French Civil Code, and more specifically under the provisions resulting from the 2016 reform of contract law (Ordinance No. 2016-131, codified in articles 1101 et seq.). Article 1194 of the Civil Code recalls that contracts bind not only to what is expressed therein, but also to all the consequences that equity, custom, or law give them — which includes recognized practices in the IT sector (Agile Manifesto, PMI/PMBOK standards).

Article 1353 governs the burden of proof in case of dispute: in the absence of contrary clause, it is up to the service provider to prove that it has fulfilled its obligations. A well-drafted SOW, with precise acceptance criteria (DoD or waterfall milestones), practically reverses this burden.

Electronic signature and probative value: eIDAS and Civil Code

The electronic signature of the SOW is governed by the European Regulation eIDAS No. 910/2014, whose article 25 provides that a qualified electronic signature has the same legal value as a handwritten signature in all Member States. In France, articles 1366 and 1367 of the Civil Code transpose this principle by recognizing the probative value of electronic writing as long as its author can be identified with certainty and its integrity is guaranteed.

For an SOW engaging amounts exceeding €1,500 (threshold in article 1359 of the Civil Code for the requirement of writing), advanced electronic signature (eIDAS level 2) is the minimum recommended. For sensitive or multi-year projects, qualified signature (level 3) with a certificate issued by a Trust Service Provider (TSP) qualified pursuant to Annex II of the eIDAS regulation is essential.

Data protection and GDPR in IT projects

Any SOW including personal data processing must integrate a sub-processor clause compliant with article 28 of GDPR No. 2016/679. This clause must detail: the nature and purpose of processing, the categories of data concerned, the service provider's obligations (the IT service provider), the technical and organizational security measures, and the conditions for data return or destruction at the end of the project.

In agile projects, where scopes evolve, it is recommended to attach to the SOW a provisional processing register updated at each major sprint, in accordance with CNIL recommendations.

Public procurement and sectoral constraints

For SOWs concluded under public procurement contracts, the Public Procurement Code (CCP) imposes specific rules on content, modification (articles L.2194-1 et seq.), and dispute resolution. Agile amendments must remain within authorized thresholds (generally 10 to 15% of the initial amount) so as not to constitute a new contract subject to competitive bidding.

Illustrative use-case scenarios: agile vs. waterfall SOW

Scenario 1 — Mid-sized ESN, ERP overhaul project (waterfall model)

These scenarios are illustrative: they describe typical situations and do not report any measured results from a client. An IT services company of about 150 consultants wins a bid for the overhaul of an industrial group's ERP system. The functional scope is defined in a detailed specifications document, validated by the client's IT department. The budget is structured into 5 contractual milestones spread over a long period.

The waterfall SOW, electronically signed via an eIDAS-compliant solution, defines: the functional specifications in an appendix, the deliverables expected at each milestone (design document, UAT environment, production release report), precise acceptance criteria, and late-delivery penalties. Thanks to this level of detail, final acceptance testing can be concluded with a limited number of minor reservations. Electronic signature of Change Request amendments occurring during the project allows each change to be validated faster, which limits coordination costs. The scale of the gain should be measured on your own project scope, before and after a pilot.

Scenario 2 — SaaS startup and external squad in agile model (Sprint Box)

A B2B startup in scaling phase recruits an external squad of 5 people (2 fullstack developers, 1 UX designer, 1 QA, 1 Scrum Master) to accelerate platform development. Given the exploratory scope and the product roadmap evolving every month, a waterfall SOW would be inadequate.

The signed agile SOW contractualizes: the profiles and daily rates, the sprint duration, the maximum budget per quarter (T&M cap), the Definition of Done applicable to all stories, and the conditions for backlog revision. In a context where the backlog is reprioritized multiple times, this framework enables continuous delivery while maintaining control over the budget envelope, something a waterfall model would struggle to achieve. The scale of the gain should be measured on the startup's own actual scope, before and after a pilot.

Scenario 3 — Digital transformation consulting firm, hybrid ScrumFall approach

A consulting firm assists a training organization in migrating its LMS to a cloud platform. The project is constrained by Qualiopi regulatory obligations (learning path traceability, RGAA accessibility) that require formal validation, but the pedagogical pathways themselves must be co-built with trainers iteratively.

The solution chosen is a hybrid SOW: a macro waterfall scope (4 contractual phases with firm milestones and fixed amounts) framing an internal agile execution (bi-weekly sprints, reviews with trainers). Formal deliverables (Qualiopi technical file, accessibility acceptance report) are contractualized as milestones, while educational content is managed through an agile backlog. This model limits the number of formal amendments compared to a similar LMS project run in pure waterfall. The scale of the gain should be measured on your own project scope, before and after a pilot.

Conclusion

The choice between an agile SOW and a waterfall SOW is not a question of methodological preference: it is a structural contractual decision that determines risk allocation, change management, and the probative value of your commitments in case of dispute. Waterfall excels on stable scopes and projects with strong regulatory constraints; agile maximizes value on evolving and innovative projects. The hybrid ScrumFall model addresses intermediate contexts, increasingly common in IT consulting in 2026.

Regardless of the model chosen, securing the SOW legally requires an eIDAS-compliant electronic signature. Certyneo allows you to generate, customize, and have your SOW signed in minutes, with probative value recognized throughout the European Union.

👉 Try Certyneo for free and sign your first SOW in less than 10 minutes.