Portfolio Rationalisation and Sunset Decisions

Why Rationalisation Is Essential

Portfolios naturally accumulate:

• Initiatives that made sense when approved but no longer align with strategy
• Systems that duplicate functionality across the organisation
• Projects that are technically "in progress" but haven't delivered value in months
• Legacy capabilities that consume maintenance budget without generating returns

Without active rationalisation, the portfolio becomes bloated — consuming capacity on low-value work while high-value opportunities wait for resources.

The Rationalisation Framework

Step 1: Portfolio Inventory

Create a complete inventory of everything consuming capacity:

• Active programmes and projects (with current status and projected benefits)
• BAU systems and services (with annual maintenance cost and business value)
• Initiatives "in progress" that haven't delivered in 6+ months
• Planned initiatives that haven't started despite being approved 12+ months ago

For each item, capture:

• Annual cost (people, infrastructure, vendors, licenses)
• Business value delivered (revenue, cost saving, capability, compliance)
• Strategic alignment (which objective does it support?)
• User base (who uses it? How many? How often?)
• Alternatives (could this be replaced, consolidated, or eliminated?)

Step 2: Value Assessment

Plot each item on a 2×2 matrix:

High Value, High Cost: Strategic assets. Optimise but don't cut. High Value, Low Cost: Efficient investments. Protect and maintain. Low Value, High Cost: Rationalisation candidates. Stop, consolidate, or sunset. Low Value, Low Cost: Monitor. Low priority for action but don't let them grow.

Step 3: Rationalisation Decisions

For items in the "Low Value, High Cost" quadrant:

Stop: Cancel the initiative entirely. Redeploy resources immediately.

• Criteria: No strategic alignment, no measurable benefits, no regulatory requirement
• Action: Formal closure, lessons learned, resource redeployment

Consolidate: Merge with another initiative or system that provides similar capability.

• Criteria: Duplicate functionality exists elsewhere, users can be migrated
• Action: Migration plan, user communication, decommission timeline

Sunset: Planned end-of-life for a system or capability that's being replaced.

• Criteria: Replacement is available, users have been migrated, data has been archived
• Action: Sunset plan with communication, support wind-down, and decommission date

Reduce: Scale back investment without stopping entirely.

• Criteria: Some value remains but current investment level is disproportionate
• Action: Reduce team size, move to maintenance-only mode, limit new feature development

Step 4: Execution

Rationalisation decisions are easy to make and hard to execute. Common blockers:

• Stakeholders resist losing "their" system or project
• Users haven't been migrated to alternatives
• Data retention requirements prevent decommissioning
• Contractual obligations with vendors prevent early termination
• Nobody wants to be the person who "killed" the initiative

Execution principles:

• Set a firm decommission date and communicate it widely
• Assign an owner accountable for the rationalisation (not the original sponsor — they're biased)
• Track progress in portfolio governance (same rigour as starting initiatives)
• Celebrate rationalisation as smart portfolio management, not failure

The Sunset Process

Phase 1: Decision and Communication (Month 1)

• Formal decision to sunset (documented in portfolio governance)
• Stakeholder communication: what's being sunset, why, when, and what replaces it
• User impact assessment: who's affected and what do they need to transition?
• Data retention plan: what data must be preserved and where?

Phase 2: Migration (Months 2-4)

• Users migrated to alternative system/process
• Data migrated or archived per retention requirements
• Integrations disconnected or redirected
• Support team trained on the replacement
• Monitoring confirms migration is complete

Phase 3: Decommission (Month 5)

• System access removed
• Infrastructure deprovisioned
• Vendor contracts terminated
• Licenses cancelled
• Final cost saving confirmed and reported

Phase 4: Confirmation (Month 6)

• Verify no residual dependencies
• Confirm cost savings are being realised
• Close the rationalisation formally
• Report freed capacity to portfolio governance

Measuring Rationalisation Impact

• Capacity freed: Person-months or budget released through rationalisation. Track quarterly.
• Cost savings: Annual run-rate reduction from decommissioned systems and cancelled contracts.
• Portfolio concentration: Number of active initiatives. Should decrease or stabilise (not grow indefinitely).
• Rationalisation velocity: Items rationalised per quarter. Target: at least 1-2 per quarter in a mature portfolio.
• Reinvestment rate: % of freed capacity redirected to strategic initiatives (vs absorbed by BAU growth).

Anti-Patterns

The zombie portfolio: Initiatives that are technically "active" but haven't delivered anything in months. Nobody stops them because nobody wants the confrontation. Fix: quarterly "zombie hunt" — any initiative with no delivery in 90 days must justify continued funding.

Rationalisation without replacement: Sunsetting a system before users have a viable alternative. Fix: migration must be complete before decommission. No exceptions.

Sunk cost paralysis: "We've already spent £2M on this — we can't stop now." Fix: sunk costs are irrelevant to future decisions. The only question is: "Given what we know now, is the remaining investment worth the remaining expected return?"

Rationalisation theatre: Decisions are made to stop things, but execution never happens. The initiative lingers in a half-alive state consuming resources. Fix: assign an owner, set a deadline, track in governance, escalate if blocked.

---

Download the [Portfolio Dashboard template](/templates) for a portfolio health view that highlights rationalisation candidates.