18.3 Re-Estimating and Schedule Optimisation

Why schedules must evolve

Even a well-built integrated schedule is based on estimates and assumptions. As the project learns — design matures, suppliers respond, productivity becomes measurable, risks crystallise — those estimates age. Learning objective 20c expects you to explain the reasons and benefits of re-estimating and schedule optimisation throughout the life cycle.

Weak answers freeze the first Gantt chart and treat all later movement as failure. Strong answers treat schedule management as continuous: update forecasts honestly, optimise where justified, and re-baseline only under governance when the authorised plan must change.

Core distinction: Forecast updates describe expected reality against the baseline. Re-baselining changes the authorised plan through change control or formal re-planning. Optimisation may affect either, depending on whether the authorised end date or approach must change.

Reasons to re-estimate throughout the life cycle

Re-estimating revisits effort, duration, cost, and resource needs using better information than was available earlier.

Re-estimating is professional control, not an admission that the original planner was incompetent. Early estimates are expected to be less accurate; the organisation should plan for progressive elaboration.

Benefits of re-estimating

1. Forecast accuracy — sponsors see realistic completion and cost outlooks.
2. Better decisions — trade-offs (descope, accelerate, accept delay) use current data.
3. Risk transparency — emerging critical paths and near-critical paths become visible.
4. Resource planning — hiring, contractors, and BAU secondments align to true demand.
5. Stakeholder trust — honest updates beat surprise failure at the end.
6. Business-case integrity — continued investment is tested against updated time-to-benefit.
7. Supplier management — claims and recovery plans rest on current logic, not nostalgia.

Scenario A — refusal to re-estimate

A six-month software build used early story-point velocity from a different team. After three sprints, actual velocity is 60% of the plan, but the end date is reported green by keeping original estimates. At month five the gap is undeniable. Earlier re-estimating would have forced a scope, resource, or date decision when options were cheaper.

Schedule optimisation — meaning and intent

Schedule optimisation improves the schedule’s ability to meet objectives within constraints: shorter duration where needed, more robust logic, better resource fit, reduced unnecessary risk, or improved chance of hitting a fixed milestone — without pretending constraints do not exist.

Optimisation asks: Given what we now know, is there a better feasible plan?

Common optimisation levers (conceptual)

Fast-tracking (conceptual)

Fast-tracking overlaps phases or activities that were sequential — for example starting construction on packages while detailed design continues on others, or beginning test script writing before coding finishes for all modules.

• Benefit: shorter elapsed time without necessarily adding many resources.
• Risk: rework if predecessor information changes; interface confusion; quality escapes.
• When used: fixed end dates, acceptable risk, strong change and configuration control.

Crashing (conceptual)

Crashing shortens critical-path activities by adding resources or cost — overtime, extra crews, parallel work cells, expedited shipping — where additional spend actually reduces duration.

• Benefit: recovers time on the critical path.
• Cost: budget increase; sometimes quality or safety risk if rushed.
• Diminishing returns: not all activities are crashable; some only move bottleneck elsewhere.
• Rule of thumb: crash activities that give maximum time save per unit cost on the critical path, then recheck the path (a new path may become critical).

Scenario B — choosing a lever

A data-centre project is three weeks late on the critical electrical package. Options: (1) crash with a second shift at premium cost; (2) fast-track by installing equipment before final inspection paperwork completes (regulatory risk); (3) phase non-critical office fit-out later to free supervision; (4) accept delay and reforecast benefits. The PM should present time–cost–risk–benefit options to the sponsor, not silently pick the riskiest overlap to protect a green RAG status.

Optimisation vs padding

Padding is adding extra time or money into estimates without transparent analysis — "add 20% because we always do." Optimisation changes logic, resources, or scope deliberately and visibly.

Optimisation may remove unnecessary padding that hides resources, or convert vague padding into explicit risk-based contingency. The exam point: do not confuse optimism bias correction and risk contingency with silent sandbagging, and do not "optimise" only by cutting every buffer until the plan is brittle.

Scenario C — padding mistaken for float

Each team lead adds two weeks to every estimate "for safety." The consolidated plan looks comfortable. In reality, leads start late and the critical path has no real buffer when a supplier fails. Better practice: tighter base estimates, explicit risk contingency on the path or at project level, and active monitoring — optimisation through honesty, not inflation.

Linear vs iterative re-planning

How re-estimating and optimisation are applied depends on life cycle approach.

Hybrid projects combine both: fixed regulatory milestones with iterative build inside phases. Re-planning must respect the fixed external constraints while allowing learning inside iterations.

Exam trap: Claiming iterative projects never re-estimate or never need a schedule. They re-estimate constantly; they may express schedule as roadmaps, release trains, and burndown/burnup rather than one frozen bar chart.

Benefits of continuous schedule management

Treat schedule management as an ongoing control loop:

1. Plan — build integrated network from WBS with dependencies and estimates.
2. Baseline — authorise the plan at the right level.
3. Monitor — progress, actuals, emerging risks, BAU changes.
4. Re-estimate / forecast — update expected completion and intermediate milestones.
5. Optimise or escalate — apply levers or seek decision on date/scope/cost/risk.
6. Re-baseline when required — through change control so the baseline remains a true control tool.
7. Communicate — one integrated story to sponsor, team, suppliers, and BAU.

Benefits summarised

Scenario D — continuous management done well

A rail improvement project reviews critical and near-critical paths weekly, re-estimates civils productivity from site data monthly, and holds a decision gate when weather risk consumes contingency. The sponsor chooses a limited crash on night possessions plus deferral of non-critical station aesthetics. Benefits of the core safety output stay on track; secondary benefits slip transparently. That is optimisation and re-estimating serving objectives, not vanity dates.

Putting LO20c answers together

When a long-response scenario shows delay, uncertainty, or pressure to "make the date":

1. Explain why re-estimating is needed given new information.
2. Separate forecast from baseline change.
3. Offer optimisation options: logic, resources, fast-track, crash, phase/descope, accept delay.
4. State time–cost–quality–risk trade-offs for each option.
5. Reject pure hidden padding as a control strategy; prefer transparent contingency.
6. Match approach to linear vs iterative context.
7. Escalate decisions that exceed the project manager’s authority.

Combined with integrated planning (LO19) and breakdowns/dependencies (LO20a–b), this completes the PMQ view of planning and schedule management: one integrated plan, structured scope, explicit dependencies including BAU, and continuous honest optimisation through the life cycle.