Scale vs sustain vs retire, explained

Scale, sustain, or retire is the three-way decision every value review has to end in: expand the investment, keep it running as it is, or stop it and recover the capacity. It is the closing act of the Learn practice and the point where measurement turns into money and people. A review that ends without picking one of the three has chosen sustain by default, and defaults are how portfolios accumulate work nobody would approve today.

The measurement that feeds this decision is a separate piece of work, covered in the value realization review. This page is about what you do with the answer.

How does the decision work?

Each option is a claim on capacity, and the decision is which claim the evidence supports.

• Scale increases the claim. More funding, more teams, wider rollout, or more scope on the same system.
• Sustain holds the claim steady. The thing keeps running, with an operational owner and enough capacity for support and small fixes, and no new development.
• Retire ends the claim. The system, the feature, or the program is decommissioned or absorbed, and the people and money it consumed go back into the pool.

Two rules keep the decision honest. First, the decision authority is the one named in Align, not the sponsor whose initiative is being reviewed. Second, sustain is a real decision with a real cost, and it has to be stated as one. Sustain means someone is funding support, licensing, and the attention of an operational owner, often for years. Written on the scorecard as an explicit choice, that cost gets weighed. Arrived at by silence, it never does.

What evidence supports scale?

Scale when the measured result met or beat the objective, and there is a named, sized set of users or volume the same mechanism has not reached yet.

The result should come from the operational dashboard rather than from a presentation, and it should hold outside a favorable subset: a number that is only good on early adopters or the simplest cases is not yet evidence. The expansion has to be concrete. "Expand to the other four regions, which handle 60 percent of volume" is scalable. "Roll out more broadly" is not.

Scale is a new claim on capacity, which means it goes back through Align and gets ranked against everything else, not waved through because the pilot worked.

What evidence supports sustain?

Sustain when the thing is delivering roughly what it promised, there is no sized expansion in front of it, and the cost of keeping it running is known and accepted.

The signs are a result that has held steady rather than spiked once, a support load the operational owner can absorb, a named long-term owner, and a stated annual cost of keeping it running, including the specialist knowledge it depends on.

Sustain is also the right answer for a result that missed its target for a reason you understand and accept. The discipline is to record that, rather than restating the objective so the result looks like a pass.

What evidence supports retire?

Retire when the evidence says the thing is not producing the result it was funded for and there is no credible, sized change that would fix it, or when it is producing a result that costs more than it returns.

The cleanest retire case is a failed hypothesis: adoption is fine, the system works as designed, and across the full measurement window the number did not move. Two other cases come up more often than people expect. The objective may now be served by something else, or the cost of sustaining the thing may exceed what it returns, which is the case most often missed because sustain cost is rarely totaled.

Retire needs a plan, not just a decision: decommission or absorb the system, move the data, tell the users, and release the people by a stated date. A retire decision with no date frees nothing.

Why is retire the option teams reach for least?

Retire tends to be the least-used of the three and is often the most valuable, and the reasons are human rather than analytical.

Stopping something looks like admitting the original decision was wrong, and the people in the room are frequently the people who made it. Sunk cost does the rest: the more was spent, the harder it is to stop, which is exactly backwards, since money already spent is not a reason to spend more. A live system also has defenders. Even a system that moved no portfolio number has users who have built habits around it, and their objection is specific while the case for stopping is abstract.

Three things make retire reachable. Name it as one of three standard options at approval time, so it is a normal outcome rather than an accusation. Put the sustain cost in front of the room, because a retire case is much easier to argue against a stated annual figure than against the general feeling that something is still useful. And say out loud what the freed capacity is for: people will stop something to start something specific far more readily than they will stop something in the abstract.

Where does the freed capacity go?

Back into the next Align cycle, as capacity that is available rather than as a saving to be claimed.

This is the part of the loop many portfolios leave unconnected. A retire decision in Learn creates room; Align is the only place that ranks what fills it. The freed capacity does not belong by right to the team that released it or to the sponsor who agreed to stop. It competes with everything else on the candidate list.

What good looks like here is simple to describe: the decision turns into named people and dates before the next ranking session, and somebody records where the capacity went. That record is what makes the next retire decision easier, because somebody can point at what stopping bought last time. Without it, the organization stops things and never sees the benefit, and the argument for stopping has to be made from first principles every time.

Scale, sustain, or retire vs a stage gate vs project closure

The three-way decision is sometimes mistaken for governance steps that look similar and ask different questions.

A stage gate stops work that is going badly on the way through. It cannot stop something that shipped successfully and then failed to matter, which is the case this decision exists for. Project closure is further away still: it confirms delivery and hands over, then the project ends while the system it created goes on consuming capacity with nobody scheduled to ask whether it should.

If your governance has gates and closure but no third decision after the measurement window, then nothing in the process is able to stop a live system, and the portfolio can only grow. Putting that decision point in, with named authority and a standing slot on the portfolio calendar, is part of a PPM4Agile implementation. The surrounding vocabulary is defined in agile portfolio management terms.