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 provider and its client. In 2026, almost all IT projects oscillate between two radically different philosophies — agile and waterfall — and this distinction has concrete repercussions for 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 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 — 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 total budgetary predictability for the client, making it the preferred choice for projects with a stable scope: ERP integration, structured data migration, or development of an application with fixed specifications. However, it adapts poorly to changing requirements during the project. Any change must be the subject of a contractual amendment (Change Request), a process that is often slow and a source of tension. When the scope is underestimated at signature, a waterfall project easily exceeds its initial budget.

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

---

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.

Illustrative use-case scenarios: agile vs waterfall SOW

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

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

The waterfall SOW, signed electronically via an eIDAS-compliant solution, defines: the functional specifications in an appendix, the deliverables expected at each milestone (design document, test environment, production go-live report), precise acceptance criteria and late-delivery penalties. Thanks to this level of detail, final acceptance can be concluded with a limited number of minor reservations. Electronically signing Change Request amendments during the project allows each change to be validated faster, limiting coordination costs. The scale of the gain should be measured across the actual scope of the project, before and after a pilot.

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 contractually sets out: profiles and daily rates, sprint duration, the maximum budget per quarter (T&M cap), the Definition of Done applicable to all stories, and the conditions for revising the backlog. In a context where the backlog is reprioritised several times, this framework allows continuous delivery while keeping control of the budget envelope, which a waterfall model would struggle to achieve. The scale of the gain should be measured across the actual scope of the startup, before and after a pilot.

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 chosen is a hybrid SOW: a macro waterfall scope (4 contractual phases with firm milestones and fixed-price amounts) framing an internal agile execution (fortnightly sprints, reviews with trainers). Formal deliverables (Qualiopi technical file, accessibility acceptance report) are contracted as milestones, while the educational content is managed via an agile backlog. This model limits the number of formal amendments compared with a similar LMS project run in pure waterfall. The scale of the gain should be measured across the actual scope of the project, before and after a pilot.

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.