A hybrid approach takes some elements from predictive delivery and some from adaptive delivery on one project. It is what a careful reading of the work usually produces, because the factors that decide an approach rarely give the same answer for every part of a project.
Roughly three question sets in five on the current exam sit in adaptive or hybrid territory, and the hybrid ones are reported as the harder half. The reason is that pure adaptive questions have a doctrinal answer while hybrid questions ask what fits, which requires holding both models at once.
The patterns worth recognising
| Pattern | What it looks like | When it fits |
|---|---|---|
| Predictive frame, adaptive fill | Milestones, a funding envelope and a contracted scope at the top, short cycles delivering underneath | The commitment is external and the route to meeting it is uncertain |
| Adaptive frame, predictive component | The project runs in cycles, with one long lead element planned and baselined separately | Hardware, procurement or anything with a lead time longer than a cycle |
| Sequential phases, different approaches | Discovery run adaptively, construction run predictively | Uncertainty is concentrated at the front and falls sharply once the design is settled |
| Adaptive delivery, predictive governance | Team works in cycles, reporting and change control stay formal | A regulated environment or a portfolio office that cannot change, where the team still benefits from short feedback |
| Parallel components | Several workstreams, each with its own approach, joined at integration points | A programme whose parts genuinely differ, which is most large programmes |
The second and fifth are where most real projects land, and both put the difficulty in the same place, which is what happens where the parts meet.
The seams are where hybrid fails
Two components running at different cadences have to exchange something, and the exchange is what needs designing.
A cycle finishing every two weeks that depends on a decision from a board meeting every quarter is not a hybrid arrangement, it is an adaptive team with a six week average wait. Either the board delegates within a tolerance, or the team stops depending on those decisions, or the cadence is a fiction.
A predictive component that consumes the output of an adaptive one needs to know what it is getting and when. The adaptive side's honest answer is a range, and the predictive side's plan wants a date. Bridging that means agreeing a minimum that will definitely be delivered by a date, with everything above it treated as upside.
The seam questions worth asking are short. What crosses this boundary, in which direction, how often, and what does each side need to be able to promise the other? An arrangement that cannot answer those has not been designed.
Governance has to move with the delivery
The most common hybrid failure is leaving governance untouched while changing how the work is done. The team adopts cycles, the reporting cycle stays monthly, change control stays centralised, and the benefit of short feedback is absorbed by the wait for a decision.
What moves is decision rights and tolerance. A team that delivers fortnightly needs authority to make fortnightly decisions, which usually means a threshold below which it decides for itself and above which it escalates. Setting that threshold is a governance act, and it is the one that makes the rest of the arrangement viable.
Reporting moves too. A component tracked by finished increments and one tracked by percentage of a baseline complete cannot be added together honestly, and producing a combined figure by translating one into the other manufactures a number nobody should act on. Reporting each component in its own terms, with a single view of milestones and risks above them, is less tidy and more true.
Change control across the boundary
Predictive components change by decision through a defined process. Adaptive components change by reordering a backlog, continuously and without a request.
Both are correct in their own half, and the boundary between them needs a rule. The usual one is that anything altering the contracted or funded envelope goes through change control regardless of which component it lands in, and anything inside the envelope is the delivery team's to reorder.
That rule works because it puts the control where the commitment is. It fails quietly when the envelope was never written down precisely enough for anybody to say whether a given change is inside it, which is why hybrid arrangements need a clearer statement of scope at the top than a purely adaptive one does.
What decides the mix
Return to the factors that choose an approach at all, and apply them per component rather than per project. Requirement stability, feedback availability, regulatory constraint and the cost of a wrong turn each give a different answer for hardware than for a mobile application, and that difference is the whole reason the project is hybrid.
Then check three practical things. Whether the organisation can actually support two cadences at once, whether the people involved have worked this way before, and whether the integration points are few enough to manage. A theoretically correct mix with twenty integration points and nobody who has run one before will underperform a simpler arrangement that everybody understands.
Where each syllabus puts it
Scrum describes a single cadence and says nothing about combining it with anything else, which is why hybrid guidance comes from elsewhere. Disciplined Agile treats the choice of practices as the central act and supplies a way of making it. PRINCE2 handles the same territory through tailoring, with stages and tolerances as the mechanism.
PMI treats hybrid as a first class position rather than a compromise, and the exam reflects that. Questions describe a mixed situation and ask what to do next, and the answers that score are usually the ones that adjust governance or design a seam rather than the ones that push the whole project towards one end of the range.