At a glance
- Challenge
- Multiple applications do the same job for different teams, on separate contracts, with separate owners — and no forum has the mandate to choose between them.
- Approach
- Map applications to business capabilities, validate owners, cost and adoption, assess dependencies, then drive an owner-approved decision per overlap.
- Primary KPI
- % of the in-scope portfolio with a completed, owner-approved rationalisation decision.
- Impact
- A simpler landscape with fewer contracts, lower run cost and reduced integration and support complexity.
01
Executive Summary
Portfolio rationalisation is rarely blocked by analysis. Most organisations can list their overlapping tools within a fortnight. It is blocked by decision rights: three teams each own a tool that does substantially the same job, each has a defensible reason for their choice, and no forum has both the mandate and the evidence to decide between them.
This playbook therefore treats rationalisation as a decision-making programme with an analytical foundation, rather than an analytical programme that produces recommendations. The analysis — capability mapping, adoption, cost, contract position, dependencies — exists to make the decision defensible and the migration plannable. The decision itself needs a named approver and a governance route agreed before the first assessment is run.
The other frequently underestimated element is dependency and migration cost. An application with low adoption and a high licence cost looks like an obvious retirement until the integration map shows four downstream systems consuming its data. Rationalisation decisions taken without that review produce stalled migrations and a portfolio that is now larger, because the replacement went live and the original never switched off.
02
Business Challenge
Duplication accumulates through entirely reasonable local decisions. A department needs a capability, the enterprise tool does not quite fit, and a departmental purchase solves the problem in a week. Repeated across a large organisation over a decade, this produces four project management tools, three diagramming tools and two competing collaboration platforms — each with a contract, an owner, an integration footprint and a constituency that will defend it.
The cost is not only licensing. Every additional application carries support burden, integration surface, security review, access management, training and a renewal to negotiate. The licence line is usually the smallest component of the total, which is why rationalisation cases built only on licence saving tend to underdeliver against expectation.
03
Typical Symptoms
Organisations that need this playbook usually recognise several of the following.
- Multiple applications deliver the same business capability under separate contracts and owners.
- There is no capability taxonomy, so overlap can only be identified by inspection.
- Applications have no confirmed business owner, or the recorded owner has left.
- Adoption is unknown, so low-value applications cannot be distinguished from critical ones.
- Previous rationalisation attempts stalled at the decision, not at the analysis.
- A replacement went live and the original was never decommissioned, so both are now paid for.
- Integration dependencies are discovered during migration rather than during assessment.
- Retirement benefit is claimed at decision rather than tracked to actual contract termination.
04
Business Risks
Business risks by domain, with the risk and its impact
| Domain | Risk | Impact if unaddressed |
|---|
| Operational |
Dependencies discovered during migration rather than during assessment |
Migrations stall part-complete. The replacement is live, the original cannot be switched off, and the portfolio is temporarily — often permanently — larger than before. |
| Commercial |
Benefit claimed at decision rather than at contract termination |
Reported savings never appear in the budget because the contract ran to term or auto-renewed while the migration completed. |
| Compliance |
Applications retired without data retention and access review |
Records subject to retention obligations are lost with the application, or data remains in a decommissioned system with no access governance. |
| Technology |
No capability taxonomy against which overlap can be assessed |
Overlap is identified by inspection and argued subjectively, so decisions are made on advocacy rather than on evidence and are reopened repeatedly. |
05
Operating Workflow and Reference Architecture
Operating workflow
11 stages, each producing a defined output. This workflow is specific to this
playbook; the category lifecycle on the
Software Value index is an overview of how the playbooks relate,
not how any one of them runs.
↔ Wide diagram — scroll horizontally, or use the
arrow keys once it has focus. A text description is available to screen readers.
Illustrative rationalisation workflow. The decision gate requires a named business owner's approval, not an analyst's recommendation — decision rights, not analysis, are what usually stall this work. Outcomes are not guaranteed.
Reference architecture
The systems, data and controls the workflow above runs on.
↔ Wide diagram — scroll horizontally, or use the
arrow keys once it has focus. A text description is available to screen readers.
Illustrative reference architecture. The dependency mapping in layer two is what determines whether a retirement decision is executable; assessments that omit it produce decisions that stall at migration.
06
Implementation Approach
A representative implementation sequences in 5 phases. Duration and overlap
vary with estate size, data quality and the number of source systems in scope.
Phase 1
Inventory and capability mapping
Build the portfolio view and the taxonomy that makes overlap objective rather than arguable.
- Consolidated application inventory. Assemble the application list from the CMDB, discovery, SaaS management and contract data, and reconcile the differences between them.
- Capability taxonomy. Agree a business capability taxonomy and map every application to it, since overlap can only be assessed against a shared definition of what a capability is.
- Scope definition. Define the in-scope portfolio by cost, capability area or business unit rather than attempting the whole estate at once.
- Overlap shortlist. Produce the initial shortlist of capabilities with multiple applications, ranked by combined cost and count.
Business value
Overlap becomes a factual observation against an agreed taxonomy rather than a subjective judgement that each owner can dispute.
Phase 2
Ownership, cost and adoption validation
Establish who owns each application, what it truly costs and whether anyone uses it.
- Owner confirmation. Confirm a named, current business owner for every in-scope application, and escalate unowned applications as decisions in their own right.
- Total cost of ownership. Build TCO beyond licence cost — support, infrastructure, integration maintenance, security review and administration — since licence-only cases underdeliver.
- Adoption analysis. Assess active adoption against licensed and provisioned population, distinguishing broad shallow use from narrow deep use, which have different implications.
- Contract position. Capture term, notice period and termination rights, since these dictate when a benefit can actually be realised.
Business value
Each application carries an owner, a true cost and an adoption profile — the three inputs a decision-maker actually needs.
Phase 3
Overlap and dependency assessment
Determine which overlaps are real and which retirements are executable.
- Functional fit scoring. Score each overlapping application against the capability requirement, so the choice between them rests on documented criteria.
- Genuine versus apparent overlap. Distinguish applications that genuinely duplicate from those that serve materially different requirements within the same capability.
- Integration and dependency mapping. Map integrations, data flows and downstream consumers for every retirement candidate.
- Risk assessment. Assess business criticality, regulatory dependency and migration complexity before any retirement is proposed.
- Migration effort estimation. Estimate migration and data-transfer effort, since it frequently exceeds the annual saving in the first year.
Business value
Retirement candidates are executable rather than theoretical, because the dependency and migration cost is known before the decision is taken.
Phase 4
Decision and approval
Get an actual decision from an actual decision-maker. This is where rationalisation programmes succeed or quietly stop.
- Decision framework. Apply a consistent retain, replace, consolidate or retire framework with documented criteria rather than case-by-case reasoning.
- Owner approval gate. Require the named business owner's approval on each decision, recorded with the rationale, rather than issuing an analyst recommendation.
- Escalation route. Define in advance how contested decisions are resolved and by whom, since contested overlaps are the ones with the most value attached.
- Sequencing. Sequence decisions against contract dates so that termination rights can actually be exercised.
- Decision register. Maintain a register of decisions with dates and approvers so decisions are not silently reopened.
Business value
Decisions are made, owned and recorded — which is the step that distinguishes a rationalisation programme from a rationalisation report.
Phase 5
Execution and benefit realisation
Migrate, decommission, terminate the contract and let finance confirm the benefit.
- Migration execution. Deliver migration against defined cut-over criteria, with the original application's decommission date set at the outset rather than decided afterwards.
- Data retention and archive. Address retention obligations and archive requirements before decommissioning, with legal and records input where required.
- Decommissioning. Complete technical decommissioning including access removal, integration teardown and CMDB update.
- Contract action. Execute termination or reduction at the correct contractual date — the step most often missed, and the reason claimed benefits fail to materialise.
- Benefit validation. Track benefit to actual contract termination and have finance validate it against the stated baseline.
Business value
Benefit appears in the budget because the contract was actually terminated on time, and finance can confirm it against a baseline stated in advance.
07
Technology Components
Capability categories with representative examples. Most organisations can run rationalisation from existing CMDB, contract and usage data; the binding constraint is decision rights and business engagement rather than tooling. Products are named as examples, not recommendations.
Portfolio and inventory
- ServiceNow CMDB and APM
- Application discovery
- SaaS management inventory
- Business capability taxonomy
Assessment
- Adoption and usage analytics
- Total cost of ownership model
- Integration and dependency mapping
- Contract repository
Decision and execution
- Functional fit scoring
- Decision register
- Migration planning (e.g. Jira)
- Decommissioning checklist
- Data retention and archive
Value
- Benefit register
- Finance validation
- Contract termination tracking
08
Governance Considerations
Governance should be proportionate. The six areas below are the minimum set that has to be
explicit for this capability to hold up under internal review.
Ownership
A named rationalisation programme owner; a confirmed business owner per application accountable for the decision; an architecture owner accountable for capability fit.
Decision rights
The business owner approves the decision for their application; contested overlaps escalate to a defined forum with authority to decide; architecture holds veto on capability-fit grounds.
Policies
Application ownership policy requiring a named current owner; decommissioning policy covering data retention and access removal; no-parallel-running policy with a mandated switch-off date.
Approvals
Every rationalisation decision approved by the named business owner and recorded; contract termination approved by procurement against the notice deadline; retention exceptions approved by legal.
Evidence
Decision register with rationale, approver and date; dependency assessment per retirement; retention and archive records; contract termination confirmation.
Controls
Decommission date set at migration approval, contract notice-deadline alerting, parallel-running duration limits, and benefit validation gate before reporting.
09
Success Metrics
Primary KPI
Portfolio with an approved decision
In-scope applications carrying a completed rationalisation decision approved by a named business owner, not an analyst recommendation awaiting sign-off.
100% of in-scope
Operational KPIs
Applications assessed
100% of in-scope
Applications with completed assessment data.
Business owners confirmed
100%
Applications with a named, current business owner.
Duplicate capabilities identified
Tracked against taxonomy
Capabilities served by multiple applications.
Decision cycle time
< 60 days from assessment
Elapsed time from assessment to approved decision.
Governance KPIs
Approved for retirement
Against identified overlaps
Applications with an approved retire decision.
Decommission delays
< 10% past target date
Retirements running past their planned date.
Retention compliance
100% of decommissions
Data retention addressed before switch-off.
Decisions reopened
< 5%
Approved decisions subsequently reversed.
Value KPIs
Migrations completed
Against plan
Migrations delivered to cut-over criteria.
Contracts eliminated
Count per cycle
Contracts terminated or not renewed.
Licences reclaimed
Count per cycle
Licences released through consolidation.
Annual run-cost removed
Finance-validated
Recurring cost removed and confirmed by finance.
Technical debt reduction
Integrations retired
Integration points removed with the application.
Benefit realisation
Against modelled
Realised benefit against the decision business case.
Indicative targets
Every target above is an indicative KPI for a typical enterprise, intended to support
planning discussions. Baselines should be measured in the first operating cycle and targets
set from them. These are not benchmarks, commitments or achieved client results.
10
Positive Business Impact
Overlap becomes objective
A shared capability taxonomy turns 'these tools do the same thing' from an opinion into a documented observation that owners can be held to.
Decisions actually get made
A named approver and a defined escalation route for contested overlaps addresses the reason most rationalisation programmes stall — decision rights, not analysis.
Retirements that are executable
Dependency and migration effort are assessed before the decision, so approved retirements complete rather than stalling with both systems live.
Fewer contracts to negotiate and govern
Consolidation removes not just licence cost but the renewal, security review, access management and support burden attached to each contract.
Lower integration and support complexity
Each retired application removes its integration points, which reduces the change surface for every future project.
Benefit that reaches the budget
Tracking to actual contract termination with finance validation means the saving appears where the CFO can see it.
Outcomes depend on estate, contracts, data quality and organisational context, and are not guaranteed.
11
Related Playbooks
Playbooks commonly delivered alongside, before or after this one.
Important — please read
This playbook describes a typical implementation approach and a representative operating
model. It is illustrative guidance, not a statement of results. Any figures, targets or
ranges shown are illustrative and are intended to support planning discussions rather than
to predict or promise an outcome. Outcomes are not guaranteed and depend on the estate,
contracts, data quality and organisational context of each engagement.
No client names, client data, engagement detail or confidential delivery material is
disclosed anywhere in this library. Technology named in these pages appears only as an
illustrative example of a capability category and does not imply a partnership,
certification or recommendation.
