nerdexam
PMI

PMP · Question #783

The programming activities of a project were planned to last 35 days per module, but the programming of the first module has taken 45 days. What should the project manager do?

The correct answer is A. Evaluate the situation and identify ways to compress the schedule without impacting baselines.. Upon a project activity delay, the project manager must evaluate the situation to identify schedule compression techniques and adjust the plan without impacting project baselines.

Submitted by femi9· Apr 18, 2026Process

Question

The programming activities of a project were planned to last 35 days per module, but the programming of the first module has taken 45 days. What should the project manager do?

Options

  • AEvaluate the situation and identify ways to compress the schedule without impacting baselines.
  • BAsk the team to work overtime to complete the deliverable on time.
  • CSubmit a change request to the project sponsor to change the schedule.
  • DCheck the scope to verify if there is scope creep and get the project on schedule.

How the community answered

(46 responses)
  • A
    72% (33)
  • B
    4% (2)
  • C
    9% (4)
  • D
    15% (7)

Why each option

Upon a project activity delay, the project manager must evaluate the situation to identify schedule compression techniques and adjust the plan without impacting project baselines.

AEvaluate the situation and identify ways to compress the schedule without impacting baselines.Correct

When a project activity is behind schedule, the project manager's immediate responsibility is to analyze the situation, identify the cause of the delay, and explore schedule compression techniques like crashing or fast-tracking to bring the project back on track without negatively affecting scope, quality, or budget baselines. This proactive approach aims to recover lost time efficiently.

BAsk the team to work overtime to complete the deliverable on time.

Asking the team to work overtime is a temporary, unsustainable solution that can lead to burnout, decreased quality, and does not address the underlying cause of the delay or provide a long-term fix.

CSubmit a change request to the project sponsor to change the schedule.

Submitting a change request to modify the schedule should be considered a last resort after exploring all options for schedule recovery and assessing the full impact; it's not the first action for a schedule deviation.

DCheck the scope to verify if there is scope creep and get the project on schedule.

While scope creep can cause delays, the problem statement indicates the 'programming of the first module has taken 45 days' (a duration issue), implying a need for schedule management rather than immediate scope verification, which is a separate control process.

Concept tested: Schedule management and compression techniques

Source: https://www.pmi.org/learning/library/crashing-fast-tracking-schedule-compression-7023

Topics

#Schedule Management#Schedule Variance#Corrective Action#Baseline Management

Community Discussion

8
Samuel O.Samuel O.May 27, 2026

A is correct. In my experience when a module runs long you assess the root cause first and look at schedule compression techniques like crashing or fast tracking before you touch the baseline, because going straight to the sponsor for a schedule change (option C) before you have exhausted your options will not fly in the real world.

27
Grace U.Grace U.May 6, 2026

A is right. You always assess and explore compression before touching that baseline.

4
Mateus R.Mateus R.May 16, 2026

A is correct. Think of it like a road trip where the first leg took ten hours instead of the eight you budgeted: before you call home and say you will be late, you look at the map and see if you can take a faster highway for the rest of the trip to still arrive on time. In project terms, the PM should first investigate the root cause and look for schedule compression techniques like crashing or fast-tracking to recover the delay before touching the baselines. Option B is a knee-jerk reaction that burns out the team, and C is premature because you only submit a change

-1
Fatima Z.Fatima Z.May 17, 2026

Solid analogy Mateus, just remember the exam loves the root-cause step before the crash, so I drill myself with CARS: Cause first, Analyze options, Recover with compression, then Submit change request if nothing works.

0
Toby R.Toby R.May 20, 2026

Sat for the exam last month and got a nearly identical question, so C is the move here. The 35 days per module was part of the approved schedule baseline, and now you are looking at a 10 day variance on the very first module, which is a huge red flag that the original estimate is wrong across the board. In PMI land, once your baseline is off by that much you do not just absorb it or try to crunch the remaining work, you go through formal change control. The sponsor needs to know and the schedule baseline needs a documented update through the change request process.

-1
Mateus R.Mateus R.May 23, 2026

Actually it is A, and think of it like a farmer who loses ten days of planting on the first field due to a surprise storm, you do not immediately go renegotiate the lease on the whole farm, you first check whether the other fields can absorb the delay. In PMI terms, the first move when a variance appears is not formal change control, it is schedule compression, fast tracking or crashing the remaining work to recover before the baseline is ever touched.

0
Fatima Z.Fatima Z.May 9, 2026

Picked D. Picture SCope Creep as the sneaky suspect. Fix the leak.

-2
Grace U.Grace U.May 10, 2026

It is actually A. Scope creep describes uncontrolled expansion of project work, and the fix is a documented change control process, not just patching one isolated issue.

0
Full PMP Practice