Cost-Benefit Analysis: 8 Keyed, 6 Distractors, and the Split Is About Whose Decision It Is

September 7, 2026 · 7 min read

TL;DR: Cost-benefit analysis options are keyed 8 times and used as distractors 6 times in this bank, which is close enough to even that neither instinct helps you. It keys when the stem hands the project manager a trade-off nobody has quantified yet. It fails when the decision belongs to a product owner or a governing body, when the analysis was already done, or when the scenario is not a trade-off at all.

Cost-benefit analysis has a good reputation on the exam, and deservedly. It is analytical, it resists gut feel, and it produces something you can show people. Which is exactly why the question writers use it as a distractor six times.

We measured every appearance across the bank. Eight keyed, six distractors, spread across the Process and business-environment slices. Fourteen cases is not many, so this post is less about the count than about the discriminator, which turns out to be unusually crisp: not whether the analysis would be useful, but whether the analysis is yours to run.

When does cost-benefit analysis key?

When the stem gives you two courses of action, a real trade-off between them, and no numbers.

During execution of a data-centre migration, an engineer identifies an alternative cut-over approach that would save two weeks but cost considerably more. Four options: switch to the alternative and recover the two weeks, carry out a cost-benefit analysis of it, stay with the planned approach and avoid the extra cost, or ask the stakeholders which they would prefer.

The analysis is keyed. Switching and refusing both settle the trade without quantifying it, which means the decision rests on nobody's arithmetic. And taking it to stakeholders before the analysis exists asks them to choose between two options neither of them has been costed. Whether two weeks are worth the extra spend depends on figures nobody has put on the table yet, and putting them there is the project manager's job.

The same shape recurs with a fixed deadline attached, which is where it gets interesting. A structural engineering commission is in its analysis phase when a simulation package reaches the market that would cut modelling time considerably. Adopting it means training the engineers and having them work slowly while they learn, and the client's regulatory submission deadline cannot move.

One option adopts the package immediately, on the grounds that the deadline leaves no time to evaluate it first. It sounds decisive. It is wrong. A fixed deadline raises the stakes of the trade-off; it does not remove the need to quantify it. The analysis simply has to weigh the learning-curve delay against the time actually left before submission, rather than against an open-ended schedule. Deadline pressure is the reason the analysis matters, not a reason to skip it.

What the stem gives youCBA keyed?Why
Two approaches, one costs more and saves timeYesThe trade needs numbers before anyone can choose
A fixed deadline plus a tempting new toolYesThe deadline is what the learning curve gets weighed against
Stakeholders each pushing their own featureYesSupplies a basis for comparison that is not seniority
A change to product featuresNoThe product owner decides before any work is spent
An audit already scoped and fundedNoThe analysis was effectively done when it was budgeted
Uncertainty in both frequency and severityNoThat is a simulation problem, not a trade-off

Why does it fail as often as it does?

Because a good technique applied to someone else's decision is still the wrong answer.

A hybrid project building a water-treatment monitoring system hits a product design problem. The team works out a solution together, but it would mean substantial changes to the product's features. One option runs a cost-benefit analysis to establish what the solution is worth. Another builds a prototype and demonstrates it to end users. Both are real work by competent people.

The keyed answer asks the product owner to review the change and give their recommendation. A substantial change to product features is the product owner's decision, so their review comes before any further effort is spent. Prototyping and costing both invest work in a solution the product owner may not want pursued at all. The analysis is not wrong on its merits. It is premature by one step, and that step belongs to someone else.

Common trap: reaching for cost-benefit analysis on a question about uncertainty. A construction project is hitting repeated severe weather delays and the project manager needs to predict the likely impact on the completion date and communicate it. One option runs a cost-benefit analysis on whether to add resources to offset the delays. Keyed instead is Monte Carlo simulation, because weather delays are uncertain in both frequency and severity, and a single revised completion date would state more than is actually known. Cost-benefit analysis compares two known options. It has nothing to say about a distribution, and the question was never asking you to choose between two courses of action in the first place.

What about prioritisation?

Prioritisation is the keyed use most candidates underrate.

You have authority over which features your team releases next, but you lack deep product expertise, so you gather senior users to build the feature list. Every stakeholder wants their own feature first. The options offer delivering the top executives' features to avoid trouble, running a MoSCoW analysis with the stakeholders, running a root cause analysis, and using cost-benefit analysis with a comparison of the time needed to recover each feature's cost.

The last one is keyed. With every stakeholder advocating their own feature, what is missing is a basis for comparison that is not somebody's preference. Setting each feature's cost against the value it returns, and how fast that return arrives, ranks the list on evidence anyone in the room can inspect. MoSCoW is a reasonable technique but it re-runs the same negotiation between the same advocates. Payback period gives you a number they have to argue with instead of each other.

That is the whole pattern in one line. Cost-benefit analysis keys when it replaces an opinion with a figure, and fails when it replaces a decision that was never yours.

FAQ

When is cost-benefit analysis the right answer on the PMP exam? When the stem describes a genuine trade-off that nobody has put numbers to, and the project manager is the one who has to decide. In this bank it is keyed 8 times against 6 as a distractor. Both keyed schedule examples involve spending more money to save time, with no figures yet on the table.

Why is cost-benefit analysis sometimes a distractor? Usually because the decision is not the project manager's to make. In the water-treatment question, the substantial change to product features is the product owner's call, and the analysis invests work in something they may not want pursued at all.

Does a fixed deadline mean there is no time for analysis? The exam says the opposite. Adopting the simulation package immediately because the deadline leaves no time to evaluate it is a distractor. The fixed deadline is precisely what the analysis has to weigh the learning curve against.

How does cost-benefit analysis relate to prioritising features? It is keyed as a prioritisation basis when stakeholders are each advocating their own feature. Comparing what each costs against the value it returns, and how quickly that return arrives, produces a ranking on evidence everyone can inspect.

Try it yourself

PMP Practice's 2,141 questions are re-certified against PMBOK 8 and the July 2026 exam content outline, with every wrong answer explained rather than just marked wrong, which is what turns a fourteen-question split into a rule you can apply. Start the free 20-question sample — no card, no signup required to try it.

Related

Sources

FAQ

When is cost-benefit analysis the right answer on the PMP exam?

When the stem describes a genuine trade-off that nobody has put numbers to, and the project manager is the one who has to decide. In this bank it is keyed 8 times against 6 as a distractor. Both keyed schedule examples involve spending more money to save time, with no figures yet on the table.

Why is cost-benefit analysis sometimes a distractor?

Usually because the decision is not the project manager's to make. In a water-treatment question where a proposed solution would substantially change the product's features, running a cost-benefit analysis is wrong because that change is the product owner's call, and the analysis invests work in something they may not want pursued at all.

Does a fixed deadline mean there is no time for analysis?

The exam says the opposite. In a structural engineering question, a new simulation package would cut modelling time but requires training against a fixed regulatory deadline. Adopting it immediately because the deadline leaves no time to evaluate is a distractor. The fixed deadline is precisely what the analysis has to weigh the learning curve against.

How does cost-benefit analysis relate to prioritising features?

It is keyed as a prioritisation basis when stakeholders are each advocating their own feature. Comparing what each feature costs against the value it returns, and how quickly that return arrives, produces a ranking on evidence everyone can inspect rather than on whoever has the most seniority in the room.