6.1 Activity Definition  6.2 Activity Sequencing  6.3 Activity Duration  Estimating  6.4 Schedule  Development  6.5 Schedule Control
 Integration  Scope  Time  Cost  Quality  Resource  Communications  Risk  Procurement

return to model

6.4 Schedule Developament

Schedule development means determining start and finish dates for project activities. If the start and finish dates are not realistic, the project is unlikely to be finished as scheduled. The schedule development process must often be iterated (along with the processes that provide inputs, especially duration estimating and cost estimating) prior to determination of the project schedule.

Inputs
   .1 Project network diagram
   .2 Activity duration estimates
   .3 Resource requeriments
   .4 Resource pool description
   .5 Calendars
   .6 Constrains
   .7 Assumptions
   .8 Leads and Lags
   .9 Risk management plan
   .10 Activity attributes
oooooooooooooooooooooooooo
ooooooooooooooo
ooooooooooooo
ooooooooooooooo
ooooooooooooo
Tools & Techniques
   .1 Mathematical analysis
   .2 Duration compression
   .3 Simulation
   .4 Resource leveling heuristics
   .5 Project management
       software
   .6 Coding structure
oooooooooooooooooooooooooo
oooooooooooooooooooooooooo
oooooooooooooooooooooooooo
oooooooooooooooooooooooooo
oooooooooooooooooooooooooo
oooooooooooooooooooooooooo
ooooooooooooooo
ooooooooooooo
Outputs
   .1 Project schedule
   .2 Supporting detail
   .3 Schedule management
       plan
   .4 Resource requirement
       updates
oooooooooooooooooooooooooo
oooooooooooooooooooooooooo
oooooooooooooooooooooooooo
oooooooooooooooooooooooooo
oooooooooooooooooooooooooo
oooooooooooooooooooooooooo
oooooooooooooooooooooooooo
oooooooooooooooooooooooooo
oooooooooooooooooooooooooo

6.4.1 Inputs to Schedule Development

.1 Project network diagram. Project network diagrams are described in Section 6.2.3.1.

.2 Activity duration estimates. Activity duration estimates are described in Section 6.3.3.1.

.3 Resource requirements. Resource requirements are described in Section 6.3.1.4.

.4 Resource pool description. Knowledge of what resources will be available at what times and in what patterns is necessary for schedule development. For example, shared or critical resources can be especially difficult to schedule since their availability may be highly variable. The amount of detail and the level of specificity in the resource pool description will vary. For example, one need only know that two consultants will be available in a particular time frame for preliminary schedule development of a consulting project. The final schedule for the same project, however, must identify which specific consultants will be available.

.5 Calendars. Project and resource calendars identify periods when work is allowed. Project calendars affect all resources (e.g., some projects will work only during normal business hours while others will work a full three shifts). A five-day workweek is an example of calendar usage. Resource calendars affect a specific resource or category of resources (e.g., a project team member may be on vacation or in a training program; a labor contract may limit certain workers to certain days of the week).

.6 Constraints. Constraints are factors that will limit the project management team's options. There are two major categories of time constraints considered during schedule development:

   Imposed dates – imposed dates on activity starts or finishes can be used to restrict the start or finish to occur either no earlier than a specified date or no later than a specified date. While all four date constraints are typically available in project management software, the "Start No Earlier Than" and the "Finish No Later Than" constraints are the most commonly used. Typical uses of date constraints include such situations as a market window on a technology project, weather restrictions on outdoor activities, government-mandated compliance with environmental remediation, delivery of material from parties not represented in the project schedule, etc.

   Key events or major milestones – Completion of certain deliverables by a specified date may be requested by the project sponsor, the project customer, or other stakeholders. Once scheduled, these dates become expected and often may be moved only with great difficulty. Milestones may also be used to indicate interfaces with work outside of the project. Such work is typically not in the project database, and milestones with constraint dates can provide the appropriate schedule interface.

.7 Assumpions. See Section 4.1.1.5.

.8 Leads and lags. Any of the dependencies may require specification of a lead or a lag in order to accurately define the relationship. An example of a lag:, there might be a desire to schedule a two-week delay (lag) between ordering a piece of equipment and installing or using it. An example of a lead, in a finish-to-start dependency with a ten-day lead: the successor activity stars ten days before the predecessor has completed.

.9 Risk management plan. The risk management plan is discussed in 11.1.3.

.10 Activity attributes. Attributes of the activities–including responsibility (i.e., who will perform the work), geographic area or building (where the work has to be performed), and activity type (i.e., summary or detailed)– are very important for further selection and sorting of the planned activities in a convenient way for the users. WBS classification is also an important attribute that allows useful activity ordering and sorting. 6.4.2 Tools and Techniques for Schedule Development

.1 Mathematical analysis. Mathematical analysis involves calculating theoretical early and late start and finish dates for all project activities without regard for any resource pool limitations. The resulting dates are not the schedule, but rather indicate the time periods within which the activity could be scheduled given resource limits and other known constraints. The most widely known mathematical analysis techniques are:

   Critical Path Method (CPM)—calculates a single, deterministic early and late start and finish date for each activity based on specified, sequential network logic and a single duration estimate. The focus of CPM is on calculating float in order to determine which activities have the least scheduling flexibility. The underlying CPM algorithms are often used in other types of mathematical analysis.

   Graphical Evaluation and Review Technique (GERT)—allows for probabilistic treatment of both network logic and activity duration estimates (i.e., some activities may not be performed at all, some may be performed only in part, and others may be performed more than once).

   Program Evaluation and Review Technique (PERT)—uses weighted average duration estimate to calculate activity durations. Although there are surface differences, PERT differs from CPM primarily in that it uses the distribution’s mean (expected value) instead of the most likely estimate originally used in CPM (see Figure 6–4). PERT itself is seldom used today.

.2 Duration compression. Duration compression is a special case of mathematical analysis that looks for ways to shorten the project schedule without changing the project scope (e.g., to meet imposed dates or other schedule objectives). Duration compression includes techniques such as:

   Crashing—in which cost and schedule tradeoffs are analyzed to determine how, if at all, to obtain the greatest amount of compression for the least incremental cost. Crashing does not always produce a viable alternative and often results in increased cost.

   Fast tracking—doing activities in parallel that would normally be done in sequence (e.g., starting to write code on a software project before the design is complete, or starting to build the foundation for a petroleum processing plant before the 25 percent of engineering point is reached). Fast tracking often results in rework and usually increases risk.

.3 Simulation. Simulation involves calculating multiple project durations with different set of activity assumptions. The most common technique is Monte Carlo Analysis, in which a distribution of probable results is defined for each activity and used to calculate a distribution of probable results for the total project (see also Section 11.4.2.4). In addition, what-if analyses can be made using the logic network to simulate different scenarios, such as delaying a major component delivery, extending specific engeneeiring durations, or introducing external factors (such as a strike, or a change in the permiting process). The outcome of the what-if simulations can be used to assess the feasibility of the schedule under adverse conditions, and in preparing contigency/response plans to overcome or mitigate the impact of unexpected situations.

.4 Resource leveling heuristics. Mathematical analysis often produces a preliminary early-start schedule that requires more resources during certain time periods than are available, or requires changes in resource levels that are not manageable. Heuristics, such as, “Allocate scarce resources to critical path activities first”, can be applied to develop a schedule that reflects such constraints. Resource leveling often results in a project duration that is longer than the preliminary schedule. This technique is sometimes called the resource-based method, especially when implemented with computerized optimization. Resource reallocation from non-critical to critical activities is a common way to bring the schedule back, or as close as possible, to its originally intended overall duration. Utilization of extended hours, weekends, or multiple shits should also be considered to reduce the durations of critical activities. Productivity incresases based on use of diferent technologies and/or machinery (i.e., automatic welding, electrical pipe cutters, etc.) are another way to shorten durations that have extended the preliminary schedule. Fact tracking, if feasible (as described in Section 6.4.2.2), is another way to reduce the overall project duration. Some projects may have a finite and critical project resource, requiring that this resource be scheduled in reverse from the project ending date; this is know as reserve resource allocation scheduling. Critical chain is a technique that modifies the project schedule to account for limited resources.

.5 Project management software. Project management software is widely used to assist with schedule development. Other software may be capable of interacting directly or indirectly within themselves, or with other software, to carry out the requirements of other knowledge areas. These products automate the calculation of the mathematical analysis and resource leveling and thus allow for rapid consideration of many schedule alternatives. They are also widely used to print or display the outputs of schedule development.

.6 Coding structure. The activities should have a coding structure that will allow sorting and/or extractions based on different attributes assigned to the activities, such as responsibility, geographic area or building, project phase, schedule level, activity type, and WBS classification.

6.4.3 Outputs from Schedule Development

.1 Project schedule. The project schedule includes at least planned start and expected finish dates for each detail activity. (Note: the project schedule remains preliminary until resource assignments have been confirmed. This would usually happen no later than the completion of Project Plan Development, Section 4.1).
  The project schedule may be presented in summary form (the master schedule) or in detail. Although it can be presented in tabular form, it is more often present-ed graphically, using one or more of the following formats:

   Project network diagrams with date information added (see Figure 6–5). These charts usually show both the project logic and the project’s critical path activities (see Section 6.2.3.1 for more information on project network diagrams).

   Bar charts, also called Gantt charts (see Figure 6–6), show activity start and end dates as well as expected durations, and sometimes show dependencies. They are relatively easy to read and are frequently used in management presentations.

   Milestone charts (see Figure 6–7) are similar to bar charts, but only identify the scheduled start or completion of major deliverables and key external interfaces.P>

.2 Supporting detail. Supporting detail for the project schedule includes at least documentation of all identified assumptions and constraints. The amount of additional detail varies by application area. For example:

   On a construction project, it will most likely include such items as resource histograms, cash-flow projections, and order and delivery schedules.

   On an electronics project, it will most likely include resource histograms only. Information frequently supplied as supporting detail includes, but is not limited to:

   Resource requirements by time period, often in the form of a resource histogram.

   Alternative schedules (e.g., best case or worst case, resource leveled or not, with or without imposed dates).

   Schedule contingency reserves (see Section 11.4).

.3 Schedule management plan. A schedule management plan defines how changes to the schedule will be managed. It may be formal or informal, highly detailed or broadly framed, based on the needs of the project. It is a subsidiary element of the overall project plan (see Section 4.1).

.4 Resource requirement updates. Resource leveling list updates may have a significant effect on preliminary estimates of resource requirements.

return to model

  previous page      next page