Project Scheduling Best Practices

I have been reading the Practice Standard for Scheduling – Second Edition by PMI, I found some useful information I wanted to share, below is a summary of the book:

Mainly this book covers Scheduling Methods, Scheduling Techniques, How to create, maintain, and analyze a schedule.

So What Is Scheduling and why we need a Schedule?

Scheduling is the application of skills, techniques, knowledge, and experience to develop an effective and dynamic representation of the plan for executing the project activities. Why we need to have a schedule? Because it provides a detailed plan that represent how and when the project will deliver the product or service, can be used as communication tool, and can be used for performance reporting as well. There are many more reasons but I believe these are fair enough.

Scheduling Methods:

• Critical Path Method (CPM)

  CPM determines the minimum total project duration, the earliest possible finish date of the project, and the amount of total float (flexibility) in the schedule. To use CPM, you need to calculate the Early Start (ES) & Early Finish (EF) dates for each activity in the schedule using the forward pass from a specific project date. And Late Start (LS) & Late Finish (LF) by using the backward pass, starting from the project early finish date which was calculated during the forward pass.

• Precedence Diagram Method (PDM)

  The PDM places activities on nodes with arrows linking activities; activity nodes may contain information about duration, cost, resources, and constraints. PDM takes fewer nodes than ADM to describe the same set of project data.

• Critical Chain Method (CCM)

  The critical chain method is developed from the CPM approach and considers the effects of resource allocation, resource leveling, and activity duration uncertainty on the CPM-determined critical path. To do so, the critical chain method introduces the concept of buffers and buffer management. Three types of buffers are feeding buffers, resource buffers, and project buffers:

  • Feeding Buffers: A buffer (in duration) added to the schedule model at the merge of non-critical paths with the project critical path from the CPM.
  • Resource Buffers: The frequent passing of forecast finish dates to a predecessor activity alerting the resources of the successor activity to be prepared to start work on the forecast finish date of the predecessor activity.
  • Project Buffers: Duration added to the end of the project between the last project activity and the final delivery date or contracted completion date.

  Buffers are statistically determined and aggregated safety margins assigned to individual chains of activities. Buffers are created by assigning aggressive activity realization times to remove any hidden safety margins and aggregating the resulting savings of planned times into buffers. Instead of spreading the safety margins among all activities, the safety margin is concentrated at the end of a chain and used only if risk materializes

Scheduling Techniques:

• Rolling Wave Planning

  Using the rolling wave planning technique, a detailed decomposition of the high-level activities is performed only for those activities in the “near term,” for example, the next 90 days. The rolling wave planning technique assumes the project team is very likely to have accurate and detailed information concerning the near-term activities, and less information about activities in the future or later in the project.

  An important principle for rolling wave planning is to perform the detailed planning at regular intervals. The detailed planning for the next interval needs to be completed well in advance of the start of the next wave’s execution. For periods beyond the detailed planning wave, activities are listed as “planning packages” with much less detail. These planning activities may contain cost and resource information, which becomes fixed in the baseline duration and cost. When detailed planning takes place, it replaces the planning packages with additional details.

• Agile Technique

  Agile project management is similar to rolling wave planning while emphasizing the attainment of usable results quickly and iteratively. The Agile project team utilizes CPM scheduling for each development cycle, called a sprint, which typically lasts two to four weeks. Agile project management focuses on shorter development cycles and tangible results at frequent and incremental intervals; the focus is on realization of interim benefits instead of completing activities.

  The most important elements of an Agile technique include having multiple iterations of the project phases instead of moving from one phase to another. Another key ingredient of the Agile methods is involvement of the key stakeholders, primarily the customer/end user, at the end of every iteration to approve the interim work products.

• Program Evaluation and Review Technique (PERT).

  While similar in principle to CPM and PDM, the program evaluation and review technique (PERT) is focused on activity duration. PERT allows for random activity duration and weights the activity-estimated duration on the range of duration estimates provided by stakeholders.

  Starting with a precedence diagram, PERT allows for activity duration estimates to be determined allowing for the uncertainty contained in the duration estimating process. Three duration estimates are required for each activity:
  

  Optimistic duration (the minimum activity duration under the most favorable conditions)

  Most likely duration (the activity duration that will occur most often)

  Pessimistic duration (the activity duration under the least favorable conditions)

  Activity Duration^PERT = (Optimistic Duration + 4 (Most Likely Duration) + Pessimistic Duration)/6

  The durations determined by the previous equation are used in the PERT diagram as activity-estimated durations. Generally durations are established at a specific statistical level of significance (for example, 95% confidence level). The weighting in the equation was a manual approximation of the statistical distribution. With more sophisticated calculations, mostly using computers, an implementation of statistical or multiple simulations PERT (SPERT) is possible, approaching the methods and results of Monte Carlo analysis.

• Monte Carlo Simulation

  Monte Carlo simulation considers the uncertainty in an activity’s duration, cost, resources, and relationships, etc., using the risks from the risk register to drive the uncertainty in activity durations or by estimating those durations directly as optimistic, most likely, and pessimistic estimates for activities. A probability distribution may be assigned to each activity, which considers the confidence level that stakeholders have in the estimates. When there is more confidence in the estimate, a probability distribution with a smaller standard deviation is selected and vice versa.

What is the Scheduling Model?

The introduction of project-specific data, such as the activities, durations, resources, relationships, and constraints into the scheduling tool creates a schedule model for the given project. Schedule model analysis compares changes in the schedule model based on updates of progress, cost, and scope with the project team’s expectations of the impact of these changes. The project team utilizes the schedule model to predict project finish dates in the form of schedule model instances. The schedule model provides time-based forecasts, reacting to inputs and adjustments made throughout the project’s life cycle.

Scheduling Model Analysis:

Schedule analysis utilizes common tools and techniques throughout the project life cycle in order to identify deviation from the baseline schedule model. Schedule analysis is the responsibility of the project team and the primary objective of the analysis is the early identification of threats and opportunities to the project objectives. There are several tools and techniques available to perform schedule model analysis.

• Critical Path and Critical Activities
  • Critical Path
    • The critical path is typically, but not always, the sequence of the schedule activities that predicts or defines the longest duration of the project. Generally, it is the longest path through the project and therefore determines the duration of the project. However, a critical path can end, as an example, on a schedule milestone that is in the middle of the schedule model and that has finish-no-later-than date constraint. (Remember that constraints are to be used selectively in schedule models.) But risk(s) and constraint(s) can alter the critical path, elevating the importance of seemingly lesser activities and causing unexpected changes to project duration and cost. A project can have multiple critical paths. A project with multiple critical paths has a higher level of risk since the failure to meet any of these might result in failure to complete all project milestones.
  • Critical Activities
    • It is important to distinguish between critical path activities and critical activities. Critical path activities are those activities contained in the critical path(s). Critical activities are those activities vital to the success of the project, even if they are not on the CPM predicted critical path or critical chain. Critical activities are normally high risk in terms of scope, schedule, and cost and can cause not only a delay in the project end date, but an increased likelihood of project failure. All activities in the critical path are also considered critical activities. The critical path calculations consider activities and constraints to determine the longest path in the project. Critical activities can be outside the critical path.
      
• Total Float and Free Float.

  Free float represents the amount of time an activity CPM early finish date may be delayed without impacting any successor activities’ CPM early start date. Total float represents the amount of time an activity CPM early start date or CPM early finish date may be delayed without impacting the CPM late finish date of the entire project or violating a schedule model constraint date. Review each activity total float and free float to determine if they have changed since the previous update. Changes to total float indicate a threat of achieving project completion or specific milestones; free float indicates how lack of progress impacts immediate successors. Total float and free float may be reduced by external dependencies and other hard constraint dates listed in the schedule model. These external dependencies should be explained in activity nodes or linked to external milestones.

• Level of Effort Activities (LOE).

  Level-of-effort (LOE) activities are to support other work activities or the entire project effort. Examples of such an activity may be project management, project budget accounting, customer liaison, or rotating machinery during storage (preventive maintenance), etc.

  Since an LOE activity is not itself a work item directly associated with accomplishing the final project product, service, or result, but rather one that supports such work, its duration is based on the duration of the discrete work activities that it is supporting.

• Probabilistic Distribution of Activity Durations.

  If activity durations involve a great deal of uncertainty, a commonly used estimating technique is the three-point estimate. These three points correspond to activity duration defined as optimistic, most likely, and pessimistic durations. Additionally, the risk register may also be used to support estimating the uncertainty in activity durations. In order to quantify uncertainty about the overall project duration, starting from the three point estimate of every activity, PERT (which uses an approximation of beta distribution) can be utilized.

• Schedule Risk

  Schedule risk analysis is utilized to establish and validate schedule contingencies, identify priority risks and risk-driven events, and continuously monitor changes on project-related risks. PERT does not recognize that parallel fl oat paths can contribute to risk especially at merge points also known as “merge bias” or “path convergence.” It is too complex to perform a deep analysis of this bias without doing a simulation such as Monte Carlo simulation which will determine magnitude of the bias. The larger and more complex a project, the greater the cumulative impact of risk on the project.

• Date Constraints

  Date constraints restrict a project’s natural flow, disregard the effects of risk, and limit the usefulness of schedule risk analysis. Date constraints should be avoided whenever possible and used only when compatible with a project’s expected course of development.

• Open-Ended Activities

  An open-ended activity is an activity lacking either a predecessor or a successor or both. Open-ended activities can obscure the logical relationships between project activities, create a false appearance of float in a project, and reduce the apparent impact of risk during a schedule analysis. The only open-ended activities in a project should be the start and finish milestones at the beginning and end of the project. Unless linked to other projects, a project’s start and finish milestones will always contain open ends.

• Out of Sequence (OOS) Logic

  OOS logic arises when a project is already in progress. An activity may be reported as started before its predecessor is reported as finished, causing OOS logic.

  For example, if Activity A has a finish-to-start (FS) relationship with Activity B, but Activity B has been updated with an actual start date before Activity A has been updated with an actual finish date, the result is OOS logic. OOS logic should be corrected (e.g., by further decomposition of Activity A) or removed in order to preserve the integrity of the risk analysis. Schedule analysis will properly identify how to best resolve OOS logic problems; however, do not rely solely on the scheduling tool to correct the problem, because only the team can best determine the OOS logic resolution. In some cases, it may be that the defined relationship created during the planning stage was not correct and should be corrected for this project and for future reference.

• Leads and Lags

  Risk can consume or extend fixed lags with unanticipated consequences to overall project duration. Leads and lags can introduce schedule risk and should be modeled as discrete activities with their own duration uncertainty whenever possible. Leads can also introduce cost risk especially in JIT (just-in-time) inventory management; this, in turn, may have a cascading effect on the schedule model if the project is being managed with a limited inventory space. Expressing leads/lags as discrete activities is required if Monte Carlo simulation software does not allow assignment of duration uncertainty to a lead/lag. Additionally, promoting a lead/lag to a full activity allows it to be assigned with additional attributes, such as a name, remaining duration, etc.

• Start-to-Finish Relationship

  Start-to-finish (SF) relationships are seldom deliberately used in deterministic planning because they involve the unusual circumstance of a successor task happening before its logical predecessor. Review any SF relationship to ensure that it is not the result of scheduling errors and modify them if necessary. The following illustrative example of a SF relationship provides a better understanding of this rare relationship:

  Example —Assume that the project requires the delivery of a piece of equipment to support construction activities. It may not be practical to provide logic for the equipment fabrication and delivery activities, yet the team wants the construction activities to drive the dates of the delivery. Since the predecessor always drives the successor, the SF relationship provides the solution. Then the equipment fabrication may conclude upon the start of the activity requiring the equipment to be installed.

• Links to/from Summary Activities

  It generally is not recommended to use links on summary activities because the logic can be difficult to follow and the practice may not be supported by all scheduling tools. Use of links on summary activities may produce logic errors and create circular logic within the schedule model.

Schedule Components:

Schedule components are divided into three categories (Required, Conditional, Optional). Required components are divided into four Groups:

• Core Required Components (CRC): These components are required regardless of project complexity and are known as the core required components.
  
• Resource Required Components (RRC): The resource required components are required if the project documents require resource loading.
  
• EVM Required Components (ERC): The earned value management components are required if the project documents require EVM to be utilized on the project.
• Risk Required Components (KRC): These components (KRC) are required if the project documents require risk concepts to be considered during the schedule development and maintenance.

The requirements of the project determine which required components need to be present in a schedule model before a maturity assessment can be performed.

References: Practice Standard for Scheduling – Second Edition by PMI