The Drag Efficient The Missing Quantification of Time on the Critical Path

To print a PDF copy of this article, click here.

Author: Stephen A. Devaux

Critical path analysis has been around for more than half a century. An argument can be made that no project management technique is more important. Yet in project management theory and in scheduling software, there is the significant omission of two vital critical path metrics: drag and drag cost.

Critical path drag is a key metric in the planning and scheduling of a project. It measures how much a critical path item is delaying project completion. Its greatest value is to the contractor who must manage the schedule. But it is also crucial for the customer to know that the project team is using this metric both to generate an efficient schedule and to target the most appropriate work packages when slippage occurs. The drag cost of an activity has even greater implications for the customer; it is the amount of value that the project is losing due to delivery being delayed by that activity’s critical path drag. Unfortunately, financial analysis of project work tends to focus almost exclusively on budget. Benjamin Franklin wrote that time is money. Every customer knows that the time required for a project comes at great cost. Those funding projects often would willingly pay significantly more to accelerate deployment of a mission-critical system. Since it is exclusively critical path activities that are delaying project completion, the cost of delay is an invisible and expensive cost of critical path work. The problem is the inability to identify which critical path activities are costing the time and money—i.e., their drag and drag cost. This article will show that the use of these concepts is vital to on-time delivery, schedule recovery, and the generation of maximum customer value.


Impact of Critical Path on Project Investment

jan12-article-5-secondary-2All projects, without exception, are investments, undertaken to create greater value than the cost of the required resources. No customer or sponsor would ever knowingly invest $5 million worth of resources if the total value from the final product, from all sources, was only expected to be $4.9 million. The difference between the value of the final product and the cost of producing it, what we might call project profit, should be a key metric for project performance (as it is for all other investments!). The cost of a project investment is always carefully tracked—but the return, or the expected monetary value (EMV) of the scope is little analyzed and often ignored. One of the main factors that can affect the EMV of a project is changes in delivery date. It is usually the case that the earlier the delivery date, the greater the value of the project investment. Delivery date is always determined by the project’s long­est, or critical, path. This may start as a planned critical path, but will finish as the actual longest path, or what the construction industry terms the “as-built critical path” (ABCP). The project manager should recognize the overwhelming importance of this path, and manage it. During project postmortem, the ABCP and the changes from plan that may have generated it should be a vital artifact and a generator of lessons learned.

Gaps in traditional critical path data

Whether dealing with the planned critical path or the ABCP, it is important to recognize that both the gods and the devils are in the details. Good schedule management requires knowing the contribution of each activity (as well as technical difficulties, scope changes, resource insufficiencies, schedule constraints, etc.) that contributes time to the length of the path. And here, unfortunately, we enter an area in which critical path theory, as beneficial and vital as it is, is silent. What does critical path analysis tell us about each activity in our project? If an activity is not on the critical path, both critical path theory and traditional program management software quantify something called either total float or total slack (depending on the software): the maximum amount of time that an activity can be delayed without making its path the longest in the project. Figure 1 shows a simple network logic diagram of a project with the earliest and latest dates for each activity filled in on top and at bottom respectively. Let’s assume that this is the schedule of a project with a 45-day deadline, with each additional day reducing investment value by $10,000.

Figure 1. A Simple Network Logic Diagram, Showing Forward and Backward Passes and Total Float

jan12-article-5-figure-1 As the network shows, the critical path is A, C, E, H, I, and the project duration would be 60 days. The total floats of the non-critical activities would be: F = 10 G = 10 H = 8 I = 3 But since total float quantification is all off the critical path, this gives us little help in knowing where to compress the schedule. And unfortunately, no similar quantification is performed for activities that are on the critical path! For each critical path activity, the software (and all traditional PM theory, including the PMBOK Guide) simply says zero—that its total float is zero. Of course, project schedules are much more complex than the simple example shown in Figure 1. But no matter how large or complex the schedule, the project manager’s approach should always be to make the project schedule as efficient as possible, providing the customer with the greatest value for the least cost. The trouble is that most traditional project management metrics are silent about what we all know is really important: the critical path. What we need to know is:

  • Of all the activities on the critical path, which are adding the most time to project duration and offer the greatest “bang for the buck” if shortened?
  • How much money is each activity’s added time costing, and how much would it cost to compress it?


The first metric that addresses this issue is not float—it’s the much more important metric, critical path drag (as introduced in my book Total Project Control: A Manager’s Guide to Project Planning, Measuring and Tracking, published in 1999 by John Wiley & Sons). Just as drag is what slows down a submarine or an airplane, critical path drag is the amount of time by which a critical path activity is slowing down the project. And it is vital information for any project manager to know about the activities in her project! Float is always off the critical path, whereas drag is always on critical activities. Float usually does not cost the project time and money, whereas drag almost invariably does! There is an old saying: “What is measured is what is emphasized.” As a result of the standard CPM metric of total float, the emphasis winds up being on precisely the wrong things—the work that’s not on the critical path! What the project manager needs to know is: how much time is each critical path activity adding to my project duration so that I can target the best tasks for compression. This is critical path drag. In Figure 2, we show the drag totals on the critical path activities: Although “manual” drag computation in a large network with complex dependencies (Six Sigma, lag, etc.) can be intimidating and time-consuming, it is relatively easy in a simple network such as the one above:

  • Step 1: Only critical path activities have drag.
  • Step 2: If an activity has nothing else in parallel (e.g., A and E above), its drag equals its duration.
  • Step 3: If a critical path activity has other activities in parallel, its drag is whichever is less: the total float of the parallel activity with the LEAST total float (B and C above), OR its own duration (D, whose duration of 5 days is LESS than the 10 days of total float in each of the parallel activities F and G).

Figure 2. A Simple Network Logic Diagram with Drag Computed

jan12-article-5-figure-2 Today, three software packages compute drag:

  • Project Optimizer from (an MSProject 2007 add-on)
  • Spider Project

Of course, there is more to schedule optimization than drag computation. Just because Activity E has drag of 15 and Activity B’s drag is only 8 does not necessarily mean that you can shorten E more than B. Some activities are less “resource-elastic” than others, i.e., adding resources may do little to shorten their durations. Shortening some activities may increase risk unacceptably, decrease quality, or otherwise reduce project value and profit. The resources needed to reduce one activity by each unit of time may be much more costly than those needed for an equal or greater reduction on a different activity. However, when trying to shorten the project duration (either up front during planning, or during execution when schedule slippage may leave the project manager seeking alternatives), we may be searching through a network of not five activities but 500 or 5,000! Then there needs to be a way of focusing the process of schedule reduction onto those candidates which will provide the greatest reward. These are almost always the activities with the greatest drag. In Figure 2, even though Activity C has a duration of 20 days, it is only adding 3 days to the project schedule. By contrast, even though Activity D has a duration of just 5 days, it’s adding 2 more days to the critical path than is Activity C. And, all else being equal, Activity E may offer the greatest opportunity with 15 days of drag.



Computing the Drag Cost of an Activity

Ben Franklin’s statement that “Time is money!” is never more accurate than when applied to projects. The key is to tie the cost of project delay to each individual activity generating the delay. The cost of this delay is caused by the activity’s critical path drag, and is the activity’s drag cost. Drag cost represents the synthesis of the concept of project profit with a truly scope/cost/schedule-integrated plan. It is the reduction in the net value of the project because of the delay in project completion due to the time impact of each activity’s drag. It may be caused either because the delay reduces the project’s expected monetary value, or because the delay increases the indirect costs (overhead and opportunity costs). Figure 3 computes the drag cost of each activity if the cost of delay beyond 45 days is $10,000 per day.

Figure 3. A Simple Network Logic Diagram with Drag Cost Computed at $10,000/Day

jan12-article-5-figure-3 Drag cost assigns the cost of project time to the individual critical path activities that are adding that time to the schedule. Suddenly, not only does Ben Franklin’s dictum apply to projects—it now applies to individual work items in the project, and to the resources performing that work. This allows the project manager to assess the relative cost of each work item, and to target additional resources to reduce the drag cost.

Computing the True Cost of an Activity

Although finance departments have taught us to identify the cost of work with the price of the resources doing that work, this is simply not true of work performed on the critical path of a project! A week’s work by a minimum-wage laborer can be much more costly than a week’s work by a Nobel laureate physicist—if the physicist’s work has float while the laborer’s work is on the critical path with lots of drag cost! The true cost of project work is the sum of the resource cost and the drag cost (which of course is zero if the work is not on the critical path). In Figure 4, we have provided the budget for each activity’s resources. Even though most financial analysis would determine that Activity I is the most costly work (with a budget of $30,000) since it has no drag cost, it’s actually not even close. Since Activity I is not on the critical path, its true cost is only its resources. Conversely, Activity E’s true cost is the sum of its $20,000 budget and its $150,000 of drag cost, or $170,000. The true cost of each activity is as follows: A = $15,000 + $100,000 = $115,000 B = $10,000 + $80,000 = $90,000 C = $20,000 + $30,000 = $50,000 D = $5,000 + $50,000 = $55,000 E = $20,000 + $150,000 = $170,000 F = $25,000 G = $15,000 H = $10,000 I = $30,000

Figure 4. A Simple Network Logic Diagram with both Drag Cost and Activity Budgets

jan12-article-5-figure-4 Computing the true cost of an activity can provide huge benefit to the customer, the project manager, and to the organization performing the project. jan12-article-5-secondaryAdditional resources can be targeted to the activities with large true cost. For example, if doubling the daily resources on Activity E reduced its duration and drag from 15 days to 10 days, its budget would increase from $20,000 to $26,700, but its drag cost would be reduced by $50,000 and its new true cost would be only $126,700 ($26,700 +100,000), or $43,300 less. Some optional activities (“nice-to-haves” rather than “must-haves”) often wind up delaying a project by more than they are worth. Drag cost computation would allow both the customer and the project manager to recognize the true cost of optional work when it migrates to the critical path and determine if it is of sufficient value or whether it should be jettisoned. (This analysis should be performed any time that the critical path changes, loading a new set of activities with drag cost during project performance.) Any organization in the business of performing multiple simultaneous projects should conduct quarterly assessments of the true cost of specific resource types (mechanical engineer, programmer, etc.) and create Pareto charts highlighting those that have the greatest true cost. Increases in such resources will usually result in decreases in the drag cost component of their summed true costs.


A Concluding Anecdote

A few years ago, while teaching the concept of drag in a seminar, an engineer who worked with a large defense contractor told an illuminating story. The customer had requested that a specific deliverable that was not part of the project’s critical path be pulled in by 6 weeks. The transcontinental team all flew to a central site and spent a full day suggesting the changes they thought would meet the new scheduling needs. When they were finished, they incorporated the changes into the master schedule—and the deliverable came in by 1 day! The team then spent the rest of the week engaged in pure trial-and-error: “What if we could do this in 8 days instead of 12? Nope, no change.” “What if we made this 5 days instead of 14? Okay, we gained 3 days!” The engineer told me: “If we’d understood the concept of drag, we’d never have even left our offices. We could have accomplished our goal in a half-hour conference call.”

To print a PDF copy of this article, click here.

Devaux is president of Analytic Project Management and teaches in the MBA program at Suffolk University. He has taught and consulted at many DoD contractors, as well as at Brandeis University, Franklin W. Olin College of Engineering, the University of the West Indies, and the University of Massachusetts, Lowell.

The author can be reached at



Leave a Reply

Your email address will not be published. Required fields are marked *