Try 10 focused PMI-SP questions on Schedule Monitoring and Controlling, with answers and explanations, then continue with PM Mastery.
| Field | Detail |
|---|---|
| Exam route | PMI-SP |
| Topic area | Schedule Monitoring and Controlling |
| Blueprint weight | 35% |
| Page purpose | Focused sample questions before returning to mixed practice |
Use this page to isolate Schedule Monitoring and Controlling for PMI-SP. Work through the 10 questions first, then review the explanations and return to mixed practice in PM Mastery.
| Pass | What to do | What to record |
|---|---|---|
| First attempt | Answer without checking the explanation first. | The fact, rule, calculation, or judgment point that controlled your answer. |
| Review | Read the explanation even when you were correct. | Why the best answer is stronger than the closest distractor. |
| Repair | Repeat only missed or uncertain items after a short break. | The pattern behind misses, not the answer letter. |
| Transfer | Return to mixed practice once the topic feels stable. | Whether the same skill holds up when the topic is no longer obvious. |
Blueprint context: 35% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.
These questions are original PM Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.
Topic: Schedule Monitoring and Controlling
As of the September 18 status date, the project uses a Monday-Friday calendar. Activity Cable Pull is on the driving path to a contractual milestone. It has an FS dependency from Tray Installation with no lag; the predecessor actually finished on September 11, so the September 12 actual start is valid. There are no constraints on Cable Pull. Five working days have elapsed since the actual start.
Update received
| Original duration | Actual start | % complete | Remaining / ETC |
|---|---|---|---|
| 10 working days | September 12 | 90% | 8 working days |
Which action best preserves forecast credibility?
Best answer: B
What this tests: Schedule Monitoring and Controlling
Explanation: The actual start is credible because it follows the predecessor logic and calendar. The problem is the status quality: a 10-day activity with 5 days elapsed and 8 days still estimated cannot support a reliable 90% complete entry without validation. The scheduler should confirm objective progress and remaining work before publishing the forecast.
A credible schedule update must reconcile actual dates with remaining work. In this case, the logic and actual start are fine: the predecessor finished, there is no lag, and no constraint is blocking the start. But the status values do not tell a consistent story. After 5 working days on a 10-day activity, reporting 90% complete while still needing 8 working days suggests the percent-complete entry is not reliable enough to drive the forecast.
The key takeaway is that percent complete is a weak control signal when it conflicts with actual dates and remaining work.
The actual start is traceable, but 90% complete conflicts with the elapsed time and remaining work, so the forecast should rely on validated remaining duration/ETC.
Topic: Schedule Monitoring and Controlling
On a predictive project, the status date is June 12, 2026.
Calendar: Monday-Friday
Driving path: Build interface -> System test -> Go-live
Build interface: 4 working days remaining
System test: 5 working days, FS after Build interface
Go-live baseline date: June 28, 2026
Go-live constraint: none
To mitigate a supplier-delay risk, the team approves a second tester and decides to replace System test with two parallel 2-day test activities followed by a 1-day consolidation activity. The mitigation may be executed now, but no schedule baseline change has been approved. What should the scheduler update?
Go-live for June 28 and keep the original test logic.System test to 3 days and avoid adding new activities to keep the schedule simpler.Best answer: B
What this tests: Schedule Monitoring and Controlling
Explanation: An approved mitigation should be represented in the current schedule model so the forecast reflects the new execution plan. Because no baseline change has been approved, the baseline dates remain the reference for variance measurement.
The key distinction is between the schedule model/forecast and the schedule baseline. Once the team approves a mitigation for execution, the scheduler should update the live model to show the real work, logic, and resource use—in this case, the split test activities and their consolidation step. After recalculation, forecast dates may improve because the work is now planned in parallel.
The baseline does not change just because the mitigation is being used. The June 28 Go-live baseline date remains the approved reference until formal change control authorizes a baseline revision. Replacing baseline dates, forcing a date constraint, or hiding the mitigation inside a shorter duration may make the schedule look cleaner, but each one weakens traceability, float analysis, or forecast credibility.
Mitigation updates the forecast first; approved change control updates the baseline.
The mitigation changes the live schedule model and forecast, but the baseline stays as the approved control reference until a baseline change is approved.
Topic: Schedule Monitoring and Controlling
On a data center project, the status date is September 5. The baseline for substantial completion is September 30, but the forecast is October 6.
Exhibit: Schedule update
Driving path: Functional testing -> client witness test -> turnover
Float on driving path: 0 days
Punch-list finishing float: 7 days
Client note: Phased turnover by subsystem is allowed if test records are complete
Which action best addresses the driving schedule constraint?
Best answer: C
What this tests: Schedule Monitoring and Controlling
Explanation: The delay is on the zero-float path through functional testing, client witness testing, and turnover. Phased turnover is the only choice that changes that driving sequence without hiding variance or bypassing a required acceptance dependency.
In schedule recovery, the best action is the one that directly addresses the constraint causing the slip. Here, the late forecast is driven by the zero-float path from functional testing through client witness testing to turnover. The stem also states that the client allows phased turnover by subsystem when records are complete, so resequencing acceptance this way is a valid what-if option that can recover time on the driving path.
The tempting alternatives may look faster or easier, but they do not improve the actual driver of the completion date.
Phased turnover changes the zero-float testing and acceptance sequence, directly addressing the driver of the late forecast.
Topic: Schedule Monitoring and Controlling
At the March 15 data date, a hospital fit-out project forecasts completion 12 working days late. A schedule audit shows three critical-path activities have Finish No Later Than constraints, a 15-day lag links Install medical gas piping to Pressure test with no documented basis, and commissioning uses a 24/7 calendar even though the crew works weekdays only. What is the best corrective action?
Best answer: D
What this tests: Schedule Monitoring and Controlling
Explanation: Model integrity comes before compression or rebaselining. Because the network has excessive constraints, an unsupported lag, and an invalid calendar, the reported critical path and late forecast may be misleading, so the scheduler should fix the model first and then recalculate.
A late forecast is not reliable when the schedule model itself is distorted. In this case, hard date constraints can override logic, an undocumented lag may be masking real work or arbitrary waiting time, and a 24/7 calendar overstates available working time for a weekday crew. The best control decision is to restore model integrity and then rerun the schedule to identify the true driving path and realistic finish date.
Compressing work or rebaselining before that would be acting on a potentially false schedule signal.
Recovery decisions should follow correction of invalid constraints, unsupported lag, and wrong calendars so the driving path and forecast are credible.
Topic: Schedule Monitoring and Controlling
At the June 15 data date, a critical vendor integration activity is only 40% complete, and the owner confirms 8 working days remain. If those facts are entered, the forecast for the regulatory test-start milestone moves from the June 24 baseline date to July 3, exceeding the variance threshold. No scope change has been approved. The sponsor asks the scheduler to “reset the baseline so the report stays green.” What should the scheduler do?
Best answer: D
What this tests: Schedule Monitoring and Controlling
Explanation: A reported delay on a critical activity requires a schedule model update and a new forecast, not an automatic baseline change. The baseline remains the approved control reference until formal change control authorizes a revision, while the change log only documents requests and decisions.
When valid status information shows a critical-path activity is late, the scheduler should first update the schedule model with current facts such as progress and remaining duration. That updated model produces the current forecast, which may now show July 3 instead of the June 24 baseline milestone. The baseline does not move just because the forecast is late; it changes only after an approved change-control decision. A change-log entry is useful for documenting a requested rebaseline or related actions, but it does not replace updating the current schedule or issuing an accurate forecast.
The key distinction is that forecast updates reflect current reality, while baseline changes require authorization.
This preserves baseline integrity by updating current status and forecast now while reserving any baseline revision for approved change control.
Topic: Schedule Monitoring and Controlling
As of the May 15 data date on a plant startup project, the approved schedule baseline still commits to a July 31 commissioning milestone, and baseline dates can change only through approved change control. Only one commissioning specialist is available for recovery work in the next two weeks.
| Path | Baseline total float | Current total float |
|---|---|---|
| A: piping test -> punch fixes | 0 days | +3 days |
| B: vendor FAT -> site integration | +2 days | -1 day |
The vendor FAT slipped 3 working days, and Path B now drives the milestone forecast. What is the BEST action?
Best answer: D
What this tests: Schedule Monitoring and Controlling
Explanation: In schedule control, the current driving path and current total float show where the real date risk is. Path B has moved to negative float and now drives the July 31 commitment, so limited recovery effort should be focused there and reported against the unchanged baseline.
The key concept is that schedule impact is determined by the current driving path and current float, not by which path was critical in the baseline. In this update, Path A has gained float, while Path B has lost float and moved to -1 day, meaning it now threatens the July 31 commissioning milestone. Because only one specialist is available, the scheduler should direct recovery attention to Path B first.
Focusing on the old baseline critical path would use scarce recovery capacity without protecting the committed date.
Path B now has negative float and drives the milestone, so recovery and reporting should focus there while the approved baseline remains the control reference.
Topic: Schedule Monitoring and Controlling
A project’s change control board approves adding a new regulatory test before deployment, which inserts a new dependency and moves a contract milestone by 10 working days. The scheduler has updated the schedule model. What is the best documentation action next?
Best answer: A
What this tests: Schedule Monitoring and Controlling
Explanation: When an approved change affects schedule logic or milestones, the key need is traceability. The scheduler should document the approved change and its impact in the schedule change log rather than treating the new dates as routine status or overwriting the baseline.
This situation is about documenting an approved schedule change, not merely reporting current status. Because the change adds a new dependency and shifts a contractual milestone, the project needs a clear record of what changed, who approved it, and what schedule impact resulted. The schedule change log is the correct artifact for that history and supports later analysis, audits, and forensic review.
Updating the schedule model is necessary, but documentation must preserve control evidence. A forecast reflects the current expected outcome, while the baseline remains the approved reference unless a formal baseline change is also authorized. A status report communicates current conditions to stakeholders, but it does not replace the need for controlled change documentation. Likewise, forcing dates with constraints without documenting the logic change weakens schedule integrity.
The key distinction is approved schedule change documentation versus routine status reporting or overwriting baseline data.
An approved change that alters logic or milestones should be traceable in the schedule change log, including approval and impact history.
Topic: Schedule Monitoring and Controlling
At the July 1 status update on a hospital expansion project, a critical-path transformer delivery is already 8 workdays late. The forecast energization date moved from the October 10 baseline to October 18, and no change request to move the contractual turnover milestone has been approved. Which response is a recovery plan, a form of corrective action, rather than a preventive action, workaround, or rebaseline decision?
Best answer: D
What this tests: Schedule Monitoring and Controlling
Explanation: A recovery plan is used after a schedule issue has already occurred and the team is trying to regain a threatened milestone. Adding resources and extra working time to remaining critical-path work is a corrective response aimed at recovery, not a baseline change, workaround, or future-focused prevention step.
A recovery plan is a specific kind of corrective action used when schedule variance already exists and the team needs to recover a threatened date. In this scenario, the transformer delay has already happened, it affects the critical path, the forecast is later than the baseline, and the contractual milestone has not been formally changed. The best response is to compress the remaining driving work, such as adding a second crew and weekend commissioning, to try to regain time while keeping the approved baseline in place.
The closest trap is resetting the baseline to the forecast, which hides variance instead of controlling it.
It compresses remaining critical-path work to recover the committed date while preserving the approved baseline for variance measurement.
Topic: Schedule Monitoring and Controlling
A contractor claims a 10-workday excusable delay to a contractual turnover milestone. On the September 30, 2026 status date, the current schedule uses a 5-day workweek and shows Vendor FAT -> Site Install -> Regulatory Test -> Turnover as the driving FS path; three milestone dates also have Finish On constraints. The team kept monthly PDF reports but did not retain archived native update files, approved baseline copies, or a dated log of logic/constraint changes. Which missing documentation most clearly makes the record insufficient for forensic schedule analysis?
Best answer: A
What this tests: Schedule Monitoring and Controlling
Explanation: Forensic schedule analysis depends on reconstructing what the schedule model looked like over time, not just viewing the latest forecast. Without archived native files, baseline history, and dated records of logic and constraint changes, you cannot reliably prove when a delay became driving.
The core issue is schedule traceability. Even though the current file shows a status date, calendar, FS driving path, and Finish On constraints, forensic analysis must establish what the approved schedule and each update looked like at the time decisions were made. That requires archived native schedule files, approved baseline records, and a dated history of logic and constraint changes.
PDF reports and summaries may show dates, but they usually do not preserve enough model detail to test relationships, float movement, calendar effects, or when a hard constraint was introduced. Without that audit trail, an analyst cannot separate true delay causation from later schedule edits or cleanup. Helpful reporting is not a substitute for versioned, traceable schedule evidence.
Forensic analysis needs a time-phased audit trail of the actual schedule model, approved baseline, and dated logic or constraint changes.
Topic: Schedule Monitoring and Controlling
A predictive project approved this response at baseline approval: if prototype defect rate exceeds 5%, perform a 3-day extended test before Milestone M4. At the June 10 data date, defect rate is 7%, and the scheduler wants to add that mitigation activity to the current schedule model.
| Item | Value |
|---|---|
| Baseline M4 | July 22 |
| Current forecast M4 | July 18 |
| Approved schedule contingency on M4 path | 4 days |
Which interpretation is best?
Best answer: D
What this tests: Schedule Monitoring and Controlling
Explanation: This is approved risk mitigation, not an unapproved schedule change. The trigger has occurred, and the 3-day task fits within the 4-day approved contingency, so the scheduler should model it in the forecast while keeping the baseline milestone unchanged.
The best schedule analysis approach is what-if analysis. The response was approved in advance, the trigger condition is now met, and modeling the 3-day test shows its impact on the current forecast. With a current forecast of July 18 and 4 days of approved contingency on the path, adding 3 days still supports the July 22 baseline milestone. That means the team is executing planned mitigation and updating the forecast, not making an unapproved change to the schedule baseline.
The key distinction is that forecast updates and approved response execution do not automatically require rebaselining.
The trigger occurred and the approved mitigation fits within the planned contingency, so it should be modeled in the forecast without treating it as an unauthorized baseline change.
Use the PMI-SP Practice Test page for the full PM Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.
Read the PMI-SP guide on PMExams.com, then return to PM Mastery for timed practice.