The critical path method is a way to organize projects and sort out your priorities. I’ve found critical paths to be a very useful tool for project planning, which can scale to support all organizational levels: individuals, pods, teams, and the org writ large. They’re useful when working on one-off projects, and can improve recurring processes and optimize concurrent software.

Project graphs are a visual representation of the work required for your project. Each node on the graph is a discrete task. Arrows indicate dependencies, where a task is dependent on work from another task. Numbers display time, rather than cost, and assume no resource bottlenecks.

Critical paths provide project managers and teams with important insights, and an ability to evaluate a project as a process. After talking through these insights and why teams might adopt this method, I’ll explain how to build a project graph and identify your own critical path in eight steps. I’ll also provide two ways to mutate your graph to adjust as needs change.

Why the Critical Path?

The critical path method does more than document progress. Critical paths reveal reliable and actionable insights that empower project managers, specifically in four areas.

Minimum Time to Completion

When can you expect your project to be done? By mapping the discrete tasks and the effort they’ll require, you can easily find the longest path on your project roadmap. The critical path provides a meaningful basis for explaining this timeline, and allows you to look for risk areas and opportunities to shorten the timeline.

Critical Lines of Work

Critical lines of work are those areas where an individual delay would cause a delay for the whole project. These choke points become apparent by tracking dependencies.

When a parent task must be completed in its entirety before a child task is started, the child task is said to have a dependency on the parent task. Graphs can display this information in different formats: - Earliest start - Latest start - Latest finish - Discrete start/stop nodes

Prioritization

The beginning of a project starts with a critical chain of big tasks. By front-loading the big, heavy tasks, you can reduce uncertainty over the course of the project.

Resource Allocation and Scheduling

The critical path can be invaluable for scheduling heterogeneous teams. By thinking of the project as a process, the critical path shows which roles will be needed over time. This enables intelligent scheduling that overlaps across different projects.

8 Steps to Build the Project Graph

Creating a project graph and identifying the critical paths within can seem daunting at first. But the eight steps below become quite intuitive after completing a couple examples.

1. Establish Level of Granularity

The critical path method can work for groups and projects of all sizes, but the way you define different elements will depend on your group size: - Individual - Pod - Team - Organizational/Company

2. Establish a Time Scale

The time scale should correspond to the size of the graph’s level of granularity and discrete tasks. On average, are these things that can be completed in an hour, a day, or a week?

3. Identify Tasks

List out all of the tasks or user stories that need to be completed. The size and scope of these tasks should align with the level of granularity and time scale. When encountering unknown elements of a project, adding a larger, less granular task may be necessary. This task can later be broken down into smaller tasks as they become apparent.

4. Identify Task Dependencies

For each task, identify tasks that must be completed before its work can begin. Draw dependencies between these tasks as directed edges, with arrows pointing from the parent (earlier) task to the child (later) task. Reorganize the task list along these relationships.

5. Refine Tasks and Dependencies

This dependencies diagram might already help frame your project in a different way, and you can adjust tasks at this point to create a smooth process from start to finish. Because projects ultimately need to finish, there cannot be any circular dependencies, and the project graph must be a directed acyclic graph (DAG). There are a few ways to address dependency chains when they do arise: - Break up tasks into smaller subtasks, pulling out the work that can be done ahead of time without waiting on dependencies. - Merge tasks together. - Pick the priority task between mutually exclusive tasks.

6. Estimate Tasks

Each task should be given a time estimate. Note that tasks should be estimated by time, not cost. For example, when estimating the task of pouring a concrete driveway, you should include the time for the concrete to dry even though the curing process requires little work.

When encountering uncertainty, err on the side of caution and give a higher estimate.

7. Compute Longest Paths

Begin computing the longest paths by recording an “earliest finish time” for each task, starting with the tasks that have no dependencies.

Repeat this step in the next row, adding the next task’s estimate to the previous task’s earliest finish time, until the graph is complete with the earliest finish time of all nodes.

8. Identify the Critical Paths

Identifying the critical path is simple enough to be described in two steps: (1) Highlight the tasks with the latest “earliest finish” time, and then (2) highlight that task’s children with the latest “earliest finish” time. Repeat step 2 until a starting task (with no dependencies) has been highlighted. The critical paths are the paths between the highlighted tasks.

Mutating the Project Graph

As projects evolve, requirements become more fleshed out, timelines become clear, and plans change the project graph. The next section describes two common scenarios that result in changes to the project graph and how insights that can be derived from those changes.

Splitting

Project managers will always get asked how they can speed up a project, and the critical path provides a meaningful basis for explaining where, if anywhere, that’s possible.

Splitting tasks introduces additional labor and overhead. If a software change was going to need one cycle of Q&A and review, it will now need twice those efforts on the split tasks.

The critical path allows us to see whether the extra effort will pay off. If tasks are split up that are not on the critical path, the project duration stays the same. It’s only when tasks are split up on the critical path that project velocity can be influenced.

Adding Scope

It’s also common for stakeholders to want to add scope to a project as it comes to life. The critical path identifies when and where scope can be added, and how those additions affect the project duration.

If there’s slack in the plan and the team and materials are available, capacity can be added that won’t impact the project timeline. However, if the work gets added to the critical path, it will delay the overall timeline.

The project graph also provides a good explanation for why throwing more developers at a project won’t actually help. If those developers aren't working on the critical path, they aren't influencing the overall velocity.

Conclusion

Project Graphs can be helpful and illuminating tools for teams of all sizes, and they can help coordinate diverse needs, unblock workflows, and unlock your team’s potential. They are fairly easy to create, and they can be manipulated and used to provide complex visualizations into your team’s processes.

If you’re interested in learning more, I recommend reading about calculating slack and the PERT estimation method.