What Is the Critical Path Method in Project Management?

The Critical Path Method, or CPM, is a technique used to analyze the sequence of activities in a project and identify which ones determine its duration. To do this, we need to understand the activities, their durations, and, most importantly, the logical relationships between them.

PMI explains this construction clearly in its scheduling materials. In Moving from the WBS to a Critical Path Schedule , for example, it describes a logical progression from project deliverables to activity identification, dependencies, duration estimates, and ultimately the critical path.

This means a project schedule should not simply be a list like this:

• Activity A — May 1 to May 5;
• Activity B — May 6 to May 10;
• Activity C — May 11 to May 15.

Dates are important, but they tell only part of the story. I also need to understand why B comes after A, whether B actually depends on A, and what happens to C if B does not finish when expected.

In another PMI resource, Critical Path Method Calculations , the organization goes deeper into CPM and explains how activity relationships, durations, start and finish dates, and float values can be used to calculate the critical path.

This leads to one of the first important conclusions: a late task does not automatically mean that the project is late. In the same way, a task being on schedule does not automatically mean that the project is healthy. Everything depends on where that activity sits within the project network and on the impact a variation in that task can have on the activities that follow it.

Before the Critical Path, We Need to Understand Project Dependencies

To identify the critical path in project management with any reasonable level of confidence, we first need to understand the dependencies between activities. A dependency exists when the start or completion of one activity is related to the start or completion of another.

It is a simple concept, but an extremely important one. Imagine, for example, that one team needs to complete an API before another team can begin an integration. Until that API is available, the second activity may simply have no conditions to move forward.

The Atlassian guide to project dependencies discusses exactly this relationship between tasks and how dependencies can affect work sequencing, resources, and project schedules. Asana also provides a comprehensive guide to project dependencies , including logical, resource-based, preferential, and external dependencies.

Although classifications can vary depending on the context, there is a classic technical structure for representing precedence relationships between activities. It contains four main dependency types: Finish-to-Start, Finish-to-Finish, Start-to-Start, and Start-to-Finish.

The Four Types of Task Dependencies

The most common relationship is Finish-to-Start. One activity must finish before the next one can begin. A simple example is development that needs to be completed before a particular test can start.

In a Finish-to-Finish relationship, the completion of one activity is related to the completion of another. In a Start-to-Start relationship, the beginning of one activity depends on the beginning of another. The fourth possibility, Start-to-Finish, is less common and occurs when one activity cannot finish until another activity has started.

Asana's own documentation on task dependencies uses these relationships to explain how tasks can block or depend on one another.

For me, however, understanding the principle behind these relationships is more important than memorizing the four names: one activity can change when another activity is able to start or finish. When several of these relationships are chained together, an apparently small problem can propagate through a significant part of the project.

How to Find the Critical Path in a Project

I don't want to turn this article into a class on how to calculate the critical path, because that is not the main objective here. But we do need to understand, at least conceptually, how we identify it.

First, we need to know the activities required to produce the project's deliverables. Then we identify the dependencies between those activities and estimate their durations. With this information, we can build a logical network, identify the different paths from the beginning to the end of the project, and calculate how long each sequence requires.

In a very simplified example, imagine that we have three possible paths:

• A → B → C → delivery = 20 days;
• D → E → delivery = 12 days;
• F → G → H → delivery = 16 days.

If nothing else interferes with the plan, the A → B → C sequence deserves particular attention because it is determining the duration of the delivery. PMI explains that activities on the critical path have little or no flexibility to experience delays without affecting the project's completion date. In Moving from the WBS to a Critical Path Schedule , this relationship between dependencies, duration, float, and the critical path is discussed in a very practical way.

This does not mean that we can simply ignore every other activity. A task that has float today can begin consuming it and eventually become critical. Real projects also involve shared resources, suppliers, scope changes, technical decisions, approvals, different teams, and dozens of other variables capable of changing what we originally planned.

This is exactly why I don't like looking at a project schedule as a photograph. A schedule is a model that needs to be continuously monitored during execution because the reality of the project keeps changing.

A Project Dependency Is Not Necessarily a Risk

There is an important distinction here: a dependency and a risk are not the same thing.

Imagine again that one team needs to complete an API before another team can begin an integration. The dependency exists. But if the API is progressing normally, has a reliable estimate, the team has enough capacity, and there is still sufficient slack before the integration needs to begin, that dependency may not represent a significant threat at that moment.

Now imagine a different situation. The API should be almost complete, but its estimate has already changed twice. Some subtasks still have no estimates, the person responsible is simultaneously involved in several other deliveries, the sprint is delivering below plan, and the integration that depends on the API has almost no slack.

The dependency is exactly the same. The risk associated with it has changed completely.

This is where the discussion about dependencies begins to connect with project risk management. A PMI resource that I find particularly interesting is Project Interdependency Management . The paper presents a practice for identifying, validating, analyzing, monitoring, and reporting external interdependencies between projects and treats them within the broader universe of project risks.

What I find particularly important in this approach is that a dependency is not simply identified at the beginning of the project and then forgotten. It needs to continue being monitored because whatever we depend on is also changing over time.

The Problem Is Not Just the Dependency. It Is the Chain Reaction.

One of the most dangerous things in project management may be analyzing activities individually. Imagine that A allows B to start. B allows C and D to start. C needs to finish before E can begin, while D needs to finish before F can begin. In the end, both E and F are required for an important customer delivery.

If A becomes delayed, the information “A is two days late” is not enough for me to understand the actual problem. I want to know how far those two days can propagate. I want to understand how much slack exists downstream, which activities will be affected, which teams depend on that delivery, and whether the delay has the potential to reach the project's final date.

This is one of the reasons I consider it dangerous to evaluate project health simply by counting how many tasks are late. Ten delayed tasks may have very little impact on a delivery. A single delayed critical activity may compromise the entire project.

PMI also discusses this problem in Scheduling High-Tech Projects , where it addresses an important limitation of treating the critical path purely deterministically: when estimates contain uncertainty, different paths can become critical. In other words, what appears to be the project's main sequence today should not be analyzed without also considering the risks within its activities.

Project Risks Should Be Detected Before the Delay

This is where, for me, the discussion becomes even more interesting. PMI published a resource called Risk-Based Scheduling and Analysis , which proposes analyzing risk at the individual activity level, adjusting the schedule to account for those uncertainties, and then evaluating how risk can even change the critical path itself.

The principle remains extremely relevant: we should not wait for a delay to happen before we start looking at the risk associated with that activity.

Yet many times we do exactly the opposite. First a task becomes late. Then someone realizes that another activity could not start. A schedule deviation appears, the project changes from green to yellow, someone registers a risk, and only then do we start discussing mitigation.

There is an obvious problem with this sequence: when an activity that depended on the previous one has already been unable to start, we may no longer be dealing only with a risk. The problem has already started happening.

How Can We Identify a Possible Project Delay Before It Happens?

This is where I believe we need to move beyond a purely static view of the schedule and start observing the project's actual behavior. If a critical activity is supposed to finish two weeks from now, I don't want to wait two weeks to discover whether we have a problem. I want to look for signals during execution.

I can start by checking whether the activity has remained idle for too long, whether the effort already consumed is close to or above the estimate, whether the estimate changed during execution, or whether important activities still have no estimates at all. I can also look at whether Work in Progress has increased too much, whether there are blockers, whether too much work is concentrated on a single person, or whether the team's delivery velocity is deteriorating.

In Agile teams, there are other useful signals as well. Actual sprint delivery may be moving further away from what was planned. Similar activities may consistently take longer than estimated. Bugs and regressions may increase, creating rework. Certain types of work may begin consuming much more effort than they did historically.

None of these indicators, by itself, proves that the activity will be delayed. But several signals appearing at the same time can begin to tell a story.

It is the same principle I use when discussing productivity. As I explained in Productivity Metrics for Software Teams: KPIs to Measure and Improve Developer Performance , a single KPI is rarely enough to explain how a team is performing. We need to analyze context and the combination of different signals.

Some Task Dependencies Should Be Identified Before Work Even Starts

There is another problem as well: many dependencies are discovered too late because the activity has already started before anyone checked whether it was actually ready to be executed.

Imagine discovering during development that we need an API that does not exist yet, an approval nobody requested, a customer definition that was never obtained, or another team that did not even know we depended on them. Technically, we discovered a dependency. In practice, however, we discovered it too late.

This is why, when I work with a Definition of Ready, one of the questions I consider important is whether the activity's main dependencies have already been identified. I discuss this in more detail in Definition of Ready vs Definition of Done: Differences, Examples, and How to Use Them .

The earlier we know about an important dependency, the more options we have. We can change the execution sequence, talk to another team, request an approval earlier, prepare a technical alternative, or even decide that the activity should not enter the sprint yet.

Dependency Mapping Helps Reveal What Usually Remains Hidden

One useful practice for making these relationships more visible is dependency mapping. Atlassian provides a specific Dependency Mapping exercise designed to identify factors that could prevent an initiative from succeeding, understand how one team's work affects other parts of the organization, and create actions before those problems become harder to manage.

This matters because a dependency does not exist only between two tickets. We may depend on another team, a specific person, an approval, a supplier, an API, infrastructure, an architecture decision, a customer definition, another project, or even an executive decision.

Asana, in its guide to project dependencies , also highlights resource and external dependencies in addition to purely logical ones. This matters because not every project risk becomes visible simply by drawing an arrow between two tasks on a board.

Mapping these relationships greatly improves project visibility, but it still leaves another question unanswered: how do we know which of these dependencies are starting to become dangerous?

A Project Dependency Can Be Treated as a Risk Before It Becomes a Problem

This approach also appears outside PMI. In How to Manage Dependencies and Assess Risks , Tempo proposes looking at dependencies as potential risks so teams can work on them before they become concrete project issues.

I like this logic because it changes our posture. Instead of simply recording “Team B depends on Team A's delivery”, we start asking what the current situation of Team A is, when that capability needs to be available, what signals indicate a possible problem, and what impact our delivery will face if the dependency does not happen as expected.

It is a small change in how we ask the question, but a significant change in management capability. A dependency stops being just a line connecting two activities and becomes something whose health needs to be continuously monitored.

The Board Knows the Tasks. But Who Is Looking at the Project?

Jira, Azure DevOps, Asana, Monday.com, and ClickUp play an extremely important role. These are the platforms where teams register activities, owners, estimates, sprints, statuses, dates, dependencies, and much of the information related to work execution.

The challenge appears as the project grows. We may have hundreds or thousands of activities distributed across multiple teams, projects, and types of work. In that environment, finding a task that is already late is not necessarily difficult. The difficult question is:

“What is happening today that could make my delivery late three weeks from now?”

To answer that question, I don't want to look only at a task's final date. I want to understand how that activity is progressing, how similar activities behaved in the past, whether the team is delivering what it planned, whether estimates are becoming unreliable, whether work is concentrated on too few people, whether rework is increasing, and whether meaningful deviations in effort, productivity, or cost are starting to appear.

In other words, the board remains essential for organizing work. But there is a difference between tracking tasks and interpreting what task data is telling us about project health.

This Is Where Saint Jude Project Intelligence Comes In

This is exactly one of the reasons we created the risk module in Saint Jude Project Intelligence .

Saint Jude was not created to replace Jira, Azure DevOps, Asana, Monday.com, or ClickUp. These platforms remain the places where teams organize and execute their work. Saint Jude operates at a different layer: it uses project data to help project managers, PMOs, and leaders interpret what is happening and identify signals that may require attention.

In the risk module, managers can structure and monitor project risks and maintain a history of how those risks evolve over time. But there is another part that I find even more interesting: Saint Jude's artificial intelligence can analyze actual project progress to generate risks and suggest action plans based on the information it finds.

This means that signals such as a sprint delivering below plan, activities without estimates, poorly written tasks, significant differences between effort and delivery, or other patterns identified during execution can stop being information scattered across dozens or hundreds of tickets and become part of a project risk analysis.

Managers still have the autonomy to create their own risks and action plans because not every risk exists inside a board. Political decisions, strategic changes, customer information, commercial negotiations, and external factors may never be visible through a project management integration alone.

The objective is not to take decisions away from the project manager. It is to give the manager more information and, most importantly, more time to decide.

The Difference Between Identifying a Risk and Explaining a Delay

For me, there is a huge difference between saying “your project was delayed because Activity X finished eight days later than expected” and saying “Activity X is showing signs that it may compromise the next delivery.”

The first statement is useful. It explains the past and can help us prevent the same problem from happening again. This is exactly the type of analysis I discuss in How to Find the Root Cause of Your Project's Problems .

But the second statement has a different characteristic: there is still time to make a decision before the consequence happens. I may be able to change a priority, reallocate someone, split the scope, talk to another team, renegotiate a dependency, or inform a stakeholder before the issue becomes a surprise.

Project Intelligence Does Not Eliminate Risk. It Gives You More Time to React.

I don't believe there is a platform, methodology, or project manager capable of eliminating every project risk. Projects involve uncertainty. People change, estimates can be wrong, suppliers can be late, priorities shift, customers change their minds, and technology can fail. Project dependencies will continue to exist regardless of which tool we use.

The difference lies in when we discover that something is beginning to move in the wrong direction.

If I discover a problem when the delivery was supposed to happen, I have very few options. If I identify it a few weeks earlier, I may be able to change a priority, reallocate professionals, reduce or split the scope, renegotiate a dependency, change the sequence of work, involve another team, or create a mitigation plan.

In the end, project risk management is also about managing the amount of time available to make decisions.

And perhaps this is one of the biggest differences between tracking a schedule and truly understanding a project. The critical path method helps us identify which sequences of activities determine our deliveries. Project dependencies show us how those activities are connected. Risk management helps us understand what could prevent what we planned from actually happening.

Project Intelligence adds a fourth layer to this equation: using the data the project already produces to look for signals that something is beginning to deviate from what we expected.

Because the objective should not only be to discover why a delivery was late. That is still important, but at that point we are already analyzing the past.

The objective should be to identify, while there is still time to do something about it, what could make that delivery late.

And very often, the answer starts with an apparently small task that another activity is waiting for before it can begin.

What about your project? Do you know which activities can actually compromise the final delivery date, or do you only discover them once they are already late?

See you soon!

Erik Scaranello