It is not uncommon for construction CPM schedules for projects exceeding $50M+ in construction costs to encompass over 3,000 activities. Along with the 3,000+ activities, a schedule of this sort could easily contain 6,000+ logical ties, many of which may include leads/ lags. Even with all the advanced sorting, grouping, and filtering capabilities of today’s CPM software, a schedule this large can be cumbersome at best; at worst it is a useless time-sink that requires valuable resource hours each month to update and is truly understood by no one.
Further compounding the issue, in today’s construction industry, the scheduler is often not really a planner, but rather a ‘software jockey’, for lack of a better term. He or she is likely quite proficient in the scheduling software of choice, but often times a junior-level person with limited field experience to draw from. Likewise, it is common that the planners on the project (typically the project manager and superintendents) are not fluent in the protocols of the CPM software package of choice. Therefore, the disconnect may be set from the start, with each party fluent in their own expertise, but with only a basic understanding of their counterpart’s. As a result, the scheduler frequently acts as a scribe or surrogate planner endeavoring to portray through the CPM software the plan as envisioned by the project manager (PM) and superintendents, however, sometimes subtle details are lost in the translation from project manager/superintendents to scheduler to CPM software.
Following the initial input of the schedule, the iterative review process begins. Typically this consists of the scheduler passing a hardcopy of the CPM output along for comments. Due partially to time constraints as well as potential lack of understanding of the CPM software details, this review does not typically include any detailed review of logic ties and constraints and includes perhaps only a cursory review of such basic elements as durations. The more likely focus of the review is the projected finish dates for key project milestones. The obvious problem of this scenario is the scheduler knows the software and the PM/superintendents know the project, but neither knows enough of the other to ensure a tight project schedule. Once the baseline is set in this manner, there is distinct potential that the newly anointed baseline schedule is wrought with pitfalls. Likely, updates of the schedule proceed in this similar iterative process, and the pitfalls of the baseline are unearthed (and not necessarily corrected) as the updates continue, only compounding the problems.
Dr. Gui Ponce de Leon, PE
John M. Zann, PE
Presented at PMICOS Annual Conference 2008