Benefits Management
Outputs are not benefits
A benefit is a measurable, intended outcome that provides value to stakeholders; an output is a product or deliverable; a dis-benefit is an unintended negative outcome. Programs exist to deliver benefits, so the exam repeatedly tests whether you can separate the deliverable from the value it creates.
Name these artifacts: the benefits register (each benefit, metric, baseline, target, owner, timing), the benefits realization plan (how and when benefits are measured, and by whom), the benefits map or dependency network linking components to benefits, transition and sustainment plans, and realization metrics with baselines.
Accountability is the classic trap. The program manager is accountable for identifying, planning, tracking, and transitioning benefits; the benefit owner (usually an operations or business leader) is accountable for realizing and sustaining a benefit after transition. Answers that make the program manager personally own every realized benefit are usually wrong, as are answers that assume benefits appear when a project closes.
Traps. Ignoring intangible or non-financial benefits; omitting dis-benefits; measuring benefits only once at the end; and confusing the benefits realization plan with the business case.
Rule of thumb - the three-part test. If you cannot name (1) the metric with a baseline and target, (2) the point of realization, and (3) a named owner, it is not yet a benefit - it is a wish, and it belongs in the register only after definition.
Worked example. 'Faster customer service' fails the test. 'Reduce average call handling time from 9 to 6 minutes by Q3, measured by ACD reports, realized continuously by the Contact Center Director' passes, and it also identifies the sustainment mechanism the business will keep tracking after the program closes.