Construction Management Association of America

The 2002 Unified Facilities Guide Specification for Network Analysis Systems (“UFGS”) has been adopted by the U.S. Corps of Engineers, U.S. Air Force and the U.S. Navy. This Guide Specification confronts many of the issues identified in Parts One and Two of this series of articles addressing the drafting of scheduling specifications. These issues include the types of reports required during performance to address owner requirements, issues relative to pitfalls and abuses of scheduling software and network analysis logic, and issues relative to nature of float, major project revisions and the calculation of project delays.

In this article, we will work from the April 2002 version of the UFGS, since it sets out separately the requirements for a design/bid/build type procurement, which was the focus of Parts One and Two of this series. Due to space limitations, we have limited the amount of direct citations from the UFGS. However, the complete April 2002 Guide Specification and a more complete version of the article, with appropriate excerpts from the UFGS, can be found on the CMAA’s website at: ____________________. In addition, a February 2003 version of the Guide Specification, which combines both design build provisions with design/bid/build provisions, can be found at http://www.ccb.org/ufgs/ufgs.htm.

We will first examine the manner by which the April 2002 UFGS addresses necessary elements of scheduling specifications. Second, we examine the means by which the specification deals with diagramming/software abuses as well as with the potential conflict of precedence (activity on node) versus arrow (activity on arrow) diagramming methods to assure good quality schedules. Third, we will address the manner by which the specification deals with float, major project revisions and calculation of project delays. Finally, we will provide our assessment of whether the UFGS adequately addresses the issues we have previously discussed in Parts One and Two of this series.

In Part One of this series, we identified the following items as necessary elements for consideration in preparing a Schedule Specification: 1. feasibility of specified schedule; 2. type of diagram; 3. number of activities; 4. resource loading; 5. approval; 6. control of the record schedule; 7. updating; 8. cost loading; 9. subcontractor involvement; 10. float use and reporting; 11. major revisions and time extensions, and 12. prohibitions on schedule manipulations.

We also identified in Part Two of this series the typical areas of conflict arising from scheduling specification: 1. reasonableness of the schedule; 2. approval/non approval issue; 3. approval standoff; 4. failure to require initial and continuing involvement of major trade contractors; 5. vague and defective updating procedures and need for joint updates; 6. definitive procedures for approval and incorporation of logic revisions; 7. failure to provide for definite baseline and methodology for approval and incorporation of time extensions, and 8. submission of early completion schedules.

We will now review the UFGS Specification within the context of these issues and concerns.

Section 1.1 of the UFGS requires the preparation of a schedule on the basis of a network analysis system. This system is to include a network analysis schedule (diagram), a mathematical analysis and associated reports. (We immediately know when we are talking about a diagram that we are not referring to a mere bar chart without logic ties.) This section further provides that scheduling is the responsibility of the contractor not the government and provides that the submission of progress data will be used to assess progress, evaluate payment and time extension requests. Critical Path Method of network calculation will be used to generate the schedule and the precedence diagram technique is to be used to satisfy time and cost applications, with the schedule being cost-loaded for payment purposes. The reference to critical path calculation means that the forward and backward pass for finding the critical path is clearly required. Further, although this section of the specification refers to the use of precedence diagram technique we will see that the UFGS specification greatly limits the use of precedence type relationships [such as start to start or finish to finish or leads and lags with the attendant need for careful vigilance] where traditional predecessor successor relationships [finish to start] can be used.

Section 1.3 of the specifications confirms that the schedule submission requires acceptance but that the contractor remains responsible for scheduling and prosecuting the work. The government notes that its acceptance only extends to activities for which the government is responsible. Subsection 1.3.1 confirms that the accepted network analysis system is required before the contractor will be allowed to start work. Subsection 1.3.2 details the fact that once the network analysis schedule has been accepted, it becomes the baseline schedule for planning, executing and reporting the work. The submission of monthly updates constitutes a representation that the schedule meets all contract requirements and accurately reflects the work accomplished and that the work will be executed in the sequence indicated on the submitted schedule. Section 1.4 calls for the use of Primavera software or software convertible to Primavera readable format. However, as we will see from the later section on activity properties, some of the user features of Primavera are severely restricted. Section 1.5 requires an experienced scheduler be provided at a level commensurate with the nature of the project. If one is not provided, progress payments will not be processed.

B. Prohibitions Against Software Abuses and Precedence Vs. Arrow Diagramming

Section 1.6, “Network System Format,” and its subsections are some of the most important provisions of the specification. These provisions make it clear that the Corps, Navy and Air Force want real time scaled logic diagrams with well defined activity logic, not bar chart reports. Further, the specifications make it clear that short cut logic will not be allowed. Although the specifications earlier noted that precedence diagramming would be used, here the government requires that activities, wherever possible, have predecessor and successor ties – looking therefore for finish to start relationships and avoiding open ends. Moreover, as will be seen from an examination of later activity properties, we see that the government prohibits manipulations such as constraints, improper updating, incorrect calendars, etc.

Section 1.6 thus requires a time scaled logic diagram and mathematical analyses. Subsection 1.6.1 specifies the diagram and makes it clear that finish to start relationships are desired by the language: “the basic concept of a network analysis diagram will be followed to show how the start of a given activity is dependent on the completion of preceding activities and how its completion restricts or restrains the start of following activities.” This section also addresses the required reports as well as limitations on the duration of activities. By requiring that logic ties move from right to left only, the UFGS effectively prohibits the use of logic such as negative lags.

Subsection 1.6.2 covers the quantity and numbering of activities. Here the specification calls for the use, in general, of higher numbers for successor activities than predecessors. 1.6.2.2 requires that procurement activities be included as separate activities and 1.6.2.3 requires that government activities that could impact progress shall be identified in the network. Section 1.6.2.4 requires that contractor activities be based on a calendar where Saturday, Sundays and federal holidays are shown as non-work days. 1.6.2.5 covers the requirement for taking into account normal weather delays and requires that the number of allocated weather delays be reflected in the activity’s calendar.

Subsection 1.6.2.6, entitled “Activity Properties,” contains provisions extremely important to assuring the validity and integrity of the network schedule. These include subsections a. through x. and cover such key requirements as: a standard activity coding dictionary; activity description; work phase; work category; area code; responsibility code; CSI code; drawing code; modification code; REA (request for equitable adjustment) or claim code; project milestone dates; scheduled project duration; project start date milestones; constraint of last activity milestone; early completion milestone, and substantial completion milestone. Most significantly, Section 1.6.2.6 sets forth specific provisions in subsections v., w., and x., which specifically call for the use of activities rather than shortcut diagramming techniques. These provisions also prohibit poor scheduling or potential abuses such as incorrect use of leads and lags or incorrect logic or incorrect updating (e.g. specification prohibits the use of automatically updating procedures and requires that activities be updated by actual work progress rather than being cash flow driven).

Subsection 1.6.3 covers the requirement for mathematical analysis for each activity in the network including total float, manpower required, early start, early finish, late start, late finish, actual starts, actual finishes, etc. Subsection 1.6.4 provides for additional information to track on site manpower loading and equipment loading. Section 1.6.5, “Required Reports,” contains provisions to ensure that the government has real visibility as to what is happening on the project, including identification of logic relationships and changes in schedule logic from month to month. This provision includes requirements for a monthly disk and reports detailing activities by preceding event number, by amount of total float, by latest allowable start dates, by earned value report for all activities, by early start dates and by 30 day look ahead.

Sub-subsections 1.6.5 g., h., i., and j. contain specific requirements for a schedule comparison listing all changes made between the previous and current updated schedules, including changes for added and deleted activities, original durations, remaining durations, activity percent complete, total float, free float, calendars, constraints added or deleted, actual starts/finishes, resource information, changed relation lags, changed critical status. There are also requirements for a predecessor/successor report and manpower and equipment staffing reports and histograms.

Section 1.7 covers “Submission and Acceptance” of the schedule. Of significance here is the requirement for a schedule development session attended not only by the government but also major subcontractors. Further time cycles are called out for the submission and review process. Section 1.7.7, “Monthly Network Analysis Updates,” covers the preparation of the monthly updates and requires joint updating meetings to develop an accurate picture of construction progress and predictions of completion dates based on current status. Further, submission of an error free acceptable update is a condition precedent to processing the Contractor’s pay request. Section 1.7.8 covers the requirement for a summary network and Section 1.7.9 requires the preparation of an accurate as built schedule prior to the release of retention, including accurate logic ties as well as actual starts and finishes of activities.

Section 1.8 details the requirements for “Contract Modification.” Proposed revisions to the schedule must be submitted with a fragnet and cost proposal –no reservation of rights is allowed. All modifications require separately identifiable activities and are inserted into the network in the first update following notice to proceed. This provision further requires submission of the total float report and proposed time impact analysis on a disk to establish the change. Unless allowed by the government, only confirmed modification fragnets will be added to later monthly updates.

Subsection 1.8.1 covers the requirement for a “Time Impact Analysis” to justify extensions of time and to illustrate the effect of the change or delay on the completion dates. The specification requires the use of the current monthly schedule accepted by the government to display the impact of the change. This leads to several questions. For example, in considering a delay purported to occur in the May of 2002, which is not evaluated (for what ever reason) until November 2002, which update will be used to incorporate the time impact analysis? As we will see, this question becomes more interesting when we get to Section 1.11, “Time Extensions,” which calls for granting time only in circumstances where a given matter actually delays the project. Section 1.11 also requires that the purported delay must affect the contract completion dates on the CPM network at the time of the delay.

As noted, Subsection 1.8.2 provides for no reservation of rights for direct or indirect costs on modifications. Section 1.9, “Changes to the Network Analysis Schedule,” requires submissions to the government where the contractor wants to make major changes in logic and particularly where the contractor is trying to shorten the schedule.

Section 1.10 and its subsections cover the topic of float and are some of the most important provisions in the entire specification. First, in Section 1.10 the specification prohibits the use of potential gaming techniques, including the use of float suppression techniques; preferential sequencing; special lead/lag logic relationships; constraints to force dates and interrupt the math of the network; unreasonable resource leveling to manipulate float; extended activity times to remove float.

Subsection 1.10.2, “Ownership of Float,” clearly indicates that float is a shared resource available to both parties. In addition, this specification deals with the issue of early completion schedules, identifying the time for the early completion to the contract completion date as float and specifying that no time or delay damages will be granted unless a delay extends the project beyond the contract completion date. Subsection 1.10.3, “Negative Float,” provides that negative float by itself will not be grounds for requesting time extensions. This is entirely logical. When a project goes negative the critical path does not end; rather, one needs to look for the path with the greatest amount of negative float to find the critical path.

Section 1.11, “Time Extensions,” details the need for the time impact analysis, total float report, etc. to demonstrate that the critical path is actually affected utilizing the dates shown on the CPM network at the time of the delay. This provision would appear, thus, to require chronological and cumulative analyses of the updates to determine the effect of the delay and to also make certain (probably by looking both at the updates at the beginning of a period and what happened during the update) that purported delays actually delayed the critical path. Finally, Sections 11.12, 11.13, 11.14 and 11.15 cover requirements for meetings, reports and correspondence.

The UFGS does a good job covering the items that were addressed in Part One of this series concerning the necessary elements of a scheduling specification. Perhaps one area requiring attention is the control of the record schedule. It is certainly undesirable for an owner to have the contractor running unapproved schedules or unapproved updates. However, this would appear to be addressed by the requirement for the joint updating meeting, the requirement that actual starts and finishes be based only on the Contractor Quality Control and Production Reports, and by the ability to withhold payments. The specification could also more clearly state that the government has the right to request electronic versions of all schedule data; not only the schedules regularly submitted to the government, but also the right to electronic versions of all backup calculations relating to the submitted schedules.

The UFGS also successfully deals with the typical areas of conflict discussed in Part Two of this series. The specification addresses the unreasonable schedule through the review process and addresses the approval standoff through the requirement that the project not start without approval (as well as power of the purse). It also specifies clear updating procedures, requires joint meetings to update the schedule, and provides a protocol for logic revisions. Importantly, the UFGS prohibits a litany of devices to game play the schedule using current software features, provides for a baseline and methodology for incorporating logic revisions and time extension and addresses early completion schedules in a very successful way through float definitions. The one area which perhaps could be clearer is the protocol for time impact analyses and time extensions. What appears to be the standard in the specification is the use of the updates for the time period in question. The specification appears to call for evaluating updates both at the beginning and end of the period to confirm the location of the critical path and to see indeed whether the issue presented was on the critical path and actually delayed contract completion dates.

In summary, the April 2000 UFGS is a well thought out, detailed specification. Because of its length (26 pages) and detail, however, use of a similar specification in private contracts may not always be economically feasible. Nevertheless, at the very least, the UFGS is an important reference point for parties faced with the task of drafting an appropriate schedule specification for their project.

* Jon M. Wickwire and Mark J. Groff are shareholders in the national construction law firm of Wickwire Gavin, P.C., with offices in Vienna, Virginia; Madison, Wisconsin; and Los Angeles, California. They can be reached at (703) 790-8750 or via email at jwickwire@wickwire.com and mgroff@wickwire.com.