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 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 in the SOW: deliverables, milestones, payment methods, acceptance criteria and change management. Understanding the difference between an agile SOW and a waterfall SOW means avoiding the contractual disputes that cost an average of 15% of project budget according to PMI sectoral 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 — is based on 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 the 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 annexed specification document.
• Firm contractual milestones: delivery of validated mockup, functional testing, production rollout, warranty period. Each milestone is associated with a calendar date and a percentage of the fixed price.
• A global fixed price: the financial consideration is determined in advance. The service provider assumes the risk of overrun if the scope is poorly calibrated.
• Clear acceptance criteria: the conditions for validating each deliverable are defined contractually, reducing disputes during testing.

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 stable scope: ERP integration, structured data migration, development of an application whose specifications are fixed. However, it adapts poorly to evolving requirements during the project. Any change must be subject to a contract 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, profiles made available) 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 includes:

• 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 point. It evolves with each sprint review with the agreement of both parties.
• Sprints as billing units: 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 revision: after N sprints, the parties may revise the overall scope without formal amendment, within the limits of a defined global budget envelope.

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 the time actually consumed by the teams, according to contractualised daily rates. This model maximises flexibility but transfers budget risk to the client. It is suitable for 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 days/person) for a fixed price. This hybrid model combines the financial predictability of waterfall with the flexibility of the agile backlog. It is now the dominant model in French consulting firms for web and mobile development projects.

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

---

Comparison table: agile vs waterfall SOW, key differences

| Criterion | Waterfall SOW | Agile SOW | |---|---|---| | Scope | Fixed and exhaustive from signature | Evolving, managed via prioritised backlog | | Deliverables | Defined contractually and dated | Defined by sprint, continuously validated | | Milestones | Firm milestones with calendar dates | Periodic sprint reviews | | Price | Global fixed price | T&M or sprint-based fixed price | | Change management | Formal amendment (Change Request) | Backlog re-prioritisation | | Budget risk | Service provider (fixed scope) | Client (T&M) or shared (sprint box) | | Acceptance criteria | Formal 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 selection criterion is the stability of expressed needs. If the client has a validated specification document, finalised wireframes and a DSI capable of conducting formal testing, the waterfall SOW minimises contractual risk. Conversely, if the project is in discovery phase, if business needs are evolving rapidly or if the client wishes to involve end users in iterative validations, the agile SOW is structurally more suitable.

A concrete indicator: if the initial specification is estimated to be over 80% functionally stable, opt for waterfall. Below 60%, the agile approach will significantly reduce amendments and overruns.

Consider regulatory context and sector

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 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 now widely documented in the 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 accordance with the rules. 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 re-prioritisations, sprint extensions), electronic signature significantly accelerates validation times: where handwritten signature requires 3 to 7 days, a solution like Certyneo allows validation to be completed in less than 24 hours, without travel.

Consulting teams managing multiple SOWs simultaneously can rely on the AI-powered contract generator from Certyneo 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 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 in the first place under the Civil Code, and more specifically the provisions resulting from the 2016 contract law reform (Order No. 2016-131, codified in Articles 1101 et seq.). Article 1194 of the Civil Code reminds us that contracts bind not only to what is expressed therein, but also to all the consequences that equity, usage or law gives them — which includes recognised IT sector practices (Agile Manifesto, PMI/PMBOK standards).

Article 1353 governs the burden of proof in case of dispute: absent a contrary clause, it is for the service provider to prove that it has complied with its obligations. A well-drafted SOW, with clear 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 EU Regulation eIDAS No. 910/2014, whose article 25 provides 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 as long as its author can be identified with certainty and its integrity is guaranteed.

For an SOW involving amounts exceeding €1,500 (threshold in Article 1359 of the Civil Code for requiring written documentation), 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 Qualified Trust Service Provider (QTSP) within the meaning of Annex II of eIDAS is required.

Data protection and GDPR in IT projects

Any SOW including personal data processing 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, the categories of data concerned, the obligations of the sub-processor (the IT service provider), technical and organisational security measures, and the conditions for return or destruction of data at the end of the project.

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 procurement, the Public Procurement Code (CCP) imposes specific rules on content, modification (Articles L.2194-1 et seq.) and dispute settlement. Agile amendments must remain within authorised thresholds (generally 10 to 15% of the initial amount) to not constitute a new contract subject to competitive bidding.

Usage scenarios: agile vs waterfall SOW in practice

Scenario 1 — Mid-size consulting firm, ERP overhaul project (waterfall model)

A consulting firm of approximately 150 consultants wins a tender for the overhaul of an industrial group's ERP system. The functional scope is defined in a 120-page specification document, validated by the client's DSI. The budget is €480,000 (inc. 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 documentation, testing environment, production rollout minutes), clear acceptance criteria and delay penalties. Thanks to this level of detail, final testing is completed with only 3 minor reservations. Electronic signature of the 7 Change Request amendments that occurred during the project reduced validation times from 5 working days to 18 hours on average, representing 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. With the scope being exploratory and the product roadmap evolving monthly, a waterfall SOW would be unsuitable.

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

Scenario 3 — Digital transformation consulting firm, hybrid ScrumFall approach

A consulting firm accompanies a training organisation in migrating its LMS to a cloud platform. The project is constrained by Qualiopi regulatory obligations (tracking of learning paths, RGAA accessibility) that impose formal validation, but the learning paths themselves must be co-built with trainers in an iterative manner.

The solution chosen 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 documentation, accessibility testing minutes) are contractualised as milestones, while training 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

Choosing between an agile SOW and a waterfall SOW is not a matter 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 maximises value on evolving and innovative projects. The hybrid ScrumFall model addresses intermediate contexts, increasingly frequent in IT consulting in 2026.

Regardless of the model chosen, securing the SOW legally passes through electronic signature compliant with eIDAS. Certyneo allows you to generate, personalise and have your SOWs signed in minutes, with probative value recognised throughout the European Union.

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