PM Notebook
Hints on Implementing Critical Path Analysis on Your Projects
Bill Hoberecht - This email address is being protected from spambots. You need JavaScript enabled to view it.

Unfortunately for project managers, a project's schedule is so visible and easy to understand that executives and project stakeholders all feel compelled to offer their opinion that the project is taking too long, propose suggestions for reducing the project duration, and question the team's ability to create a reasonable schedule.  Actually, these 'outsiders' may have valid points.  Rather than be victim to this external scrutiny, take the initiative by completing solid project planning, understanding your project's critical path, and managing to that critical path.  As well, communicate this critical path information to your stakeholders.   


So Many Discussions Relating to the Project Schedule

As a project manager you are no doubt familiar with the concept of critical path and are comfortable with the lexicon of critical path analysis (e.g., task dependencies, critical tasks, slack, float).  Project managers who want to utilize the power of this technique will go far beyond simply having a textbook understanding and will make the effort to apply critical path analysis to their projects.  Mastering the techniques of critical path analysis and effectively communicating this information to project stakeholders are two essential skills for all project managers, particularly those with responsibilities for large or complex undertakings.

I am constantly involved in discussions regarding project schedules.  Rarely does a week pass without one of these situations surfacing about a project for which I have responsibility:

  • Questions about the project schedule: Can the project be completed sooner?  We have a task that is behind schedule, does this slip affect the overall project schedule?
  • Delayed resolution of an issue:  An executive delays in resolving a critical issue or completing a tasks that is on the critical path; they finally resolve the issue (later than needed) and yet still expect the project to finish as originally scheduled.  (A variant of this situation occurs when development completes late yet system testing is still expected to complete on schedule).
  • A miracle performed by the project team:  A series of critical tasks unexpectedly completes significantly late, yet the project team is able to replan the work so that the project still completes on schedule.  (Such a result is a two-edged sword: there is cause for rewarding the team’s ‘can do’ attitude and their result, but at the same time this situation probably leaves management with the feeling that this team’s project schedule was packed with excessive contingency).

Each of these situations comes about because of shortcomings in implementing Critical Path Analysis effectively on a project.  Because a project’s schedule (along with budget) are so visible, it becomes a convenient subject for discussion, questions and scrutiny.  You can best prepare for these interactions by mastering critical path analysis, implementing it on your projects, and effectively communicating with team members and stakeholders about the critical path.


Ignoring the Critical Path on Your Project

A healthy part of a project manager’s day is determining where to direct the limited time of the project team.  A misdirected focus will reduce project efficiency, probably impacting the quality of work and potentially jeopardizing the ability of the project to succeed.  Having a well-defined, analyzed, understood and communicated critical path will always help a project manager in leading a project team.  Without this information, a project exposes itself to these unfavorable situations:

  • Insufficient attention to tasks that are on the critical path.  The owners of these items probably don’t understand that their work directly affects the ability of the project to complete on time – if they complete a day late, then the project probably completes a day late.  Without an understanding that they are responsible for a critical task, these owners may not have an adequate sense of urgency to fulfill their responsibilities; they might even have the perspective that they can complete their work at their leisure without having any impact on the project schedule.
  • No acknowledgement that the project schedule is real, valid and accurate.  This perspective is frequently held in organizations with a low project management maturity.  Those on the project team as well as executive sponsors express little concern if critical tasks early on the project are completed late – the prevailing thought is that any early schedule slips can be recovered by having people work ‘harder’ on subsequent project tasks.  This effectively conveys a lack of any confidence in the work effort estimates and schedules for later tasks, and suggests a huge bias towards believing that those tasks can be completed with less effort and in less time than are indicated in the project plan.
  • Increased work hours to recover from schedule slips.  This is a qualify of work life problem, and occurs when the project team is asked or directed to work increased hours in order to accelerate the completion of project tasks – this acceleration is needed to eliminate the schedule impact from late completions of prior critical tasks.  This extra work is often uncompensated and encroaches upon the personal time of project team members.  This may not be significant if occurring infrequently and for only short durations of time; however,  repeated and prolonged overtime can be accompanied by a host of unfavorable ramifications.  The ethics of expecting team members to put in excessive working hours is questionable and certainly is not a project management ‘best practice.’
  • Distracted by non-critical tasks.  Spending too much time managing tasks that are not on the critical path and keeping them ‘on schedule’ is not a wise use of a project manager’s most limited resource: time.  This extra attentiveness is unwarranted and consumes management effort that would be better applied to other project areas that are more deserving of the attention.
  • Adding skilled people to the project without any resulting reduction in the project timeline.  Your project is running late and you add trained, experienced people to the project.  This additional staff works productively yet you don’t see any reduction in the overall project schedule.  How can this be?  The answer is this:  if the assignments for the additional staff don’t affect the critical path (e.g., by completing critical tasks faster), then there will be no impact on the overall project schedule.  When adding trained staff to a project (with the intention of reducing the project timeline), you need to understand your project’s critical path and focus the team on reducing the time for critical tasks.  (Of course, keep Brooks Law in mind, with its reminder that adding staff to a late project will not resolve that schedule problem).


Mastering Critical Path Analysis and Effectively Communicating the Critical Path

Although use of critical path analysis on your project doesn’t guarantee success, the absence of any critical path information makes it all but impossible to suitably address the myriad of schedule questions and issues that you face on your projects.   Start your journey towards mastering critical path analysis by completing training focused on project planning and project controls, working through several case studies that involve understanding a critical path and using that information when a project goes awry, and following the activities of an accomplished project manager to understand their use of critical path analysis on their projects.

When implementing critical path methods on your own projects:

  1. Define your work breakdown structure so that tasks each have a reasonable effort and duration.  A good rule-of-thumb is that no task should have a duration of more than ten days, with most tasks having a duration of five days or less.  You are striving for a balance: tasks that are too short will add to your planning and tracking effort, tasks that are too long will be more difficult to accurately track;  a plethora of longer tasks in the critical path will reduce your ability to predict project completion and decrease your options when having to recover from schedule slips.
  2. Include all tasks, not just the technical work items.  For some projects, you’ll find that authority to proceed, funding approval, staff acquisition, training, executing a supplier contract or other project management activities are actually on your critical path.
  3. Verify and re-verify that your schedule has the correct dependencies.  Introducing an inter-task dependency where it is not needed can unnecessarily extend a project schedule.  I am constantly discovering that dependencies seem to disappear when a project falls behind schedule and must be replanned in order to meet the original completion date; if a dependency is real, it should survive a replanning effort.  (I do recognize that under replanning conditions, some project assumptions or scope adjustments are introduced and that these changes result in a modification to the task dependencies; in such cases, there are changes to project parameters that result in this change in dependency relationships and possibly the critical path).
  4. Ensure that your schedule has an identified and agreed critical path.  Communicate this critical path and actively seek confirmation that your team and stakeholders agree that this is a real critical path; leverage this agreement in conveying a sense of urgency for completing critical tasks as scheduled.  Construct an easy-to-understand representation of the critical path for use in briefing executives and stakeholders – a simple, straightforward linear diagram of tasks in the critical path can be very effective.
  5. Verify that owners of critical tasks understand that their work is on the project’s critical path.  This includes executives and those in partnering organizations.  You’ll want them to recognize the importance of accomplishing their critical tasks as scheduled.
  6. Remember that your critical path will probably change as the project progresses.  This change could come from alterations to the project definition, schedule variances or other sources internal and external to the project.  Revisit your critical path frequently!
  7. Focus on critical path tasks when determining project status.  If a non-critical task is slipping, this isn’t a problem until the slip puts that task onto the critical path and the schedule is extended.  When you review the status of task progress and completions, your first attention should be on critical tasks in chronological sequence.  Once you’ve devoted sufficient attention to critical tasks then shift your focus to the other tasks (perhaps starting with higher risk or otherwise important tasks to be tracking).  Don’t fall into the trap of simply walking through a chronological listing of all tasks as a means of tracking status – adopt an approach in reviewing the status of project work items that focuses attention on the more important tasks.
  8. Focus on critical path tasks when reporting project status.  Keep your status reporting meaningful by eliminating information that is not relevant to the overall project status.  Projecting a late completion for a critical task is significant and should always be part of your status reporting.  A late completion for a non-critical task is almost always unnecessary noise that can obfuscate your true project status;  unless you have some systemic issues with a large number of non-critical tasks, you should probably avoid regularly reporting on these items.


What’s Next?

Use of Critical Path Analysis should be part of your Project Management Toolkit, and you will benefit from using this on every project that you lead.  Whether you are a novice or an experienced project manager, take an hour to refresh your understanding of Critical Path Analysis.  Your scheduling tool (e.g., MS-Project) will automatically generate critical path information for your analysis – become familiar with this feature and make use of it.  Finally, look over the eight tips immediately above and see how you can implement all of them of your current project.