Baseline, Execute, and Analyze Schedule Variation

Introduction

This lesson covers the second half of task 8 of the Process domain in the July 2026 PMP Examination Content Outline (Process carries 41% of the exam): baseline the schedule, execute the schedule management plan, and analyze schedule variation. The previous lesson built the schedule. Here the project is moving, and the questions are: are we on track, what is causing the variance, and which response is justified?

The exam tests three kinds of skill: calculation (schedule variance, SPI, float consumption), choosing a compression technique, and judging which action is appropriate in predictive versus agile contexts. After this lesson you will be able to baseline and control a schedule, measure variance with earned schedule data and agile metrics, use crashing and fast tracking correctly, handle schedule changes through governance, and communicate schedule status.

Learning objectives

• Define the schedule baseline and explain when it can change.
• Execute the schedule management plan, collect progress data, and update the schedule.
• Compute SV, SPI, and interpret them; read float consumption and critical path changes.
• Apply schedule compression (crashing, fast tracking), resource optimization, and scope-based options.
• Analyze variation in agile projects with burndown, burnup, velocity, and cycle time.
• Process schedule changes, forecast completion, and communicate with stakeholders.

1. The schedule baseline

The schedule baseline is the approved version of the schedule model that can be changed only through formal change control procedures. It is used as the basis for comparison with actual results. It includes the agreed start and finish dates and is one component of the performance measurement baseline, along with the scope and cost baselines.

Distinguish:

A baseline should be set after the schedule is realistic, resource-loaded, and agreed with stakeholders. Rebaselining, meaning replacing the baseline with a new one, is done only for major changes, such as an approved scope change or a new funding decision. It is not a way to hide poor performance. A variance caused by lateness is reported against the original baseline.

Baselines in adaptive projects

In agile projects there is usually no detailed schedule baseline. The baseline is the product roadmap and release plan, a forecast updated after each iteration, and the iteration goals. Control is exercised by inspecting working increments, reviewing velocity, and adapting the backlog. In hybrid projects, fixed milestones (contractual, regulatory) are baselined while the iteration content is not.

2. Execute the schedule management plan

The schedule management plan sets the methods, tools, units of measure, thresholds, reporting formats, and procedures for updating the schedule. Execution means doing the work according to the plan and gathering performance data:

• Percent complete, remaining duration, and actual start and finish dates (predictive).
• Completed stories against the definition of done, burn data, and cycle time (agile).
• Issues, impediments, risks triggered, and approved changes.

The project manager should:

1. Collect progress data at regular intervals with a consistent rule for earned value (0/100, 50/50, or weighted milestones). Use rules agreed in the plan.
2. Update the working schedule and re-run the critical path.
3. Compare to the baseline and check thresholds. For example: report any variance over 5 days or any SPI below 0.9.
4. Forecast completion and prepare options for variances that exceed thresholds.
5. Communicate to stakeholders using agreed formats.

Reading float consumption

A change in float tells a story. If an activity with 10 days of float has now only 2 days, the path is becoming near-critical even though the project end date is unchanged. A project manager monitors the float of near-critical paths because small delays can shift the critical path. When two paths are within a few days of each other, risk to the end date rises.

3. Analyze schedule variance with earned value

Earned value schedule metrics from the finance lesson apply here:

• Schedule variance (SV) = EV - PV. Negative means behind.
• Schedule performance index (SPI) = EV / PV. Below 1 means behind.

Worked example: SV and SPI

Scenario. A project has a budget at completion of 600,000. At the status date, the plan called for 45% of the work (PV = 270,000). The team has completed work worth 225,000 (EV), and actual cost is 240,000.

Step 1: SV. 225,000 - 270,000 = -45,000 (behind schedule in value terms).

Step 2: SPI. 225,000 / 270,000 = 0.83. For each 1.00 of work planned, 0.83 has been done.

Step 3: interpret. The project is performing at 83% of the planned pace. If the original duration is 12 months and the trend continues, a simple forecast is 12 / 0.83 = about 14.4 months, which is 2.4 months late. This is a rough indicator, and the real forecast should come from the critical path, since SPI is based on money, not on critical activities.

Step 4: caveat. SV and SPI in cost terms can mislead: late non-critical work lowers SPI without delaying the project, while a delayed critical activity may represent small value yet delay the end date. Always check the critical path.

Step 5: act. Look for the cause. If it is a single critical path activity, apply targeted compression; if it is lack of capacity across the board, review resources and scope.

Why other readings are weaker. Deciding the project is only 15% late from the 0.83 value alone is wrong; SPI does not equal the delay in time. Ignoring the variance because the cost is near plan (CPI = 225/240 = 0.94) confuses cost with time. Rebaselining immediately hides the variance.

Earned schedule (optional concept)

Earned schedule converts earned value into time: the time at which the current EV should have been earned in the plan. If EV of 225,000 equals the planned value at month 4.2, and actual time is 5.4 months, the schedule variance in time is 4.2 - 5.4 = -1.2 months. SPI(t) = 4.2 / 5.4 = 0.78. This avoids the money-versus-time distortion near the project end.

4. Schedule compression and recovery options

When the schedule is late or the end date is moved earlier, compression shortens the schedule without reducing scope.

Both techniques apply to critical path activities only; compressing a non-critical activity does not shorten the project. After compression the critical path may change, so recompute it. Choose the activities that give the most time saving at the least additional cost (lowest cost slope).

Worked example: crashing with cost slope

Scenario. The critical path A-B-D-F is 17 days and a client wants delivery in 15 days. Crash data:

The other path A-C-E-F is 16 days; it also contains A.

Step 1: cost slope per day. A: 1,000 per day. B: 3,000 / 2 = 1,500 per day. D: 2,500 per day.

Step 2: crash the cheapest first. A is on both paths, so crashing it by 1 day (cost 1,000) shortens A-B-D-F to 16 days and A-C-E-F to 15 days.

Step 3: crash the next cheapest on the remaining critical path. A-B-D-F is still the longest (16 days). B costs 1,500 per day, less than D at 2,500. Crashing B by 1 day gives A-B-D-F = 3 + 5 + 5 + 2 = 15 days. A-C-E-F = 3 + 3 + 7 + 2 = 15 days. Both paths are now 15 days and the target is met.

Step 4: total cost. 1,000 (A by 1) + 1,500 (B by 1) = 2,500.

Step 5: consider risks. Crashing A and B adds coordination effort and may reduce quality; the project manager checks resource availability and agrees the extra cost through change control.

Why other choices are weaker. Crashing D costs 2,500 for one day, more than B. Crashing F is impossible. Crashing a non-critical activity (such as C) adds cost without shortening the project.

Other recovery options

• Resource optimization: reassign skilled people to critical tasks; resolve overallocations.
• Reduce scope or defer lower-value items (for example, moving stories out of the release), agreed with the sponsor and product owner.
• Improve productivity: remove impediments, add automation, improve the team environment.
• Reduce rework: a good quality plan prevents schedule loss.
• Change dependencies: negotiate leads, parallel work, or earlier supplier delivery.
• Adjust the end date: if compression is too costly or risky, present a revised date to the sponsor for approval.

Do not cut quality or testing silently to recover time. That moves the problem to later and increases cost of nonconformance.

5. Analyze variation in agile projects

Predictive metrics like SV rely on a baseline. Agile teams use direct measures of progress and flow.

Burnup versus burndown

A burndown chart can hide scope changes: if the line is flat, is the team slow or was new work added? A burnup chart shows the total-scope line separately, so you can see that the team completed 12 points while scope grew by 10. Use burnup for stakeholders interested in scope changes.

Worked example: reading a burnup chart

Scenario. After 5 two-week iterations, a team has completed 150 points. Total scope was 300 points at the start and is now 340 points, because 40 points of new stories were approved. The release is planned for 10 iterations.

Step 1: velocity. 150 / 5 = 30 points per iteration.

Step 2: remaining work. 340 - 150 = 190 points.

Step 3: forecast. 190 / 30 = 6.3, so about 7 more iterations, 12 in total versus 10 planned: about 2 iterations late.

Step 4: options for the product owner.

• Move 60 points of lower priority items out of the release: remaining 130 / 30 = 4.3 iterations, total about 10.
• Extend the release by two iterations.
• Add capacity, with the caution that new team members reduce velocity temporarily (Brooks' law: adding people to a late project can make it later).

Step 5: decide with the product owner and sponsor. The project manager shows the burnup, the forecast range, and the options; the product owner reprioritizes the backlog.

Why other choices are weaker. Telling the team to work overtime treats a symptom and endangers sustainable pace. Hiding the scope growth makes the team look unproductive. Rebaselining a fixed release date without a scope trade-off ignores the sponsor's constraint.

Impediments

Schedule variance in agile often traces to impediments: blocked environments, waiting for decisions, unclear acceptance criteria, or team changes. The project manager or servant leader removes or escalates them quickly. Limiting work in progress and visualizing blocked items on the board make delays visible early.

6. Handling schedule changes

When analysis shows the schedule needs to change:

1. Assess the cause and impact (critical path, cost, risk, quality, scope, resources).
2. Identify options such as crashing, fast tracking, reducing scope, or accepting a revised date.
3. Raise a change request with the analysis, for approval by the change control board or authorized decision maker, per the plan.
4. After approval, implement, update the schedule, and rebaseline if the approved change affects the baseline.
5. Communicate the decision and update related documents (risk register, issue log, forecasts, communication to stakeholders).

Distinguish a schedule issue (already happened) from a schedule risk (may happen). Delays caused by a supplier that has already failed to deliver are an issue; the possibility that a supplier may be late is a risk to respond to in advance with a plan.

Schedule reserve use

Use schedule reserves for identified risks as planned: if a risk event occurs and the response consumes 3 days of the schedule reserve, record it, update the forecast, and report the remaining reserve. If the reserve is nearly exhausted and risks remain, escalate early rather than waiting for the baseline to be missed.

7. Reporting schedule status

Schedule reports should answer: where are we, why, what is the forecast, what are we doing, and what do we need from the stakeholders. Tailor the format:

Use trends rather than single points. Be transparent: reporting bad news early gives the sponsor time to act. Include a forecast and the recommended response, not only the problem.

8. Common pitfalls and exam tips

• Pitfall: changing the baseline without approval. Baseline changes need change control.
• Pitfall: compressing non-critical work. It does not shorten the project.
• Pitfall: choosing crashing when the issue is poor requirements. Fix the cause, not only the symptom.
• Pitfall: relying on SPI alone. Check the critical path.
• Pitfall: hiding scope growth. Show it with burnup charts.
• Pitfall: asking for overtime as the first move. It is unsustainable and may reduce quality.

Exam tip: Crashing adds cost, fast tracking adds risk. If a question says "without increasing cost", think fast tracking (and mind the rework risk); "with a risk of rework" also points to fast tracking.

Exam tip: If the project manager discovers a delay, the first step is usually to analyze the cause and impact before taking action, unless the scenario says action is urgent.

Exam tip: In agile questions, forecast with velocity and adapt the backlog with the product owner; do not force a predictive baseline on an agile team.

Exam tip: Whenever a change to the baseline is proposed, the answer involves a change request and the approval route.

9. Mini case study: the slipping data migration

Context. A project to migrate a customer database has a baseline end date of 30 June. At the end of March, the status shows PV = 400,000, EV = 320,000, AC = 330,000. The critical path runs through "data cleansing", planned for 20 days and now estimated at 32 days because the source data quality is worse than expected. A parallel activity, "build reports", has 10 days of float. The sponsor insists on 30 June. The team has two free data engineers from another project, and there are discretionary dependencies between cleansing and mapping design.

Question. What should the project manager do?

Solution (commented).

1. Compute the metrics. SV = 320,000 - 400,000 = -80,000. SPI = 320 / 400 = 0.80. CPI = 320 / 330 = 0.97. The main problem is schedule, not cost.
2. Confirm with the critical path. Data cleansing is critical and is 12 days late, so the end date is forecast about 12 working days late unless action is taken. SPI alone would have suggested a larger delay; use the critical path for the real forecast.
3. Find the root cause. Poor data quality was an assumption that proved false. Update the risk register and look for similar assumptions.
4. Generate options. (a) Crash: add the two engineers to cleansing; if this cuts 8 days, the delay falls to 4 days, at a cost of extra effort. (b) Fast track: begin mapping design on cleansed subsets while cleansing continues, accepting rework risk. (c) Defer low-value report features to a later release, with the sponsor's agreement. (d) Negotiate the date.
5. Combine and evaluate. Crashing plus fast tracking could recover 10 to 12 days; confirm with the team and check the effect on cost and risk. Do not compress "build reports" because it is non-critical.
6. Raise a change request with analysis and a recommended option; obtain approval; update the schedule and report.
7. Communicate with the sponsor immediately rather than waiting for the next report, showing the forecast date with and without action.
8. Do not rebaseline to 12 days later without an approved change, and do not tell the team to skip data validation to save time.

Key terms

• Schedule baseline: approved schedule used for comparison; changed only via change control.
• Schedule variance (SV) and SPI: EV - PV, and EV / PV.
• Crashing: adding resources to shorten the critical path, at extra cost.
• Fast tracking: overlapping activities that were sequential, with rework risk.
• Burndown / burnup chart: remaining work / completed work and scope over time.
• Velocity: points completed per iteration.
• Cycle time: time to complete one item once started.
• Cumulative flow diagram: work items per state over time, showing bottlenecks.
• Schedule reserve: time added to the baseline for identified risks.
• Earned schedule: converts earned value into time.

Summary checklist

• I know what the schedule baseline is and how it can change.
• I can compute SV and SPI and recognize their limits.
• I can pick crashing or fast tracking and explain the trade-offs.
• I can choose the cheapest crash path using cost slope.
• I can read a burnup chart and forecast from velocity.
• I process schedule changes through change control.
• I distinguish a schedule issue from a schedule risk.
• I tailor schedule reports to the audience and include recommended actions.

Official sources

• PMI, PMP Examination Content Outline (July 2026): https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/new-pmp-examination-content-outline-2026.pdf (opens in a new tab)
• PMI, About the new PMP exam: https://www.pmi.org/certifications/project-management-pmp/new-exam (opens in a new tab)
• PMI, Project Management Professional (PMP): https://www.pmi.org/certifications/project-management-pmp (opens in a new tab)