A project schedule is not a one-time prediction. It is a management instrument that must be observed, updated, interpreted and, when necessary, redesigned. In software projects, progress rarely follows the original plan exactly. Requirements may change, technical dependencies may prove more difficult than expected, staff may become unavailable, or testing may reveal defects that require additional work. Effective project managers therefore treat the schedule as a controlled model of the project rather than as a fixed promise.
Schedule monitoring connects planned work with actual performance. It involves collecting reliable progress data, updating the schedule, identifying deviations, interpreting trends and deciding whether corrective action is required. Replanning then converts those decisions into an authorized and realistic future plan.
This chapter presents practical methods for schedule control, including variance analysis, trend analysis, earned value management, earned schedule, forecasting, change control and corrective replanning.
Learning Objectives
By the end of this chapter, the learner should be able to:
collect and validate schedule progress data;
distinguish baseline, current forecast and actual performance;
calculate and interpret schedule variance and schedule performance indicators;
apply earned value and earned schedule measures;
forecast likely completion dates and explain uncertainty;
identify causes of delay and distinguish symptoms from root causes;
evaluate schedule changes through formal change control;
prepare a corrective replanning response; and
recognize the limitations, ethical responsibilities and governance requirements of schedule reporting.
1. The Schedule as a Control System
Schedule control is a feedback process. The project team establishes a baseline, performs work, measures actual results, compares results with the baseline and takes action. The process is repeated at agreed reporting intervals.
A useful control loop contains five activities:
Plan: define activities, dependencies, durations, resources and milestones.
Record: capture actual starts, finishes, remaining durations and completed deliverables.
Compare: calculate deviations from the approved baseline or current control plan.
Diagnose: investigate why deviations occurred and whether they are temporary or persistent.
Act: take corrective action, approve a change or replan the remaining work.
Schedule monitoring and replanning control cycle
Figure: Schedule monitoring and replanning control cycle
Figure: Schedule control is a repeating feedback cycle rather than a single end-of-project review.
The baseline is the approved version against which performance is measured. It should include schedule logic, planned dates, milestones and, where relevant, resource and cost information. A baseline must not be silently overwritten. If the approved scope or delivery strategy changes, a revised baseline should be created through change control while the historical baseline is retained for learning and accountability.
2. Collecting Reliable Progress Data
Schedule analysis is only as good as its data. A date entered without evidence can create a false impression of progress and cause later forecasts to be unreliable.
2.1 What to collect
At each status date, the project manager should collect:
actual start and finish dates;
percentage complete, preferably linked to objective deliverables;
remaining duration or remaining effort;
completed acceptance criteria, tests or review points;
blockers, assumptions and external dependencies;
availability of assigned resources;
changes to scope, priority or technical approach; and
revised estimates supplied by the people performing the work.
A status date is the common point in time at which all progress data is assessed. Mixing observations from different dates makes comparisons misleading.
2.2 Measuring completion
Percentage complete should not be treated as a casual opinion. Suitable techniques include:
Milestone method: completion is recognized when a defined milestone is achieved.
0/100 method: an activity earns no progress until fully complete. This is useful for short, discrete tasks.
50/50 method: half the planned value is credited at start and the remainder at finish; it is suitable only for relatively short, low-risk activities.
Weighted milestone method: progress is credited when objectively defined sub-results are completed.
Physical measurement: progress is based on accepted outputs, such as tested functions or completed interfaces.
For software work, lines of code are generally a poor progress measure because they do not indicate value, quality or readiness. Accepted features, completed test conditions and verified configuration items are usually more meaningful.
2.3 Data-quality checks
Before updating the schedule, the project manager should check whether:
every in-progress activity has a current remaining-duration estimate;
completed activities have evidence of completion;
actual dates are not in the future relative to the status date;
predecessor and successor links remain valid;
open-ended activities and unintended constraints are identified;
calendars reflect holidays, leave and working-time changes; and
reported progress is consistent with defect, test and acceptance records.
A useful principle is that reporting should be evidence-based but proportionate. Excessive data collection can burden the team, while insufficient data produces late surprises.
3. Updating and Interpreting the Schedule
After collecting data, actual starts and finishes are entered, remaining durations are revised and the scheduling engine recalculates dates. The manager then compares the updated forecast with the approved baseline.
Three schedule views should be distinguished:
View
Meaning
Main use
Baseline schedule
Approved original or approved change-controlled plan
Accountability and variance measurement
Current schedule
Latest logic and actual progress
Operational management
Forecast schedule
Expected future dates based on current information
Decision-making and communication
A current schedule may contain actual performance and future estimates. A forecast date is not necessarily an approved commitment. This distinction prevents teams from presenting an optimistic estimate as an authorized promise.
3.1 Schedule variance
For an activity or milestone, a simple date variance is:
Date variance = Forecast date − Baseline date
A positive value usually indicates lateness when dates are measured from a common origin; a negative value indicates earlier completion. Units must be consistent, such as calendar days or working days. Date variance is intuitive, but it does not show the value or amount of work completed.
For a milestone originally planned for day 40 and currently forecast for day 47:
Date variance = 47 − 40 = 7 days late
3.2 Critical path and float
The critical path is the sequence of logically connected activities that determines the earliest possible project completion under the modeled assumptions. Activities on or near the critical path deserve close attention because small delays may affect the final date.
Total float can be expressed conceptually as:
Total float = Latest allowable start − Earliest possible start
Equivalently, using finish dates:
Total float = Latest allowable finish − Earliest possible finish
The units are time units. These relationships assume that the schedule network and calendars are valid. Float is not automatically a reserve of freely usable time: consuming float may move an activity onto the critical path, and shared resources or external deadlines may reduce practical flexibility.
4. Variance and Trend Analysis
Variance analysis asks, “How different are actual or forecast results from the plan?” Trend analysis asks, “Is performance improving, deteriorating or remaining stable over time?” Both are necessary.
A single late activity may be harmless if it has sufficient float. Conversely, repeated small negative variances on a critical chain may predict a major milestone failure. Managers should examine:
variance by activity, work package, release and milestone;
variance direction across successive reporting periods;
activities newly becoming critical;
changes in remaining-duration estimates;
dependencies outside the project team;
rework, defects and approval delays; and
whether reported progress is concentrated in low-value tasks.
A simple trend measure for a metric such as milestone delay is:
Trend slope = (Latest variance − Earlier variance) ÷ Number of intervals
This is a descriptive indicator, not a universal forecasting law. It assumes comparable measurement periods and a metric whose direction is meaningful. A positive slope in days late indicates worsening delay; however, a slope based on only two observations should be treated cautiously.
Root-cause analysis may use a cause-and-effect diagram, the five-whys technique or a dependency review. Common causes include underestimated complexity, unclear acceptance criteria, excessive work in progress, unavailable specialists, slow decisions, unstable environments and late defect discovery. Corrective action should address the cause rather than merely moving dates.
5. Earned Value Management for Schedule Analysis
Earned value management (EVM) integrates scope, schedule and cost through time-phased planned value. Although EVM is often associated with cost control, its schedule indicators can reveal whether the project is producing the planned amount of work.
The basic terms are:
Planned Value (PV): authorized budget for work scheduled to be completed by the status date.
Earned Value (EV): authorized budget for work actually completed by the status date.
Actual Cost (AC): actual cost incurred for the completed work by the status date.
Budget at Completion (BAC): total authorized budget for the defined scope.
The monetary unit used for PV, EV, AC and BAC may be currency or a consistent resource-value measure. EVM requires a defined scope, a time-phased baseline and objective rules for measuring completion.
5.1 Core indicators
Schedule variance (SV) = EV − PV
Schedule performance index (SPI) = EV ÷ PV
SV is expressed in value units, not days. A negative SV means that less budgeted work has been completed than planned at the status date. An SPI below 1.00 indicates that earned progress is less than planned progress. An SPI above 1.00 indicates more earned progress than planned, subject to the quality of the measurement system.
For cost analysis:
Cost variance (CV) = EV − AC
Cost performance index (CPI) = EV ÷ AC
A CPI below 1.00 indicates that the project is obtaining less budgeted value per currency unit than planned. EVM indicators should be interpreted together with actual dates, critical-path status and product quality.
5.2 Worked EVM example
A software release has a BAC of £120,000. At the status date, the plan expected £60,000 of budgeted work to be complete. The team has objectively completed £54,000 of budgeted work and has incurred £58,000 of actual cost.
Therefore:
SV = £54,000 − £60,000 = −£6,000
SPI = £54,000 ÷ £60,000 = 0.90
CV = £54,000 − £58,000 = −£4,000
CPI = £54,000 ÷ £58,000 ≈ 0.93
The project has earned £6,000 less planned value than expected and is progressing at 90% of the planned rate under this measurement system. It is also spending inefficiently. These results do not by themselves say that the final date will be exactly a particular number of days late; further schedule analysis is required.
6. Earned Schedule
Traditional SV becomes zero when the project is complete, even if completion occurred late. Earned schedule (ES) expresses earned progress in time units and helps interpret schedule performance near completion.
Let:
PV(t) be the planned value at time t;
EV be earned value at the status date; and
ES be the point on the baseline time scale at which the planned value equals EV.
In a discrete baseline, ES is found by locating the time at which cumulative PV reaches EV, often interpolating between adjacent periods. The earned schedule variance is:
SV(t) = ES − AT
where AT is actual time elapsed from the baseline start to the status date. The earned schedule performance index is:
SPI(t) = ES ÷ AT
A value below 1.00 indicates that the amount of work earned corresponds to less baseline time than has actually elapsed. Earned schedule is especially useful for schedule interpretation, but it remains dependent on the quality of the baseline and progress measurement.
Worked earned-schedule example
Suppose that at day 30 the project has earned value of £45,000. The cumulative baseline PV was £42,000 at day 27 and £48,000 at day 33. Linear interpolation gives:
Under this simplified example, earned progress corresponds exactly to 30 baseline days. If ES had been 27 at actual day 30, the time variance would have been −3 days and the time-based SPI would have been 0.90.
The interpolation assumes that planned value changes approximately linearly between the two surrounding baseline points. For highly uneven or milestone-based profiles, the result should be interpreted as an approximation.
7. Forecasting Completion
Forecasting is the disciplined estimation of likely future dates using current evidence. It is not the selection of a desired date.
7.1 Duration-based forecast
A basic forecast is obtained by adding remaining duration to the status date:
Forecast finish date = Status date + Estimated remaining duration
This is appropriate when the remaining-duration estimate has been reviewed by the responsible team and schedule logic is credible.
7.2 EVM cost forecasts and schedule caution
Common EVM cost forecasts include:
EAC = AC + (BAC − EV) ÷ CPI
where EAC is estimate at completion. This form assumes that current cost efficiency will continue and that remaining work is represented by the remaining budget.
If future work is expected to follow both the original plan and current cost performance, another commonly used form is:
EAC = AC + (BAC − EV) ÷ (CPI × SPI)
This is a management approximation, not a law of project behavior. It should not be applied mechanically, especially because SPI is based on value over time and may not predict resource productivity or the final calendar date reliably.
For schedule forecasting, managers should examine the critical path, remaining durations, resource constraints, dependency commitments and uncertainty. A schedule risk analysis may use three-point estimates:
This PERT-style estimate assumes a beta-shaped distribution and meaningful optimistic, most-likely and pessimistic estimates. It is an approximation and should not be presented as a guarantee. Confidence ranges are more honest than a single date when uncertainty is material.
8. Change Control and Corrective Replanning
Not every variance justifies a baseline change. A team should first determine whether the deviation can be managed within approved scope, authority, budget and tolerance.
A formal change-control process normally includes:
documenting the proposed change or corrective action;
explaining the reason and urgency;
assessing effects on scope, schedule, cost, quality, risk, security and resources;
identifying alternatives and their consequences;
obtaining approval from the authorized decision-maker;
updating the schedule, baseline and related plans; and
communicating the decision and retaining an audit trail.
Corrective replanning may include resequencing work, removing unnecessary handoffs, adding resources, changing a technical approach, splitting a release, reducing work in progress, accelerating decisions or negotiating a new milestone. It should not rely automatically on overtime or parallel work. Fast-tracking can increase rework and risk; crashing can increase cost and coordination overhead.
A practical replanning sequence is:
freeze the status date and preserve the previous schedule version;
confirm the actual state of work;
identify the driving cause and affected dependencies;
recalculate the critical path and float;
develop at least two feasible response options;
evaluate trade-offs and risks;
obtain approval;
enter the revised logic and dates; and
monitor the response at the next control cycle.
The revised schedule should show what changed and why. Quietly moving incomplete activities forward destroys the information needed for organizational learning.
9. Illustrative Case: The Northstar Mobile Release
Background
The Northstar team is developing a mobile ordering application for a regional retailer. The baseline planned a 16-week release consisting of design, application development, payment integration, system testing, security review and deployment. The payment integration and security review were placed on the critical path.
Problem
At the end of week 8, the baseline expected £80,000 of planned value. The team had earned £68,000 and incurred £76,000 of actual cost. A payment-provider interface had changed, and the security test environment had been unavailable for ten working days.
The indicators were:
SV = £68,000 − £80,000 = −£12,000
SPI = £68,000 ÷ £80,000 = 0.85
CV = £68,000 − £76,000 = −£8,000
CPI ≈ £68,000 ÷ £76,000 = 0.89
Analysis
The figures indicated both schedule and cost pressure, but they did not identify the cause. The project manager reviewed completed acceptance criteria, the dependency network, defect records and environment availability. The analysis showed that the main problem was not low developer effort. It was an external interface change combined with delayed access to a test environment. Several activities reported as “90% complete” had not produced testable increments, so their earned value had been overstated in earlier reports.
Approach and solution
The team corrected its progress rules so that payment integration earned value only after an agreed interface test passed. It then developed two options:
continue all features and request a four-week delay; or
defer two low-priority reporting functions, complete the payment path, reserve the test environment, and conduct security testing in a protected sequence.
The product owner approved the second option through change control. The scope of the release was reduced, but the business-critical ordering capability remained. The schedule was replanned with explicit environment reservations and a decision milestone before deployment.
Outcome
The release was delivered two weeks later than the original baseline rather than four weeks later. The deferred functions were placed in a subsequent release. The revised baseline documented the approved scope change, the new dependency dates and the reason for the change. The team also introduced weekly dependency reviews and evidence-based completion criteria.
Learning points
The case demonstrates that:
EVM identifies the existence and magnitude of pressure but requires causal analysis;
apparent progress can be misleading if completion rules are weak;
protecting a critical integration and test path may be more valuable than maintaining every feature;
replanning requires authorized scope decisions, not cosmetic date movement; and
a transparent delay can be better project governance than an unrealistic promise.
10. Governance, Ethics and Technology
Schedule information influences funding, staffing, contractual decisions and stakeholder trust. Managers therefore have an ethical duty to report material deviations accurately. Selectively reporting favorable activities, inflating percentage complete or changing the baseline to conceal delay can create misleading information and may breach organizational policy or contractual obligations.
Governance practices should define reporting frequency, tolerance thresholds, approval rights, baseline ownership, version control and escalation routes. Sensitive schedule information may also reveal security weaknesses, supplier dependencies or personal availability; access should therefore follow appropriate confidentiality controls.
Project-management tools can automate critical-path recalculation, dashboards, dependency alerts and trend charts. Artificial intelligence may assist with anomaly detection, natural-language status summaries or forecasting, but its outputs require human validation. AI systems can reproduce biased historical estimates, misunderstand causal relationships or treat missing data as evidence of progress. A responsible manager should preserve source data, explain important assumptions, protect confidential information and ensure that accountable people—not an opaque tool—make material decisions.
11. Best Practices and Limitations
Effective schedule monitoring is supported by the following practices:
establish a credible, time-phased baseline;
use a single status date for each reporting cycle;
measure completion using objective evidence;
distinguish actuals, forecasts and commitments;
monitor critical and near-critical paths;
combine date analysis with EVM, quality and risk information;
investigate trends rather than reacting to isolated numbers;
record assumptions and uncertainty;
preserve historical baselines and approvals;
replan the remaining work, not the historical facts; and
communicate bad news early with options for action.
No indicator is sufficient on its own. SPI can be distorted by front-loaded or back-loaded budgets, by inappropriate earning rules or by work that has financial value but does not drive the final completion date. A project may show acceptable EVM results while a single technical dependency threatens deployment. Conversely, a negative variance may be acceptable if an approved scope decision deliberately changed the delivery strategy. Professional judgment remains essential.
Chapter Summary
Schedule monitoring is a feedback process that compares actual performance and forecasts with an approved baseline. Reliable monitoring begins with a common status date, objective completion evidence and validated schedule logic. Date variance, float, critical-path analysis and trend analysis help explain where the plan is diverging.
Earned value provides integrated indicators: PV represents planned work, EV represents completed budgeted work and AC represents actual expenditure. SV and SPI describe schedule performance in value terms, while earned schedule expresses performance in time terms. Forecasts must state their assumptions and should be supported by critical-path, resource, dependency and risk analysis.
Corrective replanning is not the silent movement of dates. It is an authorized process that diagnoses causes, evaluates alternatives, updates future logic and preserves historical information. Ethical reporting, governance, version control and human oversight of technology are essential to trustworthy schedule decisions.
Key Terms
Actual Cost (AC): Cost incurred for completed work by the status date.
Actual Finish: The date on which an activity is genuinely completed.
Baseline: Approved time-phased plan used for comparison and control.
Budget at Completion (BAC): Total authorized budget for the defined scope.
Critical Path: Logic sequence determining the earliest modeled project completion.
Earned Schedule (ES): Baseline time corresponding to the earned value achieved.
Earned Value (EV): Budgeted value of work objectively completed.
Estimate at Completion (EAC): Forecast of total cost at project completion.
Float: Time an activity can move without violating a relevant schedule constraint.
Forecast: Current expectation of a future date or result.
Milestone: Significant event or decision point with zero or minimal duration.
Planned Value (PV): Budgeted value of work scheduled by a specified date.
Replanning: Authorized redesign of remaining schedule work and logic.
Schedule Performance Index (SPI): EV divided by PV.
Schedule Variance (SV): EV minus PV.
Status Date: Common date used to assess project progress.
Trend Analysis: Examination of performance direction across reporting periods.
Variance: Difference between planned, actual or forecast performance.
Review Questions
Short Answer Questions
Why should a schedule baseline be preserved rather than silently overwritten?
What is the difference between a status date and a forecast finish date?
Define planned value, earned value and actual cost.
Why can percentage complete be misleading in software projects?
What information should be collected when updating an in-progress activity?
Long Answer Questions
Explain the schedule-monitoring control cycle and describe how each stage supports project control.
Compare date variance, critical-path analysis, EVM schedule indicators and earned schedule.
Explain the assumptions and limitations of using SPI and EAC for forecasting.
Describe a formal change-control process for corrective schedule replanning.
Discuss the ethical and governance responsibilities associated with schedule reporting.
Analytical / Application Questions
A project has PV of £90,000, EV of £81,000 and AC of £86,000. Calculate SV, SPI, CV and CPI, then interpret the results.
A milestone planned for working day 55 is forecast for working day 63, but it has 10 working days of total float. Explain the immediate schedule implication and identify what further information is needed.
A team reports 95% completion for a payment feature, but no integration test has passed and the external interface has changed. Propose a data-validation, analysis and replanning response.
Multiple Choice Questions with Answers
Question 1
Which measure represents the budgeted value of work actually completed by the status date?
A. Planned Value
B. Earned Value
C. Actual Cost
D. Budget at Completion
Correct Answer: B. Earned Value
Question 2
A project has EV = £45,000 and PV = £50,000. What is its SPI?
A. 0.90
B. 1.11
C. £5,000
D. −£5,000
Correct Answer: A. 0.90
Question 3
What does a negative schedule variance in EVM generally indicate?
A. Actual cost is below budget
B. More work was completed than planned
C. Less budgeted work was completed than planned
D. The project is necessarily late by the same number of days
Correct Answer: C. Less budgeted work was completed than planned
Question 4
Which practice provides the strongest evidence that a software feature is complete?
A. The developer estimates 100% completion
B. Most source code has been written
C. The feature has passed defined acceptance criteria
D. The activity has consumed its planned duration
Correct Answer: C. The feature has passed defined acceptance criteria
Question 5
What is the primary purpose of a status date?
A. To authorize overtime
B. To provide a common point for assessing progress
C. To replace the approved baseline
D. To eliminate schedule uncertainty
Correct Answer: B. To provide a common point for assessing progress
Question 6
If ES is 27 days and actual time elapsed is 30 days, what is the earned schedule variance?
A. 3 days
B. −3 days
C. 57 days
D. 0.90 days
Correct Answer: B. −3 days
Question 7
Which action is most appropriate before changing an approved baseline?
A. Move all incomplete activities forward
B. Delete the original schedule
C. Assess impacts and obtain authorized change approval
D. Report only favorable activities
Correct Answer: C. Assess impacts and obtain authorized change approval
Question 8
A CPI below 1.00 generally means that the project is:
A. Obtaining less budgeted value per currency unit than planned
B. Completing more work than planned
C. Guaranteed to finish late
D. Using no resources
Correct Answer: A. Obtaining less budgeted value per currency unit than planned
Question 9
Which situation most clearly requires causal analysis rather than immediate date movement?
A. A critical dependency is blocked by an unavailable test environment
B. A completed milestone has objective acceptance evidence
C. A baseline date is unchanged
D. A planned activity has positive float
Correct Answer: A. A critical dependency is blocked by an unavailable test environment
Question 10
Why should AI-generated schedule forecasts be reviewed by a project professional?
A. AI cannot display dates
B. AI outputs may reflect poor data, hidden assumptions or misleading correlations
C. AI always produces schedules without dependencies
D. AI is legally authorized to approve all changes
Correct Answer: B. AI outputs may reflect poor data, hidden assumptions or misleading correlations