Path Dependency is a concept that many project professionals have never heard of – and yet, for many projects, it is far more important to success than Critical Path.
To understand why, let’s start with some definitions.
What is Critical Path?
“A critical path is determined by identifying the longest stretch of dependent activities and measuring the time required to complete them from start to finish.”
Critical Path determines how long a project will take. It focuses on tasks, durations, and dependencies between activities. Activities that directly determine the completion date are said to be “on the critical path.” Importantly, the Critical Path is dynamic – it can change as tasks are completed early, late, or exactly on time.
For construction projects in particular, managing the Critical Path is an essential part of the modus operandi. If the concrete pour for the slab is late, the columns for the next floor are delayed, and so on. Project managers, therefore, manage task dependencies and durations tightly, making continuous adjustments to avoid cascading delays.
However, the start-to-end task constraints that dominate construction projects are far less important in many other project types.
In most software and organisational transformation projects I have worked on, for example, it is possible to tackle 80–90% of the tasks simultaneously and work on many tasks in almost any sequence. In these environments, Critical Path exists, but it is not the dominant factor determining success.
Yet something else is critically essential.
How Executives Think About “Critical Path”
When you say “Critical Path” to most C-level executives, they define it very differently.
“Essential points on the way to an outcome.”
“Critical decisions we must get right.”
This describes a completely different mental model – not about tasks and durations but rather about decisions and how those decisions shape what becomes possible.
Decisions have consequences, and yet, on many projects, decisions are made that can steer the project in the wrong direction. Often, the only way to correct them is to backtrack to get back on target. Indeed, it is the quality of decision-making by business and technical leadership that distinguishes the most successful projects from the also-rans.
The Missing Concept: Path Dependency
High-performing managers intuitively understand this. They know there is a best sequence in which to tackle work – not because tasks cannot be done in another order, but rather because the right sequence makes delivery easier, progress more visible, and success more attainable.
They think in terms of:
- “Once this bit is working just right, then that bit will be easier.”
- “If we get this foundation right first, the rest will be straightforward.”
So, while tasks could be undertaken in any order, they are sequenced in the best order based on experience and judgement.
For many years, however, there was no widely used term in project management to describe this logic.
In 2012, I came across a blog post by leading economic commentator John Mauldin discussing the concept of Path Dependency. As I read, I had an immediate epiphany. This was the term I had been looking for – so I could explain to executives and project professionals why the right decisions, and doing things in the right sequence, are so critical to project success.
The formal definition of Path Dependency is:
“Path Dependency explains how the set of decisions and options possible at any point and for any given circumstance is limited by the decisions one has made in the past, even though past circumstances may no longer be relevant.” Wikipedia
Why Path Dependency Matters
Path Dependency is tacitly understood by most people, even if they have never heard the term.
Each decision either opens up options or closes them down. Every decision you make determines what you can or cannot do — now, and in the future. Where your project is today is the cumulative result of a series of path-dependent decisions.
The wrong decisions can lock your project into a future where you can never get to where you intend to go.
Implicitly, we all understand this when navigating toward a destination. There is a right – and a wrong – place to start a journey (as captured perfectly in the famous Irish joke). And yet, in projects, this logic is rarely made explicit.
Well-Known Examples of Path Dependency
A classic example of path dependency is the use of biological pest control versus chemical pesticides.
Countries such as the Netherlands deliberately invested early in integrated pest management and biological control methods, particularly in horticulture and greenhouse agriculture. These early decisions enabled a future with reduced chemical dependence and greater adaptability to tightening environmental regulations. By contrast, regions that relied heavily on chemical pesticides became locked into a path where switching later was far more difficult due to resistance, environmental damage, regulatory pressure, and sunk investment in chemical-based systems.
Another well-known example is the QWERTY keyboard. Originally designed in the 19th century to slow typing to reduce mechanical jamming in early typewriters, QWERTY was not optimised for speed or ergonomics. Even though keyboards are no longer mechanical, and so the conditions that drove their adoption are no longer relevant, it has become so embedded in our technology, training, and habits that we still use that layout today.
In both cases, early decisions shaped what was possible long after the original context had disappeared.
What Is Outcomes Path Dependency?
Outcomes Path Dependency is an evolution that shows how Desired Outcomes – the working pieces of the future- ,[1] <Insert Link to other article> once realised partially or fully, enable subsequent outcomes. For example, it explains the logic that:
- Once Outcome A is working, Outcome B becomes achievable.
- But to get Outcome D working well, Outcome C and B must also be in place.
- And if Outcome A, B, or C are not achieved, then Outcome D may be impossible.
This logic is common in transformation initiatives – yet it is rarely articulated clearly.
A common problem I have seen is transformation projects that do not understand the path-dependent relationships and, so instead of simplifying and improving processes first, they automate poor processes – “paving the cow paths” and embedding inefficiencies into new systems. Another example: implementing a new financial software without first cleaning up the Chart of Accounts, locking in old problems for years to come.
Outcomes Path Dependency helps determine the best sequence for delivery – not to minimise elapsed time, but to maximise early gains and momentum. It also allows projects to get started even when there are many unknowns.
Why Path Dependency Is Critical to Agile Success
Agile methods are often described as flexible, adaptive, and non-linear. However, this is frequently misunderstood to mean that sequence does not matter. In practice, the opposite is true.
Agile delivery is highly path dependent. While Agile teams work in short iterations and can change direction based on feedback, the sequence in which outcomes are pursued has a profound impact on speed, learning, and value delivery. Early decisions about architecture, data models, interfaces, and operating processes either enable future sprints — or constrain them.
Without an explicit understanding of path dependency, Agile teams risk:
- delivering features quickly that later need to be undone,
- locking in poor architectural or process decisions,
- accumulating technical and organisational debt,
- and running fast while failing to build sustainable momentum.
In Summary
Outcomes Path Dependency makes visible what experienced leaders already know intuitively: success depends not just on what you do, but on making the right decisions, understanding their long-term consequences, and delivering projects or software drops in a sequence that makes each subsequent step easier rather than harder
[1] https://enterpriseviewpoint.com/why-outcomes-thinking-is-the-missing-link-for-project-success/
