September 8, 2026 · 7 min read
TL;DR: Reassigning someone's tasks appears in twenty-four options in this bank and is keyed twice. Both keyed cases sit after the diagnosis, not instead of it: an investigation had already isolated a specific technology skill gap, or the team member had just explained they were absorbing an unassigned second workstream. The twenty-two distractors all move work before anyone knows why the work is stuck, which is why the bank keeps offering it as the fastest-looking wrong answer.
Reassignment feels like management. It is decisive, it is visible, and it produces a plan you can send by close of business. That is exactly why it makes such a good distractor, and this bank uses it as one twenty-two times.
Because it treats the location of the work as the problem when the stem has told you the problem is somewhere else.
Take the retail loyalty-programme record. Every team member is meeting their agreed key performance indicators except one, who has now missed them for three consecutive reporting periods. Replace the team member with someone who has a stronger delivery record is offered. Keyed is discuss the shortfall privately with the team member to understand what lies behind it.
The explanation gives the reason in one clause: replacing someone before the cause is known may remove a capable person who is facing a temporary obstacle. Three periods of missed indicators is a fact about outcomes. It is not yet a fact about capability, motivation, workload, health, or a dependency nobody has noticed, and the four possibilities lead to four different fixes.
The same shape recurs across the bank's people records with the details swapped. Reassign the problem team member's tasks to others. Reassign the outstanding work to the team members who have been meeting their dates. Reassign this person's tasks to teammates in closer time zones. Reassign some of the junior economist's tasks to other economists. Each one is a plausible operational response and each one is offered against a stem where the cause is still unknown.
A diagnosis that has already happened inside the stem.
The first is a team whose weekly output has fallen sharply. The stem is unusually explicit: on investigation, the drop traces to a single member who has been assigned tasks in a technology stack they have never used, while the rest of the team's work and collaboration are unaffected and on pace. Keyed is pair the member with someone experienced in the stack, or reassign the tasks to close the specific skill gap.
Read the distractors next to it. Run a team-building session so the group covers for the gap together. Raise the team's cohesion through more frequent retrospectives. Wait for the member to build proficiency on their own. The explanation dismisses the first two in the same breath: the rest of the team's output and collaboration are unaffected, so this is a capability gap, not a cohesion problem.
The second keyed case is a team member who, in a private conversation about a missed content deadline, explains the real cause: they were quietly absorbing a second workstream that was never formally assigned to them. Keyed is formally reassign the second workstream to someone else or adjust the team member's committed workload, and record the change.
Both keyed options do the same two things. They name what is moving and why, and in the second case they write it down.
Four properties, and the distractors fail at least one of them each time.
| Property | Keyed reassignment | Typical distractor |
|---|---|---|
| Cause | Named in the stem before the option acts | Unknown, or assumed from a second-hand report |
| Target | The specific tasks causing the problem | The person's workload in general |
| Reason | Closes a stated gap | Protects the schedule, or spreads load |
| Record | The change is documented | Nothing is written down |
The new-hire record is where all four fail at once. An experienced team member tells the project manager privately that a newly hired colleague does not seem to have the skills for the role, and suggests reassigning their tasks. The project manager has not yet observed the new hire's work. Reassign the new hire's tasks to a more experienced team member, as suggested, to protect the schedule is option A. Keyed is observe the new hire's actual work and check it against the role's expectations before deciding anything.
The explanation is blunt about what the reassignment would be built on. What the project manager has in hand is one colleague's secondhand impression, not a verified finding, and the claim may be wrong, incomplete, or itself the product of friction between the two team members.
Common trap: treating reassignment as the quiet, kind option. The bank explicitly rejects this framing. In the new-hire record the explanation says reassigning the tasks and releasing the person both commit to an outcome, the first quietly, the second irreversibly, on the strength of a report nobody has tested. Quiet is not neutral. A capable person whose work is moved away without a conversation has been judged and not told, and if the impression was wrong the project has lost capacity for no reason. The bank's wrong answers repeatedly offer the softer-sounding version of a decision the stem has not earned, and its explanations name that softness as part of the defect rather than a mitigation.
The rule holds, but the diagnosis you need is different.
Two bank records offer reassignment as a way of balancing load. Reassign tasks to focus on high-priority deliverables and lighten the team's workload. Reassign the next few tasks by hand so the varied work is shared out this cycle. Both are distractors, and neither is rejected because balancing load is wrong.
They are rejected because the project manager is doing by hand, once, what the team's own planning is supposed to do every cycle. A manual reallocation this sprint leaves the mechanism that produced the imbalance untouched, so it will produce the same imbalance next sprint and the project manager will be back doing it again.
The keyed overload record makes the contrast visible. There the reassignment is keyed precisely because it changes the standing commitment, formally reassign the second workstream or adjust the committed workload, and it is recorded, so the next cycle starts from a corrected baseline rather than from the same overload plus one manual intervention.
Is reassigning tasks ever correct on the PMP exam? Yes, but only after the cause is known. Across twenty-four options offering some form of reassignment, two are keyed. In one the stem states the investigation already traced the drop to a specific skill gap; in the other the team member has just explained they are carrying an unassigned second workstream. In both, reassignment closes a cause that has been named.
Why is reassigning work usually the wrong answer? Because it moves the symptom without touching the cause. The bank's distractors reassign to protect a schedule, to satisfy a complaint, to spread work more evenly, or to route around someone who is struggling. In each case the underlying problem, a skill gap, an overload, a conflict, a mistaken assumption, is still there and now sits with somebody else.
What is usually keyed instead of reassigning? A private conversation with the person, or direct observation of the work. When one team member is missing indicators the rest are meeting, the bank keys discussing the shortfall privately to understand what lies behind it. When a colleague reports that a new hire lacks the skills, the bank keys observing the new hire's actual work before deciding anything.
What makes the keyed reassignment different? It is specific and it is recorded. The bank's keyed option pairs the team member with someone experienced in the stack or reassigns the tasks to close the specific skill gap, and the second one formally reassigns the second workstream or adjusts the committed workload, and records the change. Vague redistribution is a distractor; a targeted, documented reallocation against a named cause is not.
PMP Practice's 2,141 questions are re-certified against PMBOK 8 and the July 2026 Exam Content Outline, with every wrong answer explained, not just marked wrong. Start the free 20-question sample and see how often the decisive difference is whether the stem has diagnosed anything yet. No card, no signup required to try it.
Is reassigning tasks ever correct on the PMP exam?
Yes, but only after the cause is known. Across twenty-four options offering some form of reassignment, two are keyed. In one the stem states the investigation already traced the drop to a specific skill gap; in the other the team member has just explained they are carrying an unassigned second workstream. In both, reassignment closes a cause that has been named.
Why is reassigning work usually the wrong answer?
Because it moves the symptom without touching the cause. The bank's distractors reassign to protect a schedule, to satisfy a complaint, to spread work more evenly, or to route around someone who is struggling. In each case the underlying problem, a skill gap, an overload, a conflict, a mistaken assumption, is still there and now sits with somebody else.
What is usually keyed instead of reassigning?
A private conversation with the person, or direct observation of the work. When one team member is missing indicators the rest are meeting, the bank keys discussing the shortfall privately to understand what lies behind it. When a colleague reports that a new hire lacks the skills, the bank keys observing the new hire's actual work before deciding anything.
What makes the keyed reassignment different?
It is specific and it is recorded. The bank's keyed option pairs the team member with someone experienced in the stack or reassigns the tasks to close the specific skill gap, and the second one formally reassigns the second workstream or adjusts the committed workload, and records the change. Vague redistribution is a distractor; a targeted, documented reallocation against a named cause is not.