Schedule Optimization and the Baseline

The Network Is Not Yet the Schedule

The forward and backward pass from the previous chapter give you the critical path and the minimum duration the activity network implies. That is a necessary calculation, but it is not the same thing as a schedule the project can actually execute. The network assumes resources are available whenever an activity needs them. Real projects do not work that way. People are shared across multiple activities and sometimes across multiple projects. Equipment has its own availability constraints. A vendor may have capacity limits that mean two work streams that appear parallel on paper cannot actually run in parallel in practice. Before the schedule can be baselined, the plan must be tested against resource reality. The tools for that are resource leveling and resource smoothing. After those adjustments, the schedule also needs intentional protection against uncertainty, which is the role of buffers. And when the schedule still needs to be shorter, the team has two legitimate techniques for compressing it. This chapter covers all of those steps, ending with the decisions and approvals that lock the baseline.

Resource Leveling

Resource leveling addresses overallocation: the situation where the schedule, as produced by the network calculation, assigns more work to a resource than it can handle during the same time period. This happens whenever two or more activities that share a resource have overlapping Earliest Start windows. The leveling process adjusts the schedule to stay within resource availability limits. It may delay activities, extend durations, or change the sequence of parallel work. The consequence is that resource leveling can change the critical path and may extend the project end date. A schedule that looked achievable on paper may take longer once the team's actual capacity is applied. This is not a failure of planning. It is the process surfacing a real constraint that the activity network could not see. The output of leveling is a schedule that can actually be executed by the people and resources available, rather than a mathematically optimal plan that assumes infinite capacity.

Resource Smoothing

Resource smoothing is a different technique with a different constraint. Where leveling accepts that the project end date may move in order to resolve overallocation, smoothing works within the available float to rearrange activities so that resource demand becomes more even, without pushing the project beyond its baseline end date. Activities on the critical path are not moved; only activities with float are candidates for smoothing. The result may not fully resolve every overallocation, but it reduces peaks and troughs in resource demand, making the schedule easier to staff and execute. On projects where the deadline is fixed and resource overallocation is moderate, smoothing within float is often the first tool to try before considering leveling, which can move the end date, or compression, which adds cost.

Critical Path vs Critical Chain

The critical path method identifies the longest chain of dependent activities and focuses schedule management attention there. Critical chain method takes that analysis a step further by explicitly incorporating resource constraints into the identification of the controlling path. On a network where two critical path activities require the same resource, the critical chain recognizes that those activities cannot actually run in parallel even if the network shows no dependency between them. The resource dependency becomes an implicit sequencing constraint, and the critical chain reflects that reality in a way the pure dependency network does not. Critical chain also changes where protection is placed. Rather than hiding buffer inside individual activity estimates, critical chain removes that hidden padding and places explicit, visible buffers at strategic points in the schedule. This produces more honest estimates and more manageable protection.

Buffer Types

Buffers are deliberately placed slack that protects the schedule against uncertainty. Float is calculated from the network logic. A buffer is intentionally inserted as a risk management decision. The two are not the same thing, and treating float as a substitute for buffer is a common error. The three types of buffer used in schedule management each serve a different protective function.

One of the most common mistakes when a sponsor asks for a faster delivery date is to eliminate all buffers. This move trades schedule risk for schedule optics: the new plan looks faster on paper, and every risk event that previously landed in a buffer now lands directly on the critical path. The first real problem turns a manageable delay into a crisis, because there is nothing left to absorb it. Buffers are not padding invented by pessimists. They are the honest acknowledgment that a project schedule is a plan for an uncertain future, not a script for a controlled one.

Schedule Compression: Crashing

When the schedule is too long and scope cannot be reduced, crashing is the first compression technique. Crashing adds resources to critical path activities in order to reduce their duration. More people on a task, a second shift running in parallel with the first, additional equipment that allows work to proceed faster. All of these are forms of crashing. The cost of crashing is real and immediate: additional labor, equipment hire, or shift premiums. The schedule gain is bounded by diminishing returns. Doubling the crew does not halve the activity duration, because some work is inherently sequential, and coordination between more people takes time that a smaller team does not spend. When evaluating crash options, the team should identify which critical path activities have the most favorable cost-to-compression ratio — the activities where the most schedule time can be recovered per unit of additional spend — and start there rather than adding resources uniformly across the critical path.

Schedule Compression: Fast-Tracking

Fast-tracking overlaps activities that were originally planned to run in sequence, allowing a successor to begin before its predecessor is fully complete. The mechanism is changing a Finish to Start dependency to a Start to Start dependency, or introducing a lead into an existing relationship. Fast-tracking does not cost money the way crashing does, but it introduces rework risk. If the successor's early work depends on outputs from the predecessor that later change, some of what was done in parallel may need to be redone. The key discipline is identifying which overlaps are genuinely manageable (where the predecessor's early output is stable enough that the successor can act on it) and which overlaps are speculative. Fast-tracking a discretionary dependency that reflects good practice carries different risk from fast-tracking a dependency that exists because one activity's output is literally the input for the next. Both are compressible in theory. One is far more likely to create expensive rework.

These four techniques address different problems. The table below maps each situation to the right technique and its primary trade-off.

The Gantt Chart

The network diagram and its calculations are the analytical foundation of schedule management. For communication and day-to-day tracking, most teams work from a Gantt chart: a horizontal bar chart where each activity appears as a bar spanning its planned start and end dates. Dependencies show as links between bars. Milestones appear as points on the timeline. The critical path is visible as the chain of bars with no float between them. Collapsing the Gantt to the milestone level gives sponsors and steering committees a readable view of project progress without the full activity detail. The Gantt chart does not replace the network analysis. It presents the results of that analysis in a format that supports tracking and communication throughout execution.

Locking the Baseline

The schedule baseline is the approved version of the schedule: the target the project will be measured against throughout execution. Locking the baseline is the moment the plan becomes the plan. Before that approval, the following checklist confirms the plan is ready to commit to.

• Activity list is complete for the current planning horizon and reviewed by the relevant SMEs.
• Dependencies have been reviewed by the people who will execute the work, not only by the PM.
• Forward and backward pass are complete, or the output has been validated against tool calculations.
• Critical path and near-critical paths are identified and documented.
• Total float and Free float have been reviewed for activities where handoffs matter.
• Resource availability and calendars have been checked against the schedule.
• Resource leveling or smoothing has been applied where overallocation exists.
• Buffers are placed intentionally, not hidden inside individual activity estimates.
• Sponsor has formally approved the delivery commitment and the baseline is recorded.

After baseline approval, every proposed change to the schedule goes through the change control process. The baseline does not silently drift to match whatever is currently happening. That discipline is what makes the schedule a real management tool: it tells you when you are off track, because you have a fixed reference point that tells you what on track looks like.

On the RtR project, the schedule baseline could not be locked until the lease at the new location was signed. Every duration estimate for the physical move, the IT installation, and the site renovation depended on the specific configuration of a building that could not be confirmed until the landlord was committed and the terms were final. Three months of planning work was complete: activities defined, dependencies sequenced, resources identified, compression options analyzed. The baseline was formally approved the day after lease execution, with the go-live commitment made for the first time from a plan that could actually be built against.

What's Next

With the schedule baseline locked, planning moves to cost. Most cost estimates for labor and equipment depend directly on the schedule that was just built: duration drives labor hours, and the timing of activities determines when costs are expected to occur. Materials, licenses, and fixed-price contracts are more scope-driven, but the schedule still tells you when those costs will be incurred. Cost planning is the next step in the same planning chain.

Reflect

• Think about a project where resources were not checked against the schedule before baselining. What was the first conflict that surfaced during execution, and how was it resolved?
• Consider a project where buffers were removed to satisfy a shorter deadline. What was the first risk event that exposed the absence of those buffers, and what did the team do next?
• Identify an activity in a current or recent schedule where crashing would be cost-effective and one where it would not. What makes the difference?
• Look at the baseline locking checklist above. Which steps does your organization currently perform consistently, and which are typically skipped or informal?