The Agile Mindset Shift Experienced Project Managers Need

Most project managers who move from predictive delivery into adaptive delivery have no trouble with the vocabulary. Backlog, iteration, increment and review can be learned in an afternoon, and an experienced project manager usually picks up the events faster than a newcomer, because they already understand why a regular checkpoint exists at all. The difficulty tends to arrive about three weeks in, when the team surfaces something that changes what the product should be. At that moment the trained instinct fires: log it, assess the impact, protect the plan.

That instinct is not wrong. It is calibrated for a different kind of work.

The shift, when it finally lands, is narrower and less mystical than a lot of agile training implies. It is not about becoming comfortable with disorder, and it is not about caring less whether the thing gets delivered. It changes three specific things: when you commit, what you accept as evidence, and how you tell whether the project is going well.

The shift is about when you commit, not whether you plan

Predictive delivery front-loads commitment. You do the analytical work early, you agree a scope, a sequence and a set of dates, and from then on the discipline is about protecting those commitments and controlling deviation from them. That is entirely rational when the solution can be understood early and when changing your mind late is genuinely expensive, which describes a great deal of real project work.

Adaptive delivery spreads commitment across the life of the work. Section 4.2.2 of The Standard for Project Management describes adaptive approaches as a development approach in their own right, built around iterative working, incremental delivery and requirements that are refined as understanding grows. Notice what that does not say. It does not say the planning stops. Adaptive teams plan constantly; they simply plan smaller amounts of work at a time, and they treat the plan as the current best answer rather than a commitment to be defended.

So the practical change is a change in the timing of decisions. In a predictive project, changing your mind late is a governed event, because something has usually been built or bought on the strength of the earlier decision. In an adaptive project, changing your mind at the right moment is the mechanism working as designed. The skill being asked of you is not open-mindedness. It is the ability to tell which decisions are cheap to defer and which are not, and to defer only the first kind on purpose.

That is a harder skill than it sounds, and it is one that predictive experience prepares you for rather well. A project manager who has spent ten years tracking dependencies is unusually good at spotting the decision a team is trying to postpone that genuinely cannot wait.

What replaces the reassurance of a baseline

The part that unsettles experienced project managers most is not the ceremonies. It is the loss of a clean answer to the question every sponsor asks, which is whether the project is all right.

In predictive delivery you have one. Variance against baseline gives you a number, and years of practice have taught you how to read it, when to trust it and when the number is hiding something. Move to adaptive delivery and that instrument is gone. What you are offered instead is working output: the part of the product that is genuinely finished, integrated and capable of being used or shown.

For a few weeks this feels like a downgrade, because working output is a much cruder measure and it always seems to say that less is done than you hoped. The recalibration comes when you notice that it is also much harder to fool. A percentage complete against a specification can drift for months without anyone doing anything dishonest. A feature either works end to end or it does not.

Once you accept working output as the primary signal, the useful questions change shape. What is genuinely finished and usable, as opposed to written? How much of it have real stakeholders seen and reacted to, rather than been told about? Is the rate of completion stable enough across the last few iterations to forecast from, and if not, why not? What is still deliberately undecided, and is anybody depending on it sooner than we think?

The failure mode worth naming here is the halfway state, where a team runs iterations and stand-ups while the project manager continues reporting percentage complete against a fixed scope agreed at the start. That arrangement gives you the reporting burden of both approaches and the honesty of neither. If the delivery is adaptive, the measures and the governance conversation have to move with it.

A solar project that needed both habits at once

Consider a utility-scale solar project. The grid connection date is set by the network operator, the civil works, mounting frames and panel installation are sequenced, costed and baselined, and none of that is going to become adaptive because somebody read a book. Running that part predictively is not old-fashioned. It is correct.

Alongside it, a small in-house team is building the monitoring and reporting platform the operations team will use once the site is live: dashboards, alarm thresholds, performance reporting. The project manager, whose background is heavy civil delivery, does the thing that has protected her on every previous project. She pushes to freeze the platform requirements in month two, so that nothing in the software workstream can threaten the connection date.

It is a defensible instinct and it produces the wrong outcome. The first block of the array is energised months before the rest of the site, and within a fortnight it is producing real generation data. That data changes what the operations team actually want to see, because several of the thresholds specified in month two turn out to be either meaningless or set at a level that would generate alarms constantly. Frozen requirements deliver a platform that is correct against the specification and wrong for the people who have to use it.

The judgement the situation is really asking for is a sorting exercise. Which decisions must be made early because physical work depends on them, and which can wait without cost? Cable routes, cabinet positions and connection works must be settled early; concrete does not accept a change of mind. Alarm thresholds and reporting formats cost almost nothing to leave open, and leaving them open until the first block is live buys information that no amount of workshop time would have produced.

The first energised block is not only a milestone. It is the best information the project has about everything still to be built.

Notice too what the shift does not license. Nobody gets to describe the connection date as an emerging outcome. Adaptive working applies to the workstream where deferring decisions is cheap and informative. This is the kind of distinction we spend real time on during PMP® Exam Preparation, because tailoring by workstream is where most hybrid projects are won or lost.

What your predictive experience is still worth

There is a version of this conversation that treats the experienced project manager as someone with bad habits to unlearn. It is inaccurate and it wastes the most useful thing in the room.

Dependency thinking, procurement judgement, the ability to hold a difficult conversation with a sponsor, knowing what a commitment genuinely costs to break: none of that becomes less valuable in adaptive delivery. In practice, experienced project managers often become strong adaptive practitioners fairly quickly once the shift lands, precisely because they can tell the difference between a decision that is being deferred and a decision that is being avoided. Teams new to adaptive working frequently cannot.

For a PMP candidate, the exam reflects the same expectation. The July 2026 PMP Examination Content Outline places approaches across the whole exam rather than confining agile to one corner of it, and states that roughly 40 per cent of items represent predictive approaches with the remaining 60 per cent divided between adaptive or agile and hybrid. The three domains carry People at 33 per cent, Process at 41 per cent and Business Environment at 26 per cent, and recommending a development approach sits inside the Process domain as part of planning delivery. The useful preparation habit is therefore to read each scenario for its context before reaching for a preferred technique, rather than to memorise a set of adaptive-sounding answers.

The real-project version of this is simpler. You are not being asked to become a different project manager. You are being asked to hold your commitments a little more loosely where the cost of holding them tightly is information you never get, and to keep holding them firmly everywhere else. Most projects need both, sometimes in the same week, and recognising which is which is the whole of the shift.

Andre Malowney

Interested in going further?

Sorting the decisions that must be made early from the ones worth deferring is difficult to learn from a definition, because it depends on reading the context in front of you. Structured preparation gives you a lot of worked situations to practise that judgement against, across predictive, adaptive and hybrid delivery rather than one at a time.

If you want the underlying treatment of adaptive approaches and how they sit alongside predictive and hybrid delivery, the PMBOK® Guide Eighth Edition is the source to read.

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
A063: Adaptive Does Not Mean Unplanned
A032: The PMI Mindset Explained: How PMP Expects You to Think
A060: Why Hybrid Projects Use Agile and Traditional Artefacts Together

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