September 7, 2026 · 7 min read
TL;DR: Across this bank, options that reduce, cut, drop, or descope work appear 16 times and are keyed zero times. The exam is not opposed to scope shrinking. It is opposed to the project manager shrinking it. Every legitimate reduction runs through either change control or the product owner, and the distractors are the ones that skip both.
Scope is the constraint that looks softest. Cost is money someone counted, schedule is a date someone promised, but scope feels like a list you could shorten if things got tight. That instinct is why "cut scope to hold the date" reads as the pragmatic, grown-up answer in a pressured scenario.
It is keyed zero times in 2,141 questions.
We measured every answer option in the bank for language about reducing, cutting, dropping, trimming, or descoping features, requirements, or deliverables. Sixteen options offer it. None is correct. That puts it alongside removing a team member and working overtime in the small set of patterns this bank rejects without exception.
Because scope is a baseline, and a baseline is not the project manager's to edit. Almost every one of the sixteen distractors is a decision taken by the wrong person.
Read the wording of the distractors and the tell is usually sitting in the sentence. "Quietly drop some features yourself and see whether anyone notices." "Quietly reduce scope or quality wherever it will not cause trouble for you and the team, since the insufficient budget is not your fault." Those two are the pattern at its most naked, and the operative word in both is quietly. Even the neutral-sounding ones carry it: "Reduce the scope of the remaining work so that the dates can be met" is offered where several team members have missed committed dates twice running, and the keyed answer is to talk with them and establish what is causing the delays. Nobody has established the cause yet, so a scope cut is a remedy for a problem that has not been named.
Common trap: "The deadline is immovable, so something has to give, and scope is the only lever left." Check the numbers before you accept that. One bank question hands you a product-launch project with an SPI of 0.86 and a CPI of 1.12, and a sponsor asking for recovery in two months. Behind schedule, under budget. Because the cost index is favourable, there is money available to buy time, so crashing is the keyed answer, and "Cut project scope to bring the project back on track" is the distractor sitting directly beside it. The indices select the technique. This bank writes the plausible scope cut into the option list on purpose and explains why it loses, rather than just marking it wrong.
The same reversal shows up in an earned value question where planned value is $840,000, earned value is $795,000 and actual cost is $755,000. Schedule variance is negative and cost variance is positive, so again the project is behind but under budget, and the keyed answer adds resources to recover the schedule. "Raise a change request to cut the project scope" is one of the three losers, and notice that this one is not even sneaky. It goes through change control properly. It still loses, because the arithmetic points at a different remedy.
Through one of exactly two doors, and which door depends on the delivery approach.
| Route | Who decides | What it looks like in a keyed answer |
|---|---|---|
| Change control (predictive) | The change control board, or the sponsor with authority | Assess the impact, raise a change request, take it to the board |
| Backlog reprioritisation (adaptive) | The product owner | Add or rank the item in the product backlog, and let lower-value work fall below the line |
| Escalate a genuine shortfall | Project manager and sponsor together | Raise the budget problem openly and follow the organisation's process for refining estimates |
| Not a route | The project manager alone | Any option where the work simply stops being delivered and nobody approved it |
The adaptive door is the one most often misread. On agile projects, work absolutely does drop out of the plan, and it happens constantly, but the mechanism has a name and an owner. In one bank scenario a product owner asks for a data-privacy feature mid-sprint that was not in the original requirements. The keyed answer works with the product owner to add it to the product backlog for prioritisation. Two of the distractors are the extremes, dropping it into the current sprint immediately or refusing it because it was not in the original scope, and a third routes it through formal change control, which is the wrong machinery for an adaptive project. The backlog is the ordered list and the product owner sets the order. That is reprioritisation, and it is keyed. When a project manager decides which agreed work will silently not arrive, that is descoping, and it is not.
There is a third instinct worth naming because it sits close to descoping and fails the same way: abandoning the capability instead of the component. A remote-monitoring project discovers the sensor technology it was designed around is unavailable from any supplier. The options include cancelling, postponing, and removing the affected work from the project scope. The keyed answer investigates alternative technologies that could deliver the same capability. What the project owes the business is the capability, not one particular part, so conceding the scope before exploring substitutes gives up something that was never necessarily lost.
So the question to ask when a scope-cut option is in front of you is not whether the cut would work. It usually would. It is: who authorised this, and where is that recorded? If the answer is nobody and nowhere, it is the distractor.
Is cutting scope ever the right answer on the PMP exam? Not as the project manager's own move. Across 2,141 questions here, options that reduce, cut, drop, or descope work appear 16 times as answer choices and are keyed zero times. Scope can legitimately shrink, but only through the change control process on a predictive project or through the product owner's reprioritisation on an adaptive one.
What is the difference between descoping and reprioritising the backlog? Authority. Reprioritising is the product owner ordering the backlog, which is their job and is routinely keyed. Descoping is the project manager deciding which agreed work will not be delivered, which is a change to an approved baseline and is not theirs to make alone.
The scenario says the deadline is fixed. Does that not force a scope cut? It narrows the options but does not authorise the cut. In one bank scenario with an SPI of 0.86 and a CPI of 1.12, the sponsor asks for recovery in two months. The keyed answer is crashing, because the favourable cost index means money is available to buy time. "Cut project scope to bring the project back on track" sits right beside it as a distractor.
What if the budget genuinely will not cover the remaining scope? Escalate it and decide with the sponsor. One bank question describes ROM estimates at -50%/+100% that turn out to have been consistently too low. The keyed answer raises it with the sponsor and follows the organisation's process for refining budgets. "Quietly reduce scope or quality wherever it will not cause trouble" is a distractor, and the word doing the work there is "quietly."
PMP Practice's 2,141 questions are certified against PMBOK 8 and the July 2026 ECO, and every wrong answer is explained, not just marked wrong, so you learn why the sensible-looking scope cut was written into the option list at all. Start the free 20-question sample. No card, no signup required to try it.
Related reading: Project Scope and the Requirements Baseline covers what the baseline is and why it resists edits, and Change Control: Assess the Impact First covers the route a legitimate reduction takes. The Process domain study guide maps these to the 2026 ECO tasks.
Source: PMI, PMP Examination Content Outline.
Is cutting scope ever the right answer on the PMP exam?
Not as the project manager's own move. Across 2,141 questions here, options that reduce, cut, drop, or descope work appear 16 times as answer choices and are keyed zero times. Scope can legitimately shrink, but only through the change control process on a predictive project or through the product owner's reprioritisation on an adaptive one.
What is the difference between descoping and reprioritising the backlog?
Authority. Reprioritising is the product owner ordering the backlog, which is their job and is routinely keyed. Descoping is the project manager deciding which agreed work will not be delivered, which is a change to an approved baseline and is not theirs to make alone.
The scenario says the deadline is fixed. Does that not force a scope cut?
It narrows the options but does not authorise the cut. In one bank scenario with an SPI of 0.86 and a CPI of 1.12, the sponsor asks for recovery in two months. The keyed answer is crashing, because the favourable cost index means money is available to buy time. 'Cut project scope to bring the project back on track' sits right beside it as a distractor.
What if the budget genuinely will not cover the remaining scope?
Escalate it and decide with the sponsor. One bank question describes ROM estimates at -50%/+100% that turn out to have been consistently too low. The keyed answer raises it with the sponsor and follows the organisation's process for refining budgets. 'Quietly reduce scope or quality wherever it will not cause trouble' is a distractor, and the word doing the work there is 'quietly'.