Predictive Project Management Still Has a Place
It has become unusual to hear a team describe its delivery as predictive without adding something slightly apologetic afterwards. The scope was agreed at the front end, the work is sequenced, change goes through a decision process, and the delivery still gets called hybrid because there is a stand-up on Tuesdays and a board on the wall. The label costs nothing until someone starts managing the work as though the label were true.
Predictive delivery is the better choice when two conditions hold together. The important shape of the work can be understood early enough to plan and sequence it, and being wrong late would be expensive enough that the cost of defining it early is worth paying. Neither condition has anything to do with the size of the project, the age of the industry or the preferences of the people involved.
Deciding early, and living with the decision
Choosing predictive means agreeing to define, sequence and baseline more of the work before building it, and to route changes to that baseline through a decision instead of absorbing them quietly as they arrive. That is the commitment. It buys coordination, credible forecasting and the ability to let other people plan around you, and it costs flexibility that would be cheap to keep in a different kind of work.
Section 4.2.1 of The Standard for Project Management describes predictive approaches as one of several legitimate development approaches, selected because the project's conditions suit them. The selection is the point. A predictive plan chosen because the conditions call for it behaves differently from one inherited because the organisation has always worked that way, even where the two produce a similar-looking schedule.
Predictive work still learns. Rolling-wave planning, progressive elaboration, design reviews, factory acceptance testing and phase decisions are all feedback, and a baseline exists to make change visible and decidable rather than to prevent it. The version of predictive delivery that refuses to replan is a badly run predictive project, and it should not be treated as evidence about the approach.
When the conditions genuinely point that way
Knowability of the solution comes first. The question is not whether anything will change, because something always does, but whether the requirements and the technical solution can be understood well enough now to sequence the work sensibly. Where the answer is yes, spending months discovering incrementally what could have been specified in six weeks is slower and no safer.
The cost and reversibility of late change is usually the deciding factor. A transformer with a thirty-week lead time, a regulatory submission, a concrete pour, a network cutover with a contractual outage window: these are decisions that are expensive or impossible to revisit once taken. Where the cost curve of change rises steeply with time, front-loading definition is not caution for its own sake, it is the cheaper option.
Dependency density and external fixed points matter next. When suppliers, regulators, operations teams, customers and other projects are all planning around your dates, your dates become a commitment other people spend money against. Iterating a delivery date with fifteen parties who have each booked resources against it is not agility, it is a coordination failure distributed outwards.
Then there is the economics of feedback. Iteration earns its overhead when feedback is fast, cheap and genuinely informative. Where the only meaningful feedback arrives at commissioning, or where users cannot evaluate a partial system, short cycles buy ceremony without buying learning, and the planning effort is better spent making the one pass count.
Most real projects answer these questions differently for different parts of the work, which is where genuine hybrid delivery comes from. The point is to answer them deliberately rather than to inherit a default.
Eighteen days on a fuel terminal
A fuel terminal agrees an eighteen-day shutdown with its refinery supplier and its largest customers fourteen months in advance. Inside that window sit a tank internals inspection, a pipework replacement, valve changes across two isolation sections and a control-system cutover. The isolation permits determine what can be worked on and when. A replacement valve has a thirty-week lead time. Crane hire, scaffolding and around ninety contractors are mobilised against a shift pattern agreed months earlier.
Nothing about this is documentation theatre. The sequence is constrained by physical isolation and permit logic, not by a preference for planning. Discovering in week two that two jobs need the same isolation is not a backlog reordering exercise, because the alternative is a second shutdown, and a second shutdown costs more than the entire project team. The plan is the mechanism by which several hundred people avoid arriving at the same valve.
The control-system work in the same window behaves differently. The operator interface screens were developed iteratively with the control room team over the preceding six months, reviewed in short cycles, changed freely, and then frozen for a fixed cutover inside the outage. The project manager did not choose an approach for the project. She chose one for the turnaround and another for the software, and held the interface between them.
The failures usually blamed on the approach
Most complaints about predictive delivery describe practice rather than approach. A plan nobody updates. A baseline defended to conceal variance rather than to control it. Stage gates that consume three weeks and change nothing. Estimates produced under pressure and then treated as promises. A change process slow enough that people route around it, which produces the uncontrolled change the process existed to prevent. Each of these is fixable without changing the development approach, and none of them is improved by renaming the same behaviour.
The genuine failure mode is different and worth naming. Predictive goes wrong when it is applied to work whose solution is not knowable yet, because the early definition is then a guess, and the governance built on top of it protects the guess. A requirements document written for something nobody has seen before will be wrong, and the machinery around it makes the wrongness harder to correct than it would have been to discover.
For anyone preparing for the PMP® exam, this is more useful than a memorised list of characteristics. Approximately 40% of exam items represent predictive approaches, with the remaining 60% divided between adaptive or agile and hybrid, and these approaches appear throughout all three exam domains rather than sitting in a section of their own. Scenario questions rarely announce the approach. They describe conditions, and the candidate is expected to read stability, reversibility, dependency and feedback out of the situation before deciding what a competent response looks like.
Reading those conditions quickly under time pressure is a practised skill, and working through scenarios where the approach is not obvious from the first paragraph is a large part of what structured PMP® exam preparation is for.
On a live project, the practical move is to make the approach decision explicit and write down the conditions it rests on: what is knowable now, what becomes expensive to change and when, who is planning against your dates, and where real feedback comes from. Record those four answers alongside the approach, and revisit them when one of them changes. That is a far smaller decision than discovering in month seven that the approach no longer fits the work.
Interested in going further?
Judging when to define work up front, and defending that judgement to a sponsor who has been told that predictive delivery is outdated, takes more than knowing the definitions. Omega's PMP® preparation works through the conditions behind the choice using realistic delivery situations, so the reasoning holds on your own projects as well as in the exam.
The Eighth Edition sets out predictive, adaptive and hybrid approaches side by side as selections to be made in context, which is the framing this article builds on.
Ad · Amazon affiliate link.
References
A056: Predictive vs Agile vs Hybrid Project Management: How to Choose
A057: How to Recognise Predictive, Agile and Hybrid PMP Scenarios
A072: Planning in Predictive and Agile Projects
A095: Governance in Predictive Environments
A007: The Standard for Project Management vs the PMBOK Guide
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
