Ed Mahler PAI
914-834-4162
edmahler@paiwebsite.com
Specialty: Herding cats.  Coaching schedulers in the art of planning and control for multiple project managers using MS Project, anecessary project office and portfolio management skill.

Next and past conferences

Status update cycle

To join the Project Management College of Scheduling:

First, enter your email below to subscribe to our mailing list.

If you'd like to join the College or renew your membership click the Pay Now link below. Dues are $35 annually.

Once you have paid your membership dues, please register here to access the Members Only Area.

By: Rick Moffat One of the most overlooked (whether intentionally or unintentionally) areas of delay analysis is the issue of concurrent delay. The importance to determining cause and responsibility for delays has been widely published and addressed by the courts, however it continues to be ignored by project schedulers and delay experts. When investigating the cause of a delay to a project, it is common to find that there is more than one delaying event and often those delays are overlapping. When determining the compensability of a delay, one of the primary issues an analyst has to consider is whether the delaying events were concurrent and, if so, to segregate their individual impacts. The following is an example of the effect of concurrency on compensability based on a recent query raised by a client. While the facts have been greatly oversimplified for the purposes of this article, the circumstances are indeed an example from an actual construction dispute that I was asked to review.

The Program Schedule

The Program involved the construction of two projects by two different contractors. The projects were interrelated and the completion of both was necessary to complete the overall Program. For this example we will identify the projects as follows:

• Project 1 built by Contractor ABC
• Project 2 built by Contractor XYZ

The two projects were mostly independent except for an interface point at a critical contract milestone that required the completion of Project 1 two months before the completion of Project 2.

A sudden change introduced by the Owner

After month 4 of the Program, both contractors’ schedules showed that they were both on schedule. However, during month 5 the Owner issued a change order (CO) for changes to the work on Project 1 that increased the Project 1 schedule by 3 months. Because of the direct relationship between completion of Project 1 and completion of Project 2, the Owner took the responsible step of notifying Contractor XYZ that the critical milestone was being delayed and requested that the subsequent schedule update contain a delay activity that showed the impact of this change. Accordingly, Contractor XYZ issued a schedule that included an Owner’s Delay Activity, as requested, and indicated the 3-month delay to Project 2 because of the delays to Project 1 caused by the Owner’s CO.

Review of the impacted schedule shows other delays

The next logical step in the schedule analysis was to remove the Owner’s CO delays from the Project 2 schedule and see what happened to the end date of the project. Presumably, if the only delay was the Project 1 CO work, removing it should return the completion date to the Baseline completion date. On the surface, the Project 2 schedule seemed consistent with the impact from the delay of the late completion of Project 1. However, a more in-depth analysis of the Project 2 schedule showed that things were not as they seemed. As part of the schedule review, the schedule analyst removed the Delay Activity from the CPM network and the schedule re-calculated. Surprisingly, when the delay was removed, the end date of Project 2 only improved by 1 month. Therefore, there were events other than the CO work that were affecting the project’s Critical Path. A further analysis was undertaken and it was determined that in addition to the delay activities, Contractor XYZ has also modified logic and increased duration of activities that were not impacted by the changes on Project 1; these changes to the schedule, on their own, resulted in a delay of 2 months to the completion of Project 2. After discussion with Contractor XYZ, it was determined these were simply errors that were within the original schedule that Contractor XYZ had avoided disclosing to the Owner and were attempting to hide behind the delay on Project 1. Because Contractor XYZ’s error was discovered during the same time as the Owner’s CO delay, it was determined that the delay due to Contractor XYZ’s scheduling error was concurrent with the Owner’s CO delay.

Determining compensability for concurrency

The hotly debated discussion that ensued between the Owner and Contractor XYZ related to the compensability for the delays on the Project. While it did not deny that it had some logic and duration “anomalies” in its original schedule, Contractor XYZ insisted that because the 3 month delay caused by the Owner’s change was greater than the 2 month delay due to the scheduling errors, it was entitled to not just a 3 month extension of time, but also to be compensated for the costs associated with the entire 3 month delay. However, this is not how concurrency works. The purpose of reviewing concurrent delays is to determine if there are other factors delaying the project. In this instance, if it had not been for the delay to Project 1 due to the Owner’s changes, Contractor XYZ would have finished the project 2 months late due to its own planning errors. Even though the Owner’s delay was greater than Contractor XYZ’s delay, the Contractor XYZ was not entitled to be paid for the entire time associated with the delay. After much negotiating with Contractor XYZ, it was ultimately agreed that it was entitled to a time extension of 3 months of which 2 months were non-compensable and 1 month was compensable.

Conclusion

Contractor XYZ was not particularly pleased with the outcome but understood that, if it weren’t for the Owner’s changes on Project 1, it would have been forced to acknowledge its own scheduling errors and would have been responsible for the 2 month delay, all of which would be non-compensable.

Endnote: One other consideration

One issue that always has to be considered when reviewing concurrency is the concept of “hurry up and wait”: if a critical component of the project is delayed, is the contractor obligated to maintain the schedule on the rest of the work, even if it ultimately knows that it will eventually have to stop because of the critical delay? This can be a difficult issue to overcome. If outside influences cause portions of the work to be delayed, the contractor may choose to slow down the other elements of the work to pace the rest of the project with the delayed portions. When forensically analyzing schedules, it can be difficult to tell whether a concurrent delay is due to poor performance or if it is the result of the contractor “pacing” the other work. If any party on a project is intending on slowing down its work due to the delays of the other, it is always best practice to inform the other party so that the pacing is not viewed as concurrent delay.

Epilogue

There is a rightful argument to be made that the final resolution was very generous to Contractor XYZ. The fact that the “discovery” of Contractor XYZ’s schedule errors overlapped with the Owner’s CO minimized the fact that Contractor XYZ was already behind schedule BEFORE the changes occurred. In a forensic analysis that looks at the delays in the order they impact the critical path, Contractor XYZ’s delay would have been a non-excusable delay. If the contract included liquidated damages, those damages could arguably have been enforced for the 2 months of critical path delay that occurred before the Owner’s CO. Furthermore, it was also grossly inappropriate that Contractor XYZ withheld its scheduling errors from the Owner and attempted to bury them in the schedule containing the Owner’s delays. Nonetheless, the parties at the time agreed that, notwithstanding Contractor XYZ’s less than honorable approach, the Owner’s delay denied Contractor XYZ the opportunity to mitigate its delays and therefore allowed the 3 month time extension.

By: Stephen Devaux, PMP, MSPM Every chain is as weak as its weakest link, right? So how would you go about making a chain stronger? If the chain consists of 100 links, and fortifying them would be costly, we wouldn’t want to just randomly select a half dozen to strengthen. We’d like some way to select the weakest ones, those that offer the biggest bang for the buck in terms of creating a stronger chain. The newly hired general manager of a baseball team looks to identify and improve those positions where the incumbents have been unproductive. A sales & marketing vice president examines those geographic/demographic areas where sales have been lagging. And an aircraft designer seeking more speed attempts to streamline those parts of the plane causing the most air resistance, or “drag”. Every project is as long as its longest path. Yet critical path theory, and most project management software, effectively tells us only which “links are strongest”: in other words, it identifies non-critical activities that have zero impact on the project’s duration. It quantifies, as total float, the “buffer” to those activities impacting the project’s duration. About the critical path activities that delay project completion, it tells us, literally: “Zero!” Why does the duration of a project matter? Because shorter projects, just like stronger chains, better hitting shortstops, expanded market segments and faster planes, almost always offer greater value. The shorter project:

• Provides the value of its “product, service or result” sooner;
• Outpaces the competition to market;
• Removes the risk of being late; and
• On projects undertaken to save lives, saves more lives!

Occasionally, projects aren’t made more valuable by being shorter—stronger chains and faster planes aren’t always needed. But such instances are quite rare in the project world. And even then, when unexpected schedule slippage occurs, the project team starts desperately seeking ways to shorten the remaining duration—like the owner who chains his boat to the dock ahead of an impending hurricane now wishes the weakest links were a bit stronger! Critical path theory, and project management software, needs to tell us not just how far removed from critical a non-critical activity is, but also how much time each critical activity is adding to the project duration. Because that is the information that tells the team where to go to have the greatest impact on shortening the project! Yet the theory, and most software, simply says zero—that the float of each critical path activity is zero. What the team needs to be told is how much time each critical path activity is contributing to the project’s remaining duration: its critical path drag. And depending on the details of the schedule, a 30D activity on the CP could have just one day of drag, while a 10D activity might have 10D of drag. Figure 1 below shows the drag of each activity in a short network: Figure 1: A simple network diagram with float and drag computed In a small and simple network with only finish-to-start (FS) relationships, the “rules” for computing drag are not too complicated:

1. If an activity has nothing in parallel, its drag is equal to its duration.
2. If an activity has other items in parallel, its drag is whichever is less:
   • Its duration, OR
   • The total float of the parallel item with the LEAST total float.

In Figure 1: Activities A and E have nothing in parallel and so have drags equal to their respective durations. Activity B has a duration of 12D and is parallel with Activities F and G that have floats of 20D and 11D. Therefore Activity B’s drag is 11D. Activities C and D have durations of 3D and 32D, respectively. But in addition to being parallel with Activities F and G, they are both also parallel with Activity H and its float of 4D. Therefore Activity D is limited to drag of 4D, while Activity C can only be adding three days because that is its duration. If all networks were as simple as this one, drag computation would be easy even if scheduling software didn’t support it. Unfortunately, larger networks and complex dependencies (start-to-start, finish-to-finish, start-to-finish and lags/leads) make the computation much more difficult. Additionally, as soon as we alter something, all the computations change. For example, if in Figure 1 we were to add resources to Activity D such that its duration changed to 20D, not only would the project duration be compressed by 4D (i.e., Activity D’s drag) to 56D, but the critical path would change and several drag totals would change. To continue the schedule compression process, we would need new computations which, on a large project, would be quite burdensome without the software functionality. Slowly, software is emerging that computes critical path drag. Spider Project launched such an algorithm in 2009, and enhanced it to compute drag on a resource-leveled schedule in 2014 (yes, resource bottlenecks can also have drag!) In 2015, Boyle Project Consulting created an add-on to Microsoft Project that computes drag. InterPlan Systems has announced that its next release will compute drag. And in August 2016, Elecosoft announced that Version 14 of its Asta Powerproject software, to be launched in October 2016, will compute drag. But meanwhile, seventeen years after the concept and its computation was explained in the first edition of my 1999 book Total Project Control, the PMBOK® Guide and other standards still make no mention of drag. The whole project management discipline inches away from its most powerful tool, critical path analysis, and toward the often unsystematic scheduling techniques of agile projects, and worse. And that’s really a shame. Because every chain is as weak as its weakest link. And scheduling has become a weak link due to the fact that critical path theory and software fail to provide the most critical metric: drag, which costs time and money and, sometimes, human lives. And until we identify and quantify those costs, we cannot adequately address them. For much deeper exploration of the importance of critical path drag, I recommend my books Managing Projects as Investments: Earned Value to Business Value and Total Project Control: A Practitioner’s Guide to Managing Projects as Investments. *** Some Further Reading on Critical Path Drag “The Drag Efficient: The Missing Quantification of Time on the Critical Path”, Defense AT&L Magazine, Jan-Feb 2012. “Introduction to the Basics of Scheduling, and Drag as the Metric for Project Delays” by Dr. Tomoichi Sato. “A Importancia das novas metricas “Drag” e o “Custo Drag” na Analise do Caminho Critico”, written for and published in Brazil by Peter Mello, 22 de fevereiro de 2015. (English translation here.) “Seventeen Years Later, Doesn’t Critical Path Drag Belong in the 6th Edition of the PMBOK® Guide?”, LinkedIn blog, July 1, 2016.

Recently, Stu Ockman had a chance to share some ideas with ENR Deputy Editor, Richard Korman.  Here are the results of their conversation:  Ten Minutes with Stuart Ockman.

If you'd like to learn what's happening at the College as we grow, please email our VP of Communications, Rick Moffat, at jrd.moffat@gmail.com, to be added to our email list and receive notices of upcoming events.

If you'd like to volunteer to serve the College as either a director or committee member, please contact our Director of Volunteers, Ronny Warren, at mailto:rwarren@pmccompany.com

How do you know whether your schedule is good or not? The following are a few tests to see if your CPM schedule is up to par. If you have additional tests that you like, please provide them in the comments. The idea is to collect rules of thumb for identifying good schedules and eliminating bad ones. Here are half a dozen tests to try out on your next schedule:

Test 1: Does the ‘Total Float’ sort or ‘Longest Path’ filter identify a reasonable critical path for the project?

With multiple calendars, the total float/early start sort may not identify the critical path. Some software offers a Longest Path filter to work around this problem. Make sure the longest path is reasonable. Then check the reasonableness of near critical paths. [If you’re using the Longest Path filter, you may have to make a copy of the schedule and start deleting logic ties so that near critical paths show up when the Longest Path filter is rerun]. If the critical path and near critical paths are reasonable, you’re off to a good start.

Test 2: Do any activities have too much float?

Run a total float sort and examine the activities with the most float. Activities with too much float may indicate missing logic ties or logic ties that have been overridden by reporting out-of-sequence progress when updating. Add logic ties, if necessary, to insure that float durations are reasonable and correctly model the current plan.

Test 3: Do any activities have planned durations greater than the update cycle?

Ideally, project activities should be planned at a level of detail so that activity durations are equal to or less than the update cycle [with certain project specific exceptions]. Thus, if a schedule is being updated monthly, planned durations should be 30 calendar days or less. This means that each activity will be in progress for no more than a single update cycle, unless it is behind schedule. By using shorter activities, remaining duration estimates are both easier to make and more accurate, resulting in better status reports for upper management and the project team.

Test 4: Are there any unnecessarily long gaps in workflow when grouping activities by Work Area and sorting by Early Start/Early Finish?

Take a look at an early start/early finish sort grouped by work area, department or phase to get a feel for workflow and resource requirements. Long gaps in an area or phase may indicate less than ideal workflow requiring adjustment of preferential logic ties to create a better plan. In most cases, once work begins in a particular area or on a particular phase of the project, the schedule should allow work to continue uninterrupted in that area or on that phase until it is complete.

Test 5: Are there activities with unnecessary user-assigned constraints?

Since user-assigned constraints override the network logic in calculating early/late dates and float, they should be used sparingly on a project, if at all. A better approach is to use activity durations and network logic to accurately model the project and eliminate constraints. Consider either (1) printing out a constraints listing or (2) running a filter selecting constrained activities. Once you’ve identified all the constraints in the network, you can begin removing them.

Test 6: Are remaining duration estimates accurate?

Too often on a project, remaining duration estimates are automatically generated by reporting activity percents complete at each update. First, make sure that any automatic software link between remaining duration and percent complete is turned off. Next, make sure that every time the schedule is updated, the people responsible for getting the work done provide the remaining durations for activities in progress. Without accurate remaining duration estimates, no downstream dates or contingency times (float) will be accurate, making the schedule a candidate for printing on softer paper.

Try these tests on your project and let us know what you find. And, add your own tips and tricks to the comments below. Good luck and happy scheduling!