A delivery approach is the shape of the plan rather than the plan itself. It settles how much is decided before work starts, how often a usable result reaches somebody able to judge it, and what happens to the plan when change arrives. Predictive, adaptive and hybrid are the names given to positions along that range.
Treating the choice as a switch between two camps is the most common error, and it is what makes scenario questions on this topic awkward. The useful model is a dial with a great deal of workable ground in the middle.
The range runs on how much is fixed in advance
At the predictive end, scope is defined early, a baseline is set, and change flows through a formal control process. Effort goes into getting the definition right, because rework is expensive once construction has begun. Building a bridge sits here for reasons that have nothing to do with fashion.
At the adaptive end, only a small amount is defined in detail, something usable is produced in a short cycle, and what is learned reshapes the next cycle. Scope is the variable and the cadence is fixed. Between the two sit iterative approaches, which refine one deliverable over several passes, and incremental ones, which release finished pieces in sequence.
The middle of the range holds most real work, and hybrid is a position on that range rather than a fifth option beside it. That is how one programme can plan to milestones at the top level and still deliver in short cycles underneath them.
What actually decides it
Four questions carry most of the weight.
How stable are the requirements? Where the outcome is genuinely known and unlikely to move, planning it out is cheaper than discovering it. Where nobody can say what good looks like until they see something, early definition is a guess written down in an authoritative font.
How early can feedback arrive? Adaptive delivery runs on somebody looking at a real increment and reacting to it. If the users are unavailable for eight months, or the deliverable cannot be usefully seen until it is complete, the loop that makes iteration valuable is simply not there.
What does the regulatory or contractual environment demand? Evidence of design, traceability from requirement through to test, staged approvals and a fixed price agreement all pull towards documented plans and baselines. That constraint is real, and no amount of enthusiasm dissolves it.
How costly is a wrong turn? Where a mistake is cheap and reversible, learning by building is the efficient path. Where it is expensive, irreversible or dangerous, the cost of analysis is small next to the cost of finding out.
Set out as a table, the four become a way of scoring the work actually in front of you rather than a piece of doctrine.
| Factor | Points predictive | Points adaptive |
|---|---|---|
| Requirement stability | The outcome is known and unlikely to move, so defining it costs less than discovering it | Nobody can describe good until they have seen something, so early definition is a guess |
| Feedback availability | Users are reachable at gates months apart, or the thing cannot be judged until it is finished | A usable increment can go in front of somebody able to react to it every few weeks |
| Regulatory constraint | Traceability, evidence of design and staged approval are demanded, and a fixed price is signed | The regulator sets the outcome and leaves the route open, or the domain carries no formal gate |
| Cost of a wrong turn | A mistake is expensive, irreversible or dangerous, so analysis is cheap beside it | A mistake is cheap to undo, so building is the fastest way to find out |
| Team and environment | Large, distributed or contracted teams, with release infrastructure still to be built | A small team working closely together, with the tooling to release whenever it wants |
The practical factors in that last row sit alongside the four rather than under them. Team size and distribution, experience with the domain, and how much delivery infrastructure already exists all change what is achievable whatever the theory prefers.
One row pointing one way is rarely the whole answer. What the table is for is finding the factor that dominates, because a single irreversible and heavily regulated component will pull an otherwise adaptive project towards documented baselines whatever the other rows say.
Hybrid is usually the honest answer
Hybrid gets described as a halfway house for organisations not brave enough to commit. In practice it is what a careful reading of the four questions tends to produce, because the answers differ across the pieces of one project.
A common arrangement plans the programme against milestones and a funding envelope, then delivers the software in short cycles inside those milestones. Another keeps formal change control for anything touching contracted scope while letting the design detail underneath be settled iteratively. Each of those is a deliberate fit to where the risk actually sits.
Choose per component, not per project
The decision belongs at the level where the risk lives. Within one project the hardware may be predictive because tooling has a long lead and a late change scraps a mould, the mobile application may be adaptive because usage data arrives weekly, and the data migration may be iterative because each pass reveals more about the source system.
Deciding once for everything forces the components with least uncertainty to carry ceremony they do not need, or leaves the components with most of it running without the control they do need. Splitting the decision costs an integration plan and a shared view of dependencies, and that is work worth doing.
Revisit the choice as evidence arrives
An approach selected at initiation was selected with the least information anybody will ever have. Uncertainty falls as work proceeds, so an area needing short cycles at the start may be understood well enough by the second phase to be planned out, and a component assumed to be routine may turn out to need the loop after all.
The tailoring decision belongs in the plan along with the reasoning behind it, so that a later challenge can be answered with something better than preference.