Most non-technical people don’t know what the critical path is; whereas, those that work on IT projects know what it means at a high level, but have few insights into the actual mechanics of it—and how quickly it can change the outcome of their projects! The truth is that there are many misconceptions about the critical path. Let’s cover some of the major ones:

Misconception: The critical path is the shortest path through the network diagram.

Fact: The critical path is the longest path through the network diagram, meaning the sequence of activities that collectivity define the starting and ending dates for the project and have no slack or float time (excess time). Conversely, non-critical paths have slack time which is the amount of time a task can slip. This provides you wiggle room without delaying the tasks that follow it and doesn’t alter the completion date.

Misconception: Every task on the critical path is critical.

Fact: The word “critical” in this context usually has nothing to do how important these tasks are to the overall plan, but instead refers to how their scheduling will affect the project’s finish date. Also, people have to remember after a task on the critical path is completed, it’s no longer “critical” because it cannot affect the plan’s finish date.

Misconception: The critical path will never change.

Fact: Every project has at least some changes (for example, scope, time, and/or money) which means the critical path(s) will change. This will result in a new expected completion date for the project. Other reasons why the critical path will change periodically is because some of the tasks will be completed ahead or behind schedule, and/or task relationships can change.

Misconception: If you shorten the length of a task on the critical path, then the project will be completed sooner.

Fact: It depends! If you do this, more than likely the “shortened” task on the critical path could be replaced with a longer, non-critical task that now becomes a critical task. This means you have a new critical path(s) and a new completion date. It’s important to remember that reducing the critical path on most projects to shorten a project’s duration is not a trivial exercise, can be downright strenuous, and can lead to other problems. For example, you could be increasing your project risks leading to a rework situation. Of course, there are ways and techniques that can possibly shorten the length of a project to meet a certain deadline if done correctly. For example, the scope of the project could be reduced and/or have more people assigned to work on critical tasks helping to compress the schedule.

In my next article, I cover some of the mechanics of finding the critical path in a project, so that you have a better understanding how it evolves. We’ll also look at manipulation of the network sequence diagram.