18.3 Re-Estimating and Schedule Optimisation

APM Project Management Qualification PMQ

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Exam Format & Question Types 1.3 How to Study for APM PMQ

2 Life Cycles

2.1 Linear Life Cycles and Why Work Is Phased 2.2 Iterative and Hybrid Life Cycles 2.3 Project Life Cycles and Extended Life Cycles 2.4 Choosing a Life Cycle: Context, Culture, Strengths and Limitations

3 Governance Arrangements

3.1 Functional, Matrix and Projectised Structures 3.2 Governance Frameworks, Policies and Delegated Responsibility 3.3 Life-Cycle Impact on Governance and Limits of Financial Authority 3.4 Project Roles and Responsibilities 3.5 Project Manager and Project Sponsor Through the Life Cycle 3.6 Linking Projects to Organisational Objectives

4 Sustainability

4.1 Sustainability Responsibilities, Principles and Impact 4.2 Monitoring and Reporting Sustainability Measures

5 Business Case

5.1 Business Case Fundamentals and Analysis Tools 5.2 The Business Case as Baseline and Reviewing Change

6 Procurement

6.1 Procurement Strategy: Purpose and Contents 6.2 Supplier Selection and Negotiation 6.3 Features of Different Contractual Relationships 6.4 Supplier Reimbursement Methods

7 Reviews & Assurance

7.1 Reviews, Decision Gates, Benefits Reviews and Audits 7.2 What Gets Reported and Informing Decisions 7.3 Why Activities Are Re-Planned After a Review 7.4 Project Assurance

8 Transition & Benefits Management

8.1 Transition Requirements and Business-as-Usual Readiness 8.2 Knowledge Transfer and Agreeing the Transition Plan 8.3 Benefits Management: Identification to Realisation 8.4 Aligning and Communicating Benefits

9 Stakeholder Engagement & Communication

9.1 Stakeholder Analysis, Influence and Engagement 9.2 The Communication Management Plan and Its Benefits 9.3 Managing Stakeholder Expectations 9.4 Communication Methods and Tailoring the Message 9.5 Factors That Help and Hinder Communication

10 Conflict Resolution

10.1 Sources and Impacts of Conflict 10.2 Addressing Conflict and the Thomas-Kilmann Model

11 Leadership

11.1 Leadership, Motivation and Team Performance 11.2 Changing Leadership Styles for the Situation 11.3 Coaching, Mentoring and Emotional Intelligence

12 Team Management

12.1 Team Development Stages and Models 12.2 Characteristics and Benefits of Effective Teams 12.3 Leading Virtual and Hybrid Teams

13 Diversity & Inclusion

13.1 Diversity Characteristics and the Equality Act 13.2 Incorporating Diversity and Diverse Thinking 13.3 Conscious and Unconscious Bias and Fair Treatment

14 Ethics, Compliance & Professionalism

14.1 Continuing Professional Development and Competence 14.2 Sources of Specialist Advice and Standards 14.3 The Legal and Regulatory Landscape

15 Requirements & Solutions

15.1 Establishing Scope Through Requirements Management 15.2 Managing Scope Through Configuration Management 15.3 Solutions Development and Prioritisation

16 Quality Management

16.1 Quality Planning, Indicators and the Business Case 16.2 Quality Control and Success Criteria

17 Integrated Planning

17.1 The Integrated Project Management Plan: Format and Contents 17.2 Why an Integrated Plan Matters

18 Schedule Management

18.1 Defining Scope and Breakdown Structures 18.2 Dependencies and What Drives the Schedule 18.3 Re-Estimating and Schedule Optimisation

19 Resource Management

19.1 Determining Resource Requirements and Availability 19.2 Organisational Breakdown Structure and RACI 19.3 Categorising and Allocating Resources 19.4 Resource Smoothing and Resource Levelling

20 Budgeting & Cost Control

20.1 Creating a Budget and Cost Types 20.2 Earned Value and Cost Forecasting 20.3 Monitoring and Reporting Financial Performance 20.4 Closing Down Project Finances

21 Risk & Issue Management

21.1 Benefits of Risk and Issue Management and Contingency Planning 21.2 The Risk and Issue Management Processes 21.3 Proactive and Reactive Risk Responses 21.4 Governance in Risk and Issue Management

22 Change Control

22.1 The Change Control Process and Its Stages 22.2 What a Change Request Must Capture 22.3 Assessing Options and the Impact of a Change 22.4 Recommending Decisions and Updating Plans

18.3 Re-Estimating and Schedule Optimisation

Key Takeaways Explain This Topic AI

Estimates improve as uncertainty reduces, so re-estimating throughout the life cycle produces forecasts that governance can actually rely on.

Fast-tracking overlaps activities that were planned in sequence, buying time at the cost of increased rework risk.

Crashing adds resource to shorten duration, buying time at the cost of money and often reduced efficiency per person.

Hidden padding inside individual estimates is worse than managed contingency because it is invisible, unmanaged, and consumed by default.

Schedule optimisation is a continuous discipline, not a one-off exercise performed when a deadline is already missed.

Last updated: August 2026

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.

• Reason to re-estimate What improved If you do not re-estimate
• Design / requirements maturity Scope clarity, interfaces known Early optimistic durations remain fiction
• Measured productivity Actual rates replace analogous guesses Cumulative delay is discovered too late
• Supplier and procurement data Real lead times and capacity External path silently becomes critical
• Risk materialisation or retirement Threats happen or fade Contingency misallocated; false confidence
• Resource changes People leave, skills differ, BAU load shifts Resource-loaded plan invalid
• Quality findings / rework Defect density known Test and fix durations understated
• External calendar changes Regulation, weather windows, funding dates Commitments miss real constraints
• Life-cycle stage gates Authorised detail for next phase Phase plans based on outdated assumptions

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

Forecast accuracy — sponsors see realistic completion and cost outlooks.

Better decisions — trade-offs (descope, accelerate, accept delay) use current data.

Risk transparency — emerging critical paths and near-critical paths become visible.

Resource planning — hiring, contractors, and BAU secondments align to true demand.

Stakeholder trust — honest updates beat surprise failure at the end.

Business-case integrity — continued investment is tested against updated time-to-benefit.

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)

Lever What you do Typical effect Main trade-off

Dependency review Remove preferential logic; challenge soft links May free float or shorten path Must not break hard logic

Re-sequence / alternative methods Different construction or delivery method Duration or risk profile changes Method risk, cost, quality

Scope phasing Deliver MVP first; defer non-critical products Earlier partial benefit; later full scope Benefits timing; stakeholder expectation

• Resource smoothing Re-time work within float to flatten peaks More stable demand May not shorten end date
• Resource levelling Resolve overallocation by delaying work Feasible staffing May extend end date
• Fast-tracking Overlap activities normally in sequence Shortens duration Higher rework/interface risk
• Crashing Add resources/cost to shorten critical activities Shortens duration Higher cost; diminishing returns
• Calendar changes Extra shifts, longer weeks (where safe/legal) Shortens duration Cost, fatigue, quality, H&S
• Procurement acceleration Earlier award, premiums, dual source Protects external path Cost and commercial risk
• 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).

• Technique Time Cost Risk pattern
• Fast-tracking ↓ elapsed Often similar direct cost ↑ rework/interface risk
• Crashing ↓ elapsed ↑ cost Risk depends on how acceleration is done
• Descope / phase ↓ or protects date May ↓ cost short term Benefits risk if value deferred
• Extend duration ↑ elapsed May ↓ peak cost Benefits delay; opportunity cost
• 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.

Practice Characteristics Control impact

Transparent contingency Explicit time/cost buffer tied to risk analysis; owned and reported Can be managed and drawn down under rules

Management reserve Held above project for unknown unknowns (governance-dependent) Requires authority to release

Hidden padding Inflated task durations or sandbagged estimates Creates false float; Parkinson’s law; weak earned value

Student syndrome Work starts late because padding is assumed Padding consumed; real risk hits unprotected

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.

• Aspect Linear (predictive) Iterative / agile-leaning
• Detail planning More detail early for known scope Rolling wave / increment-level detail

Re-estimating rhythm At gates, after major variances, before re-baseline Continuous per iteration plus release forecasts

Baseline stability Baselines change less often; formal change control Product backlog evolves; timeboxes may stay fixed while scope flexes

Optimisation focus Network logic, crashing/fast-track to protect end date Velocity-based forecast, backlog prioritisation, dependency management across teams

Still integrated? Yes — scope/schedule/cost/risk baselines Yes — roadmap, capacity, quality (DoD), budget envelope, benefits still integrated

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:

Plan — build integrated network from WBS with dependencies and estimates.

Baseline — authorise the plan at the right level.

Monitor — progress, actuals, emerging risks, BAU changes.

Re-estimate / forecast — update expected completion and intermediate milestones.

Optimise or escalate — apply levers or seek decision on date/scope/cost/risk.

Re-baseline when required — through change control so the baseline remains a true control tool.

Communicate — one integrated story to sponsor, team, suppliers, and BAU.

Benefits summarised

• Benefit Why it matters
• Early warning Slippage visible while options remain
• Credible commitments Stakeholders can plan BAU cutovers and benefits
• Efficient use of money Crash only where time is worth the cost
• Risk-aware pace Avoid reckless fast-track without mitigation
• Learning organisation Estimates improve for later phases and future projects
• Assurance-ready Reviewers see living control, not a decorative plan
• 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":

Explain why re-estimating is needed given new information.

Separate forecast from baseline change .

Offer optimisation options : logic, resources, fast-track, crash, phase/descope, accept delay.

State time–cost–quality–risk trade-offs for each option.

Reject pure hidden padding as a control strategy; prefer transparent contingency.

Match approach to linear vs iterative context.

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.