Application Portfolio Management Best Practices: Six Rules for Estates Nobody Has Ever Fully Inventoried

Most application portfolio management programmes begin with a diagram nobody believes. The CIO presents a system map to the steering committee, and somewhere in the room, three people know of applications that are not on it. This is not a governance failure. It is the normal condition of a mature estate, and the best practices that survive it are the ones designed around that fact, not the ones that assume a clean starting point.

The honest version of the problem looks like this. Your organisation has been acquiring, building, and tolerating software for fifteen or twenty years. Some of it was licensed, some was built in-house, some arrived through an acquisition and was never fully assessed. The portfolio review scheduled for last year was postponed because a migration project consumed the team. The inventory that exists was last validated eighteen months ago by a consultant who has since left. And the business unit that runs its own SaaS stack has not shared a list of what it subscribes to since the pandemic.

This is not an unusual estate. It is a typical one. The application portfolio management best practices worth following are the ones designed for this reality.

What should application portfolio management best practices actually start with?

There is a consistent pattern in failed portfolio programmes: they begin with a tool selection. The team evaluates platforms, procures the one with the best demo, and then discovers that the tool requires clean, structured data to function and the estate has none. The tool sits partly populated for a year. The steering committee loses confidence. The programme is quietly deprioritised.

The discipline that works inverts this sequence. Before any tool, before any scoring framework, you need a first-pass inventory. That means pulling every software line item from the last twelve months of invoices. It means running a query against your active directory to see what is authenticating. It means asking the infrastructure team what is running on the servers, virtual or otherwise, and comparing that list to what the patch management system has seen recently. It means sitting with the heads of each business unit for one hour each and asking them to name the systems their team cannot work without.

This process takes four to six weeks for a mid-sized estate. It produces a list that is incomplete, inconsistent in format, and partially duplicated. That list, imperfect as it is, is worth more than a polished tool with no data in it.

Gartner's research on application portfolio management consistently identifies inventory accuracy as the foundational constraint. You cannot score what you cannot see, and you cannot retire what you do not know exists. The investment in the inventory is not a preliminary step - it is the programme.

Once the list exists, even in rough form, you can begin assigning the two things each application needs before any decision can be made: a business owner and a cost-to-run figure.

How do you assign ownership to applications in a portfolio no one is responsible for?

This is the step most portfolio programmes skip, and it is the step whose absence causes everything else to degrade.

An application without a named business owner becomes an orphan within months of the first review. No one confirms whether the usage data is current. No one flags when the business process it supported was retired. No one signs off on a renewal decision because no one knows they were supposed to. The portfolio analyst updates the spreadsheet based on whatever data was last entered, and the entry silently becomes fiction.

The fix is structural. When you identify an application in the inventory, do not assign it to IT. Assign it to whoever leads the function it serves. Accounts payable applications belong to the CFO's team. Customer relationship systems belong to the head of sales or customer success. HR platforms belong to the HR director. If the application serves multiple functions, pick the primary one and name a single owner. Shared ownership in practice means no ownership.

The business owner has two responsibilities: confirming annually that the application still delivers value, and approving any decision to change its status in the portfolio.

IT manages the technical record, tracks integration dependencies, and flags compliance and security concerns. The business owner decides whether the thing is still worth keeping. Those are different questions, and conflating them is why portfolio reviews get bogged down in debates that neither the IT team nor the steering committee can resolve cleanly.

For applications that have been running long enough that no one remembers who commissioned them, the discovery process is simple: find out which team raises support tickets for it, which team would shout if it went down, and that team's leader is your starting point.

How do you score applications in a portfolio when the data is incomplete?

Gartner's TIME model gives each application one of four labels: Tolerate, Invest, Migrate, or Eliminate. The labels are determined by plotting the application against two axes - technical fitness and business value. An application that scores low on both gets Eliminated. One that scores high on both gets Invested in. The ones that score high on business value but low on technical fitness are Migration candidates. The ones that score low on business value but are technically healthy are Tolerated until a better moment to retire them arrives.

The model is not novel, but its usefulness is precisely its simplicity. It creates a shared vocabulary that works across a steering committee where some members have deep technical backgrounds and others have none. When you say "this application is in the Tolerate quadrant," everyone understands that it is not a priority for investment, but it is also not being retired today.

The most common objection to scoring is that the data is too incomplete to trust. This objection is correct and also irrelevant. The alternative to scoring with imperfect data is making decisions with no framework at all, which is what most organisations are already doing. An estimate that is documented, owned, and revisable is categorically more useful than an undocumented impression.

Document your assumptions when you score. If you estimated the annual cost-to-run because the actual figure was not available, say so in the record and flag it for verification. If the business value score came from a single interview with the department head rather than a formal survey, record that too. When the second annual review arrives, those flagged estimates are what the analyst checks first.

The scoring improves through use. The first cycle is rough. The second cycle corrects the roughest estimates. By the third cycle, the data is reliable enough to defend in front of a board.

When is "leave it alone" the right answer from a portfolio review?

This point needs stating plainly because it runs against the grain of most content written about application portfolio management, most of which is produced by firms that also sell modernization work.

Some applications are old and that is fine. Age alone is not a reason to replace a system. If a payroll engine has been running reliably for twelve years, processes accurately, integrates cleanly with the systems around it, and costs a known amount to maintain, the burden of proof is on the case for replacement, not on the case for keeping it. The cost of a migration, including the hidden costs of data cleansing, parallel running, staff retraining, and the inevitable complications, is frequently underestimated by a factor of two or three.

The Standish Group CHAOS reports have tracked IT project outcomes for decades. Their data, which measures project delivery against original scope, schedule, and budget, consistently shows that large software replacement projects overrun significantly. The 2020 report found that projects over $10 million were delivered successfully, by their definition of on time and on budget, less than 10% of the time. This is not an argument against ever replacing a system. It is an argument for being honest about the base rate before you start.

The portfolio review should have three real outcomes available: invest, replace, and leave alone. If the team conducting the review would only ever recommend investment or replacement, the review is compromised by its own conclusions. A finding that says "these fourteen applications should be left as they are for the next three years" is as useful as a modernization roadmap, and in a mature estate, it frees budget and attention for the systems that actually need it.

The same logic applies to retiring systems. If an application has low business value, is technically unfit, and can be switched off without consequence, the right answer is to retire it. Not migrate it. Not replace it with something modern. Switch it off, confirm that nothing breaks, and remove it from the estate permanently. Every application you retire reduces the maintenance burden on the people who keep everything running.

How do you govern a portfolio so the estate does not silently grow back?

The most common failure mode after a successful first portfolio review is that the estate grows back. A business unit subscribes to a new SaaS platform without an IT conversation. A project team builds an internal tool that works well enough that three other teams start using it. An acquisition arrives with thirty applications attached, half of which overlap with systems already in the portfolio. Within two years, the carefully rationalised estate has returned to roughly its original complexity, and the steering committee is looking at the same problem it thought it had solved.

The fix is a demand-side control, applied consistently. Any request for a new application, or any renewal of an existing one above a defined spend threshold, should require a lightweight portfolio check before approval. The check asks three questions: does this capability already exist in the estate, what is the total cost including integration and support, and who is the named business owner? If the answers are satisfactory, the request proceeds. If they reveal a duplicate capability or an unowned system in the existing estate, that becomes a decision to make before adding anything new.

This is not a heavy process. For most organisations, the check can be completed in a week for a standard SaaS subscription and two weeks for anything requiring integration work. What it prevents is the slow accumulation of shadow IT and duplicate tooling that has historically been the main driver of estate complexity.

The annual scored review remains necessary alongside the demand-side control. Technology changes, business priorities shift, and the fitness of an application changes over time even when no one touches it. A system that was correctly rated Tolerate three years ago may now have a security posture that pushes it toward Eliminate. An application rated Invest may have been superseded by a platform already in the estate that now covers its function.

Konnectedly's model for independent portfolio assessment exists precisely for the moments when the internal team lacks the bandwidth or the political neutrality to run this process themselves. The value of an external review is not that it produces different data - it produces the same data, more quickly, and with fewer internal compromises on the scoring.

A portfolio review that the internal team cannot conduct without fear of internal politics is a review that will not deliver honest conclusions.

Assign a programme sponsor at the executive level. Give the programme analyst authority to request data from any part of the organisation. Publish the conclusions to the steering committee in full. These are not complex governance requirements, but each one of them is routinely absent in failed programmes, and their absence is usually why the programme fails.

Frequently Asked Questions

What are the most important application portfolio management best practices?

The most important practices are: build an accurate inventory before making any decisions, assign a business owner to every application, measure cost-to-run not just licence fees, score each application against a consistent framework such as Gartner's TIME model, and treat "leave it alone" as a legitimate outcome. Without the inventory, everything else is guesswork.

How do you start an application portfolio management programme when the estate is not documented?

Start with the financial and operational data you already have: licence invoices, infrastructure bills, support ticket volumes, and staff interviews. Cross-reference these against active directory, network traffic logs, and patch records. This produces a first-pass inventory in four to six weeks without requiring a system-of-record tool or a large project team.

What is the Gartner TIME model and how does it relate to application portfolio management?

The Gartner TIME model categorises each application as Tolerate, Invest, Migrate, or Eliminate, based on its technical condition and business value. It gives a portfolio review a consistent scoring language so decisions are comparable across business units and can be defended in a steering committee without descending into individual opinion.

How often should an application portfolio be reviewed?

A full scored review once a year is the minimum. High-velocity organisations review quarterly. The more useful discipline is a standing rule that any new application request or renewal above a defined spend threshold triggers a lightweight portfolio check, so the estate does not silently grow between formal review cycles.

What does application portfolio management cost to run as a programme?

For a mid-sized estate of 100 to 400 applications, a credible annual programme typically requires one dedicated portfolio analyst, a lightweight tooling budget of roughly $20,000 to $80,000 per year depending on the platform, and senior sponsor time of around half a day per month. The cost of not running it is usually visible in the next audit.

What is the difference between application portfolio management and app rationalization?

Application portfolio management is the ongoing discipline of tracking, scoring, and governing the full estate. App rationalization is a specific decision exercise within that discipline - the point at which you decide which applications to consolidate, retire, or replace. Rationalization is an output of good portfolio management, not a substitute for it.

When is "leave it alone" the right answer in an application portfolio review?

When an application is technically stable, costs a known and acceptable amount to run, has no near-term compliance exposure, and would cost more to replace than to keep, the right answer is to leave it alone and direct investment elsewhere. A review that always concludes "modernize" is not analysis; it is a sales pitch.

What makes application portfolio management programmes fail?

The two most common failure modes are starting with a tool purchase before the data exists to populate it, and running the review without a business owner assigned to each application. Without a named owner who can confirm what the system does and who depends on it, the data degrades within months and the portfolio becomes a list of orphans.