3 Schedule Planning and Control

How a project schedule works

A project schedule is a logic-linked model of the work. It shows what must happen, in what order, for how long, and when the project is forecast to finish. Reliable schedule practice combines realistic activity sequencing and duration estimates with critical-path analysis, an approved baseline, and disciplined updates. A reliable schedule is comprehensive, well-constructed, credible, and controlled.

Sequence activities and dependencies

Break the project scope into work activities and milestones, then link each activity to its logical predecessors. In a finish-to-start (FS) relationship, a successor cannot start until its predecessor finishes. Other relationships, such as start-to-start, may be useful when work genuinely overlaps.

Avoid artificial links, unjustified lags, and fixed-date constraints that conceal the actual work sequence. The schedule should show genuine dependencies rather than force all work into one sequence.

For example, requirements must precede both design and equipment ordering. Design precedes software build, while ordering precedes equipment receipt. Integration waits for both software build and equipment receipt, and acceptance follows integration. This allows design and ordering to proceed in parallel after requirements are defined.

Estimate activity durations

Estimate each activity's duration from its scope, expected resources, working calendar, and relevant past performance. Record important assumptions: a duration is not meaningful without specifying the work and conditions it includes.

When uncertainty is material, a three-point estimate can express optimistic duration $O$, most likely duration $M$, and pessimistic duration $P$. A common PERT expected-duration calculation is:

For testing estimated at $2$ days optimistically, $4$ days most likely, and $8$ days pessimistically, the calculation is:

This result is an estimate, not a promise or guaranteed finish date. Select a practical schedule duration and document the assumptions and any separate contingency.

Calculate the critical path and float

The critical path is the longest-duration path through the network. Given the schedule's logic and assumptions, it determines the earliest possible project finish. Activities on that path typically have zero total float. Total float is the amount of time an activity can slip without delaying the forecast project finish.

For a simple network in which all links are finish-to-start, use a forward pass to find earliest dates:

• Earliest finish is earliest start plus duration: $EF = ES + d$.

• A successor's earliest start is the latest earliest finish among its predecessors.

Use a backward pass to find the latest dates that will not delay the finish:

• Latest start is latest finish minus duration: $LS = LF - d$.

• A predecessor's latest finish is the earliest latest start among its successors.

• Total float is $LS - ES$, equivalently $LF - EF$.

Worked network

Start at day $0$; durations are working days, and every link is finish-to-start. The activities and dependencies are:

• Activity A, define requirements: $2$ days, no predecessor.

• Activity B, design solution: $4$ days, after A.

• Activity C, procure equipment: $5$ days, after A.

• Activity D, build software: $3$ days, after B.

• Activity E, receive equipment: $1$ day, after C.

• Activity F, integrate and test: $2$ days, after D and E.

• Activity G, acceptance: $1$ day, after F.

The two main paths are A–B–D–F–G, with duration $2 + 4 + 3 + 2 + 1 = 12$ working days, and A–C–E–F–G, with duration $2 + 5 + 1 + 2 + 1 = 11$ working days. The earliest project finish is $12$ working days, and A–B–D–F–G is the critical path. The procurement path has $1$ day of total float.

The forward- and backward-pass results are:

• A: $ES = 0$, $EF = 2$, $LS = 0$, $LF = 2$, total float $0$.

• B: $ES = 2$, $EF = 6$, $LS = 2$, $LF = 6$, total float $0$.

• C: $ES = 2$, $EF = 7$, $LS = 3$, $LF = 8$, total float $1$.

• D: $ES = 6$, $EF = 9$, $LS = 6$, $LF = 9$, total float $0$.

• E: $ES = 7$, $EF = 8$, $LS = 8$, $LF = 9$, total float $1$.

• F: $ES = 9$, $EF = 11$, $LS = 9$, $LF = 11$, total float $0$.

• G: $ES = 11$, $EF = 12$, $LS = 11$, $LF = 12$, total float $0$.

If equipment receipt (E) slips by $2$ working days and nothing else changes, its $1$ day of float is used and the project is delayed by $1$ working day. The procurement path becomes critical. Recalculate the network after changes instead of assuming the original critical path remains the only path that matters.

Maintain the schedule baseline

A schedule baseline is the approved target schedule used to plan and measure performance. It should reflect authorized scope, activity logic, durations, calendars, key assumptions, and milestones.

Keep the baseline distinct from the current forecast. Update the forecast using actual progress and estimates of remaining duration, then compare forecast dates with baseline dates to identify variances. Document reasons for changes and manage proposed baseline changes through the project's approval or change-control process; do not silently overwrite the target plan.

For example, if integration has a baseline start on day $9$, but an update forecasts a day $10$ start because equipment will arrive late, retain the day $9$ baseline, enter the day $10$ forecast, and report the one-day variance. Explain its cause and effect on downstream work and the finish forecast. If an approved scope or plan change warrants a new baseline, retain appropriate change records rather than treating the revised target as if it had always been the plan.

Recover from schedule delays

Schedule recovery aims to reduce a forecast delay while preserving required scope and quality. Assess cost, feasibility, risk, and effects on all paths before changing the plan.

• Crashing adds resources, overtime, or other cost to shorten an activity. Target work on the current critical path: shortening a noncritical activity may not improve the finish date.

• Fast-tracking performs activities in parallel that were originally planned in sequence. It can introduce coordination, rework, or quality risks.

• Re-sequencing or removing constraints changes the plan only when the work and dependencies genuinely permit it.

After a recovery change, recalculate the network and check whether another path becomes critical. Schedule updates should use actual progress and valid logic, and recovery actions and their effects should be visible in the forecast.

In the example network, software build (D) is forecast to take $5$ days instead of its $3$-day baseline duration, adding $2$ days to the critical path. Paying for extra resources to return D's forecast duration to $3$ days may restore the original $12$-day finish if both days are recovered and no other work has slipped. Confirm that the work can be staffed and performed safely without reducing required quality, record the added cost and assumptions, update the forecast, and verify the other path and downstream dates. Do not change baseline dates unless the authorized change-control process approves a baseline change.