Common techniques that schedulers and management teams use to recover schedule variances and, in general, accelerate a schedule. Schedule recovery is a managerial effort to recover from the interruption of events on the planned schedule.
Acceleration refers to a reduction in the duration of the overall schedule. The focus for schedule recovery or acceleration should be on critical activities and, in particular, on long-duration critical activities.
Because critical activities drive key milestone dates, the overall schedule duration will be reduced only by reducing the critical paths. Some of the strategies described below may have contractual implications.
Recovery Strategies
Schedule recovery and acceleration strategies — focus recovery efforts on the critical path
Technique
Description
Impact
Fast Tracking
Reduce sequential dependencies between activities to partial dependencies. F–S logic is changed to S–S logic to force parallel work.
Resources may become overallocated. Quality may be reduced and risk introduced if activities ideally executed in sequence are now executed in parallel.
Crashing
Add resources to time-dependent activities to complete work faster.
Requires additional resources and increases costs. May reduce quality if activities are executed faster with less-experienced labour and insufficient supervision.
Split Long Activities
Split long activities into shorter activities that can be worked in parallel.
Resources may become overallocated or unavailable.
Review Constraint & Lag Assumptions
Reassess assumptions related to forcing activities to begin on certain dates.
If the original constraint or lag is justified, removing it may not be realistic. Careful review of each constraint is required before removing.
Review Duration Estimates
Revisit duration estimates using progress records as actual effort is recorded.
May reveal opportunities to reduce durations where original estimates were conservative. Equally, may confirm that durations were accurate.
Add Overtime & Reduce Vacations
Review non-working periods and assign overtime work. Add additional work shifts.
Costs will increase over standard labour rates. As overtime increases, morale decreases — eventually affecting product quality negatively. Contingency used early reduces the probability of on-time completion for later risks.
Reduce Scope
Decrease scope to reduce both duration and costs.
Scope is the primary reason for performing the work — it may not be possible or acceptable to delete some requirements. Requires agreement with the Principal.
Schedule Contingencies
Allocate contingency to absorb delay in accordance with identified risk mitigation plans.
Using contingency too early reduces the likelihood of completing on time if the reason for delay was a risk not previously identified. Contingency can be split and appropriately allocated to different phases — Design, Procurement, Production.
Note on logic abbreviations: F–S = Finish-to-Start logic (standard sequential dependency). S–S = Start-to-Start logic (activities can begin simultaneously, allowing parallel work). See Module 2 for a full explanation of relationship types.
Choosing the Right Strategy
No single recovery strategy suits all situations. The most effective approach depends on:
Where the critical path runs — only work on the activities driving the end date
Resource availability — crashing and overtime require additional resources that may not be available in the market
Contract provisions — some strategies may require the Principal's agreement or instruction, particularly scope changes and acceleration
Stage of the project — strategies effective in early phases (fast tracking design and procurement) may be ineffective or impractical in late construction phases
Cost-benefit analysis — every recovery strategy has a cost; weigh the cost of acceleration against potential liquidated damages for delay
Module 5 Key Takeaways
Delay analysis requires contemporaneous documentation — site diaries, correspondence, programme updates, and meeting minutes are all critical
The four CPM-based methods (APIP, ABBF, Windows, Snapshot) all have different strengths and levels of rigour
The critical path is never static — it must be re-evaluated at every update to correctly identify which delays are Critical Delays
Recovery and acceleration focus must be on the critical path — not on activities with float
Float ownership, concurrency, and the quality of the Contractor's programme are all central issues in delay disputes
