 |
|
||
|
|
|||||||||
|
|
||||||||
|
|||||||||
|
© PMICOS 2002
Privacy Policy
|
 |
 |
|
|
|
Retained Logic - Not the Villain Recent articles and books tend to vilify the use of retained logic in schedule updates (recent ENR article includes retained logic in a chart titled "How PDM schedules are abused"). Many schedulers, however (myself included), have found that it is the best available option - as long as the logic is reviewed and corrected where necessary. An educated, reasoned logic change made by the scheduler should be preferred over an automatic, hidden change made by the software program. Over the last two months, a lively discussion has taken place in the
Forum area on this subject, initiated by Mike Mosley, PE, PMP, from Zachry Construction.
Eleven of the thirteen responses recommended general use of retained logic, but the discussion made points on both sides. A brief explanation and example of the options seems in order. The discussion mostly refers to the option in Primavera (and other software packages) when updating a schedule; whether to retain the logic of partially completed and completed activities, or to override the logic once an activity has started.
 I would submit that neither option gives the "right" answer. The Wall Board activity certainly cannot be completed until the MEP In-wall rough-in is completed. But it is also unlikely that the Wall Board installer intended to begin the activity and then demobilize for a week before continuing its work. The "right" answer depends on how the contractor intends to overlap the two trades, and is probably a compromise of the two - perhaps breaking the Finish-Start relationship and adding a Finish to Finish with a one or two day lag. 
Proper use of Retained LogicThe key to proper use of retained logic is a review of the critical and near-critical paths (more if there is time) during the update process. Immediately after inputting the update data and running the schedule algorithm, the paths should be reviewed for any activity discontinuity or unexplained sequencing. Spotting these inconsistencies obviously requires a degree of judgment by the scheduler, and the schedule adjustments require even more judgment - some logic ties are broken, some modified, and others are retained. This is a sticking point with some owners and construction managers - once a schedule's logic has been approved, some owners are reluctant to allow any changes in logic, especially those that have the potential for affecting the completion date. The use of Progress Override removes the judgment, but also removes the clarity of the thought process behind the original logic. Many times logic is removed automatically that requires significantly more effort (and judgment) to properly reschedule. So, what is the potential for abuse/manipulation due to the use of retained logic, and what standards can be established to restrict (or at least identify) that abuse? The one that comes immediately to mind is requiring identification and justification for each logic change - already a requirement in many contracts (but one that is frequently ignored). This is an area where the COS membership should have significant input in the development of a standard.
Summary:Both Retained Logic and Progress Override can be equally wrong if the scheduler merely accepts what the program spits out. My preference for Retained Logic is based on a reasonable respect for the original logic, but with an understanding that the project and schedule will change from month to month. Any logic changes to the schedule should reflect the work in the field, and should be consciously made by the scheduler, not unconsciously by the program. About the Author: Mark Boe, PE, is a Vice President with Capital Project Management, Inc., a Blue Bell, Pennsylvania construction consulting company specializing in CPM scheduling and claims analysis. Note: This article also appears in the discussion forums, where you are invited to respond to the opinions and ideas in this article.....
|