I had lunch the other day with Joel Koppelman, co-founder of Primavera Systems (project scheduling software). We discussed the reluctance of many in the construction industry to upgrade from the old P3 (or SureTrak) software products (developed in the 1980s) to the more modern enterprise and cloud enabled P6.


“Fred, if you could re-write P6 (to be more like P3) what is so important to require that enormous level of program development and would any but a slim minority care?” “Joel, you have to understand, construction users are like left handed golfers. We need our left handed golf clubs.”


And so we do. Also last week I ordered through EBay a “new” reconditioned laptop with XP operating system. As a backup. I have also had my main office desktop with XP hard drive “ghosted” – a bit for bit duplicate with operating system, current programs and data – bagged and placed in my home freezer. (A protocol for keeping the zip file for newer software, and weekly archiving of data was already in place). With a majority of my clients using P3 or SureTrak, availability to XP and thus P3 is a mission critical requirement.


So to better answer Joel – and more importantly the current product managers for Oracle, Deltek, Microsoft and others – exactly what are the left handed attributes we construction professionals require?


First and foremost is that while 50% of the value of the CPM is derived with the initial plan, the other 50% is not appreciated until the project is well underway, always with variation and change. The defining attribute of 1956 CPM over 1910 Gantt charts is the update – the ability of instant recalculation once entering current status (actual start, finish, remaining duration of work-in-progress). Maintenance or slipping from the current plan is made immediately obvious. Is the project moving forward? If not, what areas of scope are experiencing disruptions or delay? Later we may invest the time and effort to tweak our plan; although if properly prepared we will leave the initial plan in place, navigating the detour as does the GPS in our car to attempt to return to that initial plan. Only if the detour is so great as to make return impracticable, or we see sufficient gain to justify the effort will we re-baseline from this point forward (a recovery schedule). A few good reasons to develop a recovery plan are a cardinal change to design, conditions beyond the imagination of the parties, and default with substitution of contractor. Otherwise, we still generally plan to take I-95 from New York to Miami even if we must detour around that nasty accident in Baltimore.


Second and almost as important is that construction project managers (and especially the all important superintendents) are highly individualistic cowboys. We want to use OUR codes and not a drop down menu of enterprise codes. We want to place ALL files for each project in a separate subdirectory and thus quite possibly reusing the project codes for each project. UPD005 is update number five for whichever project is in that subdirectory. MASON01 is MY primary masonry subcontractor. If corporate wants to roll up all my data for corporate data mining, let corporate PAY for SOMEONE ELSE to convert MY data or to collect the additional data I did not bother to record as it had little or no value to MY productivity. Mostly corporate has placed me out on the jobsite with God-like powers to get the best result. Tell corporate to not to get in my way with non-job-specific tasks or enterprise protocols to divert me from this goal.


Do you want more detail on the attributes we desire?


What does the construction professional most desire in the initial CPM schedule? Speed of execution and completion of the project. Compare with the 95% of managers who are most concerned with productivity of individual human resources. Once we switched from the 1956 ADM (arrow diagramming method) model to the 1964 PDM (precedence diagramming method) model we added options to best advantage either time or productivity. One of these options is interruptible or continuous duration when calculating the forward pass through overlapping activities.




What does the construction professional most desire in the periodic status update? Accuracy of the report of past progress and forecast going forward with relation to time!



While a bar-chart of the initial schedule calculated by either the Start (S3 or PS3 progressed to start) or Begin (B3 or SS3) algorithm will look the same, the construction professional probably means the former. The reason is not only semantics – it makes a crucial difference during progress status updates. If during the course of the project, A actually starts but is then stalled (such as excavation encountering unexpected issues), the S3 / PS3 / start restraint will not advance B until the remaining duration of A is reduced by those three days to an RD=7. The B3 / SS3 / begin restraint will say that A has started, three days have elapsed, and now call the crew in to begin B.


Software of the late 1960s, 1970s and early 1980s made this distinction. The begin restraint was rarely used, at least in the construction trade. The move from 1970s mainframes to 1980s desktop computer led to effective demise of the start restraint. The algorithm is more complex requiring comparing the lag to the original minus remaining duration (OD-RD), requires pre-screening (to avoid where the lag entered is greater than 100% of the original duration) and is more difficult to explain. Today the start restraint choice is supported only in two products known to this author: Deltek Open Plan (partially) and Spider Team Project Management. Complicating this issue is that the begin restraint was re-branded as Start-to-Start. Thus the need for a new PS moniker for the start restraint advocated in this blog author’s RDCPM® compliance certified protocol. (Spider Team uses Start-to-Start-by-Time or Start-to-Start-by-Volume).


There are several other major differences in algorithms needed by construction professionals (or others desiring time-is-king rather than productivity-is-king). One previously discussed in this blog is support of the traditional interruptible versus currently supported continuous duration. This becomes apparent whenever the finish of an activity is restrained beyond early start plus estimated duration. The interruptible algorithm then calculates the early start as early as possible, the early finish as required by restraint and may note the span of the activity exceeds the duration. The continuous algorithm purposely delays the early start until the continuous and uninterrupted performance is possible, equal to the restrained early finish minus the duration. While productivity may be maximized by never starting an activity until it can proceed uninterrupted, this will in practice delay project completion. With the interruptible duration algorithm one must trade maximum productivity on an activity for savings or bonus for earliest possible completion. Oracle Primavera P6 and Microsoft Project support only the continuous algorithm most effective on the factory floor. P3 and some newer products, such as Oracle Primavera Risk Analysis (PRA, formerly known as Pertmaster) and ASTA Powerproject support the user choice of interruptible or continuous. See prior blog,  Oracle's P6 R8 – A Successful Operation, but Let's Make the Software Model How We Want to Do the Work for more details.


So while there are products that support left-handed golfers or construction professionals, they are more difficult to find, and may not quite fit in a right-handed or job-shop scheduling world. It is these types of issues that call for a forum for construction professionals such as the Construction CPM Conference. Our next conference will be January 13-17 2015 in San Diego. Early-early-bird (speaker rate) pricing is available for all up to this June 15th.