September 8, 2026 · 7 min read
TL;DR: Rework-shaped options are keyed 5 times and offered as distractors 20 times in this bank. The distractors fall into three families: schedule the rework, recover the cost of the rework, or measure and report the rework. All three treat rework as the thing to manage. The exam consistently treats it as evidence that something upstream is broken, and keys whatever finds or fixes that.
Rework is one of the few words in this bank that functions almost purely as a signal. When you see it in a stem, the question is usually not what to do about the rework.
Because doing the rework decides a remedy before anyone has the facts.
Two records make the point at different scales. In the first, deficiencies are found during the factory acceptance test of a turbine assembly, and delivery sits on the critical path. Holding the shipment until the vendor completes rework at its own facility is offered, and so is shipping as is, finishing on site, and back-charging the vendor. Keyed is assessing the schedule impact and evaluating which remedy best keeps the project on track. The explanation is unusually candid about why the distractors are attractive: reworking at the factory and finishing on site are both legitimate remedies, and which one is right depends on how much float the deficiencies actually consume, which is information the project manager does not yet have.
The second is smaller and sharper. A customer says a delivered widget is not quite what they asked for and wants it corrected at no cost to them. Putting a plan in place to rework the deliverable is offered, with the reasoning attached that your team made the mistake. Keyed is gathering the team and the project documents and running a root cause analysis. The explanation says why the correction is premature: if there was a design error it would cascade elsewhere, and if there was none, you can walk the customer through the artifacts to locate where the misunderstanding arose.
That is the whole pattern. Rework tells you an output is wrong. It does not tell you what produced it, and the exam wants to know that you noticed the difference.
They convert rework into something administrable.
| The distractor | What it does | What the bank keys instead |
|---|---|---|
| Absorb the additional rework into the schedule | Hides an unlogged risk | Add the risk to the register and assess it |
| Ask the product owner to fund the rework | Bills the party who was left out | Engage the product owner regularly |
| Quantify the rework and report it to the sponsor | Measures a past failure | Build a scan of external sources into the cadence |
| Hold the concern until rework figures make the point | Waits for damage to accumulate | Raise the rework rate as a project issue now |
| Quickly rework the sprint plan to add features | Bypasses a contractual boundary | Route it through the change process |
The vendor record is the cleanest of these. A vendor with a documented history of quality problems fails acceptance criteria a second time, and when the project manager checks the risk register, the vendor's quality history was never logged, so there is no planned response. Absorbing the additional rework into the schedule and continuing with the same vendor is offered. Keyed is updating the risk register to add the risk and assess it before deciding on a response. The explanation names the trap in all three losing options: rejecting the deliverable, escalating to default proceedings, or quietly absorbing the rework all pick a remedy before anyone has assessed probability, impact, and an owner.
The paint manufacturer record makes the reporting version explicit. A team has twice heard of an external change late and second-hand, and reworked finished increments both times. Quantifying the rework the two late notifications caused and reporting it to the sponsor is offered. Keyed is building a recurring scan of regulatory and market sources into the iteration cadence, and the explanation is the sentence to carry out of this whole topic: the two changes are not the problem, how the project found out about them is. Quantifying the rework measures what the last two cost without changing what happens on the third.
Common trap: billing the rework to whoever caused it. An agile team devises a workaround to clear a blocker, output rises for two iterations, and in the third the product owner objects and asks the team to redo the work properly. Asking the product owner to fund the rework their late objection caused is offered and reads as fair. It loses to engaging the product owner regularly, with extra catch-ups when needed, because the workaround ran for two iterations without the product owner knowing, and that gap is what produced the rework. The bank explains this rather than just marking the option wrong, and the wording is worth keeping: billing them blames the party who was not there. Fairness about a past cost is not a preventive control.
When the word appears in something other than a remedy.
The most instructive case is a prosthetics workshop moving socket fitting onto digital scanning. A first-year technician privately tells the project manager that the senior prosthetist's scan settings are causing rework, and asks not to be named. Two distractors would expose her: asking her to state her case at the next iteration review, or telling the senior prosthetist that a team member has raised concerns. A third would wait, holding the concern until the rework figures are high enough to make the point on their own. Keyed is raising the rework rate as a project issue and putting it to the team to work on. The explanation gives the mechanism: carrying the rework rate as the project's own issue gets the question examined while leaving it nobody's complaint to defend.
The other keyed uses are similar in kind. On a hybrid ERP project, a busy stakeholder asks why iteration reviews are held so often, and keyed is explaining how frequent reviews surface value sooner and cut rework, because the stakeholder is questioning what their time buys and the answer has to be the return on it. Where three distributed teams have drifted apart on a vague shared goal, keyed is reworking the shared outcome with all three teams so it is concrete enough to decide by, which is rework applied to the statement rather than to the increments.
In the non-conformance column, on the internal side.
The bank asks which of warranty costs, rework, inspection and penalties is not an example of the cost of non-conformance. Keyed is inspection. The explanation lays out the structure worth memorising: costs of non-conformance are incurred when a project fails to meet the required quality level, and split into internal failure costs before release, which include rework, fixing defects and waste, and external failure costs after release, which include warranties, penalties, support and damage control. Inspection is a cost of conformance, spent to prevent defects reaching the customer.
That classification is also the argument behind every keyed answer above. Rework is what failure costs you. Anything that reduces it has to act before the failure, which is why the exam keeps keying detection, engagement and analysis over the correction itself.
Is rework a cost of conformance or non-conformance? Non-conformance, and specifically an internal failure cost, incurred before release. Warranty costs and penalties are external failure costs, incurred after release. Inspection is the odd one out: it is a cost of conformance, spent to prevent defects reaching the customer rather than to fix ones that did.
Why is scheduling the rework almost always the wrong answer? Because it commits to a remedy before anyone has established the cause or the impact. The bank keys assessing the schedule impact before choosing a remedy, and running a root cause analysis before planning the correction, in scenarios where simply doing the rework is offered as an option.
Should you bill the party whose late objection caused the rework? No. The bank offers asking a product owner to fund rework their late objection caused, and keys regular engagement with that product owner instead. Billing the party blames someone for a gap the engagement approach created, and it does nothing to stop the next one.
When is a rework rate the right thing to raise? When it converts someone's private complaint into a project issue nobody has to defend personally. The bank keys raising a rework rate as a project issue for the team to work on, so the underlying question gets examined without exposing the person who raised it.
PMP Practice's 2,141 questions are certified against PMBOK 8 and the July 2026 ECO, with every wrong answer explained rather than just marked wrong. Start the free 20-question sample — no card, no signup required to try it.
Related reading: Quality on the PMP Exam: Prevention, Inspection, and the Cost of Getting It Wrong and Root Cause Analysis: 13 Keyed, 14 Distractors, and One Word in the Stem Decides It. Quality tasks are mapped on the Process domain study page.
Is rework a cost of conformance or non-conformance?
Non-conformance, and specifically an internal failure cost, incurred before release. Warranty costs and penalties are external failure costs, incurred after release. Inspection is the odd one out: it is a cost of conformance, spent to prevent defects reaching the customer rather than to fix ones that did.
Why is scheduling the rework almost always the wrong answer?
Because it commits to a remedy before anyone has established the cause or the impact. The bank keys assessing the schedule impact before choosing a remedy, and running a root cause analysis before planning the correction, in scenarios where simply doing the rework is offered as an option.
Should you bill the party whose late objection caused the rework?
No. The bank offers asking a product owner to fund rework their late objection caused, and keys regular engagement with that product owner instead. Billing the party blames someone for a gap the engagement approach created, and it does nothing to stop the next one.
When is a rework rate the right thing to raise?
When it converts someone's private complaint into a project issue nobody has to defend personally. The bank keys raising a rework rate as a project issue for the team to work on, so the underlying question gets examined without exposing the person who raised it.