← Perspective PPM
🎯

The Benefit That Vanished After Go Live

By The Perspective Desk · 2026-08-31 · benefits realization, portfolio management, governance

The Party Nobody Follows Up On

> Go-live gets the celebration. Benefits realization tells you whether the project was actually worth celebrating.

Picture the go-live.

The room is warm with relief. Someone brought a cake with the project name misspelled in icing.

The sponsor gives a short speech about how the new platform is going to save the company two million dollars a year.

Everyone claps.

Then everyone goes back to their inbox.

Six months later, nobody can tell you if the two million dollars ever showed up.

The project team has moved on. The sponsor has a new set of fires. The business case is sitting in a folder somewhere, opened only when somebody needs to remember what was originally promised.

And the savings?

Maybe they happened.

Maybe some of them happened.

Maybe they were offset by higher costs somewhere else.

Nobody really knows because nobody went back and looked.

> We are very good at measuring whether something shipped. We are much less consistent at measuring whether shipping it was actually worth the investment.

That is one of the quiet problems in project delivery.

---

What Do We Mean by a Benefit?

Before going any further, it helps to define the word.

A benefit is a specific, measurable change in the business that a project was expected to create.

For example:

"The team learned a lot" is not a benefit.

"Stakeholders were happy with the project" is not a benefit either.

Those things may absolutely matter, but they are not the kind of outcomes you can defend when someone asks whether a $750,000 investment actually delivered a return.

---

Delivery Is a Milestone. Benefit Is the Point.

Here is the uncomfortable part.

Go-live is often treated like the finish line when, from a value perspective, it is closer to the halfway point.

A project delivers an output.

That output is expected to create an outcome.

That outcome is expected to produce a benefit.

The value chain

Project → Output → Outcome → Business Benefit

Every connection in that chain can break.

You can deliver a technically flawless CRM platform that nobody adopts.

The project successfully produced the output.

But without adoption, the intended outcome never happens.

And without the outcome, the expected benefit never appears.

> The implementation can be a delivery success while the investment itself is still a failure.

Both things can be true at the same time.

Unfortunately, most organizations only celebrate and measure the first one.

Benefits realization is simply the discipline of following the value story beyond go-live and asking a straightforward question:

> Did the thing we promised actually happen?

That question matters far beyond a single project.

A PMO that can demonstrate measurable portfolio value becomes part of strategic decision-making.

A PMO that only reports schedule, budget, and delivery status can easily become viewed as a project administration function.

Benefits realization changes the conversation from:

> Did we finish the project?

to:

> Was this the right investment?

That is a much more important question.

---

Name the Benefit Before You Build Anything

You cannot measure a benefit that was never properly defined.

Many benefits fail to survive past go-live because they were vague from the beginning.

Those are not benefits.

They are intentions.

Before a project is approved, every major claimed benefit should answer a few basic questions.

1. The Metric

What number is expected to change?

Examples might include:

2. The Baseline

What is the number today?

Not what someone thinks it is.

Not what was estimated three years ago.

What is actually happening now?

Without a baseline, there is nothing meaningful to compare later.

3. The Target

Where should the metric land?

A target turns a general expectation into something measurable.

For example:

> Reduce average invoice processing time from nine minutes to six minutes.

Now there is something you can actually evaluate.

4. The Date

When should the benefit appear?

Benefits do not always show up immediately after implementation.

Some appear within weeks.

Others take months or even years.

The expected timeline should be part of the business case.

5. The Owner

Who owns the benefit after the project team leaves?

This should usually be someone in the business, not someone on the temporary project team.

Projects end.

Benefits often do not.

Someone needs to remain accountable for measuring the result.

6. The Counting Rule

This is the one that causes the most trouble.

How will you determine how much of the improvement was actually created by this project?

Businesses do not stand still while projects are being implemented.

Sales volumes change.

Staffing changes.

Other initiatives launch.

Markets move.

Processes get redesigned.

If you do not decide how the benefit will be measured before the project starts, the conversation afterward can quickly turn into guesswork.

---

A Worked Example: The Invoice Project That Saved Less Than It Promised

Imagine Finance launches a project called Swift, an automation initiative for Accounts Payable.

The business case promises:

> 6,000 hours of annual labor savings worth approximately $240,000.

The baseline looks reasonable.

Three months later, the team measures the process again.

Invoices now take an average of six minutes.

That sounds like a clear win.

Three minutes saved across 40,000 invoices works out to roughly 2,000 hours per year.

But that is only a third of the original 6,000-hour promise.

And then the situation gets more complicated.

During those same months:

So how much of the improvement should Swift actually receive credit for?

This is where the counting rule matters.

If the team had agreed at the beginning to measure minutes per invoice instead of total labor hours, the increase in invoice volume would not distort the measurement.

If the supplier-data cleanup had been documented as a separate initiative, its impact could also be considered.

Without those decisions made in advance, the post-launch conversation becomes a negotiation.

And negotiations around business cases have an interesting habit of producing the number everyone hoped to see.

A better outcome might sound something like this:

> Swift is currently tracking toward approximately $150,000 in realized annual savings. The difference from the original $240,000 estimate is primarily driven by increased transaction volume and a slower-than-expected rollout to the second office. Additional savings are expected as adoption increases through Q4.

That statement is far more useful than simply declaring the project successful.

It is measurable.

It is defensible.

It explains the gap.

And most importantly, it gives leadership information they can actually use.

It also improves the next business case.

If your organization consistently overestimates automation savings by 30%, that should influence how the next automation project is evaluated.

> That is where benefits realization starts creating value across the entire portfolio.

---

Expected vs. Realized Benefits

One of the simplest ways to improve benefits management is to track two numbers side by side:

Expected Benefit

The promise made when the project was approved.

Realized Benefit

What actually happened.

Then keep measuring after go-live.

For many portfolios, quarterly reviews are enough.

Some benefits may take a year or more to materialize, which is why the measurement process must outlive the project team.

> The project can close. The benefit cannot.

That is also why the benefit owner should normally sit within the business.

A PPM platform can make this easier by keeping the original business case, benefit targets, ownership, and realized results connected to the same project throughout its lifecycle.

Where Perspective PPM Fits

Perspective PPM keeps expected and realized benefits connected to the project and rolls that information up across the portfolio.

That gives leadership visibility into more than just:

It also helps answer:

> What value are these investments actually delivering?

But you do not need specialized software to start.

A shared spreadsheet containing the following will get you surprisingly far:

The important part is not the tool.

The important part is going back and looking.

---

Let the Numbers Be Uncomfortable

Benefits tracking can make people uncomfortable.

That is normal.

Once expected benefits are compared against realized results, some projects will look much less impressive than they did during the go-live celebration.

That is not a failure of benefits tracking.

That is the reason to do it.

Organizations sometimes avoid this discipline because it is easier to leave the business case in the past.

The project launched.

Everyone moved on.

Nobody asks whether the promised savings ever appeared.

That is comfortable.

It is also how organizations continue approving projects using assumptions that were never tested.

Treat the gap as information, not ammunition.

The goal should be:

Not finding someone to blame.

If people believe missed benefit targets will be used against them, future business cases will become defensive.

Assumptions will get padded.

Targets will get softened.

Eventually the numbers become meaningless.

> A healthy benefits process should make the organization more honest, not more cautious about telling the truth.

---

How to Start This Week

You do not need a new governance framework to begin.

Start with one project.

1. Pick one completed project

Choose a project that went live within the last year and had a reasonably confident business case.

2. Find the promised benefits

Rewrite each one as:

If you cannot do that, you have already learned something about the original business case.

3. Identify the benefit owner

Find someone in the business who still owns the outcome now that the project team has moved on.

4. Measure the result today

Put the realized value next to the original expected value.

Even if the number is uncomfortable.

5. Explain the difference

If the benefit is ahead or behind expectations, document why.

The explanation is often more valuable than the number itself.

6. Schedule the next review

Thirty minutes next quarter is enough to keep the benefit from disappearing with the project team.

---

Do this once and something interesting happens.

The next time someone presents a business case promising $2 million in annual savings, the conversation changes.

People start asking:

> How are we going to measure that?

> Who owns the result?

> What is the baseline?

> When should we expect to see it?

> How did similar projects perform?

Those are much better questions than simply asking when the project can start.

---

Shipping Is Not the Finish Line

Shipping proves you can build something.

Benefits prove you should have built it.