Welcome back to Project Management Masterclass, the show where we help you master the fundamentals of project management, transform the way you lead projects, and stay informed about the trends shaping the future of the profession. I'm your host, Brittany Wilkins.
This episode builds off Episode 35, Project Management Trends 2026. In that episode, I talked about the strategic value of artificial intelligence beyond productivity. Today, we're moving into the second trend in the series: adaptive planning.
Planning is a double-edged sword. It has to happen to initiate execution and delivery. It establishes the pathway toward the result the customer, client, or stakeholder is looking for. But a plan is built on what we know at a particular point in time. As the project evolves, things happen. Requirements change. Stakeholder expectations change. Resources change. Market conditions change. And when they do, the plan sometimes has to change with them.
So here's a question worth sitting with: how do you adapt the plan without constantly disrupting execution?
It becomes a tug-of-war. At some point, the team has to get something done. So adaptive planning isn't simply about getting better at changing the plan.
The harder challenge is knowing when the plan should change, what should change, and who has the authority to make that decision. That's what I want to get into today.
Grounding Adaptive Planning in the Fundamentals
Ask a room full of companies how they define adaptive planning and you'll get a million different answers. But grounded in the fundamentals of project management, adaptive planning shows up through a set of approaches and techniques for navigating change and uncertainty: iterative and incremental development, progressive elaboration, rolling-wave planning, backlogs, stakeholder engagement, tailoring, ongoing assessment and reprioritization.
In one organization, that looks like rolling-wave planning, where near-term work is planned in detail while work further out stays at a higher level until more information arrives. In another, it looks like iterative development, where the team works in cycles, learns from feedback, and uses what it learns to shape the next cycle. In another, it's as simple as maintaining a backlog of stakeholder requests, evaluating them, understanding the impact, and reprioritizing based on value and what the project is trying to achieve.
Adaptive planning isn't one thing. And most of the mechanisms we use to adapt aren't new. We've been progressively elaborating plans, working through changing requirements, engaging stakeholders, assessing impact, and reprioritizing work for a long time. These are project management fundamentals. The challenge is applying them while the environment around the project keeps moving.
Rolling Uncertainty
This brings me back to the webinar that sparked this series. One observation from the presenters stuck with me: organizations are dealing with more uncertainty than they anticipated. They called it rolling uncertainty. We're not dealing with one disruption, working through it, and returning to normal. Organizations keep encountering uncertainty and disruption, and they keep having to adjust as they go.
A second observation caught my attention. The presenters said they were seeing adaptive planning happen at the portfolio level, but not making its way down to the project level. Some project managers have the authority to adjust when circumstances change. Others don't. They recognize the project needs to shift, but then have to go back to the sponsor or other stakeholders, build the case, work through the analysis, and wait for approval.
And here's where it gets interesting. By the time the decision finally gets made, the circumstances that triggered the request may have changed again. Now the team is caught in a cycle: identify the need to adapt, do the analysis, escalate the decision, wait. Meanwhile, the project environment keeps moving.
That's where adaptive planning stops being a planning conversation and becomes a decision-making conversation. You can recognize the change, understand its impact, and know what adjustment is needed. But someone still has to have the authority to make the call, and make it in time for the decision to matter.
Decision Rights
This is where we have to talk about decision rights. If we want project managers and project teams to be adaptive, there has to be clarity around what decisions they actually have the authority to make. What can the project manager adjust without going back for approval? What decisions belong to the sponsor? What has to go through a steering committee or another governance body? At what point does a change become significant enough to escalate?
Not every change carries the same weight. Adjusting the sequence of a few activities is a different problem than a change that touches the business case, scope, budget, regulatory requirements, or the value the project is expected to deliver. That's why clear decision boundaries matter. The project manager needs enough authority to manage the project and respond when conditions change. But there also has to be governance around decisions that could materially change what the organization agreed to invest in and deliver. Ideally, this gets settled before it's needed. The moment the environment starts moving is the worst moment to figure out who has the authority to make the call.
When Adaptation Becomes Reaction
There's another side to this. At some point, people need enough stability to actually execute the work. During the webinar, an attendee asked a question that captured the tension well: at what point do we freeze the tasks and let people finish something?
That's a real question, because adaptive planning can go too far.
If every new stakeholder request changes the plan, if every shift in the market changes the priority, if every new idea from leadership sends the team in a different direction, the organization isn't adapting anymore. It's reacting.
And reacting has a cost: rework, confusion around priorities, budget overruns. Eventually people stop trusting the plan, because they expect it to change again, so they stop committing to it. Why get ahead of the work if it's probably going to change anyway?
Being too rigid creates a different problem. The presenters made the point that refusing to adjust because you're committed to finishing what you originally planned can mean successfully delivering something the customer or the market no longer needs.
My own motto has always been: I'm rigid on the outcome, but flexible on the approach that gets me there. The outcome is the anchor. If circumstances change and there's a better way to reach it, I'll adjust the approach. That doesn't mean changing direction every time something happens. It means understanding what you're trying to achieve well enough to know what can change and what shouldn't.
So there's a balance: enough flexibility to respond when something materially changes, enough stability for the team to execute. The word "materially" is doing a lot of work here, because not everything that changes around a project should change the project itself. Sometimes new information comes in, you assess it, and the right call is to stay the course.
That's still adaptive planning. You considered the information, understood the impact, and made an intentional decision not to change anything. Other times, the information tells you something in the plan no longer holds up. That's when adaptation becomes necessary. The goal isn't constant change. It's responding intentionally when change actually matters.
Putting Adaptive Planning Into Practice
Back to the day-to-day work of managing a project. Something changes. Before changing the plan, slow down long enough to understand what actually changed and whether it materially impacts the project. A stakeholder asking for something different doesn't automatically mean the plan needs to change. A new risk doesn't automatically mean the plan needs to change. A shift in resources doesn't automatically mean the plan needs to change.
You have to assess the impact first: what changed, and what part of the current plan does it touch? Scope? Schedule? Budget? Resources? Risk? Quality? The value and outcome the project is expected to deliver?
Once you understand the impact, you can determine what happens next. Maybe the plan changes. Maybe the request goes into the backlog and gets prioritized for later. Maybe the decision needs to be escalated because it's outside your authority. Or maybe, after looking at everything, the answer is: we're not changing anything, we're moving forward. That's why prioritization and impact analysis matter so much in adaptive planning. You're not simply responding to change. You're evaluating it and making an informed decision about what to do with it.
Which brings us back to decision rights. If a change does need to happen, who has the authority to make it, and how quickly can that decision get made? You don't want a project team sitting still for three weeks waiting on a decision that could have been made in three days. At the same time, you don't want teams making changes that materially affect scope, budget, strategy, or the business case without the governance to back it up. That's the balance: enough authority to keep execution moving, enough governance to keep the project aligned.
This is where the fundamentals come together. Stakeholder engagement surfaces changes earlier. Impact analysis tells you what the change means. Prioritization tells you what matters most. Rolling-wave planning gives you room to refine future work as more information becomes available. Clear decision rights let you actually act on that information. None of these operate independently.
They work together, and when they do, adaptive planning becomes less about constantly rewriting the project plan and more about building a disciplined way to respond when reality doesn't match what was originally planned.
Closing
So back to the question I opened with: how do you adapt the plan without constantly disrupting execution? There isn't one perfect answer. Every project is different, every organization is different, and the level of uncertainty you're navigating will be different too. But the fundamentals still hold. Assess the impact. Understand the trade-offs. Prioritize. Engage your stakeholders. Know your decision rights. When the information tells you the plan needs to change, be willing to change it. When it doesn't, stay the course and let your team execute.
That's why I keep coming back to my own motto: I'm rigid on the outcome, but flexible on the approach that gets me there. The plan gives us direction, but it was also built on what we knew at a particular point in time. As new information comes in, the job isn't to blindly protect the plan, and it isn't to constantly change it either. The job is judgment: understand what has materially changed, understand what it means for the project, and make an informed decision about what happens next.
Adaptive planning isn't about reacting to everything that changes around you. It's about building enough flexibility to respond when change matters, while maintaining enough stability to actually deliver. That's something to sit with as you look at the projects you're leading right now. Where might you need to adapt? And where might your team simply need the space to execute?
I'm Brittany Wilkins, and this is Project Management Masterclass.
