Lag leaves CPM Timelines in the Lurch

Lag leaves CPM Timelines in the Lurch

Bad habits are hard to break - especially within the rigid confines of P6 - if you find a good trick you stick with it. One of the hapless scheduler’s favorite trick is the use of lag. I include myself as a reformed ‘lagger,’ or the CPM scheduler who either uses lag both discriminately and indiscriminately. The trouble with lag boils down to a discrepancy in what we perceive of as intuitive and counterintuitive in the program: i.e., we learn to speak its language, think like it, without creating disconnects.

One of those disconnects is the way lag fits into float-calculations. A second throws a monkey-wrench into cost loading, as lag can have no costs. Lastly, nuisances like bar-necking, or gaps between critical path activities show up on the bar chart and demand reconciliation.

“Exactly how are you going to resource and cost load lag?

As a project manager, I knew that many construction sequences must be staggered in order to maintain fluidity, as a function of limited work area, constrained resources or logistics, and the natural order of progression that I intuited. This is especially so when multiple trades are depend on one another for access. Any non modular tower that goes up follows this sequence of operations (SOO).

As a scheduler it seemed the natural thing to stagger activity relationships with start-to-start relationships + lag, as it seemed the most precise way of determining the critical path, while at the same time optimizing total-float. Using lag at all is a bit counter intuitive to optimal CPM mitigation. I used lag for years, and it worked - after a fashion. But as I became more experienced with the way CPM works, I began to realize that there were certain shortcomings to using lag, and I eventually quit using it.

‘Lazy schedulers like lag because they don’t have to think through to a better solution.

To simplify, think again in terms of discriminate and indiscriminate lag. Discriminate lag is generally accepted; It is the sort of lag I described above: it makes total sense and logic germane to real actual SOO. The other sort is when there are real-time constraints, such as fixed delivery dates. Best practice dictates having as few constraints as necessary, as these invariably gum up float modeling. What’s more, if the version is part of a claim schedule, it will be rejected if it has superfluous hard-date constraints. Indeed, some stakeholders include terms in their schedule specifications forbidding it.

Indiscriminate lag is inexperienced schedules using lag as a tool to generate desirable dates in lieu of real dates, or what I like to call wagging-the-dog. The way P6 used to work this lag was not plainly visible to users. With 16.1. on, handy predecessor and successor details column options appeared, where lag is plain to see, provided that column is in the view.

Indiscriminate lag is also used by some, to decrease free-float to either conceal available positive float, or to simply to massage data to mollify an audience. Neither of these sound like particularly ethical practice, yet there can be mitigating circumstances, such as political or PR considerations that dictate strategy, which are more a part of doing business than they are scheduling. Suffice it to say, the difference between Indiscriminate lag and discriminate lag is that the former is discretionary, and the latter is not.

The first time I really started to question Indiscriminate lag was when I began using Acumen Fuse. The premise Acumen Fuse works under is that lag has a negative effect on a schedule if it is used on more than 5% of the activities - which is what DCMA 14 sets as a cut-off. Additionally, too much lag knocked down my Fuse Logic Index score. I next wondered “if not using lag, then what am I supposed to do with it?” It turned out there were two things I could do, and continue to do with all my schedules from that point forward.

‘5% of all activities may be lagged, otherwise the schedule deprecates

Work with real dates

The first thing was to convert BS lag and either replace it with a real activity: such as “concrete curing,’ trade transition or coordination,” or some other non-cost activity. The next was to put it through Acumen Fuse’ Cleanser, which has an excellent way of dealing with lag in the schedule: it groups - or rather relegates them together, at the bottom of the WBS, where they can also be filtered out of view. Best of all, the lag logic remains in tact. You get to keep your lag without gumming up the works too much.

The only thing worse than ‘lag’ is ‘negative-lag.’

Acumen Fuse deals with 1’000s of lagged activities in a single click, once you select that option in the Cleansers tab. While Fuse relegates lag to the bottom of the WBS, it eliminates redundant activity relationships, negative lag, SF relationships, open-ended activities, circular logic, and redundant activities. The benefits of the Cleanse operation are easy to measure by Fuse Benchmarking the schedule before and after you Cleanse it.

So, if you must use lag, keep it to a minimum, and manage it as you would any other activity. As activities begin, I like to remove the obsolete lag from the activities. Reworking or deleting lag may represent a change from the baseline that might make reviewers whine, but it’s part and parcel of means and methods, as well as best practice. But then most schedule reviewers wouldn’t have any idea what you’re talking about.

#cpm_scheduling #project_planning