Using MS Project to Manage the Critical Path

The critical path represents the longest (in duration) network of tasks between defined start and end points. The critical path is what determines the total duration of the project. Therefore project managers often draw the logical conclusion that if they diligently manage the series of activities on the critical path, they will ensure that the project is delivered on-time. In my experience, the critical path is a great place to start in terms of analyzing and understanding the project schedule, however there are several pitfalls associated with becoming too focused on managing the critical path:

1. Secondary Paths – Within most project schedules there are alternative networks of activities that are almost as long as the critical path. All it takes is a few adjustments to the plans (i.e., new tasks, or changes in activity sequencing), or variances within the actual execution of the plans (i.e., delayed start of a task, or extended duration of a task), to cause one of the alternative activity networks to become the critical path.

2. Where is the Work? – The critical path represents the longest series of networked activities, but it does not necessarily represent the one requiring the most effort (work) to complete. Generally the network of activities that requires more resources and effort to complete has more risk associated with it. It is not prudent for the project manager to ignore project components that require significant resources and effort.

3. Critical Path Changes – As discussed in pitfall #1, the critical path will change throughout the planning and execution of the project. Changes to any one of the three key elements of the project schedule (tasks, durations, and sequencing) will have a potential impact on the critical path. As a result, it is important that the project manager has the ability to identify and track the critical path on an on-going basis throughout the project life cycle.

These pitfalls highlight the fact that the critical path represents an important data point to monitor and manage throughout the project life cycle, but not the single data point to manage when performing schedule management related functions.

Using MS Project to Identify the Critical Path

As the project schedule is created and updated, MS Project will calculate the critical path, and flag the tasks on the critical path (using the “Critical” field to flag the tasks on the critical path). MS Project provides multiple ways to view / track the activities that it has calculated to be on the critical path. Below I describe the ways that I find the most valuable to manage the critical path throughout the project life cycle.

Filters – One of the filters available within MS Project views is “Critical” tasks. Selecting this filter limits the tasks displayed within the view to the tasks on the critical path.

Select “Critical” Tasks filter

Display only the tasks on the critical path. The “Yes” / “No” flag identifying critical path tasks is maintained in the field named “Critical”.

Group – The Group feature on the view menu provides the ability to group the critical and non-critical tasks.

Select Group by “Critical” Tasks

Tasks are grouped based on those identified as critical vs. non-critical.

Network View – The network view provides a Pert Chart depicting the activity sequencing, and has the ability to highlight the critical path activities within the overall network diagram. I find this view a bit cumbersome to use for projects that are of significant size and complexity. Note: The engineers I work with seem to prefer this view.

Critical tasks are highlighted in Yellow within the Network View.

Gantt View – There are a couple ways to modify the Gantt View to highlight tasks on the critical path. Because this is the view that I use the most when creating and updating the project schedule, I find this technique to be very useful. Critical tasks can be highlighted within the Gantt view by adjusting either the text styles or the Gantt Chart format.

Select Critical Tasks, and change the text color, style, size or background to highlight the tasks on the critical path.

Critical tasks are highlighted based upon the text options selected.

The Gantt Chart tool provides the ability to highlight critical tasks on the Gantt Chart (timeline).

Critical tasks are highlighted in Red on the Gantt Chart (timeline).

Using Slack to Identify “Hidden” Paths

The slack field is utilized to identify tasks that are “close” to the critical path. Slack represents the float associated with each individual task – the number of days the task can slip without impacting the end of the project. Slack is captured within MS Project for both the Start Date and the Finish Date, but I find it is only necessary to track Finish Slack for purposes of managing “alternative” network paths within the project schedule.

In this example task #46 is 5 days from the critical path, but this task requires significant duration and effort to complete (and is likely rated as a high risk task). In reality, my coaching for this project manager would be to break task #46 into multiple tasks with more manageable work efforts and durations.

4 Tips to Effectively Manage the Critical Path

Based upon my experience, managing the critical path is not an exact science. The project manager must continuously take a “holistic” view when creating and updating the schedule, and not become too focused on managing the tasks on the critical path. However, the critical path does provide valuable insights into the tasks that are driving the current project end date. MS Project provides tools that make it easier to identify and understand the tasks on the critical path. Below are 4 tips that I leverage to more effectively manage the critical path and improve project delivery outcomes.

1. Tracking throughout the Project Life Cycle – As previously mentioned, the critical path can potentially change every time you update future plans or actual results within the project schedule. Therefore processes and tools should be put into place to track and manage the critical path every time the schedule is updated. I will generally create a Gantt view that highlights the critical path tasks (either within the task list, or the Gantt Chart). This approach provides the ability to at a quick glance understand the impact of schedule updates on the critical path.

2. Assessing the Critical Path – After each schedule update, the project manager should analyze and rationalize whether or not the tasks listed as “critical” in the project schedule are indeed the tasks that will likely drive the end date of key milestones and/or the project end date. Key questions during this process include:

  • Are tasks on the critical path tracking on-schedule? Are corrective actions required for critical tasks?
  • Are tasks close to the critical path tracking on-schedule? Are corrective actions required for any non-critical tasks?
  • Are there other there other tasks that are of concern (due to effort or risk)? Are the appropriate risk mitigation plans in place?

3. Actively Mitigate Risk – As risks are identified during the schedule analysis process, ensure that risks are effectively mitigated within the project schedule. This mitigation process may include adding/updating schedule contingencies, updating estimated durations or work efforts, modifying resources, or changing activity sequencing. The risk mitigation process may impact the critical path. I will often implement risk mitigation actions to purposefully place a high risk task on the critical path and provide a higher level of visibility and scrutiny to the task.

4. Managing to Milestones – The focus of critical path analysis should not necessarily be limited network associated with the beginning to the end of the project. In fact in most of my project schedules, the end of the project (e.g., Project Closeout Complete) is not the most important project milestone (e.g., “Go Live” Complete). Therefore it is important to understand and manage the critical path to specific milestones (instead of, or in addition to the project end date). This can be accomplished by creating and linking multiple project schedules, or by performing manual analysis to identify/update the critical path for interim milestones. In my humble opinion, this is an area that could be supported more effectively within MS Project.



What has been your experience with managing the critical path? What techniques / tools have you utilized to understand and manage key tasks and improve project delivery outcomes?


Using MS Project to Manage Dependencies

The strength and integrity of your project schedule is built based upon the definition of deliverables and activities, the estimation of durations and effort, as well as the organization and sequencing of the work efforts. All three elements are important, but the one that I think project managers’ struggle with the most is organizing the deliverables and activities in a manner that reflects the way in which the work will actually be performed / completed. Organizing the work involves developing a work breakdown structure (WBS) that is arranged and decomposed in a structured manner, and sequencing the deliverables and activities based upon logical relationships (dependencies) between the deliverables and activities. This blog focuses on establishing and managing dependencies that are understandable and create a reasonable workflow. This discussion includes using project management tools like MS Project to efficiently define and managing dependencies within your project schedule.

Type of Dependencies

Understanding the types of dependencies inherent in the work that needs to be completed is one of the most important elements of creating a strong project schedule. There are 3 primary types of dependencies:

  • Mandatory Dependencies – These are dependencies that create firm relationships between two activities. Examples of this logic include:

    These two activities must be performed at the same time (starting and/or finishing at the same time).

    This activity cannot start until another activity finishes.

  • Discretionary Dependencies – These are “soft” dependencies that reflect how the team anticipates the work will be completed, or how the team “would like” the work to be completed. These types of dependencies enable the team to optimize the flow of work throughout the project life cycle. Most importantly, “soft” dependencies represent the tool that the project manager utilizes to create “float” in the schedule. This is a much more effective manner to drive the timeline than “hard coding” dates (artificial constraints) into the schedule. Examples of this logic includes:

    This activity will happen at the same time as another group of activities.

    This activity will start up a couple weeks after another activity is completed.

  • External Dependencies – These are dependencies that are outside the control of the project team, but nonetheless must be reflected in the project schedule. Examples of external dependencies include:

    Approval from an external organization must be received prior to starting an activity.

    Completion of a project milestone is linked to the completion of a milestone within another project.

Creating external dependencies within your project schedule can be accomplished in a couple different ways:

Insert a milestone that reflects the completion of the external dependency.

Insert a planning component (placeholder type task) that reflects the timing of the external dependency.

Link specific activities to activities in other project schedules (requires utilization of enterprise scheduling tools).

Dependency Relationships

Dependency relationships are utilized to link two tasks in the most logical manner possible. As in the case of dependency types, this relationship may represent a “hard” relationship (must happen in a certain manner) –or- a “soft” relationship (a relationship set up by the PM to establish a logical flow of the project activities). The valid relationships in MS Project are:

  • Finish-to-Start (FS) – This represents the default relationship in MS Project. If you do not specify the relationship, FS is assumed. This relationship is utilized to establish a sequential flow of work – this activity can start when the previous activity is completed.

  • Start-to-Start (SS) – This relationship is utilized when two activities will be launched at the same time. They may end at different times (depending on the duration of each activity), but they can start at the same time.

  • Finish-to-Finish (FF) – This relationship is utilized when the completion of two activities should be linked together. The two activities may start at different times (again, depending on the duration of each activity), but the completion of the two activities is coordinated.
  • Start-to-Finish (SF) – This relationship is seldom utilized (in 20+ years of using MS Project, I have never used a SF relationship).

In addition to establishing the relationship, predecessors and successors can be utilized to create leads (acceleration or overlap) and lags (delays or gaps) between schedule activities. Here are a couple examples of the appropriate use of lags and leads in the project schedule:

  • Lead: The technical design can be started after 75% of the requirements definition effort is completed. If the requirements represents a dedicated effort that will be completed over a 20 day period. The predecessor in MS Project for the start of the technical design would be reflected as: (n)FS-5D (where (n) represents the task number associated with the requirements definition effort).
  • Lag: The UAT test plans will be completed a week after the completion of the system test plans. The predecessor in MS Project for the UAT test plan would be reflected as: (n)FF+5D (where (n) represents the task number of the completion of the requirements effort).

Using MS Project to Establish Predecessors and Successors

Dependencies are created in MS Project using the Predecessor and Successor fields. The Predecessor is the task completed “prior to” the current task, and the Successor is the task completed “after” the current task. The dependency is entered with the ID of the Predecessor or Successor task, the Type of Dependency Relationship (FS, SS, FF, SF), and the Lag(+)/Lead(-) between the two tasks.

Below is an example of creating Predecessors and Successors within the MS project schedule.

Using the Predecessors & Successors Split view provides a good picture of the dependencies established for each task.


4 Tips for Effective Use of MS Project to Manage Dependencies

  1. Using Date Constraints – The most important take-away from this discussion is that establishing dependencies is the key to creating a logical flow (organization) of work within the project schedule. A “worst” practice is to hard wire dates (e.g., must start on, or must finish on date constraints) within the project schedule. As things change (and they inevitably will change) with regards to how the work is actually completed, these arbitrary date constraints quickly become inaccurate and difficult to maintain. They will impact not only the accuracy of the specific schedule activity, but also the accuracy of any subsequent dependent schedule activities.
  2. Using Summary Tasks for Dependencies – Another thing to avoid is linking dependencies to the summary tasks. During the first cut of creating the schedule, it may seem like a good shortcut if multiple activities are tied to the same set of activities, but ultimately this practice results in a schedule that is difficult to understand and maintain. All activities should be linked to specific activities, and not to summary tasks.
  3. Look for Activities without Predecessors or Successors – Activities should have both a predecessor and a successor, unless they truly represent the beginning or end of a project (or string of standalone activities within the project).
  4. Fully Leverage Dependency Relationship Capabilities – Dependency relationships (and leads/lags) are an aspect of creating a project schedule that should be well understood by the PM, and fully utilized. A project schedule that contains all FS relationships, and no leads/lags, is generally an indication that not a lot of effort has been put into understanding the activity dependencies, or the flow of the project work.

PM Foundations – Creating a Strong Project Schedule

While teaching Time Management at the PMP Certification Class for the past two years, I often receive feedback about my passion on the topic of Time Management. This passion stems from my belief that without a good schedule that directly supports the project objectives (scope, time, and cost), the project manager will struggle to effectively deliver on customer expectations.

What does a good project schedule look like? Below are a few questions that help you test your schedule.

  • Are the deliverables and activities broken down to a level that can be estimated and tracked?
  • Has accountability / responsibility been established for deliverables and activities?
  • Can you easily follow the flow of the project work?
  • Do the milestones appear to be reasonable and achievable?
  • Does the resource usage link appropriately to the project budget?

Although these steps are not completed in an entirely sequential manner, I do believe that a project schedule is created most effectively and efficiently based upon a very specific approach and sequence of processes:

1. Activity Definition – Starting with the Work Breakdown Structure (WBS) that defines and organizes the project deliverables into a logic manner, activity definition adds the detail work to be performed to create the deliverables. This process adds 1-3 levels of detail to the WBS, and provides the basis for estimating, identifying resource requirements, and tracking progress.

2.  Activity Sequencing – Activity sequencing establishes the relationship between deliverables and activities. This process defines both “hard” and “soft” logic in the schedule, that establishes the flow of the work to be completed throughout the project life cycle.

3.  Duration Estimating – Duration Estimating establishes the number of work periods required to complete schedule activities (reflected in work days). This process is utilized to create the first cut of the project timeline. At this point in the process the project manager is assessing the schedule for reasonableness, not perfection.

4. Resource Loading & Leveling – Resource requirements for specific activities are loaded based upon a percent allocation for resources, or “bottoms-up” estimates of work effort. Resource leveling is utilized to resolve resource usage conflicts and over allocation of specific resources.

5. Schedule Analysis – Schedule analysis is utilized to finalize the project schedule and create the baseline project schedule. The goal of this process is to ensure that the team can deliver on customer expectations with the schedule that has been created, and that the project schedule is fully documented and well understood by key stakeholders.

Leveraging best practices, the project manager ensures that a project schedule is efficiently created and is proactively utilized to successfully deliver on the project objectives:

  • Ensure that the appropriate schedule related defaults have been set-up within the scheduling tool. These defaults define work hours, holidays, and other key behaviors within the scheduling tool. A good example of set-up data that drives behaviors in the project schedule is the task type field (I recommend using fixed duration as the default task type)..


  • Schedule related risks should be appropriately mitigated within the project schedule in the form of schedule reserves or contingencies. I find it most effective to explicitly document the schedule reserves in the project schedule.


  • Leverage dependencies in the project schedule to create a logical “flow” of the project deliverables and activities. Conversely, avoid arbitrary constraints (e.g., “must start on” or “must finish no earlier than”). As things change (and they inevitably will change) with regards to how the work is actually completed, these arbitrary date constraints quickly become inaccurate.


  • Before the first cut of the timeline is complete, milestones should be inserted into the appropriate points in the schedule. How do the milestones in the timeline compare to target dates that were established up-front (potentially committed dates from the project sponsors)? Are there actions that can be taken to close gaps between milestones and target dates?
  • There are several techniques that represent best practices during the final schedule review. Each of these techniques will help uncover opportunities to improve the schedule or reduce the risk, but can drive undesirable results if used improperly (see the chart below).