Project Schedule Assessment Using Best Scheduling Practices

Project scheduling is a key tool used for project planning, efficient execution, reporting and ultimately project claims. A good project schedule provides some confidence in the project plan and the dates for important project milestones. It helps manage resources. Finally, a good critical path method (CPM) schedule is an essential prerequisite to a successful schedule risk analysis.

Project scheduling is a profession that is at its best when the scheduler understands the best scheduling practices recognized by many professional organizations. A good project schedule is a dynamic tool to help plan and execute the project and to forecast completion dates. If the assumptions change the dates are likely to change because the scheduler has represented the plan faithfully in logic and durations, avoiding the use of lags and leads, constraints and incomplete logic leading to dangling activities. The results of the schedule can be found in the quality of the critical or longest path, total float that represents realistically the flexibility of the schedule and statusing of current schedules that is complete.

Unfortunately project scheduling is not an easy skill and many people in the scheduling positions do not have the training, experience or even mindset to produce professional schedules that can be relied upon to represent reality in the project. Some “schedulers” do not understand the difference between dates as inputs or dates as outputs or the meaning of criticality or total float. Unfortunately many schedules are pictures of someone’s desired dates rather than a dynamic tool to determine what dates are feasible given the scope of work (SOW), its complexity, the available resources and their productivity, and the risks that may make it difficult to finish on time.

There are several different approaches to project scheduling best practices. We use the 10-point best practices being developed by the US Government Accountability Office in Washington DC. These best practices were initially introduced in the GAO Cost Estimating and Assessment Guide Best Practices for Developing and Managing Capital Program Costs in 2009 (http://www.gao.gov/products/GAO-09-3SP). The current version has been developed over the last 3 years since that publication by GAO in cooperation with a large number of project management experts. These best practices were also examined by a pro bono group of professional schedulers organized by David Hulett under the auspices of the Project Management Institute’s College of Scheduling (now Scheduling Community of Practice) and including representatives from the AACE and CII.

We assess project schedules of many different US Government projects and programs for GAO. In addition, we use these best practices to assess and improve schedules in preparation for conducting a quantitative project schedule risk analysis using Monte Carlo simulation. The description below summarizes these best practices. There are a few software schedule assessment packages that we use, such as the Primavera Risk Analysis (Pertmaster) Schedule Check Report and Acumen FUSE, as well as reviewing the schedule in the native scheduling software such as Primavera P6, Microsoft Project or Deltek Open Plan.

The 10-Point Scheduling Best Practices criteria we use when assessing schedules are shown below:

• Capturing all activities

  The schedule should reflect all activities (steps, events, outcomes, etc.) as defined in the program’s work breakdown structure (WBS), to include activities to be performed by both the government and its contractors.  In other words, we need to look at the WBS or SOW and compare the work described therein to the schedule, to see if it is reflected in the activities. Generally we do not check all of the SOW but a segment, and evaluate the process by which compliance is ensured.

• Sequencing all activities

  The schedule should be planned so that it can meet program critical dates. To meet this objective, activities need to be logically sequenced in the order that they are to be carried out.
  1. To avoid dangling activity logic each activity’s start date should be driven by a S-S or F-S predecessor, and its finish date should drive a successor by F-S or F-F logic.
  2. Also, the schedule should not rely on constraints such as start-not-earlier-than (SNET) or must-finish-on some calendar date. There are some legitimate date-driven events that must be taken into account, but many constraints are placed to keep the schedule dates from changing. In other words, the dates are inputs not outputs of the scheduling exercise.
  3. Lags should be used only where appropriate. Lags are used only to represent a duration between activities that must happen, takes a specific duration under all circumstances and does not represent work nor takes resources. The standard explanation of a proper lag is watching concrete cure.  Leads are to be avoided.
  4. Summary or level-of-effort (LOE) activities should not drive the project schedule.

• Assigning resources to all activities

  The schedule should realistically reflect what resources (i.e., labor, material, and overhead) are needed to do the work, whether all required resources will be available when they are needed, and whether any funding or time constraints exist. Sometimes the resources are put into the schedule and leveled by the scheduling software. However, often the resource planning and leveling is taking place outside the schedule in other software. The challenge is to determine whether activity shifting found necessary is implemented in the schedule – we believe that this trend may be the cause of SNET constraints in many schedules.

• Establishing the duration of all activities

  The durations (and remaining durations) of activities should reflect how long each activity will take to execute. In determining the duration of each activity, the same rationale, data, and assumptions used for cost estimating should be used for schedule estimating, and this is often found in the Basis of Estimate (BOE). Further, these durations should be as short as necessary to provide management and accurate monitoring and progress reporting. Excessively long periods needed to execute an activity should prompt further decomposition of the activity so that shorter execution durations will result. In particular, we find that some of the long activities are actually LOE activities that are scheduled as normal activities rather than LOE or hammock activities.

• Integrating schedule activities horizontally and vertically

  The schedule should be horizontally integrated, meaning that it should link the products and outcomes associated with already sequenced activities (see best practice 2). These links are commonly referred to as “hand offs” and serve to verify that activities are arranged in the right order to achieve aggregated products or outcomes. The schedule should also be vertically integrated, meaning that traceability exists among varying levels of activities and supporting tasks and sub-tasks. Such mapping or alignment among levels enables different groups to work to the same master schedule. Interestingly, some representations of the project schedule are developed manually in scheduling packages other than the one used for the detailed schedule, or in presentation packages such as PowerPoint. Vertical traceability means that the important dates are the same in each such representation referring to the same data date.

• Establishing the critical path for all activities

  Using scheduling software the critical path—the longest duration path through the sequenced list of activities often defined by zero or negative total float—should be identified. The establishment of a program’s critical path is necessary for examining the effects of any activity slipping along this path and to highlight the work that is important to achieving an on-time completion. Potential problems that may occur on or near the critical path should also be identified and reflected in the scheduling of the time for high risk activities. If there are constraints, the critical path may include a number of activities that are not driving the finish date but rather an intermediate milestone with a backward-path constraint. In this case, we prefer the longest path concept, where the activities are identified by zero free float to the final delivery date.  The longest path provides more focus on those activities driving that date, although it is not available in all scheduling software.

• Identifying total float

  The schedule software computes total float—the time that a predecessor activity can slip before the delay affects successor activities represented by the early finish minus the late finish—so that schedule flexibility can be determined. Activities along the critical path have zero total float in the absence of backward-pass constraints, or negative total float if there are such constraints. We often find large total float values that usually represent incomplete logic (e.g., activities without successors, causing large float values on the path).  Sometimes even when activities all have successors we find total float that indicates unreasonable and unbelievable flexibility in the schedule because the successors are to late milestones rather than to the very next activity in the plan. It is surprising how often the project manager does not focus on total float to see if he thinks the project is properly represented.

• Conducting a schedule risk analysis

  A schedule risk analysis (SRA) uses a good critical path method schedule as its foundation – schedule risk analysis complements good scheduling. The SRA uses data about project schedule risks collected from project participants and others. The analysis is the result of modeling the risks into the project schedule and simulating that schedule using specialized Monte Carlo software and (statistical) techniques. Results are the level of confidence in meeting a program’s completion date, the amount of time contingency needed for a level of confidence, and the identification of high-priority risks. This analysis focuses not only on critical path activities but also on other schedule paths because they may become critical under some combination of risks’ occurring.  A schedule may vary due to, among other things: limited data; optimistic estimating; technical challenges; lack of qualified personnel; and regulatory, market or other external factors. As a result, the baseline schedule should include a buffer, calculated by performing a schedule risk of extra time required to give the organization a desired level of confidence in succeeding. As a general rule, the reserve should be held at the total project level, just before the finish date, by the project manager and applied as needed to those activities that take longer than scheduled because of the identified risks.

• Updating the schedule using logic and durations to determine the dates

  The schedule should be continually monitored to determine when forecasted completion dates differ from the planned dates, since those imply schedule variances that may affect the dates of downstream work. Maintaining the integrity of the schedule logic is not only necessary to reflect true status, but is also required before conducting a schedule risk analysis.  To ensure that the schedule is properly updated, individuals trained in critical path method scheduling should be responsible for statusing the schedule. Schedule updating (statusing) requires knowing activities’ actual start and finish dates and the difference between actual duration (from the start to the data or status date) and remaining duration to eventual activity completion.

• Baselining the schedule

  The project schedule should be baselined and that baseline has to be agreed to by all involved parties. The baseline schedule is useful to determine commitments and for variance analysis. The baseline schedule is the starting point for conducting earned value management (EVM) analysis. The baseline should not be statused, in contrast to the current schedule. The baseline can be changed (re-baselining) only with formal, written agreement of the original parties to its adoption.