By William Ibbs and Farid Saddik
The Critical Path Method (CPM) has been a staple of industry scheduling practice for more than 50 years, and the software that has arisen around CPM has evolved substantially in the past 30 years. That evolution to some extent has been good and to some extent bad. We believe that the construction management community in general, and schedulers in particular, have a lot of experience and wisdom to share. Our goal, through a series of articles such as this one, is to stimulate discussion about both the CPM methodology and the software. We start with a short review of CPM history, followed by a discussion of the application of “dynamic modeling,” to common CPM activity components, including durations, relationships, and constraints. Feedback is therefore definitely welcome.
Introduction
Detractors of CPM point to its unintended poster child -- the Gantt chart and its deficiencies -- as a primary reason to abandon the algorithm. They also argue that CPM’s age makes it outdated.
Henry Gantt’s bar charts have existed for more than 100 years. The Polish engineer Karol Adamiecki was reportedly working along similar lines as early as 1896, but his failure to publish his work in the West led us to use Gantt charts rather than Adamiecki charts.
As society evolved and pursued larger, more complex projects, the need for more sophistication increased, particularly for displaying activity logic relationships. A precursor to the CPM method was developed by DuPont in the early 1940s to plan and control the Manhattan Project. Invention of the CPM method is generally credited to Morgan Walker of DuPont and James Kelley of Remington Rand. Booz Allen Hamilton’s work on the PERT method at about the same time is also noteworthy because it reinforced the notion that there were better tools than the bar chart.
CPM early adopters used the Gantt chart only after having adapted it as a simplified familiar visual representation. The primary graphic representations, until recently, however, have been the logic network diagram and the time-scaled network diagram.
The evolution of CPM’s underlying algorithms has slowed since the late 1980s, after CPM software moved from the mainframe computing environment to the PC environment. The method itself remains robust and lends itself to great innovations. Dynamic modeling, in-place forensic analysis, sophisticated risk modeling, cost and revenue analysis, and forecasting are some of the available functionalities that are not possible when using other methods. This article examines how dynamic modeling concepts could be applied to activity durations, relationships, and constraints to add value to a CPM schedule.
Dynamic Modeling
Durations
Single-point activity duration values (six days) do not fully capture the important thinking, discussion, analysis, and collaboration that led to that value. The uncertainty associated with that forecast is lost, too. (Is it very, very likely to be six days, or is it probably six days but quite possibly 12 days?) It also fails to maintain the intended flexibility in progressing an activity’s duration.
Such generalization hinders planners and scheduling professionals who are trying to accurately retrace the intended methods of task execution, progress activities, or simply test a plan’s sensitivity to changes. Allowing activities to retain a “proposed” duration value, the mechanism to track pacing, and an accurate method to reflect intended rate of progress, however complex, as a function of the scope of work to be done and not the resources used, can be accomplished by augmenting CPM algorithms. Such augmentation tends to be rare, though, and “home grown” rather than developed, using industry standard protocols.
Relationships
Relationships or dependencies represent a frequently overlooked component of the basic CPM trio of elements (tasks or activities, durations, and relationships). Traditionally, they are treated as static links between tasks with no behavior, attributes, or properties of their own. That is, of course, a gross over-simplification. In order to attain real-life dynamic modeling of projects, such relationships need to exhibit more depth and knowledge and be assigned various important attributes. Examples of such attributes include the following:
Relationship Calendar -- While most dependencies carry the same calendar properties of either the successor or predecessor task, there are times when the relationship itself requires its own calendar, which may be different from either the predecessor or successor task.
Relationship Type -- Start-to-start (SS) or finish-to-finish (FF) relationship types with a single, static time-based duration are insufficient, if not unrealistic. In real-life, an SS or FF lag is often a function of the remaining duration or the percent complete of the predecessor activity and sometimes even events that are occurring elsewhere in the schedule, not on this activity’s chain.
Lag Type -- As indicated above, a single static lag duration, where a static lag is needed to model the relationship, may not be sufficient. Where the lag is neither a function of a portion of the predecessor task being completed nor a function of the remaining portion of work of the predecessor task, a minimum and a maximum lag value might be required.
Relationship Dynamic Constraint -- Often, dynamic task constraints are too broad. Just-in-time (JIT or ALAP) and as-soon-as-possible (ASAP) constraints, when applied to a task, may affect several relationships and tasks at once. Applying a JIT or ASAP constraint to a single relationship will affect only a single predecessor and a single successor and thus miss affecting other activities.
Dynamic Alternate Relationship -- Often, real-world modeling requires conditional relationships. A task may have one of two possible successors, depending on various factors, such as the time of year the task finishes, how long a task actually took, the type and number of resources used, and so forth.
Relationship Attributes -- Schedule calculations may take into account several relationship attributes. A relationship may be added forensically and designated accordingly, to be taken into consideration only if a forensic relationship calculation option is chosen. Similarly, a relationship may be deemed a “resource” relationship that some calculation options would not consider. Several other attributes may be added to a relationship.
Relationship Float -- Calculated task floats are not sufficient to allow a scheduling professional to make informed decisions about how a task is linked to other tasks. Each relationship must retain its own set of applicable floats. Non-critical but significant sequences often are missed in schedule analysis as the result of not exposing relative relationship floats.
Dynamic Planning -- Scheduling professionals often find themselves statically constraining a task so as to model it in the context of another task/s. An example of dynamic planning is the ability to dynamically model that a task only be mutually exclusive of another task or a group of tasks. In such modeling mode, it would not matter which starts first as long as they are not performed at the same time or perhaps get done by a certain date. “Pinning” and milestones can be used to accomplish this but do not convey the underlying rationale.
Constraints
We believe that, contrary to the prevailing tendencies, constraints are not necessarily bad. They are an important component of modeling contractual obligations and rights as well as contractor means and methods. Their overuse, due to lack of other modeling tools, definitely can be a problem and has caused a recoil to all uses of constraints.
Contractual Constraints -- Most contracts specify hard dates for certain milestones, events, or other considerations. A schedule that does not reflect such contractual constraints would be unresponsive. An activity constraint should allow an attribute to designate a constraint contractual and provide for the contractual reference. Early completion schedules are a related issue.
Enforced Constraint -- While it is likely that every contractual constraint should be enforced, some non-contractual constraints may also require the “enforce” attribute. Procurement, subcontracting, and means and methods preferences are examples. CPM calculations can be performed to include or exclude constraints with different attributes for comprehensive schedule analysis.
Expanded Constraint Types -- Until recently, available constraints were woefully lacking, forcing schedulers to impose static constraints and/or add artificial relationships in their attempts to model the work. Accurate modeling often would require that a specific task be started on a given day of the week or that a task or a group of tasks be completed within a given number of days from being started (scheduling such tasks within a total duration that consumes the entire number of days may be incorrect or not feasible due to discontinuity of the group of tasks). Furthermore, an activity may be mutually exclusive of another activity or group of activities without necessarily requiring artificial dependencies to model the work.
A schedule is a planner’s representation of how he or she intends to perform work. The issues we have raised in this article are, of course, important to some schedulers, depending on many factors. Most such factors, some of which we identified and discussed earlier, are often overlooked by CPM software developers, much to the detriment of the planner. Our hope is that this and future articles of this kind will help bridge the gap between those parties.
Editor’s Note: Ibbs and Saddik intend to implement some of these concepts in RevelPoint LLC's scheduling software product.
Prof. William Ibbs is the group leader of the Construction Management program in the Civil Engineering Department at the University of California at Berkeley. He teaches courses in construction management, including scheduling, labor productivity analysis, cost accounting, and project management. He earned his Ph.D. from U.C. Berkeley in civil engineering with a construction management emphasis.
Farid Saddik has more than 29 years of experience in domestic and international project management and project controls. He has a strong management, technical, and engineering background. He is an MIEAust, CPEng. and has a B.Sc. Mechanical Engineering and M.Sc., Systems Engineering.
