Adaptive Does Not Mean Unplanned

An experienced project manager joins an adaptive programme and asks to see the plan. Someone points to a backlog tool, a board covered in cards and a calendar of short recurring meetings. There is no integrated schedule, no baseline finish date and no document that looks like a project management plan. A reasonable first reaction is that nobody has done any planning, and the team's easy confidence only deepens the suspicion.

Sometimes that suspicion is correct. More often, the planning exists but sits in several places at once. It is held at different levels of detail and revisited far more often than a predictive plan would be. Planning in an adaptive project works in layers. The outcome, constraints, funding and fixed commitments are planned early and at low detail. Work in the near future is planned in more detail as the team comes to understand it. Each iteration or cycle is planned in full, on the understanding that the next one will be planned again with better information. What adapts is the detailed plan. The frame around it should change only through a deliberate decision.

Planning moves closer to the work

Predictive delivery concentrates a good deal of detailed planning early. That makes sense when the requirements and solution can be understood well enough to justify the effort. A baseline then gives the project a stable reference for controlling change. The logic is sound where it applies, and experienced project managers are right to value it.

Adaptive approaches start from a different assumption about the work. Some of what needs to be built will only become clear once early versions have been produced, shown to users and adjusted. Planning every feature in detail months ahead would mean planning things that will not survive feedback, so the detail is deferred until better information is available. Section 4.2.2 of The Standard for Project Management treats the adaptive approach as a deliberate choice for work whose requirements or solution need to evolve through feedback and learning. Nothing in that framing removes the need to plan. It changes when detail is added and how firmly it is held.

The Eighth Edition of the PMBOK® Guide takes the same view of planning more broadly. Planning can be rolling-wave, iterative or backlog-based, and it can happen at several levels at the same time. An ordered backlog is itself a plan: it records an intended sequence of work based on value, risk and dependency. Every refinement session that reorders it is a planning activity, whether or not anyone calls it that.

Detail matched to distance

A useful way to picture adaptive planning is as a set of horizons, each with its own level of detail and its own rate of change.

The widest horizon covers the product or outcome. It answers who the work is for, what should be different when it succeeds and how success will be recognised. It also sets the available funding and the constraints and external dates that cannot move. This layer is deliberately light on detail and should be fairly stable. If it shifts every month, the team does not have an adaptive plan; it has an unsettled purpose.

Closer in sits release or roadmap planning, typically covering a few weeks to a few months. Here the team groups capabilities that need to arrive together and coordinates with other teams and suppliers. It also forecasts when meaningful increments are likely to be ready. Good forecasts at this level are expressed as ranges and updated from what the team has actually delivered.

Closest of all is the iteration, or in flow-based teams the next replenishment of work. At this level the team identifies tasks, discusses effort, applies the definition of done and commits to a small, concrete body of work. Daily coordination then adjusts the plan within that short window. As the horizon shortens, detail and commitment rise and stability falls.

The iteration plan is built to be rubbed out and redrawn every couple of weeks. The frame around it, meaning the outcome, the funding, the fixed dates and the dependencies on other teams, is planned carefully so that it does not have to be. One practical question keeps the layers honest. If this piece of detail changes next month, how much planning effort will we have thrown away? If the answer is "a lot", the detail is probably arriving too early. If the answer is "nothing, because we have not thought about it at all", something important may be arriving too late.

The planning that cannot wait for an iteration

Consider a fictional university research office replacing a patchwork of spreadsheets with a research data management platform. An internal digital team delivers the platform in two-week iterations. The product owner comes from research services and knows the users well. The backlog is carefully ordered, early iterations put working screens in front of researchers, and the feedback is encouraging.

In the fourth iteration, the team is ready to connect grant codes to the university's finance system. Only then does it learn that the finance systems team deploys integration changes in a quarterly release window, and the next window is already fully booked. At the same time, the information governance office confirms that real research data cannot be loaded until a data protection impact assessment has been signed off, which takes several weeks. Neither fact was secret. Nobody had asked, because the team had come to think of planning as ordering the backlog. The result is two iterations of good work that cannot be released, and a funder reporting date that suddenly looks exposed.

The team had not been too adaptive. It had been under-planned in exactly the places where adaptive work still needs planning. Recovery did not require a detailed baseline for the whole platform. First, the fixed points, meaning the finance release windows, the assessment lead time and the reporting date, went onto the roadmap where everyone could see them. Next came a conversation with finance about the earliest realistic slot. Finally, the team reordered the backlog so that integration and data-protection items reached a releasable state before those dates. The product scope stayed flexible. The dates it depended on did not.

Anyone from a predictive background will recognise the areas that usually need early planning in adaptive work:

• how funding will be released and reviewed;
• who holds which decisions, and when escalation is needed;
• which regulatory, contractual or calendar dates are genuinely fixed;
• which dependencies sit with teams working to a different cadence;
• whether the people who make product decisions will be available often enough;
• what quality standard defines "done";
• how risks will be surfaced and acted on.

Experienced predictive project managers are often strongest in precisely these areas, and adaptive teams are better for their involvement.

Telling adaptive planning from improvisation

When you join, review or sponsor an adaptive project, the absence of a Gantt chart tells you very little. What people can explain tells you much more. Ask someone to describe in a sentence or two what the next release is meant to change for users. Ask the product owner why the top items in the backlog are at the top. Look for a forecast stated as a range and updated from real delivery, and for fixed dates and external dependencies sitting visibly alongside the work instead of being discovered by collision. Find out where plans get changed, and whether that happens in a known forum with the right people present.

Confident answers suggest a planned adaptive project, even if the artefacts look unfamiliar. Stock answers such as "it's all in the backlog" or "we'll know more after the next sprint", given to every question, suggest improvisation dressed in adaptive language. The opposite error matters just as much. Demanding fully decomposed scope and fixed dates for features nobody yet understands produces a plan that looks rigorous but is wrong. It also teaches the team to maintain documents rather than learn.

For a PMP® candidate, this distinction has direct value. The current PMP® Examination Content Outline places predictive, adaptive and hybrid approaches across all three exam domains. Roughly 40% of items represent predictive approaches, and the remaining 60% are divided between adaptive or agile and hybrid, although the exact mix can vary by exam form. Scenarios will often describe an adaptive team facing a problem. The useful preparation habit is to ask whether the situation shows legitimate re-planning from feedback, or a planning gap the team has not noticed. An option phrased in adaptive vocabulary can still leave that gap untouched. Scenario practice in Omega's PMP® Exam Preparation gives this separation deliberate attention, because the wording of an answer can make a weak response sound convincing.

On a real project, the discipline is easier to state than to maintain. Look for the layers. Check that the frame is stable and visible. Bring the dependency, risk and governance planning that adaptive teams sometimes skip. The team keeps the freedom to change what it builds next, and the organisation keeps the confidence that someone has thought about what cannot change.

Andre Malowney

Interested in going further?

Exam scenarios rarely state whether a team has planned properly, so candidates have to infer it from what the team does next. Structured PMP preparation helps you read those cues across predictive, adaptive and hybrid situations instead of reacting to familiar vocabulary.

The PMBOK® Guide Eighth Edition sets adaptive approaches alongside predictive and hybrid options within The Standard for Project Management, and it is the best place to read the concept in full.

Ad · Amazon affiliate link.

References

A061: The Agile Mindset Shift Experienced Project Managers Need
A122: Tailoring Schedule Management for Adaptive Delivery
A073: Executing in an Adaptive Project
A072: Planning in Predictive and Agile Projects
A059: Hybrid Project Management Explained for Traditional Project Managers

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