The Problem with Planning:

In the theory of project planning, the iron triangle is often considered, where scope, capacity, and time are the dimensions that can be controlled to manage risk and uncertainty. In software development, quality is added as a fourth dimension.

The challenge with established planning methods is that the estimation of required effort, concerning each of these four dimensions, exhibits non-linear behavior. This non-linear nature leads to unpredictable and significant problems in team performance.

When it comes to capacity, we encounter Brook’s Law: Increasing capacity (e.g., the number of people in the team) increases the total effort the team can put towards delivery. Simultaneously, the effort required for communication and coordination will increase exponentially. Additionally, there is the social loafing phenomenon, where people feel less responsibility for results in a larger team setting. Consequently, small, tightly-knit teams are more effective than large ones.

When it comes to quality, a double feedback loop exists. In software, it is possible to support many functionalities in a short time, but then it becomes harder to develop them further because the robust organization of components is neglected (i.e., technical liability or software rot). Secondly, poorly conceived decomposition distorts the conceptual model of possible solutions, causing the product to drift further and further away from the platonic ideal solution.

When it comes to time, we see, among other things, the student syndrome, an increase in effectiveness as the deadline approaches. However, knowledge work (such as software development) is highly dependent on bursts of inspiration and insight, with long intervals of analysis and reflection. As a result, much uncertainty is hidden behind estimates of duration.

Then, scope remains. Unfortunately, an increase in scope always leads to a more-than-linear increase in the cognitive load of a team. Scope is, after all, about the combination of essential and incidental complexity. The more features a team supports, the more concepts they must know, and thus the more layering in their mental models and the more abstraction they must process.

This means that scope, capacity, quality, and time are difficult to control, and the effects of small adjustments to these dimensions have significant consequences for team performance. Effective organizations and teams therefore operate within a very narrow bandwidth of these aspects.

This constant battle with non-linear factors is why traditional planning techniques, despite all efforts, so often lead to false expectations, and why organizations incorporate extreme margins of uncertainty into their planning.

Iterative approaches help but are not a solution:

It is tempting to think that iterative methodologies, such as Scrum, circumvent these challenges by dividing projects into manageable, incremental steps. The idea is that working in small time units (sprints) reduces unpredictability, but in reality, it does not address the fundamental exponential relationships.

Worse still, by shortening the horizon of our approach, it becomes harder to analyze the trend across multiple iterations: in fixed time units, a fixed team delivers an unclear set of features of unclear quality. But is cadence truly more important than scope and quality?

In my experience, stakeholders, whether domain experts, end-users, or managers, are much better at handling risks in timely delivery than at dealing with uncertainty about the fit of the final solution.

Reverse Planning:

The solution lies in a method of ‘reverse planning,’ where the intentions of a project or product vision are central. We do not start with the current state but with the intended end goal.

This process begins with clearly defining the success criteria at a high-over, non-technical level. Once we have sharp success criteria, we reason backward. What are the changes necessary to meet those criteria? These changes are then broken down into increasingly smaller goals and changes until workable, executable tasks remain. We do not make choices in this process. We only map out all our possible paths to success.

By remaining at the level of more and more granular non-technical objectives for as long as possible, a tree structure emerges that consists of steps that directly contribute to the success criteria, in a language understood by stakeholders. The desired outcome (i.e., the intention) forms the trunk, ensuring an unwavering focus on what we want to achieve rather than what we must deliver.

Creating a plan becomes an analytical exercise in decomposition instead of an intuitive attempt at prediction. This first part is exactly what software engineers excel at!

Such a structured approach gives us a clear path from intention to action, which offers a powerful tool in negotiations with stakeholders. Because every task and every goal can be traced directly back to the final criteria of the desired outcome, it becomes possible to compare choices about scope and quality: what is necessary, where can we get by with a temporary solution, and where are the critical choices that we absolutely must get right?

Visualizing alternative paths to success reduces the risk of scope creep and makes the consequences of every decision transparent. Furthermore, roadblocks are signaled early, and unanswered questions are not ignored: we mark them as explicit dependencies. This exposes the connections regarding decisions, knowledge, or tasks held by other teams or parties.

With this, ‘reverse planning’ transforms the discussion from “When will it be ready?” to “What do we want to accomplish?“. Because the focus is on the value and intention of the work, the team is able to consider trade-offs and make the impact of choices clear to others.

Teams using ‘reverse planning’ can visibly share their path to success with their stakeholders, enabling them to adjust the team’s course in time. This gives stakeholders control over progress and keeps the team focused on the most critical steps.

Easier said than done, of course, but the starting point is awareness: plans succeed or fail not on the timeline but on alignment with the underlying intentions and the early signaling of risk. With ‘reverse planning’, a timeline merely becomes a derivative of the action plan that our problem breakdown provides.

No plan survives contact with reality:

An overview of dependencies on others, potential roadblocks, and how different paths of effort combine to lead to success is just the beginning. Plans must change with advancing insight and shifts in priorities. After all, knowledge work is unpredictable: we discover new options and limitations along the way.

So, ‘reverse planning’ is only a starting point. As our knowledge increases, we revise the paths to success and discuss the impact of the new insight with stakeholders. But how do we ensure that this impact carries minimal risk of failure?

Setbacks or delays stem from unforeseen dependencies. We can prevent these by identifying the most risky open questions and critical steps in the earliest version of a ‘reverse planning’ exercise. By addressing critical decisions with proof-of-concept models, simulations, or data collection, measurement, and analysis at the earliest possible moment, we create clarity as early as we can.

This lowers the risk of unforeseen problems later in the process and ensures that the probability of failure decreases as time or effort (i.e., the cost we have invested) grows. This reduces the likelihood of a sunken cost fallacy.

In Short:

‘Reverse planning’ transforms the discussion about project progress from “When will it be finished?” to “What do we want to achieve?“. By starting with success criteria and desired outcome we make the intentions of our work a central driving force. We then reason backwards analytically, and our plan becomes a structured decomposition based on intention. This ensures a focus on the value to be realized and makes risks visible early. This allows teams and stakeholders to jointly take the critical steps as early as possible and thus limit risks later in the process.

So, start with the intention, then reason backward, and address the issues with the greatest uncertainties first. That’s what ‘reverse planning’ is about.