Common Barriers to a Valid Critical Path
As noted above, the critical path ideally represents the longest path, as when the schedule network is free of backward-pass constraints and activities on this path have the least float in the network. In this section, we highlight issues that prevent the critical path from being the longest path. When these issues arise, it is imperative that management recognize not only critical path activities—that is, activities with the lowest total float—but also activities that are truly driving the finish date of key milestones.
Calculating a critical path is directly related to the logical sequencing of activities. Missing or convoluted logic and artificial date constraints prevent the calculation of a valid critical path; they can cause activities that are not critical to appear to be critical.
Successfully identifying the critical path relies on a valid, reliable schedule. This includes capturing all activities (Best Practice 1), proper sequencing of activities (Best Practice 2), horizontal traceability (Best Practice 5), the reasonableness of float (Best Practice 7), accurate status updates (Best Practice 9), and—if there are resource limitations—assigning resources (Best Practice 3).
It is essential that the critical path be evaluated before the schedule is baselined and after every status update to ensure that it is valid. If the schedule is missing activities, then the critical path will not be valid. Moreover, if the critical path is missing dependencies or has date constraints, lags, or LOE activities or it is not a continuous path from the current status date to the finish milestone, then it is not valid.
Continuous through All Activities
Unless the IMS represents the entire scope of effort, the scheduling software will report an incorrect or invalid critical path. As discussed in Best Practice 1 and Best Practice 4, the IMS must include planning for all activities that have to be accomplished in the program. A critical path for one block, increment, or contract for a multiyear multiphased program is not a sufficient plan that can reliably forecast the finish date for the program. A critical path should exist for the entire program because detail activities, as well as long-term planning packages, must be logically linked within the schedule to create a complete picture of the program from start to finish. In addition, for projects under way, the lo gest path or critical path should start with at least one in-progress activity that has an actual start date.25
The critical path should be a continuous sequence of activities from the schedule status date to the finish milestone. In general, the sequence of activities should have no breaks and no large gaps of unaccounted time. The critical path may branch off into several sequences of activities, but they must ultimately converge at the finish milestone. Sorting the schedule by activity start date, filtering by critical activities, and visually assessing the sequence of activities in a Gantt chart is an easy way to assess the practicality of the calculated critical path. Ideally, the Gantt chart displays a continuous waterfall of activities from the status date to the program finish date that are logically linked with finish-to-start relationships. Case study 11 shows why program-wide critical paths are important.
Officials from FAA’s Collaborative Air Traffic Management Technologies system said that because of its 6-month spiral development, the program schedule could not deliver a single critical path for the entire program. Instead, it had critical paths by release. To produce the critical paths, the prime contractor used a constraint on the key deliverable finish milestone for each release.
At the time of GAO’s analysis, officials stated that only work related to Release 5 was subject to a critical path analysis because that release was management’s current focus. GAO was able to trace a continuous critical path for Release 5, beginning with the project status date and ending with the Release 5 finish milestone.
However, the validity of the Release 5 critical path was hampered by seven in-progress and remaining detail activities within Release 5 that had over 1,300 working days of total float. GAO also determined that a small number of activities outside Release 5 were under way (for example, activities related to other task orders). Because these activities fell outside the Release 5 task order, and therefore outside the purview of a Release 5 critical path analysis, management may not have been fully aware of the effect of any delay in these activities.Breaks in the critical path should be examined immediately and justified or otherwise addressed. Common causes of noncontinuous critical paths are that
the start or finish date of an activity is driven by a constraint;
a successor activity is driven by an unexplained lag;
the start date of an activity is driven by an external predecessor;
activities are scheduled according to different calendars, as when a predecessor activity ends in a nonworking period for the successor; and
resource leveling is causing delays.
For example, if an activity on the critical path starts some days or weeks after its driving predecessor finishes (assuming finish-to-start logic) because of a start date constraint or an unexplained lag, then the path is considered to be noncontinuous and broken. In each scenario above, additional total float may occur in the predecessor activities; it would break the sequence of activities with zero total float. The program management team must determine whether this additional total float is meaningful. If they decide that it is not, the threshold for total float criticality may have to be raised.
Noncontinuous critical paths are often caused by the use of multiple calendars. Once multiple calendars are introduced into a schedule network, total float calculations may be adversely affected. In the sequence of activities in figure 32, all activities and resources are assigned standard 5-day workweek calendars except “install footing and pier rebar.”
The installation activity is assigned a 7-day workweek calendar as well as resources that can work on Saturdays and Sundays. Because Sunday is a valid workday for this activity, it has one day of total float available: its early start is Saturday, September 20, and its late start is Sunday, September 21. However, its successor, “inspect footing and pier rebar,” can occur only on Monday through Friday, so its early and late start dates are Monday, September 22. The critical path (red activities), as defined by total float, is discontinuous at the weekend.
Figure 32: The Effect of Multiple Calendars on the Critical Path
Figure 32 is a simple instance that can quickly become more complex. For example, if “lay out and form footings and pier pads” is also assigned a 7-day workweek and 7-day resources, as a predecessor to “install footing and pier rebar,” it too gains a day of total float.
As we noted in Best Practice 4, while the use of multiple calendars allows for greater insight into resource availability and precision of forecasted start and finish dates, their use must be tempered with their possibly negative effect on the critical path. The threshold for total float criticality may need to be raised to capture the entire critical path, which in turn complicates the tracking of near-critical paths. Because the longest path makes no reference to total float, it is the only guaranteed method of identifying the driving sequence of activities when using multiple calendars. But when the longest path is not easily traceable, schedulers may opt to simplify the network by avoiding multiple calendars, especially if very few activities need a slightly different calendar.
The Number of Critical Activities
In general, assessing the quality of the critical path by predetermining the number of activities that should be critical is not useful. The number of activities on the critical path depends on the visibility required to manage the program and reduce risk. However, if the ratio of critical path activities to the total remaining activity count is nearly 100 percent, then the schedule may be overly serial and resource limited. Conversely, if only a few activities are on the critical path and if all represent LOE, then the critical path is being driven by supporting effort and will not identify effort that is driving key milestones.
Logical Sequencing
Float calculations are directly related to the logical sequencing of events (see Best Practice 7). Because float dictates the criticality of activities, the critical path is directly related to the logical sequencing of events and float calculations. If activities are missing dependencies, linked incorrectly, or performed out of sequence, float estimates will be miscalculated. Incorrect float estimates will result in an invalid critical path, hindering management’s ability to reallocate resources from noncritical activities to those that must be completed on time. Errors or incomplete logic often cause values of total float that do not represent the state of the program schedule (we discuss the effect of dependencies on total float in Best Practice 7 and describe out-of-sequence progress in Best Practice 9).
Date Constraints
We saw in Best Practice 2 that placing a hard constraint on an activity fixes the dates and immediately causes the activity to become critical. It is therefore possible to use hard constraints as a working tool while developing a schedule to calculate total available float up to key milestones. The temporary use of hard constraints is also valuable for assessing the likelihood that using available resources can achieve the planned activity date. However, using hard constraints simply to fix activity dates at certain points in time immediately convolutes critical path calculations. It also reduces the credibility of any schedule date on activities that logically occur after the hard constraint. In this case, the critical path is no longer the longest path; instead, each hard constraint in the schedule generates its own sequence of critical activities, and the purpose of CPM scheduling is defeated.
Lags
The critical path should be free of lags because they obfuscate the identification and management of critical activities. As described in Best Practice 2, a lag is used in a schedule to denote the passing of time between two activities. Lags cannot represent work and cannot be assigned resources. Lags simply delay the successor activity, and no effort or resources are associated with them.
Lags are often misused to force successor activities to begin on specific dates. Evaluating a critical path that includes lags can therefore be difficult because the lag may or may not represent work that has to be accomplished by some resource, either internal or external to the program. In addition, because lags are not represented in a schedule as an activity, they can easily be overlooked as drivers of the finish milestone date. A lag that indicates a waiting period, such as for document review or materials delivery, should be replaced with an activity that can be actively monitored, statused, and perhaps mitigated if necessary.
In figure 33, “inspect rough-in HVAC” now has a 2-day lag on its finish-to-start relationship to the activity “install interior vapor barrier,” representing 2 days of paperwork that the general contractor’s company must perform. The total duration of “inspect rough-in HVAC,” including its lag, is 3 days. The activity becomes critical because the 2-day lag consumes its 2 days of total float. A report to the general contractor listing the current critical activities in the project would list “inspect rough-in HVAC” as critical but would more than likely fail to mention that its successor lag is causing it to be on the critical path, not the inspection activity itself. Any management initiatives by the general contractor to reduce the criticality of the inspection activity would fail, because the initiatives would be misdirected. The planned effort that is causing the criticality is concealed by the lag.
Figure 33: The Critical Path and Lags
Level-of-Effort and Other Long-Duration Activities
We learned in Best Practice 1 that some schedulers represent LOE work by activities that have estimated durations rather than by hammock activities, the preferred practice. Their long durations mean that these activities may inadvertently define the length of a project and, thus, become critical if they are linked to successors through logic. A critical path cannot include LOE activities because, by their very nature, they do not represent discrete effort. The duration of LOE activities is determined by the overall duration of the discrete work they support. Therefore, an LOE activity cannot drive any successor and become critical. The logic should be placed on the detailed activities that the LOE resources support.
In the house construction framing example in figure 34, we see an overarching general contractor project management activity planned through November 12 to ensure that all framing activities are managed properly and all documentation is created and filed appropriately. However, the LOE project management activity now determines the minimum duration of the framing sequence of activities, rather than the sequence of actual work that has to be accomplished to complete framing. It is impossible to reduce the duration of framing by adding resources: adding resources to a level-of-effort activity simply increases the work. Using this schedule, management has no indication of which activities can slip and which will respond positively to additional resources and reduce the risk of finishing late.
Figure 34: An Incorrect Critical Path with Level-of-Effort Activities
Long-duration non-LOE activities in the detail planning period should be reevaluated to determine if they can be broken down into more manageable pieces, particularly if they appear on the critical path. If work is broken into smaller pieces, some portions of it might be able to start earlier or in parallel with other portions or might be reassigned to other available resources, saving time and possibly moving the activity off the critical path. In particular, summary activities should never be on the critical path. As described in Best Practice 2, linking summary activities obfuscates the logic of the schedule. Tracing logic through summary links does not impart to management the sequence in which lower-level activities should be carried out. If a summary activity becomes critical, there is no way to determine which subactivities are critical and which are not.
Predetermined Critical Activities
Finally, because all activities can become critical under some circumstances, intermediate and summary-level schedules should derive their critical paths from detailed schedules while recognizing that this will not be as informative as the full critical path. For example, separate summary schedules should not be created by selectively choosing lower-level milestones and detail activities that management has determined are important to monitor. Activities may be important in terms of cost or scope, but there is little guarantee that hand-picked activities will determine the finish milestone date as the program progresses. By only reporting on or monitoring the progress of favorite activities, management risks losing sight of previously unimportant activities that may now be driving the program’s finish date (see case study 12).
The U.S. Citizenship and Immigration Services (USCIS) Transformation Program schedule consisted of 18 individual project schedules. To provide an alternative to an IMS and to ease reporting to the Acquisition Review Board and other senior officials, the Transformation Program Office (TPO) developed a high-level tracking tool summarizing dates and activities for the first release of the program based on individual schedules such as the Office of Information Technology and solutions architect schedule, which TPO did not directly manage. TPO used this tool to ensure the coordination and alignment of activities by collaborating with staff responsible for managing individual schedules.
However, this tracking tool was not an IMS because it did not integrate all activities necessary to meet the milestones for Release A. Rather, it was a selection of key activities drawn from the individual schedules that USCIS components and the solutions architect maintained. Moreover, the Transformation Program Manager expressed concern in a May 2011 program management review that the information reported in the high-level tracking tool was not being reported in the individual schedules. In addition, this tracking tool was not an IMS because it did not show activities over the life of the program. That is, it had no dates or activities for the four other releases’ set of work activities or information on how long they would take and how they were related to one another.
As a result, program officials would have difficulty predicting, with any degree of confidence, how long completing all five releases of the Transformation Program would take. Program officials would also have difficulty managing and measuring progress in executing the work needed to deliver the program, thus increasing the risk of cost, schedule, and performance shortfalls. Last, USCIS would be hindered in accurately communicating the status of Transformation Program efforts to employees, the Congress, and the public.
In addition, neither of the two underlying schedules that GAO assessed had a valid critical path. The USCIS Office of Information Technology schedule had missing or dangling logic on over 60 percent of its remaining activities. The solutions architect’s schedule was missing logic in 40 percent of its remaining activities and contained excessive constraints, lags, and dangling logic.As noted in Best Practice 9, in principle, a critical activity could be scheduled to start the next day after a status update. It would therefore not be in progress at that time, although it would be scheduled to start as soon as possible.↩︎