Loading...
Quick Links

Four Misconceptions about the Critical Path

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.

Share This Post
9 Comments
  1. Great tips–especially for program executives who think they know the game 🙂

    Reply
  2. Very good ariticle Ronald – Respect!!

    Reply
  3. “This provides you wiggle room without delaying the tasks that follow it and doesn’t alter the completion date.”

    This is not true – Only tasks with Free Float will not delay tasks that follow.

    I think you should also distinguish between Critical Path tasks and tasks that are “critical” as in important.

    Reply
  4. Good highlights. I’m fairly new to MS Project although I’ve been leading projects and teams most of my 18yr career(s). The critical path is something that my boss and I have been taking a close look at lately. I like to see it so that I can take a look to see if there’s something I can change in the schedule that could more accurately reflect real life options and decrease schedule duration. One technique I’ve leaned on heavily and would like to get some feedback on is the use of finish-to-finish task relationships vs. finish-to-start. We are an engineering company so there are countless iterations of design and then generate a drawing. In the past, we’ve planned/scheduled for the drawing to start once the engineering is done but what I’ve found is that, most times, a drawing (typically 40 hrs of work) can be started before the design is finalized and tweaked along the way to *almost* coincide with design completion. If we have the resources available, this is my preferred method since the drawing is often times generated by someone different than the original designer anyway.

    I’m open to thoughts about and critiques of this train of thought and would appreciate any and all feedback!

    Reply
  5. @Rob Pettigrew – Finish-to-finish should work fine in that situation. To model the “almost coincide” timing, you may want to add a lead time: FF-3d, or FF-10% (note, the lead time will take drawing off the CP, as their is some flexibility there).

    I hope I am making myself clear.

    Reply
  6. “The critical path is the longest path through the network diagram.” Whilst this statement is true, it is also true to say “The critical path describes the shortest overall project duration”. Without changing some aspect of the critical path you simply cannot do the project any quicker than the sum of the tasks on the critical path. Project managers should always focus on completing the tasks on the critical path on the day they are due, otherwise the project is slowed down. Other tasks with slack can be allowed to slide a little bit to free up resources to work on critical path tasks – just don’t allow them to slide so much that they become the new critical path.

    Reply
  7. Good read
    Critical Path is … it depends

    Reply
  8. Thank you so much for sharing such valuable topic on critical path.

    Reply
  9. “The critical path is the longest path through the network diagram.” Whilst this statement is true, but the sequence of activities that collectivity define the starting and ending dates for the project and have no slack or float time it is true only in one particular case: when the project is completed in the minimum of time (it does not have a total reserve of time).
    If the project has a certain total time reserve then ALL the activities on the critical path have a slack equal to the smallest value of the set consisting of all the values of the slack within the network. This value (slack) can be found as the difference between the Latest Finish Time and the Earliest Start Time of the last activity in the logical network. Otherwise, must be analyzed the set consisting of all the slack values of the network activities – the smallest value defines the critical activities.

    Reply

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Please complete this equation so we know you’re not a robot. *

Thanks for submitting your comment!
You must be logged in to comment.