A change is approved on the strength of its expected benefits: fewer errors, faster service, lower costs, more sales. Then it meets reality. Some benefits arrive sooner than expected. Others fall short. A benefit nobody predicted turns up. And some people find the change makes their work harder, or some customers find it makes the business harder to deal with.
That creates a dilemma. If the business never revises the benefits it approved, it stays loyal to assumptions that are no longer true and cannot tell whether the remaining work is still worth doing. If it revises them freely, any change can be made to look successful after the event, by quietly swapping the original promise for whatever happened. Good practice sits between the two: the expected benefits are a controlled, honest record of what the business now expects, updated on evidence and with a trail back to what was originally promised.
This article explains four ways benefits change after approval, how to tell an honest revision from a convenient one, why negative consequences need owners just as benefits do, and how changing benefits should feed back into what the business continues to do. It is general information for owners and managers who approve changes and want to know whether they are paying off.
Four ways benefits change
- Erosion. An expected benefit falls short because an assumption proved wrong, the scope was reduced, timing slipped or conditions changed. A delay can deliver the same result but miss a season or postpone savings long enough to weaken the whole case.
- Emergent benefit. Value nobody anticipated appears: a new system makes a different task easier, or a process change improves safety as well as speed.
- Dis-benefit. A negative consequence that arises directly from the change: more work for one team, a harder experience for some customers, a loss of local flexibility. Changes often redistribute value, and someone carries the cost.
- Substitution. One benefit becomes less important while another becomes more so, perhaps because the business’s priorities or circumstances changed.
Each needs a different response.
Honest revision or convenient rewrite
The difference between a genuine revision and moving the goalposts lies in the process. A credible revision has:
- Evidence: what changed in the data, assumptions or circumstances.
- A cause: why the benefit moved.
- Consequences: what it means for cost, timing, risk and the people affected.
- An approver: someone with authority agreed the revision.
- A trail: the original figure is kept, alongside the new one.
A convenient rewrite usually appears only after results disappoint, has no clear cause and no decision trail. Keep the original baseline visible in every update, so anyone can see both what was promised and what is now expected.
Erosion should test the remaining case
When an expected benefit falls, the natural response is to revise the forecast and carry on. A better response asks whether the remaining work is still justified at the lower level. Sometimes it is; sometimes the honest answer is to reduce scope, change approach or stop. The stopping projects well article covers making that decision cleanly.
Emergent benefits are not free
New value is welcome, but three questions come before claiming it:
- Is it really caused by this change, or would it have happened anyway?
- Does it need further investment or effort to realise fully?
- Is someone else already counting it? In a business running several changes, the same improvement can easily be claimed twice.
If it passes those tests, give it an owner and a measure, as for any other benefit. The what would have happened anyway article covers separating real effects from changes that would have occurred regardless.
Dis-benefits need owners too
Negative consequences are often left out of benefit records entirely, which makes every change look better than it is. A change can be clearly worthwhile overall while imposing concentrated costs on one team, one customer group or one supplier. If those costs have no owner, they become someone’s unacknowledged operational problem after the project closes.
Record significant dis-benefits alongside benefits, with:
- Who bears them.
- How large they are, in time, money or experience.
- Who owns reducing them, and how.
- How they will be measured.
Making them visible is also fairer to the people affected and more honest with the customers or staff who experience them. The designing change around what people lose article covers why losses from change deserve attention in the design.
Changing benefits should change the plan
The relationship runs both ways. Scope changes affect benefits, and changing benefits should affect scope. If evidence shows part of a change contributes little value, reduce or drop it. If a new opportunity has unusual value, consider whether to pursue it now or record it as a later option. When approving a scope change, ask not only what it does to cost and time, but what it does to the benefits: a cut that saves a little cost can destroy a disproportionate share of the value.
Five actions
For each material change in benefits, choose one action:
| Action | When |
|---|---|
| Rebase | Evidence changes the expected level of an existing benefit |
| Add | A genuine new benefit appears and has a clear owner |
| Mitigate | A dis-benefit threatens the net value or fairness of the change |
| Substitute | Changed priorities make a different benefit more important |
| Stop | The remaining value no longer justifies the remaining effort |
Substitution needs particular care. It can be a legitimate response to changed circumstances, or a way of justifying money already spent. Ask whether you would choose this change today, for the new benefit, over the alternatives available. If not, the substitution is a rationalisation.
Keep a simple change record
For each material revision, write down:
- the original benefit and baseline;
- the new evidence and the reason for the change;
- the effect on cost, timing, risk and the people affected;
- whether it is erosion, emergent benefit, dis-benefit or substitution;
- the owner, and any new dependencies;
- who approved it;
- what it means for whether the change continues as planned.
It takes a few minutes per change and prevents two common failures: hiding erosion and overclaiming success.
Set review points before go-live
Decide when benefits will be reviewed, and by whom, before the change goes live. Early reviews tend to catch teething problems rather than settled results, and late reviews come after the chance to adjust has passed. A sensible pattern is a quick check a few weeks after go-live for obvious problems, a fuller review at around three months, and another at six or twelve months when results have settled. Agree the measures and data sources in advance, so the review compares like with like rather than whatever figures are easiest to find on the day.
Benefits belong to the people who run the result
The project lead who delivered a change usually moves on. The benefits arrive later, in the hands of the people who run the business day to day. Give each benefit, and each significant dis-benefit, an owner in the operating part of the business: the person whose decisions and habits determine whether it is realised. That person should agree the measure, report against it at the review points and have the authority to make the adjustments that keep it on track.
Look across changes, not just within one
A business running several changes at once faces two extra risks. The same improvement can be claimed by more than one change, and dis-benefits from different changes can land on the same team at the same time. Keep benefits and dis-benefits from all current changes in one simple list. It shows where value is double counted, where one group is absorbing the downsides of several changes, and where changes interact in ways no single plan anticipated.
Make honest revision normal
People revise benefits honestly when doing so is safe. If a lower figure is treated as failure, people protect themselves: they hold on to the original number, look for new benefits to fill the gap, or stop measuring. Treat a well-evidenced rebase as good management, share revisions openly with the people involved, and judge leaders on the quality of their information and decisions rather than on whether the original forecast was hit exactly.
A worked example
This is an illustration. A dental practice with three dentists introduces online booking with automated reminders. The case rested mainly on reducing missed appointments from about 8% to about 4%. With roughly 21,600 appointments a year at an average fee of around $180, that four-point reduction was expected to recover about 864 appointments a year, worth around $155,000 in fees, with less reception time spent on the phone.
Six months in, the practice manager reviews the benefits:
- Erosion: missed appointments have fallen to about 6%, not 4%. The two-point improvement recovers about 432 appointments, worth around $78,000 a year. The cause is clear: some patients ignore text reminders. The benefit is rebased, with the original figure kept in the record. The remaining case still easily justifies the system’s cost.
- Emergent benefit: online health forms completed before appointments are reducing delays at the start of sessions. The practice manager checks that nothing else explains the change, gives the benefit to the clinical coordinator to own, and adds it with a measure: average minutes late starting.
- Dis-benefit: some older patients find online booking difficult and are frustrated that phone lines are busier at certain times. The reception lead takes ownership and mitigates it: a dedicated phone booking time each morning, and staff offering to set up the online booking for patients during visits.
- Plan change: a planned second phase, online payment for all appointments, is reviewed. Evidence suggests little additional benefit, so it is reduced to optional prepayment for longer treatments only.
The practice manager also sets the next review for twelve months, with the same measures and data sources, so the figures can be compared fairly.
The practice ends the year with a smaller headline benefit than first promised, a new one it did not expect, a dis-benefit being actively managed and a clear record showing how each figure changed and why.
How this applies to a small Australian business
- Keep the original benefits visible alongside every revision.
- Review benefits at set points after a change, not only at go-live.
- Test the remaining case when benefits erode.
- Check emergent benefits for cause, cost and double counting.
- Record dis-benefits with owners and measures.
- Ask what scope changes do to benefits, not just to cost.
- Choose an action: rebase, add, mitigate, substitute or stop.
- Keep a short change record for each material revision.
Signals worth watching
- Benefit targets unchanged despite big changes in scope or timing.
- New benefits claimed only after original ones fell short.
- Complaints from one group about a change everyone else praises.
- The same improvement claimed by two projects.
- Scope cut to save cost with no check on lost benefits.
- Nobody owning the downsides of a change.
- Benefit reviews that use different measures each time.
Common mistakes
- Never revising benefits, or revising them without a trail.
- Treating emergent benefits as free.
- Leaving dis-benefits out of the picture.
- Approving scope changes on cost and time alone.
- Using substitution to justify sunk costs.
- Carrying on when the remaining case no longer holds.
- Leaving benefits with a project lead who has moved on.
Frequently asked questions
Doesn’t revising benefits undermine accountability? Not if the original figures stay visible and revisions are evidenced and approved. Hiding change undermines accountability more.
How often should we review benefits? At agreed points: shortly after go-live, at three and six months, and annually for larger changes, using the same measures and data sources each time.
Who should own a dis-benefit? The person best placed to reduce it, usually the manager of the area where it is felt.
What if a benefit cannot be measured precisely? Use the best available indicator and say how uncertain it is. A rough measure honestly reported is more useful than none.
What if the change delivers more than expected? Record that too, with the same evidence and trail. Understanding why a forecast was too cautious improves the next one as much as understanding why one was too optimistic.
Should small changes have this much record-keeping? Scale it. A few lines in a shared document is enough for most small-business changes.
Questions to ask
- What did we originally expect this change to deliver?
- What has changed since, and why?
- Is the remaining work still justified at today’s expected benefits?
- What new value has appeared, and is it really ours to claim?
- Who is worse off because of this change, and who owns fixing that?
- Would we choose this change again today, for the benefits we now expect?
Bringing it together
Benefits rarely arrive exactly as approved. Some erode, some appear unexpectedly, some come with downsides and some lose importance as circumstances change. Revise them honestly, with evidence, an approver and the original figures kept visible. Test the remaining case when benefits fall, check new benefits before claiming them, and give dis-benefits owners and measures. Let changing benefits shape what the business continues to do, including stopping when the case no longer holds.
Source: KEVOS notes, drawing on the PMI Benefits Realization Management Framework and the New Zealand Treasury’s 2017 guidance on benefits management, including emergent benefits and dis-benefits. Examples and figures in this article are illustrations. This article is general information.
