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

Introduction: why the SOW model conditions contractual success

In the world of IT consulting and software development, the Statement of Work (SOW) is not merely an administrative document: it is the contractual backbone governing the relationship between the service provider and their client. In 2026, virtually all IT projects oscillate between two radically different philosophies — agile and waterfall — and this distinction has concrete repercussions on the drafting of every clause of the SOW: deliverables, milestones, payment terms, acceptance criteria and change management. Understanding the difference between an agile SOW and a waterfall SOW means avoiding contractual disputes that cost on average 15% of project budget according to PMI sector surveys. 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 — rests 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 waterfall SOW

A typical waterfall SOW comprises:

• A detailed description of the functional scope: each feature is described, often accompanied by general functional specifications (GFS) or an attached requirements document.
• Firm contractual milestones: delivery of the validated prototype, functional acceptance testing, production rollout, 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 calibrated.
• Precise acceptance criteria: the conditions for validating each deliverable are defined contractually, reducing disputes at acceptance testing.

Advantages and limitations of waterfall SOW for IT projects

The waterfall model offers complete budgetary predictability for the client, making it the preferred choice for projects with stable scope: ERP integration, structured data migration, development of an application whose specifications are fixed. Conversely, it adapts poorly to changing requirements during project execution. Any modification must be subject to a contractual amendment (Change Request), a process often slow and a source of tension. According to data from the Standish Group Chaos Report 2024, waterfall projects exceed their initial budget in 45% of cases, precisely due to underestimation of scope at signature.

For more information on drafting and signing this type of document, the Certyneo SOW hub centralises 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 fixed scope. It contractualises a delivery capacity (team velocity, number of sprints, allocated 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 integrates:

• 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 fixed price).
• A prioritised 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 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 may revise the overall scope without formal amendment, within the limits of a global budget envelope defined.

Pricing models in an agile SOW: Time & Materials vs sprint-based fixed price

Two models coexist in practice:

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

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

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

---

Comparative table: agile vs waterfall SOW, the key differences

| Criterion | Waterfall SOW | Agile SOW | |---|---|---| | Scope | Fixed and exhaustive from signature | Evolving, managed via prioritised backlog | | Deliverables | Contractually defined and dated | Defined by sprint, validated continuously | | Milestones | Firm milestones with calendar dates | Periodic sprint reviews | | Price | Fixed global package | T&M or sprint-based fixed price | | Change management | Formal amendment (Change Request) | Backlog reprioritisation | | Budget risk | Service provider (fixed scope) | Client (T&M) or shared (sprint box) | | Acceptance criteria | Formal acceptance testing at defined milestones | Definition of Done per story | | Ideal for | Stable scope, regulatory constraints | Continuous evolution, innovation |

---

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

Analyse scope stability and client maturity

The first choice criterion is the stability of expressed requirements. If the client has a validated requirements document, finalised wireframes and an IT department capable of conducting formal acceptance testing, the waterfall SOW minimises contractual risk. Conversely, if the project is in discovery phase, if business requirements 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 cost overruns.

Take into account regulatory and sectoral context

Certain sectors impose constraints that influence the choice of SOW model. Projects in healthcare (HDS certification, healthcare data hosting), finance (DORA compliance, ISO 27001 audit) or public procurement (Public Procurement Code) often require greater documentary traceability and formal validation of deliverables 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 agile internal 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 being in order. In France, an advanced or qualified electronic signature in accordance with the eIDAS regulation guarantees the probative value of the document in case of dispute. For agile amendments (formal reprioritisations, sprint extensions), electronic signature considerably accelerates validation timescales: where a handwritten signature requires 3 to 7 days, a solution like Certyneo makes it possible to complete validation in less than 24 hours, without travel.

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

Legal framework applicable to SOWs in IT projects and consulting

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

Civil Code and contract law

The SOW falls under the Civil Code, and more specifically the provisions arising from the 2016 contract law reform (Ordinance 2016-131, codified in articles 1101 et seq.). Article 1194 of the Civil Code recalls that contracts bind not only to what is expressly stated, but also to all consequences given to them by equity, custom or law — which includes recognised 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 a contrary clause, it is for 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, of which article 25 states that 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 recognising the probative value of electronic writing provided that its author can be identified with certainty and its integrity is guaranteed.

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

Data protection and GDPR in IT projects

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

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

Public procurement and sectoral constraints

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

Usage scenarios: agile vs waterfall SOW in practice

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

A systems integrator of about 150 consultants wins a call for tenders for the overhaul of an industrial group's ERP system. The functional scope is defined in a 120-page requirements document, validated by the client's IT department. The budget is €480,000 including VAT, structured in 5 contractual milestones over 18 months.

The waterfall SOW signed electronically via an eIDAS-compliant solution defines: functional specifications in annex, expected deliverables at each milestone (design file, test environment, production rollout report), precise acceptance criteria and delay penalties. Thanks to this level of detail, final acceptance testing is completed with only 3 minor reservations. Electronic signature of the 7 Change Request amendments that occurred during the project reduced validation timescales from 5 working days to 18 hours on average, an estimated saving of €12,000 in coordination costs.

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

A B2B startup in scale-up phase recruits an external squad of 5 people (2 fullstack developers, 1 UX designer, 1 QA, 1 Scrum Master) to accelerate platform development. Given that scope is exploratory and the product roadmap evolves monthly, a waterfall SOW would be unsuitable.

The signed agile SOW contractualises: profiles and daily rates, sprint duration (2 weeks), maximum budget per quarter (T&M cap of €85,000 per quarter), Definition of Done applicable to all stories, and backlog review conditions. After 6 months, the startup has delivered 3 times more features than initially estimated, with budget overrun of only 8% against the overall envelope — a performance impossible with a waterfall model given the 23 major backlog reprioritisations that occurred.

Scenario 3 — Digital transformation consulting firm, hybrid ScrumFall approach

A consulting firm assists a training organisation in migrating its LMS to a cloud platform. The project is constrained by Qualiopi regulatory obligations (learner pathway traceability, RGAA accessibility) which impose formal validation, but the pedagogical pathways themselves must be co-constructed with trainers in an iterative manner.

The solution adopted is a hybrid SOW: a waterfall macro scope (4 contractual phases with firm milestones and fixed amounts) framing agile internal execution (bi-weekly sprints, reviews with trainers). Formal deliverables (Qualiopi technical file, accessibility acceptance testing report) are contractualised as milestones, whilst pedagogical content is managed via an agile backlog. This model reduced by 35% the number of formal amendments compared to a similar LMS project conducted in pure waterfall the previous year.

Conclusion

The choice between an agile SOW and a waterfall SOW is not a matter of methodological preference: it is a structuring 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 maximises value on evolving and innovative projects. The hybrid ScrumFall model addresses intermediate contexts, increasingly common in IT consulting in 2026.

Whatever model is chosen, securing the legal value of the SOW involves eIDAS-compliant electronic signature. Certyneo enables you to generate, customise and have your SOWs signed in minutes, with probative value recognised throughout the European Union.

👉 Try Certyneo free and sign your first SOW in under 10 minutes.