No best SDLC model, only a correct fit

What is the best SDLC methodology?

There is no single best SDLC methodology, and the strongest evidence in this argument is the evidence against a universal winner. The best SDLC methodology for a given piece of work is the one matched to three project variables: how expensive a late change is to make and certify, how much audit evidence the domain demands, and what the contract has already locked. Team preference belongs nowhere on that list.

That answer only disappoints if you came for a champion. It is useful if you treat the decision as a scoring exercise you rerun per project, which is what follows: what the success-rate data does and does not prove, why hybrid models are growing fastest, a decision table you can apply in an afternoon, and the delivery capabilities that outrank whichever label ends up on the wall.

Agile vs waterfall: what does the evidence actually say?

The number everyone quotes comes from the Standish Group’s pooled CHAOS data covering 2013 to 2020: agile projects were rated successful 42 percent of the time, waterfall projects 13 percent.¹ The failure column is wider still.

Then the caveats, because that comparison is routinely used as proof and it is not one. It is observational. Teams select their own method, and the programmes that attract a waterfall plan tend to be larger, longer and more heavily contracted before anyone writes code, which loads the result before sequencing has any effect at all. Success in that dataset is also a rating against schedule, budget and scope, not a measure of whether the software earned anything.

The counterweight is more recent, and less flattering to both camps.

Two datasets, two eras, one honest reading. Agile holds the better historical record on change-heavy work, and no model rescues an organisation that under-resources delivery. Choose the model for fit, then spend the remaining argument budget on capability.

Why do most organisations land on a hybrid SDLC model?

Because governance moves slower than delivery. Procurement cycles, annual budgets, stage gates and audit calendars are predictive by construction, and the teams working inside them still want two-week feedback loops. Hybrid is what that compromise is called once somebody writes it down.

PMI’s 2024 sample puts predictive approaches at 44 percent of organisations, hybrid at 32 percent and agile at 26 percent, with agile down two points on the prior year.³ The movement is all in the middle column: hybrid rose from 20 percent of organisations in 2020 to roughly a third across 2023 and 2024.³

Set that against the Digital.ai State of Agile figures and the two look incompatible. There, 74 percent of organisations report agile or hybrid-agile approaches, and 97 percent use agile methods to some extent.⁵ The explanation is likely definitional rather than factual. One survey asks which approach governs the project; the other asks whether agile practice exists anywhere in the organisation. A stage-gated programme running Scrum inside its build phase answers yes to both questions and gets counted differently each time.

Scaling adds a layer of its own: 65 percent of organisations practising scaled agile use a formal scaled framework, and SAFe is the most common at 35 percent.⁵ Expectations point one way too, with 76 percent of PMI respondents expecting agile use to rise over the next five years and 34 percent expecting predictive use to decline.³ Expectation is not adoption. Plan for the mix you have, not the mix the survey predicts.

How do you choose the best SDLC methodology for a project?

Score the project on six variables before naming a model. Each pushes toward iteration or toward specification, and the weight of the majority is your answer. This is the SDLC model comparison worth running, because it compares your constraints rather than the methodologies’ marketing.

The tie-breaker is the cost-of-change curve for that specific product. If a change made in month nine costs roughly what it would have cost in month two, iterate, because you are buying information cheaply. If a change in month nine triggers requalification, retooling or a conversation with a regulator, front-load the specification and pay for certainty instead. Most web platforms sit at the cheap end of that curve. Embedded, hardware-coupled and safety-critical builds sit at the expensive end, and no amount of enthusiasm moves them.

One caution on mixed scores. A project that reads iterative on five variables and predictive on the sixth is not a hybrid, it is an agile project with one hard constraint. Hybrid is for genuine splits, normally a predictive shell of gates, evidence and billing wrapped around iterative delivery. Design the shell first, then leave the inside alone. That sequencing is what keeps engineering delivery legible to the business without making it slow.

When do waterfall and the V-model still win?

Waterfall is not obsolete, it is domain-specific. It runs each phase once, in order, with sign-off between phases, and it earns its keep wherever locking requirements early is cheaper than discovering them late. Three cases recur.

Fixed-price, fixed-scope contracts

If the commercial model prices a scope, something has to define that scope precisely enough to bill against, and that something is a specification written before build. Running iterative delivery inside a fixed-price wrapper without also rewriting the change-control process is the standard way margin disappears.

Hardware-coupled builds

When software ships with or inside a physical product, the software date is the hardware date. Iteration still happens, it just happens before the tooling is committed rather than after.

Safety-critical and regulated systems

Medical devices, aerospace and defence work produce a certification package as a first-class deliverable. The V-model is the usual answer: it pairs every specification stage with a matching verification stage, so requirements trace to tests and the trace itself is the evidence. That is not slower because the model is old. It is slower because the proof obligation is real.

What none of this licenses is waterfall by default. If the product is a consumer mobile application shipping through an app store to users you will never meet, none of the three cases applies, and the specification written in month one will be wrong by month three.

Does delivery capability outrank the methodology label?

Usually, yes. DORA’s 2024 State of DevOps data describes elite performers by behaviour rather than by method: deploying on demand, holding change failure rate at roughly 5 percent, restoring service after a failed deployment in under an hour, and deploying around 182 times more often than the lowest performing group.⁶ None of those are properties of a methodology. They are consequences of automation, small batch sizes and fast feedback, and they can be layered onto agile, hybrid, or a disciplined predictive pipeline.

The delivery metrics do not ask what your methodology is called. They ask how small your changes are and how quickly you find out when one is wrong.

The shrinking middle is the interesting part. Capability is not accumulating on its own, which sits comfortably with the PMI finding that performance is roughly flat across approaches. So if you are choosing between models in order to fix delivery, you are probably solving the wrong problem. Instrument deployment frequency, lead time, change failure rate and restore time first, then change the model only if the numbers say sequencing is the constraint.

Can you change SDLC methodology mid-project?

Yes, at phase boundaries, and rarely more than one layer at a time. Changing sequencing halfway through a build while also changing team structure, tooling and contract terms produces a relaunch on a reduced budget, which is nobody’s plan.

1. Change the inside before the outside. Move build and test onto short cycles while gates, billing and reporting stay untouched. Most of the benefit arrives here and none of the governance fight does.
2. Instrument before you compare. Record the four delivery metrics for a full quarter ahead of the change, or the after-state is an opinion.
3. Pilot on one product line. A single team with a real deadline, not a sandbox. Sandboxes prove nothing about governance friction.
4. Rewrite the change-control clause last. If the contract still prices a fixed scope, iterative delivery keeps colliding with it whatever the team calls itself.

The phases themselves never change when the model does. Requirements, design, build, test, deploy and maintain all still happen; the model only decides how often you revisit them, which is worth reading next to where each SDLC phase actually breaks. When a specific programme is genuinely contested, the constraints tend to settle it faster than the debate does, and that is a short conversation rather than a workshop.

Written by the group's editorial team with the practice leads who run these builds. Reviewed before publish. Spotted an error? Tell us and we will fix it.