Planning in Predictive and Agile Projects

An experienced project manager joins an Agile programme and asks to see the plan. Someone points to a board of cards and a two-week iteration goal. The project manager leaves the conversation quietly concerned that nobody has thought beyond the end of the month. A few floors away, a product owner looks at a predictive schedule with task bars reaching eighteen months ahead and concludes that most of it is fiction. Both reactions are understandable, and both usually misread what they are looking at.

Predictive and Agile projects do not differ in whether they plan, or even in how much planning they do in total. They differ in three ways: when detail is committed, what the plan holds fixed, and how the plan is expected to respond once the work starts teaching the team something new. Once those differences are clear, most of the apparent conflict between the two styles turns out to be a disagreement about timing rather than about discipline.

The same questions, answered at different moments

Every project plan, whatever its format, tries to answer a familiar set of questions. What are we delivering? In what order? With which people and how much money? By when? What could stop us? The approaches differ on when those questions are answered in detail, not on whether they are asked.

A predictive plan answers most of them early. Requirements are defined and broken down, activities are sequenced against their dependencies, and durations and costs are estimated. The result is baselined so that performance can be measured against it. This makes sense when the solution can be understood well enough at the outset and changing course later is expensive: a building's foundations, a regulatory submission, a contracted delivery date. Good predictive practice is also less rigid than its critics assume. Rolling-wave planning has long been part of predictive delivery. Near-term work is planned in detail, and later phases are held at a coarser level until more is known.

An adaptive, or Agile, plan answers the same questions in layers. A product vision and roadmap set direction and rough sequence over a longer horizon. A release plan forecasts which capabilities are likely to arrive around which dates. The iteration plan commits in detail only to the work the team is about to do, and daily coordination adjusts that commitment as the work unfolds. Detail is produced as late as is responsible, because the team expects feedback from each increment to change what the next one should contain.

The Eighth Edition of the PMBOK® Guide makes room for both patterns. Section 4.5.2 of The Standard for Project Management treats planning as a Focus Area rather than a one-off stage at the start of a project. It recognises that planning can be done upfront, in rolling waves, iteratively, through a backlog or at several levels at once, with its depth and timing matched to the uncertainty involved. Readers who learned the Process Groups from earlier editions will recognise the territory. What has changed is the emphasis: the planning pattern is chosen to fit the work, rather than one pattern being assumed to fit every project.

What the plan holds fixed, and what it lets move

The second difference is less visible and more consequential. A predictive plan usually treats scope as its anchor. Once the deliverables are agreed, the schedule and budget are worked out from them, and change control exists to protect that agreement. A proposed change is assessed for its effect on time, cost, quality and risk before anyone decides whether to accept it.

Many adaptive projects reverse that relationship. The iteration length is fixed and the team is relatively stable, so time and capacity become the anchors and scope is what flexes. New or changed requirements enter the backlog, and the person accountable for product value decides where they sit relative to everything else. This is still change control. It happens continuously, through prioritisation, rather than occasionally through a formal request.

The reversal also shapes estimating and progress measurement. Predictive estimates are usually expressed as effort and duration against specific activities, and progress is read as variance from the baseline. Adaptive teams more often size work relative to other work, observe how much they actually complete over several iterations, and forecast from that evidence. Progress is read through working increments and a forecast that sharpens over time. Neither is the more serious form of control. Each suits a different degree of certainty about what the work will turn out to be.

Planning usually goes wrong when the logic of one model is carried into the other. A detailed task schedule for software features that users have not yet seen gives a steering group confidence it has not earned. Detail written beyond the point where anyone can genuinely know it is not rigour; it is guesswork that has been given a baseline. The opposite failure is just as real. Picture a team that plans only to the end of the current iteration while a contract expiry or regulatory deadline sits a few months away. That team has mistaken a short planning horizon for a complete one.

Reading the planning logic in a PMP® scenario

For a PMP candidate, the important skill is recognising a planning pattern rather than memorising a preferred one. The current PMP Examination Content Outline, published for the July 2026 exam update, says that predictive, adaptive/agile and hybrid approaches appear throughout all three domains and are not isolated to particular tasks. Approximately 40 per cent of items represent predictive approaches, and the remaining 60 per cent are divided between adaptive/agile and hybrid. In the Process domain, the task of developing an integrated project management plan includes recommending a development approach. The schedule task includes preparing a schedule based on the selected approach, and estimating with milestones, dependencies and story points.

A useful exam-preparation habit is to work out the planning logic of a scenario before weighing the options. Suppose a stakeholder asks for an additional feature. On a project managed against an agreed, baselined scope, the request raises questions about impact on the baseline and the change control process. On a project where a product owner manages a prioritised backlog, the same request is mainly a prioritisation decision. An option that is sensible in one context can be poorly judged in the other, so reading the situation carefully tends to matter more than recalling a rule. We practise this kind of situational reading throughout PMP® Exam Preparation, and the first step is always to identify which planning model a situation is operating under.

Deciding where detail belongs

On a real project, the useful question is rarely "predictive or Agile planning?" in the abstract. It is closer to this: which decisions need to be made firmly now, and which would we only be guessing at?

A workable test is to plan in detail wherever a decision has any of these features:

• it is expensive to reverse;
• it has a long lead time;
• other people will commit money, staff or reputation because of it.

Keep the plan deliberately coarse wherever the next piece of learning is likely to change the answer. Most projects contain both kinds of decision, so planning style is often chosen workstream by workstream rather than once for the whole project.

Consider a local authority replacing the system its housing repairs service uses to log and schedule jobs. Support for the existing system ends on a fixed date at the end of March. The data migration needs a weekend when call handlers can go back to logging jobs manually, and operations need months of notice to release that weekend. Around 140 repairs staff must be trained before go-live, and training cannot start until the screens they will use are stable. Meanwhile, the repairs officers cannot say with any confidence how the new job triage workflow should behave until they have used a working version of it.

A competent project manager notices the fixed points first. The support end date, the cutover weekend, the training programme and the data protection impact assessment all have long lead times or hard consequences. So they are planned predictively: sequenced, dependencies mapped, owners named and a baseline agreed with the programme board. The workflow configuration is planned adaptively, in two-week cycles. Repairs officers review working screens at the end of each cycle, and anything beyond the next cycle or two stays in the backlog at a coarse level.

The judgement lies in connecting the two. The configuration backlog has to be forecast at release level against the date training must begin, because that date is the real deadline for the adaptive work. If the forecast shows the backlog will not be finished in time, the project manager needs a conversation with the business owner. The question is which workflows are genuinely needed at go-live and which can follow in a later increment. That conversation belongs in October, not in February.

Two responses would be premature. Writing a task-level schedule in October for February's configuration work creates precision that the first review session will overturn. Declaring the whole programme Agile and leaving the cutover weekend unbooked is the more damaging mistake. No amount of iteration can recover a migration window that operations were never asked to release.

Whichever approach a project uses, the best plan is detailed where commitments are real and honest about where they are not. Predictive planning earns its upfront effort when the work can be known and change is costly. Adaptive planning earns its shorter detailed horizon when the team will learn its way to the right answer. Most project managers will move between the two across a career, and many will manage both inside a single programme. The capability worth building is not loyalty to either style. It is the ability to look at a piece of work and explain, with reasons, how far ahead it can sensibly be planned.

Andre Malowney

Interested in going further?

Two judgements improve with deliberate practice: deciding how far ahead a piece of work can sensibly be planned, and recognising which planning logic a situation is using. Structured PMP® preparation works through both across predictive, Agile and hybrid scenarios, so the reasoning becomes a habit rather than an improvisation.

The PMBOK® Guide Eighth Edition is the reference to keep close for the full treatment of the Planning Focus Area and how it sits alongside the development approaches.

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
A061: The Agile Mindset Shift Experienced Project Managers Need
A060: Why Hybrid Projects Use Agile and Traditional Artefacts Together

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