Ethics in scheduling

Jon Wickwire, Wickwire Gavin, P.C., (703) 790-8750

Introduction

There is a dearth of good schedules on projects today. A history of the problem and many of the causes were identified in our earlier paper (Ockman & Wickwire 1999). Let's look at what can, in fact, what must be done to reverse this trend.

Ethics is “the discipline dealing with what is good and bad or right and wrong” [Webster's Third New International Dictionary]. What makes a schedule a good schedule or a bad schedule? Is there a right way to schedule a project? What about a wrong way? Industry invests enormous resources in planning projects and monitoring progress against the plan. Yet, an initial plan, or even a schedule update, issued with just one mistake runs the very real risk of the schedule being ignored (or used only as a vehicle for collecting progress payments) by project personnel from that point forward. Therefore, industry has a very real interest in producing perfect schedules that accurately model the project team's plan and accurately predict the project's completion, not only at the beginning of the project, but at every monthly (or more frequent) update.

Armed with accurate scope definition, resource availability data, and productivity rates; the choice between producing a good schedule or a bad schedule is in the hands of the scheduler. In fact, the rules for producing a good schedule are straightforward and can be counted on your fingers: (1) develop a work breakdown structure breaking the project down to the task level (one level below the activity level) to identify all activities at the appropriate level of detail, (2) assign activity duration estimates based on ideal staffing levels or crew sizes for optimum productivity, (3) identify appropriate logic ties to reflect the planned sequence of work, (4) dump the activity descriptions, duration estimates and logic ties into a scheduling program together with the project start date and project calendar and push a button, (5) compare the calculated project completion date to the desired completion date, and make any needed adjustments, (6) input accurate actual start and finish dates and remaining duration estimates for each schedule update. And, you're done.

It really should be that simple. But, it's not. There are opportunities for doing it wrong at every step. And too many schedulers today don't just stumble on a step but fall down the staircase. How can we do it right? It's easy to identify the steps, but not so easy to perform them. It's hard to use a work breakdown structure to identify activities if you don't know what one is. It's also hard to input accurate actual dates (or any dates at all) for each update if you don't understand the importance of maintaining a record of actual performance. There are other issues that complicate matters even further; multiple calendars and user-assigned constraints, leads and lags, sorting and selection criteria, activity coding and report selection. And, we're not even talking about resource and cost loading or resource levelling yet.

There are a lot of ways to attack this problem: better training, less options (read fewer pitfalls), software wizards and expert audit features, licensing of certified project schedulers (like the licensing of CPA's) in industries or projects where producing “right” schedules is deemed to be in the public interest. Right now the cost to the public is enormous, with schedule related disputes easily in the hundreds of millions of dollars or more annually.

This paper will discuss the role of the scheduler, the software developer, the litigator and the expert witness in moving from bad to good schedules.

The Role of the Scheduler

If archaeologists in the year 3501 unearthed a variety of schedule reports from the 1990's, they would likely conclude that the state of the art for scheduling in that era was a bar chart schedule depicting a flawed plan. Digging further and finding a stack of schedule updates, the archaeologists are almost sure to discover schedules with inaccurate remaining duration estimates and wrong actual start and finish dates, if there had been any actual progress recorded at all. Why are we leaving this legacy for the future, and what should the schedules of our era really look like? What is the role of the scheduler?

It should be clear that the scheduler today must be more than a computer jockey who manipulates a database to produce a nice-looking bar chart schedule once a month. The ideal scheduler is a consummate professional who understands scheduling theory: topological ordering; the forward and backward pass; the concept of float; the computerized tools available for sorting, selecting and summarizing; effectively using resource tracking and/or resource levelling; exception reporting; earned value; providing timely information to top management; initiating change orders for delay; etc.

The scheduler's first responsibility is to develop a reasonable, accurate plan. It helps if the scheduler has the technical expertise to understand the project and how the various components interrelate. This expertise aids in achieving a consistent and proper level of activity detail (work breakdown structure) and accurate logic ties. It is also useful to have experience in estimating so that one is familiar with productivity rates and optimal crew sizes for performing the work. This experience leads to schedules with reasonable activity durations.

However, it is not enough to take one's experience and simply develop a schedule. The current state of the art in scheduling software together with the complexity of many projects virtually assures erroneous logic ties or other data entry errors will find their way into the scheduling database. Thus, a scheduler must perform a quick audit of the initial schedule and each update before distributing the schedule printouts. The audit is important because issuing just one bad schedule can provide an excuse for all project participants to ignore the schedule reports for the rest of the project. Here is a list of some important tests to make sure your schedule is reasonable [Primavera Project Planner (P3) is used to provide specific examples]:

Test 1: Does the critical path make sense and does it meet the contract completion date?

With multiple calendars, the total float/early start sort may not identify the critical path. P3 offers the Longest Path filter to work around this problem. Make sure the critical path is reasonable (both logic-wise and time-wise). Then check the reasonableness of near critical paths (with P3, you may have to make a copy of the schedule and start deleting logic ties so that near critical paths show up when the Longest Path filter is rerun). If the critical path and near critical paths are reasonable, you're off to a good start.

Test 2: Does the early start sort make sense? Are activities shown in the proper sequence?

Do a quick check of the activity sequence in the early start sort. Does roof installation start before erection of building framing? Does commissioning start before the start of equipment installation? These are extreme examples of logic errors; but other, less obvious, problems with network logic will jump out by looking at the sequence of activities to see whether or not it makes sense.

Test 3: Do any activities have too much float?

Run a total float sort and examine the activities with the most float. Activities with too much float may indicate missing logic ties or logic ties that have been overridden by reporting out-of-sequence progress when updating. Add logic ties, if necessary, to insure that float durations are reasonable and correctly model the current plan.

Test 4: Do any activities have planned durations greater than the update cycle?

Ideally, project activities should be planned at a level of detail so that activity durations are equal to or less than the update cycle (with certain project specific exceptions). Thus, if a schedule is being updated monthly, planned durations should be 30 calendar days or less. This means that each activity will be in progress for no more than a single update cycle, unless it is behind schedule. By using shorter activities, remaining duration estimates are both easier to make and more accurate, resulting in better status reports for upper management and the project team.

Test 5: Are there any unnecessarily long gaps in workflow when grouping activities by Work Area and sorting by Early Start/Early Finish?

Take a look at an early start/early finish sort grouped by work area, department or phase to get a feel for workflow and resource requirements. Long gaps in an area or phase may indicate less than ideal workflow requiring adjustment of preferential logic ties to create a better plan. In most cases, once work begins in a particular area or on a particular phase of the project, the schedule should allow work to continue uninterrupted in that area or on that phase until it is complete.

Test 6: Are there activities with unnecessary user-assigned constraints?

Since user-assigned constraints override the network logic in calculating early/late dates and float, they should be used sparingly on a project, if at all. A better approach is to use activity durations and network logic to accurately model the project and eliminate constraints. Consider either (1) printing out a constraints listing or (2) running a filter selecting constrained activities. Once you've identified all the constraints in the network, you can begin removing them.

The above tests are recommended to insure that the plan is accurate and optimised to provide a roadmap to achieving a timely and cost-effective project.

Once you have a reasonable plan, the next step is to use it to monitor progress by performing daily, weekly or monthly updates and reporting the results to management. Utilize the available report options to highlight problem areas and suggest corrective actions. Obtain remaining duration estimates from supervisors in charge of production. Obtain management support to make clear that performance ratings (and continued employment) of supervisors are tied to the ability to perform work as scheduled. Use earned value to insure work is being performed at the rate planned on all cost-loaded schedules. Track and/or level critical resources on resource-driven projects to assure that available resources will support a timely project completion. Identify the impact of changes on the critical path to assist in negotiating equitable adjustments. In P3, make sure the progress override option is selected, and retie activities (whose successors have started out of sequence so that the activities no longer restrain downstream activities) back into the network.

The Role of the Software Developer

For starters, the software developer should be providing the scheduling practitioner with the required tools to perform a proper critical path analysis and to present the schedule to all levels of management. One of these tools, now lacking in at least some software programs, is a total float/early start sort that identifies the critical path (and parallel paths with progressively more float) so that one can follow the network logic and determine the reasonableness of the schedule just by looking at the total float sort. Other tools should be enhanced to allow, for example, the automatic generation of a report that shows all activities with a value of more than 10,000 dollars that have slipped more than five days since the last update, certainly something a scheduler might want to include in a report to management.

The current trend to make software packages easy for the scheduler to use has had the unintended result of making it easy for the scheduler to produce inaccurate schedules. In response to those in the industry who have not yet recognized the ethical problem with today's schedules; one need only ask, “If scheduling is a profession, isn't it unethical for a professional scheduler to produce inaccurate, misleading schedule reports?” It is certainly unethical for a professional engineer to produce an inaccurate design. Why is there a double standard? Could it be that the industry does not value an accurate schedule the way it values an accurate design? While selecting options like retained logic or progress override make it easy for a scheduler to report out-of-sequence progress, using the retained logic option makes it impossible for the scheduler to generate accurate updates while the progress override option makes it too easy to lose a logic tie and have an activity late finish date ‘float away’ to the end of the project.

Another land mine is linking remaining duration and percent complete. This is fine on a project where the remaining duration determines the percent complete (e.g., projects without resource/cost loading). However, on a project where a cost-loaded schedule is used for determining progress payments (i.e., percent complete determines the remaining duration), linking insures inaccurate schedule updates with wrong remaining duration estimates affecting both float calculations and early schedule dates. A good scheduler will get accurate remaining duration estimates from the line managers responsible for completing the activities in progress at each schedule update; yet, far too many schedule updates have inaccurate remaining durations.

The state of the art in software has reached the point where the software developer should be providing tools to insure good schedules instead of pitfalls to make it easy to produce bad ones. The president of Primavera may have had the right idea in 1999 when he suggested P3 Classic, a version of Primavera without the bells and whistles. There was a time, after all, when software packages would not perform scheduling calculations until the scheduler had corrected not only the loops in the network logic but also all of the out-of-sequence logic ties in each update.

In the near future, scheduling software should be providing wizards and audit tools to help even the inexperienced scheduler produce good, accurate schedules. Taking a page from TurboTax, interviews could walk the scheduler through generating a monthly schedule update or even developing an initial project schedule. An audit option could point out potential problems like constraints that override the network logic or out-of-sequence progress creating open ends. The opportunities are limitless, but the industry has to get there.

The Role of the Litigator: Applying CPM Techniques to Contract Claims

The “Classic Technique” which Underlies CPM Analyses of Time Related Claims

With Government specification of the use of network analysis techniques for major projects and the perception by contractors (after a period of initial resistance) that network analysis techniques could be extremely important tools for project management, the use of the critical path method (CPM) to plan and schedule work has become an accepted standard in industry. Further, Boards of Contract Appeals and the Courts have shown their willingness to utilize network analysis techniques to identify delays and disruptions on projects, as well as the causes of delays and disruptions.

The basic technique used in evaluating contract claims with CPM is to compare the as-planned CPM schedule with the as-built CPM schedule. The technique can be summarized in the following five questions:

  1. How was it planned that the project would be implemented?
  2. Was the plan reasonable? If the plan was not reasonable and contains major errors in logic and durations, it must be corrected to remove these errors.
  3. How did the work actually occur?
  4. What are the variances, or differences, between the plan for performance and the actual performance with respect to activities, sequences, durations, manpower, and other resources?
  5. What are the causes of the differences or variances between the reasonable plan and the actual performance?
  6. What are the effects of the variances in sequence, duration, manpower, and so on as they relate to the costs experienced, both by the contractor and the owner for the project?

The Dynamic Nature of CPM - Recognition by Courts, Boards and Major Public Agencies

The critical path through any CPM network is the longest chain or chains of connected activities through the project in terms of time. The great advantage to the critical path network planning technique is that it is not static. The plan reflected by the critical path network (and the critical path itself) will change as work is performed and events occur later or earlier than originally anticipated. The beauty of the CPM process is that it is dynamic and allows the executor of the schedule, at any given point in time, to react to events as they change. Resources (work forces, equipment, time) thus can be applied in a different fashion and still achieve the planned project completion or minimize the effect of delays.

Courts and Boards

The Boards and Courts are fully aware of the dynamic nature of the CPM process. The United States Claims Court, in a landmark decision, Fortec Constructors v. United States (1985), recognized that control of a project, as well as the time extension process, is lost if the parties do not properly update the critical path diagram to properly reflect delays and time extensions.

Recent cases recognize the concept that the critical path can and does change over the life of the project. For example, in Wilner v. United States (1991), the Court found that the critical path had changed when the contractor revised its sequence of work to make up for lost time. The Court noted that reversing the planned sequence of activities was not prohibited by the contract documents.

Santa Fe Engineers, Inc. (1994), provides another excellent example of the sophistication of the Boards and Courts in understanding CPM principles. The discussion by the Armed Services Board of Contract Appeals in this decision makes particular reference to the dynamic nature of the critical path or paths on the project, which can change from month to month.

Summary of Major Issues Arising from the Use of CPM Techniques – 1960's to Present

Since the mid-1960's, the United States Government has specified CPM scheduling for use in connection with procuring major infrastructure projects and systems. This extensive empirical experience has led to legal decisions addressing issues peculiar to the increased visibility arising from the use of CPM network analysis systems. In addition, the last forty years have seen the evolution of computers and software scheduling programming.

While the same basic rules apply to the concept of network analysis systems today as in the 1960's – e.g., the network must always reflect which activities within the connected matrix of the project must:

  • precede, or
  • succeed, or
  • be performed concurrently with other activities

the “bells and whistles” associated with computer programs have increased greatly.

Some of the more significant issues related to the use of network analysis systems in resolving delay claims, which the Courts and Boards have addressed in the last thirty years, have included:

  • Which Party or Parties to the process owns extra time or float?
  • When and how should we measure delay?
  • How do we reconcile the need to grant time extensions on a real time basis (update by update) with the desire to know and prove which events actually delayed the project?
  • What role do resources play in evaluating and granting time extension requests?
  • Who owns additional float created in certain schedule activities during performance as a result of delays?
  • What is the significance of approval by the Owner of the project schedule?
  • How and when can a contractor recover for the inability to complete the project early?

Where We Stand Today – A Summary of Significant Decisions Resolving a Variety of CPM Issues

Over the years, the Courts and Boards have created a body of decisions, which we can analyse for answers to key issues in CPM analysis. Some of the more significant decisions have recognized the following concepts:

  • Critical Path Method networks are the preferred method for analysing delays. Bar charts may be used to establish delay in circumstances where a CPM was not used to execute the project, where costs of the use of a CPM analysis may be prohibitive, and where manifest delays by the Owner were present.
  • CPMs that do not include reasonable resource usage and appropriate logic constraints are unrealistic and do not constitute a basis for evaluating project delays.
  • Float is an expiring resource available to all parties on the project on a non-discriminatory basis who act in good faith.
  • CPMs are dynamic. Things almost never go exactly as planned, and the critical path may change from month to month. When project delays occur which create additional float in the schedule, the contractor is not required to “hurry up and wait” and slavishly follow the original plan for performance.
  • Delays are best evaluated on a chronological and cumulative basis taking into account the status (and critical path[s]) of the project at the time of the delay in question. With this methodology and protocol, all parties on the project live with the events, actions and “sins” of the past.
  • Hypothetical impacted as-planned network delay analyses, which do not take into account actual events on the project as they evolve, are unacceptable measures to evaluate project delays.
  • Time impact analyses and “window” analyses should not only identify the critical path at the time of the inception of the delay, but also take into account the actual duration of all activities on the project as they unfold during the period of delay analysis (update, window, impact period) to clearly establish those activities affecting the critical path.
  • True concurrent critical path delays by an Owner and Contractor entitle both to additional time, but no compensation for delay.
  • Two concurrent delays, which involve one delay by an Owner to the critical path and the second by the Contractor to an activity with float, entitle the Contractor to recovery for both delay damages as well as time extensions. Of course, in a reverse scenario, the Owner would be entitled to a like recovery for delay damages.
  • Early completion claims will be rejected, even in the face of approved schedules, where intent is not matched by capability.

The Role of the Expert Witness

The trier of fact starts out with a clean slate and, by hearing the evidence, attempts to render an equitable decision to resolve a dispute. A scheduling expert's role is to identify the controlling delays and the impact of those delays on the parties. This role can best be accomplished by having the scheduling experts on each side present a single position. Unfortunately, our legal system seldom asks the experts for a unified opinion. And, while an expert almost always has the opportunity to explain why the opposing expert has reached a very different conclusion as to what happened on the project, far too many experts seem content with letting the trier of fact make a decision without hearing this explanation.

First, don't let two ships pass in the night. If both experts think their analysis is right (and, if they are testifying under oath, they'd better), there has to be a problem with the methodology used or a misinterpretation of what happened on the project to account for differing views. Make sure you understand the differences in the approach of each expert and explain why your approach is right and the other wrong, or revise yours to make it right or both.

Second, don't blindly follow the logic in the project schedule and ignore the rule of reason. Recently, an expert testified that the late start of roofing delayed the start of siding on a family housing project at Warren Air Force Base in Wyoming. The expert's testimony was based on seeing that the contractor's schedule showed a plan to start roofing before starting siding but ignored what actually happened in the field. The following pictures helped to demonstrate that the Government's failure to approve prototype siding, and not progress with roofing, was the true controlling delay:

img

The photos on the left show a prototype with siding installed in February 1997 before the roofing work had started (upper) and prototypes with siding and roofing completed in April 1997 which have been awaiting approval to start production units since the middle of the month (lower), while the photos on the right show 12 production units ready for siding in April 1997 (with a thirteenth about a day away) and being delayed by the lack of Government approval.

At another family housing project at Columbus Air Force Base in Mississippi, an expert testified that not a single contemporaneous schedule update showed that slow acceptance of the completed housing units was on the critical path. What the expert failed to point out is that there were no unit-to-unit logic ties between the Government Acceptance activities for each housing unit; and, without these logic ties, it is impossible for acceptance to show up on the critical path since there is no such path (i.e., no chain of Government Acceptance activities) in the schedule network.

The lesson to be learned here is that any schedule must be interpreted in the context of what actually happened on the project. Preferential logic ties represent one option for performing the work but do not limit the contractor from using other options. And conversely, the absence of certain logic restraints does not mean that the missing restraints are not important in evaluating delays. The goal of the expert is to determine, after the fact, what a group of experts on the project at the time of each controlling delay (and knowledgeable project participants as well) would agree were the actual delays to the critical path at those points in the project.

Third, any scheduling expert must use the best methodology, and use it correctly. Scheduling experts should understand the different means of performing a schedule analysis and reject methodologies that do not consistently produce accurate results (e.g., Adjusted As-Planned and Collapsed As-Built approaches). In theory, a good methodology used properly by two experts should produce nearly identical results. It is important to choose a methodology that does a better job of reflecting what really happened on the project than the judgment (or lack thereof) of the expert.

Finally, even if you attend a three-day claims seminar, you do not usually become a scheduling expert overnight. You need experience scheduling a variety of projects so you can see what works and what doesn't work on a real-time basis. Further, it helps to have spent some time working with experienced scheduling experts in evaluating entitlement to time extensions and delay damages to hone your skills.

Conclusion

The good news is that having a lot of room for improvement provides a lot of opportunity to get better. A group of concerned practitioners, software developers, educators and litigators including some of the top people in the industry has joined together in PMI's new College of Scheduling to promote accurate, ethical schedules throughout the world (www.pmicos.org), but we need your help. As a scheduler, insist on the right tools and use those tools to produce good schedules consistently; as a software developer, identify the needed enhancements, prioritise the development effort and roll out the enhancements at an aggressive rate to meet industry needs; as a litigator, work more on the front end to thwart problems before they occur; and as an expert witness, use the rule of reason to provide the trier of fact with a good understanding of the controlling delays on the project and the impact of those delays on the injured party. The future is bright if we can work together to reach it.

References

Ockman & Wickwire, (1990) Construction Scheduling Software – An Industry Crisis, Proceedings of the PMI '99 Seminars & Symposium.

Wickwire & Smith, (1974) The Use of Critical Path Method Techniques in Contract Claims, 7 Pub. Cont. L. J. 1, 21-28.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.