Application Portfolio Management
The estate you already run, decided and kept that way.
A defensible list of what you run, a verdict against every line, and the function that stops both going stale.
Advisory. Set up as a standing practice your own team runs, with us in the cycle where the calls are contested.
The software spend has three answers depending on who you ask, agreements renew themselves because nobody served notice, or you are about to buy something a vendor you already pay for now includes.
The work this practice comes out of
More of our work ↗An estate inventoried, decided and kept decided
Every application inventoried from evidence rather than memory, assessed on business value and technical condition, and given a verdict: tolerate, invest, migrate or eliminate. The portfolio practice went in behind the review, so the next round of decisions started from a live list rather than a fresh count. Read the work
Two of everything, after an acquisition
An acquisition left the combined business with two of every system, contract and data set. Both estates were mapped, a decision taken on which systems survived, were retired or were merged, and the moves sequenced — identity and email first, then the core systems. Read the work
Capability models built to map a portfolio against
Enterprise capability models across telecom, oil and gas, financial services and the public sector, including a university and a city. Each was structured so applications, processes and investment could be mapped against it. Read the work
What you keep
The code and the data·Your existing relationships·Approval and control·The ability to stop·The off switchWhat that means
What keeps a portfolio current
One inventory, reconciled
Built from where money and access leave a trace — the ledger, the identity provider, the contract folder — rather than from a survey of what people remember, then mapped onto the capability model your architecture function maintains. No CMDB, and none needed.
Sign-in data before the scoring session
Every owner will call their system essential, and they will all be sincere. With active-use data on the table the review is an evidence conversation. Without it, the most senior person in the room wins every disputed call.
Cost per application, and per capability
What each application costs to run for a year, and what the capability it serves costs in total — including the spend that arrives on a credit card and the spend folded inside somebody else's bundle. The model underneath is IT financial management. Here it stops being reporting and becomes an argument.
A verdict, and what it commits you to
Tolerate, invest, migrate or eliminate, each written down as something a named person has agreed to carry. Migrate is the one that tests whether the exercise was real, because it spends money and goodwill on a system that is not currently failing. Where the model helps, and where it stops.
The renewal calendar
Every agreement carrying real money, with its notice window against it and a usage check that has to clear before anything is signed again. Entitlements against deployment and the true-up exposure sit with IT financial management; what sits here is the decision the date forces, on a date the business did not choose.
Lifecycle and support exposure
Which parts of the estate are late in life, and the vendor dates that will force a call before the replacement is affordable. An end-of-support date that has survived several planning rounds on the same slide is not a plan. It is a deadline somebody else set.
An intake gate on new spend
A purchase request tested against what the estate already covers before it is approved, rather than after it is live and has users. A rationalization almost never leaves this behind, which is why its results do not last.
Agents counted like anything else you run
An agent built in a workshop and wired into a mailbox is a system a team now depends on. It takes an owner, a cost, a place on the capability map and a stated reason it would ever be switched off. What to build with them is AI strategy. What you already own is this.
One set of criteria, three functions
IT, procurement and finance working one list against one set of criteria, on a cycle that lands where the money is decided rather than in a technology forum the CFO does not attend. The three of them together are also the only way an application nobody owns gets an owner, rather than another year of everybody assuming somebody else was watching.
We keep the inventory reconciled against where the money and the logins actually are, hold an owner and a run cost against every application, and keep the verdict on each one current as the estate moves. Behind that sit the renewal calendar and the intake gate that stop the list going stale again. Where there is no list yet, that is the application estate review.
Three functions have a number, and none of them is the estate
IT knows what runs. Procurement knows what was signed. Finance knows what is being paid. Each list is accurate, and the gap between the smallest number and the largest is often wider than the budget line everyone is arguing about cutting.
Run cost is the part that never resolves, because nobody can say which applications it belongs to. So the cut, when it comes, is a flat percentage applied equally to the systems the business competes on and the ones still being paid for out of habit. A total is a number. The same total split by application, and then by capability, is a decision.
A defensible count beats a precise one. The estates that never get counted are the ones waiting to be counted exactly.
The rationalization was not wrong. Nothing came after it
A rationalization ends. The buying does not. Applications keep arriving one at a time — a departmental subscription, a module a vendor included at renewal, a tool someone needed on a Thursday — and not one of them passes through an exercise that has already closed. The estate reassembles itself out of individually sensible purchases.
Nothing about that looks like failure, which is why it runs so long. The review was good work and the verdicts were sound. What was never touched was the buying that built the estate in the first place. A rationalization is an event. A portfolio is a function, and the difference between them is whether anything happens after the presentation.
Two portfolios, one word
One portfolio is what is being asked for. The other is what you already run. IT portfolio management decides what starts. This decides what stays — and hands the other one the run cost it plans against, plus the retirements that pay for anything new. The same discipline, pointed at the estate instead of the pipeline.
The newest things you run are the least counted
The estate stopped being IT’s to count some time ago. Software arrives on an expense claim and a personal login, works well, is liked — and has no contract, no owner and no line in any budget. AI made that faster, because a free tier is a sign-up rather than a purchase, and the company’s information goes with it.
Every incumbent vendor has become an AI vendor too, which means capability you already pay for is quietly being bought a second time, usually by the people most enthusiastic about it. And the pilots nobody can list are all still running, because nobody ever wrote down what would end one.
When the board asks when the business will be ready to do something serious with AI, the honest answer is a description of the estate: where the information an agent would need actually sits, who owns it, and how much of it is a spreadsheet. Every integration and reporting initiative is priced by that same estate, which is why this work sits upstream of the work people are actually excited about.
Buy the picture first, if you have never had one
Most organizations should not start here. If nobody can produce the list, a standing practice has nothing to keep current. The first complete picture is a piece of work in its own right: the application estate review builds the capability model, maps the landscape and takes a verdict on every application, and the worked example carries an invented mid-market estate through end to end. This page is what comes next, and it is the part that usually lapses.
Taking them in the other order is possible. It usually means the first decisions get made against a list nobody trusts yet.
IT Strategy
A technology plan your business recognizes, costed and funded.
Learn more ↗Enterprise Architecture
Decisions made once, so every project is not a fresh argument.
Learn more ↗AI Strategy & Enablement
An AI plan the business can fund, and the capability to deliver it.
Learn more ↗IT Portfolio Management
One list of everything being asked for, ranked and funded.
Learn more ↗IT Operating Model
An IT function set up to deliver what the business asks of it.
Learn more ↗IT Service Management Design
Service levels, incidents and changes that work the way people expect.
Learn more ↗IT Financial Management
Know what technology costs, where it goes, and what it buys.
Learn more ↗Program & Project Delivery Assurance
An independent read on whether a program is where it says it is.
Learn more ↗Fractional CIO
Experienced technology leadership, without a full-time hire.
Learn more ↗Start with a 45-minute briefing.
No pitch. Bring the decision you are stuck on and we will tell you what we would do about it, including when that is nothing.