The mission of the Construction CPM Conference is to improve the knowledge of planning & scheduling professionals, and to improve the tools which we use for our unique needs to support on-time construction deadlines.
A recurring theme of my ENR blog posts and commentary has been that many software products currently used and often mandated do not support the goal, but rather support “best productivity” of individual tasks over the group effort of on-time completion.
And yet, by our meeting at the conference in a specific software-agnostic setting open to competing products, we are having some success in nudging the software developers to serve our needs. And the needs of their perhaps more numerous customers in other fields.
We are happy to report we have encouraged another software developer to add back the original algorithm of 1956 supporting fastest completion. In the 1980s this was supplanted by another algorithm designed for perhaps lower cost at the price of earliest completion. To put it in perspective, the choice of the interruptible versus continuous algorithm on one of my current projects targeting completion in under two years means a savings of nine weeks. On another very urgent project with a ten-month deadline, the choice of algorithm saved five weeks.
What are these two algorithms? The original 1956 “interruptible” algorithm called for calculation of early start to be equal to latest of early finishes of all predecessors:
ES = latest EF(preds)
This equation is to be followed in all instances. But where the finish of an activity may be pushed beyond EF = ES + Duration by a finish-to-finish restraint by this or other predecessor activity, such may lead to lower productivity of the subject activity. After all, to start up, do some work, then stop for a while to let another activity to catch up, then to start again to complete, should be more costly than continuous work. But if the start of the second activity is required to start a third activity, it can delay the whole project. See diagram below.
The 1980s “continuous” algorithm avoids the cost of start-stop-restart by deferring the early start of the activity until work can proceed without interruption. Here we preliminarily calculate the early start from preceding early finishes, then after calculation of the early finish of this activity (perhaps driven by that other FF restraint) recalculate the start by subtracting the duration:
ES = latter of latest EF(preds) .or. EF – Duration
All of this has been discussed previously in my blog posts and commentary; for example our post of July 3rd 2014 touted the reintroduction of the interruptible algorithm as an option in Phoenix Project Manager. And now Spider Project Team software has also reintroduced the interruptible (or in their terminology “adjustable”) algorithm.
Also quietly supporting “interruptible” are Deltek Open Plan (as “discontinuous”) and Elecosoft Asta Powerproject. It is available but you have to know to ask. While Primavera’s legacy P3 and current PRA (formerly named Pertmaster) support both options, Oracle’s flagship P6 does not, which has been a serious complaint since deployment in the 1990s.
And yet, while many practitioners and construction professionals complained, Primavera and now Oracle development has been dominated by the needs of manufacturing and IT customers. At a user meeting for Primavera – or a User Meeting for Deltek – or a User Meeting of Asta – the attendees focusing on construction have been a small (and perhaps too silent) minority. At our Construction CPM Conference we construction professionals are the majority and can make our voices and needs heard.
Our next conference is January 20-23, 2019 in San Diego. Perhaps you can join us. Go to Construction CPM Conference - http://www.constructioncpm.com/
Post a comment to this article
Report Abusive Comment