I agree with this principle, as I promote the Drum Beat method specifically as an operational approach for this. However, one must be careful not to lose perspective on the scale. If the most important requirements aren't clear at the project's outset, then it's not a project but an adventure. You can certainly tackle an adventure using project management methods, but you must always be aware that what emerges at the end remains uncertain throughout. It might turn out well, but it doesn't have to. Ultimately, it comes down to expectations management: whoever promises a project must deliver on requirements, budget, and timeline and needs therefore to be clear on that. Those who can't or won't do that should only promise an adventure.
I think this is exactly where the discomfort comes from. When work is genuinely complex, planning feels less like executing a map and more like going on an adventure. Not because it is careless, but because the terrain cannot be fully known upfront.
In complex software projects, uncertainty is structural, not a planning failure. Complexity shows up in very specific ways:
Many interacting components. Modern systems include multiple modules, services, APIs, databases, and external dependencies. Integration with other systems.
Evolving requirements. Users understand their needs better once they see working software. Policies shift. Constraints surface. Regulatory or internal policy constraints. Requirements may be known in principle but interpreted differently, clarified late, or updated midstream.
Risks, dependencies, and even core features often emerge during delivery rather than being visible at the start. Long time horizons. Over multi-year efforts, technology changes, people change, and organizational priorities shift.
And although stakeholders often know the information they want and how they expect to use the software, part of our responsibility is to explain these moving parts and set realistic expectations about what can be known when.
This is where rolling wave planning becomes less a technique and more a discipline of honesty.
Bent Flyvbjerg’s work is helpful here because he is not arguing against planning. He is arguing against premature certainty. His core position can be summarized as: plan in layers, commit late, and anchor decisions in evidence rather than optimism. He calls it the planning fallacy.
In plain terms, Flyvbjerg argues that large and complex initiatives fail not because people plan too little, but because they lock in detailed plans too early, before uncertainty has reduced and before real constraints are understood.
Seen this way, rolling wave planning is not an excuse. It is an acknowledgment that in complex software work, credibility comes from knowing when not to pretend.
I understand exactly what you mean. Unfortunately, I've observed many occasions where people mistake the situation and excuse carelessness and sloppy work by citing complexity when it doesn't apply. I won't become tired of fighting this misinterpretation. This is precisely what we need systems thinking for. First, one has to understand the system and draw the conclusions that can be drawn; only then do we deal with the remaining uncertainties in the way you've perfectly described. I won't get tired of making this point, because I've suffered greatly from not being particular about this matter.
Such great thoughts, thank for continuing to share these frameworks!
Thank you! And thanks for reading my articles it means so much.
Super helpful framework, explanation, and sample language to use - thank you!
Appreciate the comment.
I agree with this principle, as I promote the Drum Beat method specifically as an operational approach for this. However, one must be careful not to lose perspective on the scale. If the most important requirements aren't clear at the project's outset, then it's not a project but an adventure. You can certainly tackle an adventure using project management methods, but you must always be aware that what emerges at the end remains uncertain throughout. It might turn out well, but it doesn't have to. Ultimately, it comes down to expectations management: whoever promises a project must deliver on requirements, budget, and timeline and needs therefore to be clear on that. Those who can't or won't do that should only promise an adventure.
I think this is exactly where the discomfort comes from. When work is genuinely complex, planning feels less like executing a map and more like going on an adventure. Not because it is careless, but because the terrain cannot be fully known upfront.
In complex software projects, uncertainty is structural, not a planning failure. Complexity shows up in very specific ways:
Many interacting components. Modern systems include multiple modules, services, APIs, databases, and external dependencies. Integration with other systems.
Evolving requirements. Users understand their needs better once they see working software. Policies shift. Constraints surface. Regulatory or internal policy constraints. Requirements may be known in principle but interpreted differently, clarified late, or updated midstream.
Risks, dependencies, and even core features often emerge during delivery rather than being visible at the start. Long time horizons. Over multi-year efforts, technology changes, people change, and organizational priorities shift.
And although stakeholders often know the information they want and how they expect to use the software, part of our responsibility is to explain these moving parts and set realistic expectations about what can be known when.
This is where rolling wave planning becomes less a technique and more a discipline of honesty.
Bent Flyvbjerg’s work is helpful here because he is not arguing against planning. He is arguing against premature certainty. His core position can be summarized as: plan in layers, commit late, and anchor decisions in evidence rather than optimism. He calls it the planning fallacy.
In plain terms, Flyvbjerg argues that large and complex initiatives fail not because people plan too little, but because they lock in detailed plans too early, before uncertainty has reduced and before real constraints are understood.
Seen this way, rolling wave planning is not an excuse. It is an acknowledgment that in complex software work, credibility comes from knowing when not to pretend.
I understand exactly what you mean. Unfortunately, I've observed many occasions where people mistake the situation and excuse carelessness and sloppy work by citing complexity when it doesn't apply. I won't become tired of fighting this misinterpretation. This is precisely what we need systems thinking for. First, one has to understand the system and draw the conclusions that can be drawn; only then do we deal with the remaining uncertainties in the way you've perfectly described. I won't get tired of making this point, because I've suffered greatly from not being particular about this matter.
I’ve been there. Thank you.
That seems like important work. You’re welcome.