Project Scheduling

Push: The Critical Path Method (CPM)

CPM is especially useful for large, complex projects where schedule interrelationships may not be readily apparent. It is "ideally suited to projects consisting of numerous activities that interact in a complex manner". First used in industry in the late 1950's, CPM has its roots in earlier undertakings, most notably on the Manhattan Project.

CPM focuses on identifying the critical path and then closely monitoring the activities on the critical path through the entire project. For example, when developing a new machine, the electronic circuit design may be the critical path defining the time to launch. Designing the mechanical structure might also be important, but it may not dictate the overall time to completion and therefore the critical path.

Creating a CPM model of a project involves these six steps:

  1. Identify the project milestones or deliverables.
  2. Create a list of all the activities in the project, as described in a work breakdown structure.
  3. Identify the duration for each activity.
  4. Construct a network diagram that identifies the dependencies between activities.
  5. Calculate early-start, late-start, early-finish, and late-finish dates for each activity.
  6. Identify the sequence of tasks through the project with tasks of zero float (slack). This is the critical path.

Using CPM, you can identify:

  • The minimum total time required to complete the project – that is, the critical path.
  • Flexibility, or slack, in the schedule along other, non-critical paths.

A key value of CPM analysis is the understanding it can reveal to the project team about the chain of activities that are likely to establish the earliest completion of the project. This understanding can help the team explore ways to reduce project duration and can help the team focus on efficient execution of time-critical activities.

If you are considering pursuing certification as a Project Management Professional (PMP), you'll definitely want to gain experience in CPM. As a technical project manager, you need to become conversant in CPM, even if you lack the technical expertise to create a full-blown CPM analysis in one of the many software products available for the job. Here are some helpful resources on the topic:

  • A helpful introduction to CPM: "The Ultimate Guide to the Critical Path Method".
  • Comments from veteran project managers on the importance of CPM: page 174 in Project Management: The Managerial Process by Erik W. Larson and Clifford F. Gray.
  • A 13-minute video introduction to CPM: "Project Scheduling: Ed March".
  • A blog post that describes where determining the critical path falls in the overall schedule process: "Efficient Project Scheduling Techniques To Keep Things Running Smoothly".

Avoiding CPM Pitfalls

As you explore the tools available for implementing CPM, keep in mind that CPM is the ultimate geometric order tool for project management. It can lure you into a false sense of security regarding the predictableness of a project, causing you to presume, for instance, that it is always possible to identify all project activities and their durations ahead of time, or that the dependencies between them is always clear. But in the constantly changing living order, you need to be prepared for change at all times. In some large projects, there actually may be more than one critical path, or the critical path may shift during project execution. This means you need to keep your eye on near critical activities and paths, so you can spring into action if they suddenly become more critical than your original analysis had foreseen.

CPM provides a helpful model for testing the feasibility of a project's overall schedule, and is therefore useful in the initial strategizing phase. However, it can become more of a burden than a help during execution if the project team feels compelled to follow the dictates of the CPM model too rigidly. It has limited value in guiding daily schedule decisions and on-the-job coordination. Project managers who spend too much time looking at their CPM models will miss the realities of day-to-day execution. This can enable reactive rather than proactive project management – that is, managing by looking out the rearview mirror instead of out of the windshield.

A successful project manager uses CPM as a means of keeping the project on track and assigning the most reliable personnel to critical activities, all the while keeping in mind that CPM does not deliver absolute truths. In the words of Dr. George Box, the founder of the Department of Statistics at the University of Wisconsin-Madison, "Essentially, all models are wrong, but some are useful". This is absolutely true of CPM. You need to evaluate your CPM project models regularly to ensure that they are in alignment with the stakeholders' definition of project success.

In the fast-changing projects that are becoming increasingly common in living order environments, you might have to start with a schedule for project milestones, with only a hypothesis of the overall critical path. Then, throughout the project, you might need to continually revise your concept of the critical path. For instance, when planning a large conference, your critical path may change if registrations significantly lag (or exceed) expectations, requiring you to adjust marketing efforts, logistics, and even the content of the conference. In software development, the critical path may change due to actions by competitors, changes in technology, risk mitigation efforts, scope changes and integration issues, just to name a few.

Schedule Compression

CPM can be very helpful when you need to compress a schedule – that is, when you need to take a schedule you have already developed and reduce it without adjusting the project's scope. You can only compress a schedule by adjusting the schedule of activities on the critical path. Keep in mind that compressing a schedule adds cost and risk – often a lot of both. And compressing a schedule is often only achieved at the expense of the people doing the work – increasing their stress levels and overall frustration with their job.

There are two key ways to compress a schedule:

  • fast tracking – A schedule compression technique in which "activities that would have been performed sequentially using the original schedule are performed in parallel. In other words, fast tracking a project means the activities are worked on simultaneously instead of waiting for each piece to be completed separately. But fast tracking can only be applied if the activities in question can actually be overlapped"For example, when building a new house, you might be able to overlap pouring the concrete for an exterior patio and shingling the roof, but you can't overlap digging the foundation for the house and shingling a roof that has not yet been built.
  • crashing – This technique involves adding resources such as overtime or more equipment to speed up the schedule. Because of the costs involved in adding resources, crashing is "the technique to use when fast tracking has not saved enough time on the project schedule. With this technique, resources are added to the project for the least cost possible. Cost and schedule tradeoffs are analyzed to determine how to obtain the greatest amount of compression for the least incremental cost". Note that crashing is not typically effective with IT projects.

The important thing to remember when attempting to compress a schedule it that you need to focus on compressing the critical path. It doesn't do any good to speed up tasks that aren't on the critical path. According to an early, but still useful article about CPM, you can think of the critical path as the "bottleneck route:"

Only by finding ways to shorten jobs along the critical path can the overall project time be reduced; the time required to perform noncritical jobs is irrelevant from the viewpoint of total project time. The frequent (and costly) practice of "crashing" all jobs in a project in order to reduce total project time is thus unnecessary. Typically, only about 10% of the jobs in large projects are critical. (This figure will naturally vary from project to project.) Of course, if some way is found to shorten one or more of the critical jobs, then not only will the whole project time be shortened but the critical path itself may shift and some previously noncritical jobs may become critical.

Brooks' Law and Agile Development

In his seminal book The Mythical Man-Month, Fred Brooks explains that crashing a schedule doesn't work in software development because: 1) people need time (often a lot of time) to get up to speed on a project; 2) as you add more people to a project, you increase the amount of communication required, which reduces everyone's productivity; and 3) software development tasks can't be subdivided into smaller tasks the way physical tasks such as painting a house can be. His entire argument can be boiled down to one widely quoted line, known as Brooks' Law: "Adding manpower to a late software project makes it later".

Dave Pagenkopf, an Application Development & Integration Director at the UW-Madison, explains how Agile software development offers an alternative to the painful realities of Brooks' Law:

Early in my career, like many software engineers, I didn't see how Brooks Law could possibly be true. But as I began to lead software projects, I began to see first-hand the problems that come with crashing a software development schedule. One of the reasons that I prefer Agile so much is that the approach keeps options open when a project is behind schedule. To hit a date in an Agile project, you can reduce the scope (keeping in mind that you can always add more scope later). An Agile software project that is 80% completed is likely still useful. A waterfall software project that is 80% completed is likely useless.

Here are a few tips to keep in mind when attempting to compress a schedule:

  • Engage the entire team in searching for opportunities with the largest time/cost impact.
  • Look for ways to increase concurrency, and for activities in which increasing assigned resources will shorten the activity's duration.
  • Consider offering incentives for early completion. This is common, for example, in some highway projects, in which contractors are charged for every day that a lane is closed, or a bonus for completing the project early. This gives the contractors incentives to minimize the amount of lane closures at any given time.
  • Not all activities have equal value to project delivery. Some are merely "nice to have" activities. This is often true in open-ended projects, such as product development projects. Once you get to work shortening a project plan, you may be surprised by how much you can cut out without significantly affecting final deliverables.
  • Make schedule compression changes carefully, always keeping in mind that schedule compression can add risk. Make sure you thoroughly understand the eliminated activities to ensure you don't miss something crucial.
  • Although CPM presumes a geometric order approach to planning and scheduling, it is not blind to the uncertainties that can arise in any project. A typical CPM schedule specifies the slack (or float), associated with each activity, thereby allowing leeway for activities that might run longer or take less time than expected.