Choosing Predictive, Agile or Hybrid for a Real Project

Most comparisons of predictive, Agile and hybrid delivery make the choice look tidier than it feels on a real project. Stable requirements point one way, evolving requirements point the other, and hybrid sits in the middle for anything undecided. Then the actual project arrives: a sponsor who has already told the board it will be "done Agile", a stage-gate lifecycle that expects an approved design at the second gate, a fixed-price supplier contract, and a team of whom half have never worked in iterations. None of those conditions appears in the comparison table, and every one of them affects what will work.

The more reliable way to choose a development approach is to stop asking what kind of project this is and start asking what each significant part of the work needs. Some parts will benefit from being defined, built and verified in a planned sequence. Others will only become right through trial and feedback. The organisation, the contract and any regulator will then set boundaries around both. The result is often a combination, but a deliberate one, with a clear account of why each part is handled as it is.

Labels are where most weak choices begin. Choosing by industry ("it's construction, so predictive" or "it's software, so Agile") ignores the fact that building design can be highly iterative and that safety-certified software may need a great deal of upfront definition. Choosing by project size, by fashion or by the word a sponsor happened to use in a steering meeting is no better. Section 4.3 of The Standard for Project Management, which accompanies the PMBOK® Guide in its Eighth Edition, treats approach selection as a matter of considerations rather than rules, grouped around the deliverables, the project itself and the organisation. That framing asks the project manager to look at the conditions and reason from them, which is harder than following a decision tree and considerably more useful.

Three questions to ask of each part of the work

A practical way to apply those considerations is to break the project into its main components or workstreams and put the same three questions to each. These are Omega's working questions rather than an official framework, but they bring the right evidence to the surface quickly.

When would we discover we were wrong, and what would it cost at that point? This question does most of the work. Where the cost of change rises steeply once something is manufactured, installed, contracted or approved, it pays to invest in definition and verification before committing, and a predictive sequence with controlled change is usually the right shape. Where change stays cheap for longer, or where nobody can know what "right" looks like until users try it, early delivery and feedback reduce risk more effectively than further analysis. Uncertainty on its own does not settle the matter. Some uncertainty is best reduced by a prototype or a short investigation before a baseline is set, and that kind of learning sits comfortably inside a predictive plan.

Can this part be delivered or tested in useful pieces, and is someone available to judge each piece? Adaptive delivery depends on two things that are easy to assume and often missing. The first is work that can be split into increments someone can use, test or react to. The second is regular access to people with the knowledge and authority to say whether an increment is heading in the right direction. A team running fortnightly iterations with nobody available to review the output is not learning; it is producing unreviewed work to a timetable. Where either condition is absent, the sound response is to create it or to choose a different approach for that part, rather than adopting the ceremonies and hoping.

What will the environment accept? Funding released against a fixed business case, procurement rules that require a firm specification, assurance gates, regulatory evidence, contractual acceptance and the team's own experience all shape what is realistic. These constraints rarely choose the approach outright. They do determine how far adaptive working can extend, what has to be fixed and documented, and where negotiation is worth attempting. An experienced project manager treats them as design inputs, neither a reason to abandon a better approach nor an obstacle to be quietly ignored.

Put to each component, these questions often produce different answers for different parts of the same project. That is not indecision. It is the normal result of looking closely, and it is where a hybrid approach earns its name.

A control room upgrade, taken part by part

Consider an original scenario. A regional emergency services organisation is replacing the operator consoles and call-handling software in a control room that runs twenty-four hours a day. A contractor builds the consoles under a fixed-price contract, with payments tied to acceptance. The switchover has to happen over a single planned weekend while calls are handled from a fallback site. The sponsor's first question to the incoming project manager is whether the project should be run as Agile.

She does not answer that question directly. She takes the work apart instead.

The consoles are steel frames with long manufacturing lead times, and they must fit an existing room. Once fabricated, changing them means re-manufacture and a delayed switchover, so the right shape is predictive: define, freeze, build, verify. That does not exclude learning. Before the design freeze, the contractor sets up a full-size plywood mock-up beside its standard steel console, and operators work at it through simulated shifts. They find that the main screen, at the standard height, sits too high to glance between it and the radio panel. Lowering the screen on the mock-up takes an afternoon. Lowering it after the frames had been fabricated would have meant re-manufacturing every console.

The call-handling screens and workflows are a different matter. Operators can describe what they need in general terms, but they only find the real friction when working through realistic call scenarios. That part runs in short iterations, with a small operator panel reviewing each release in a test environment and their findings driving the order of the remaining work.

Migrating address and hazard records is predictive again. A partially migrated dataset in a live control room is not acceptable, so the migration is planned, rehearsed through trial runs and reconciled before switchover. The switchover weekend itself follows a fixed, rehearsed sequence with agreed points at which the team can roll back.

The most consequential decisions sit at the joins. The project manager agrees a date after which changes to the call-handling configuration go through formal change control, because training material and switchover rehearsals depend on a stable version. She also works with the commercial lead and the contractor to frame acceptance around outcomes, such as operators completing defined call scenarios within agreed times, rather than around a frozen screen specification, so that iterative refinement does not become a contract variation every fortnight.

The answer to the sponsor's question turns out to be neither yes nor no. The project is hybrid, but not because hybrid felt like a safe compromise. Each part is handled in the way its own cost of change and access to feedback require, and the seams between the parts have been designed rather than left to chance.

Where the exam comes in

The same reasoning matters to PMP® candidates, although it surfaces differently. The 2026 PMP Examination Content Outline lists recommending a development approach (predictive, adaptive/agile or hybrid) among the enablers for the first task in the Process domain, which covers developing an integrated project management plan and planning delivery. The Process domain accounts for 41 per cent of the exam. The outline also states that predictive, adaptive/agile and hybrid approaches appear throughout all three domains, with approximately 40 per cent of items representing predictive approaches and the remaining 60 per cent divided between adaptive/agile and hybrid.

For a candidate, the useful habit is not memorising which characteristics map to which approach. Exam preparation can leave people with shortcuts such as "high stakeholder involvement means Agile" or "regulation means predictive", and those shortcuts tend to fail wherever several conditions point in different directions, which is exactly the kind of situation a scenario-based question can describe. The stronger habit is to read a scenario the way the control room project manager read her project: what is expensive to change, where feedback is available, and what the environment will allow. It is the kind of judgement we build across the wider syllabus in PMP® Exam Preparation, because recognising the conditions is more dependable than recalling a favoured method.

Recording the choice so it can be revisited

The final practical step is the one most often skipped. Once an approach has been chosen for each part, write down the reasoning in a few lines per component: what was chosen, which conditions drove the choice, and what would have to change for the decision to be reopened. It takes minutes and repays itself the first time circumstances shift.

They usually do shift. A supplier shortens its lead time, and a hardware freeze can move later to allow more trials. A regulator adds an evidence requirement that iterative releases now have to satisfy. An operator panel loses its most experienced members and the quality of feedback drops. Without a record of why the original choice was made, teams tend either to cling to the approach out of habit or to abandon it wholesale at the first difficulty. With one, the project manager can see which assumption has failed and adjust that part of the approach without unpicking the rest. The PMBOK® Guide treats selecting an initial development approach as the start of tailoring rather than its conclusion, and that is a sound way to hold the decision on any project.

A good approach choice is therefore less a verdict on what kind of project you are running and more a considered answer to what each part of the work needs in order to succeed. It gives predictive discipline to work that is costly to change, uses adaptive delivery where learning is genuinely available, and gives the joins between them as much attention as the parts.

Andre Malowney

Interested in going further?

Choosing an approach well means weighing the cost of change, access to feedback and organisational constraints together, often when they point in different directions. Structured PMP® preparation gives you repeated practice at that weighing across the wider syllabus, so the reasoning becomes a habit rather than a checklist.

The full considerations behind approach selection are set out in The Standard for Project Management, published with the PMBOK® Guide Eighth Edition.

Ad · Amazon affiliate link.

References

A065: Choose the Approach Around the Deliverable
A057: How to Recognise Predictive, Agile and Hybrid PMP Scenarios
A056: Predictive vs Agile vs Hybrid Project Management: How to Choose
A084: Selecting the Initial Development Approach
A067: How Your Organisation Limits or Enables Agile Delivery

PMP and PMBOK are registered marks of the Project Management Institute, Inc.