Monitor and Control Schedule in PMBOK 8 — Complete Guide

Article updated in March 2026 for the PMBOK® Guide — Eighth Edition.

Monitor and Control Schedule in PMBOK 8 — Complete Guide

Formerly known as: Control Schedule (PMBOK 6)

The project manager was three weeks from the planned go-live when the sponsor asked the question she had been dreading: “Are we on track?” She knew the answer was no — but she had no data to quantify how far off track they were. No earned value metrics. No trend data. No SPI calculation. Just a subjective sense that things were “a bit behind.” She gave a reassuring answer, the sponsor made decisions based on that reassurance, and three weeks later the project missed the go-live by six weeks. The six-week delay had been building for two months; it just was not being measured.

The conversation that never happened — the one backed by schedule performance data, trend analysis, and a clear projection of the expected completion date — is what Monitor and Control Schedule enables. It is Process 3 of PMBOK 8’s Schedule Domain, and its fundamental value is providing the visibility that transforms schedule management from reactive fire-fighting into proactive performance management.

This guide covers everything you need to master Monitor and Control Schedule:

• What it is — definition, PMBOK 8 position, and what changed from PMBOK 6
• Why use it — direct benefits and the cost of failing to control schedule
• Full ITTO — from the official PMBOK 8 PDF
• Step-by-step application guide
• When to apply it
• Two real-world examples — Project Phoenix and Project ProjectAdm
• Templates and downloads
• Five common errors
• Tailoring — predictive, agile, and hybrid
• Process interactions
• Quick-application checklist

1. What Is Monitor and Control Schedule

Monitor and Control Schedule is the process of monitoring the status of the project to update the project schedule and managing changes to the schedule baseline or agreed-upon schedule. Its key benefit is maintaining a realistic schedule throughout the duration of the project.

Updating the schedule requires knowing the actual or forecasted performance to date. The process is concerned with:

• Determining the current status of the project schedule
• Influencing the factors that create schedule changes
• Reconsidering necessary schedule reserves
• Determining if the overall project schedule has changed
• Managing the actual changes as they occur

In predictive approaches, any change to the schedule baseline can only be approved through the integrated change control process (Assess and Implement Changes). In adaptive approaches, Monitor and Control Schedule focuses on sprint velocity tracking, burnup/burndown analysis, backlog reprioritization, and retrospectives — the mechanisms through which the agile schedule is continuously managed and adjusted.

What changed from PMBOK 6 to PMBOK 8

2. Why Use Monitor and Control Schedule

Direct benefits

• Early detection of schedule variances: Regular schedule monitoring detects deviations before they compound into irrecoverable delays. A Schedule Performance Index (SPI) of 0.85 detected in week 4 is recoverable with focused corrective action. The same SPI sustained through week 8 without detection may require fundamental scope reductions to recover.
• Data-backed communication with stakeholders: Schedule monitoring provides the PM with specific, measurable data to communicate schedule status objectively: the SPI value, the current variance in calendar days, the expected completion date based on current performance, and the confidence level of the forecast. This data-backed communication is far more credible and useful than subjective assessments.
• Proactive schedule recovery: When schedule variances are detected early, a range of recovery techniques is available: schedule compression (fast-tracking or crashing), resource optimization (resource leveling or smoothing), scope reduction (deferring non-critical deliverables), or increased contingency consumption. Late detection eliminates most of these options.
• Maintained baseline integrity: Approved schedule changes are incorporated into the baseline through formal change control. This ensures the baseline remains the authoritative reference for performance measurement throughout the project.
• Contractor and vendor management: For projects involving external contractors, regular schedule status reviews and milestone walkthroughs verify that contractor progress is on track. Schedule monitoring of contractor performance prevents the common pattern of discovering a contractor is significantly behind schedule only when a milestone payment is due.

The cost of failing to control schedule

• Late-stage schedule collapses: Projects that do not monitor schedule consistently during execution face a predictable pattern: slow, undetected drift during the first half of the project followed by a schedule collapse in the second half as all deferred decisions and accumulated delays become simultaneously visible.
• Stakeholder surprises: Stakeholders who receive no schedule performance data during execution and discover delays only at milestone reviews lose trust in the PM’s ability to manage the project. Trust, once lost, is difficult to rebuild and creates governance friction for the remainder of the project.
• Suboptimal recovery decisions: Recovery decisions made under crisis pressure (after a schedule collapse is discovered late) are rarely optimal. They typically involve overtime, fast-tracking with inadequate quality safeguards, or forced scope reductions that eliminate high-value features. Early detection produces better recovery options and better decisions.

3. Inputs, Tools & Techniques, and Outputs (ITTO)

The following table presents the complete ITTO of Monitor and Control Schedule as defined in PMBOK 8 (Figure 2-24, p.159):

Inputs explained

Schedule management plan: Defines the control thresholds, performance measurement rules, and reporting format that govern all schedule monitoring activities. Monitor and Control Schedule applies the process defined in the schedule management plan — it does not invent a new process each time it is executed.

Performance measurement baseline: The integrated baseline (scope + schedule + cost) is the reference against which actual schedule performance is measured. Schedule performance index (SPI) and schedule variance (SV) calculations require a defined baseline with planned value data for each time period.

Project schedule: The current approved schedule (including any previously approved changes) is the operational reference for tracking. The schedule contains the planned start and finish dates for all activities — the comparison point for actual performance data.

Work performance data: Raw data from project execution: activity start and finish dates, percentage complete for in-progress activities, actual duration data, and resource utilization data. Work performance data is transformed into work performance information through analysis.

Product backlog (adaptive): In agile projects, the product backlog is the adaptive equivalent of the project schedule. The backlog’s current state — total story points remaining, sprint velocity, and forecasted completion date — provides the schedule performance data for adaptive monitoring.

Tools & Techniques explained

Earned value analysis: The most powerful quantitative technique for schedule monitoring. Key EVA metrics: Schedule Variance (SV = EV − PV; negative value indicates behind schedule); Schedule Performance Index (SPI = EV / PV; values below 1.0 indicate behind schedule); Estimated Time to Complete (ETC); Estimated Duration at Completion (EAC for schedule). EVA provides an objective, quantitative basis for schedule status communication that removes subjectivity from progress reporting.

Burnup/burndown charts: The primary schedule tracking tool for adaptive projects. Burndown charts show remaining work (story points, tasks, or features) declining toward zero over time. Burnup charts show completed work increasing toward the total scope target. Burnup charts are generally preferred for schedule management because they simultaneously show scope completion progress and any scope additions — making scope creep visible alongside velocity data.

Trend analysis: Examination of SPI or velocity values over multiple periods to identify persistent patterns. A team with SPI values of 0.92, 0.89, 0.85, and 0.82 over four consecutive periods is on a deteriorating trend that will produce a significant schedule overrun. Trend analysis identifies this pattern while recovery options are still available.

Critical path method: Recalculation of the critical path from the current schedule status to identify which activities now determine the project end date. In a project with significant variance, the critical path often shifts: activities that were previously on the critical path may have float recovered by corrective actions, while other activities have had their float consumed. Critical path recalculation after significant variances is essential for accurate schedule forecasting.

Schedule compression: Recovery techniques applied when the schedule baseline needs to be recovered: fast-tracking (executing activities in parallel that were originally planned sequentially — increases risk); crashing (adding resources to critical path activities to reduce their duration — increases cost). Both are constrained recovery options with trade-offs that must be assessed and documented.

Velocity: In agile projects, velocity is the primary schedule performance metric — the average number of story points completed per sprint. Velocity enables sprint-based schedule forecasting: if 40 story points remain and the team’s rolling average velocity is 10 points per sprint, the project will complete in approximately 4 sprints. Velocity stability (or instability) is a key indicator of team and process health.

Daily coordination meetings (stand-ups): In agile and hybrid projects, the daily stand-up (or daily scrum) is the primary real-time schedule monitoring mechanism. Three questions — What did I complete? What will I do next? What is blocking me? — provide daily visibility into schedule progress and impediments. Blockers identified in the stand-up should be resolved within 24 hours to prevent single-day delays from compounding into sprint misses.

Sprint reviews: The end-of-sprint ceremony where the team demonstrates completed work to stakeholders. Sprint reviews provide formal schedule visibility: what was committed, what was completed, and what was not completed. Sprint review outcomes directly update the schedule forecast and the burnup chart.

Outputs explained

Schedule forecasts: Estimates of the project completion date based on current schedule performance. Common forecasting methods: EAC for schedule (based on earned value performance data); burnup projection (based on current velocity and remaining backlog); critical path recalculation (based on current activity completion status). Schedule forecasts should be presented as ranges (e.g., P50/P80 completion dates) rather than single-point estimates, reflecting the inherent uncertainty in forecasting.

Work performance information: The analyzed and structured schedule performance data: SPI, SV, ETC, EAC, variance explanations, trend analysis results, and any risk implications of current schedule performance. Work performance information is the input to stakeholder communications and to the change control process when schedule changes are required.

Change requests: Formal requests for schedule baseline adjustments triggered by approved scope changes, resource availability changes, or corrective action plans that require baseline updates. Change requests from schedule monitoring should include the impact analysis that justifies the baseline change.

4. How to Apply the Process Step by Step

Step 1 — Collect work performance data

At each monitoring cycle, collect actual performance data from all team members and sources: actual start and finish dates for completed activities; percentage complete and actual hours expended for in-progress activities; sprint velocity for adaptive components; and contractor/vendor milestone completion status. Establish a consistent data collection mechanism (team self-reporting in the project management tool, automated time tracking, or a structured status template) so data quality is consistent across the team.

Step 2 — Update the schedule model

Enter the collected work performance data into the project schedule (Gantt chart, project management software, or backlog tool). Update actual start and finish dates. Recalculate forecasted completion dates for in-progress activities based on current actual duration and percent complete data. Allow the scheduling tool to recalculate the critical path and projected end date.

Step 3 — Calculate schedule performance metrics

Calculate the key schedule performance metrics defined in the schedule management plan: SPI and SV for each WBS element and for the overall project (predictive); sprint velocity and burnup projection (adaptive). Compare current metrics to the previous period’s metrics to identify trends. Compare to the control thresholds in the schedule management plan to determine whether corrective action or escalation is required.

Step 4 — Analyze variances and identify root causes

For any activity, WBS element, or sprint where performance falls below thresholds, perform variance analysis: What was planned? What actually occurred? What is the variance? What caused it (root cause)? Is the root cause resolved or ongoing? If ongoing, what is the projected impact on the completion date? Root cause identification is essential for effective corrective action — corrective actions that address the symptom without addressing the root cause will produce short-term improvement followed by recurrence.

Step 5 — Develop corrective action plans

For variances exceeding thresholds, develop and document corrective action plans: the specific actions to be taken; the expected impact on the schedule; the resources required; the risks introduced by the corrective actions; and the timeline for expected recovery. For schedule compression actions, explicitly document the quality and risk trade-offs to ensure the sponsor makes an informed approval decision.

Step 6 — Produce schedule performance reports and forecasts

Compile work performance information and schedule forecasts into the stakeholder-facing schedule status report in the format and frequency defined in the schedule management plan. Include: current schedule status (SPI/SV or velocity/burnup); trend analysis (improving, stable, or deteriorating); expected completion date and range; active corrective actions; and any change requests in process. Deliver the report on the agreed schedule, without exception.

5. When to Apply Monitor and Control Schedule

• Every status reporting cycle without exception: Schedule monitoring is not optional or situational. It is executed at every status reporting cycle regardless of whether problems are suspected.
• When work performance data reveals a significant variance: A variance exceeding the defined control thresholds triggers immediate corrective action analysis, not deferred to the next reporting cycle.
• At phase gates: Comprehensive schedule performance reviews at phase gate decisions assess whether the project’s schedule performance supports proceeding to the next phase.
• When an approved scope change affects the schedule: Approved scope changes trigger schedule model updates and, if they affect the critical path, schedule baseline revisions through formal change control.
• When a resource change affects the schedule: Team member departures, contractor performance issues, or resource availability changes trigger schedule model updates and corrective action assessment.

6. Two Real-World Examples

Project Phoenix — TechCorp Website Relaunch

Alex Morgan monitored the Project Phoenix schedule using Microsoft Project with weekly data collection. Every Monday, team leads entered their actual hours and percent complete data. Alex calculated SPI for each of the five WBS Level 2 deliverables and the overall project. In week 9, the Frontend Development deliverable showed an SPI of 0.78 — below the 0.85 threshold defined in the schedule management plan. This triggered the Tier 2 escalation protocol: Alex prepared a one-page corrective action plan for Sarah Chen.

Root cause analysis revealed that the frontend developer had discovered unexpected browser compatibility issues that added approximately 22 hours of unplanned remediation work. The corrective action plan included: two overtime days for the frontend developer in weeks 10 and 11 (net cost: $1,400 at overtime rate); reprioritization of two lower-priority features to Phase 2 to recover critical path float; and a 3-day schedule buffer consumption for the Frontend Development deliverable. Sarah Chen approved the plan in a 20-minute call. The SPI recovered to 0.91 by week 12, and the go-live date was maintained.

Project ProjectAdm — SaaS Project Management Platform

Eduardo tracked ProjectAdm’s schedule performance through sprint velocity and burnup charts. During sprint 5, velocity dropped to 7 story points (from a rolling average of 12). The sprint retrospective identified two root causes: one team member was sick for three days; and a significant refactoring requirement had been discovered mid-sprint that had not been estimated. Neither was a systematic problem, so no corrective action was triggered beyond noting in the lessons learned register the need to add a “discovery spike” user story at the start of each sprint for architectural assessment.

In sprint 8, velocity dropped again to 8 points. Combined with the sprint 5 drop, the burnup chart was showing a 6-story-point gap between planned and actual completion. Eduardo triggered a schedule analysis: at the current trend, the Q2 investor board release would miss by approximately 1.5 sprints. Root cause: the product owner had been adding on average 4–5 story points per sprint through informal additions approved by the CEO without product owner triage. Eduardo presented the burnup chart data at the Q1 board meeting and obtained alignment on a scope freeze policy for the Q2 release: no new stories added to the Q2 backlog without written product owner approval. Velocity stabilized at 11–13 points for sprints 9–12, and the Q2 release was delivered one sprint ahead of the revised forecast.

7. Templates & Downloads

• Schedule Management Plan Template: Download — includes control thresholds, reporting format, and performance measurement rules.
• Project Schedule Template: Download — WBS-based schedule for software development with baseline and actual columns.
• Schedule Baseline Template: Download — the approved schedule baseline document for performance measurement reference.

8. Five Common Errors

Error 1 — Monitoring schedule completion without measuring performance

The most common schedule monitoring error is tracking activity completion (which activities are done) without calculating performance metrics (SPI, SV, or velocity). Knowing that 60% of activities are complete does not tell the PM whether the project is on track — it depends on how much time has elapsed and how much time was planned. Performance metrics provide the comparative analysis that activity completion alone cannot.

Error 2 — Allowing the schedule baseline to drift informally

When actual dates diverge from the baseline, many PMs update the schedule’s planned dates to match the actual dates — effectively rewriting history. This “baseline drift” practice makes the schedule look current but destroys its value as a performance measurement reference. The baseline must remain fixed until a formal change request is approved. Actual variances should be recorded as variances, not hidden through baseline resets.

Error 3 — Reporting schedule status without trend data

A single-period schedule performance report provides a snapshot. Trend data across multiple periods tells the story that the snapshot cannot: Is performance improving, stable, or deteriorating? A project with SPI = 0.85 that was 0.75 last week is on a positive trend. A project with SPI = 0.90 that was 0.95 last week is on a negative trend. Always include trend data in schedule performance communications.

Error 4 — Applying schedule compression without documenting quality and risk trade-offs

Fast-tracking and crashing are legitimate schedule recovery tools, but they introduce risks that must be explicitly assessed and accepted. Fast-tracking activities that have technical dependencies increases the probability of rework. Crashing with overtime reduces team capacity for quality assurance. These trade-offs must be documented in the corrective action plan and explicitly accepted by the sponsor — not quietly absorbed by the project team.

Error 5 — Not updating the risk register after schedule variances

Schedule variances have risk implications that must be assessed. A delay in a predecessor activity may have activated previously identified schedule risks. A corrective action that consumes schedule reserves may have changed the risk exposure for future milestones. After any significant schedule variance, review the risk register and update the risk assessments for schedule-related risks.

9. Tailoring Considerations

10. Process Interactions

Inputs from: Plan Schedule Management (schedule management plan, control thresholds, measurement rules); Develop Schedule (project schedule, schedule baseline, schedule data); project execution (work performance data); Develop Scope Structure (scope baseline for integrated performance measurement).

Feeds into: Governance Domain’s Assess and Implement Changes (change requests for schedule baseline adjustments); Monitor and Control Finances (schedule performance data feeds into integrated cost-schedule performance analysis); risk register updates feed into Risk Domain monitoring processes.

Interactions with other domains: Finance Domain (SPI and SV data are inputs to financial forecasting; schedule changes affect cost baseline); Scope Domain (scope changes trigger schedule model updates; scope monitoring and schedule monitoring share the performance measurement baseline); Resources Domain (resource optimization decisions in schedule recovery affect resource allocation in the Resources Domain); Risk Domain (schedule variances trigger risk register reviews; risk responses may include schedule recovery actions).

11. Quick-Application Checklist

• Work performance data collected from all team members at each monitoring cycle?
• Schedule model updated with actual performance data?
• SPI and SV (or velocity and burnup) calculated for each monitoring period?
• Current performance compared to schedule management plan control thresholds?
• Trend analysis performed across multiple monitoring periods?
• Root cause analysis completed for all variances exceeding thresholds?
• Corrective action plan developed and approved for threshold-triggering variances?
• Schedule forecasts produced (expected completion date and range)?
• Schedule performance report produced and distributed in agreed format and on agreed schedule?
• Risk register reviewed and updated for schedule-related risk implications?

Call to Action:

References

Project Management Institute (PMI). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Eighth Edition. Newtown Square, Pennsylvania, USA: Project Management Institute, 2025.

PMBOK Guide 8: The New Era of Value-Based Project Management. Available at: https://projectmanagement.com.br/pmbok-guide-8/

Disclaimer

This article is an independent educational interpretation of the PMBOK® Guide – Eighth Edition, developed for informational purposes by ProjectManagement.com.br. It does not reproduce or redistribute proprietary PMI content. All trademarks, including PMI, PMBOK, and Project Management Institute, are the property of the Project Management Institute, Inc. For access to the complete and official content, purchase the guide from Amazon or download it for free at https://www.pmi.org/standards/pmbok if you are a PMI member.