Application Portfolio Management Tools: Why the Tool Is the Last Decision, Not the First

The procurement sequence goes like this: a steering committee decides it needs visibility of the application estate, someone is asked to find a tool that provides it, three vendors are shortlisted, and six months later the organisation has a licence, an implementation partner, and a database full of fields that nobody agreed to populate. The application portfolio management tools market is built on that sequence. It works extremely well for the vendors. It works considerably less well for the people who signed the contract.

The problem is not that the tools are bad. Several of them are genuinely good. The problem is that the tool is purchased to solve a data problem when the actual problem is a decision problem. No platform, however well integrated, tells you which of your 340 applications deserves investment and which should be switched off next quarter. It stores the information that might lead you to that conclusion, provided someone has put the right information in and someone else has agreed on what "right" means. Those two conditions are not technical. They are organisational. And they are almost never in place before the licence is signed.

What do application portfolio management tools actually do?

It is worth being precise about this, because the sales materials are not. An APM tool is a data repository with visualisation on top. The visualisations - heat maps of technical health against business value, bubble charts of cost against usage, capability maps showing which functions are served by how many applications - are genuinely useful. They surface patterns that a manually maintained spreadsheet makes hard to see. A portfolio of 400 applications with overlapping capability coverage becomes visible in a way that 400 rows of a spreadsheet does not.

But the tool does not generate the underlying judgements; it displays them. Someone still has to score each application's technical health. Someone still has to map each application to a business capability. Someone still has to agree on whether "strategic fit" is scored 1-to-5 or rated against a fixed taxonomy. Those decisions sit entirely outside the platform. They are governance decisions, and governance is not a feature you can buy.

The leading platforms - LeanIX, Planview Enterprise One, Alfabet (now part of Software AG), and ServiceNow's Strategic Portfolio Management module - each handle this differently. LeanIX pushes hard on integrations, pulling data automatically from cloud infrastructure and HR systems to reduce manual entry. Planview emphasises the connection between portfolio data and investment planning. Alfabet has historically served large regulated enterprises that need an audit trail for every data change. ServiceNow's value proposition is consolidation: if you are already running ServiceNow for ITSM, adding the APM module keeps the data in one place. Each has genuine strengths. Each also requires significant upfront work to configure and populate before it produces anything a steering committee would trust.

That upfront work is what vendors tend to understate in the sales process. Getting 200 application records to a genuinely usable state - verified owners, accurate fully loaded costs, meaningful capability mappings, honest technical health scores - typically takes three to six months of focused analyst effort. That effort exists regardless of which platform hosts the data. The tool gives the effort somewhere to live; it does not reduce the effort.

When does a spreadsheet outperform a dedicated APM tool?

This is the part of the conversation that vendors have no commercial interest in having, so it rarely gets had. The honest boundary is somewhere around 200 applications. Below that threshold, the core analytical task - scoring each application, mapping it to business capabilities, reviewing it on a regular cycle - is entirely manageable in a spreadsheet that a single portfolio analyst owns and maintains.

The spreadsheet breaks down in three specific situations. First, when multiple business units need to submit and update data simultaneously and a single owner becomes a bottleneck. Second, when you need automated cost feeds from finance and infrastructure systems because manual entry is too slow or too error-prone. Third, when regulatory or audit requirements demand a complete change history that shows who altered which record and when.

None of those conditions apply to most organisations with estates under 200 applications. What does apply is the governance model: who owns each record, what fields are mandatory, what the review cadence is, and what decisions the portfolio review is supposed to inform. A spreadsheet with a clear governance model produces better decisions than a sophisticated platform with a vague one.

There is a practical test worth running before any tool evaluation starts. Take your current application list, whatever form it exists in, and try to run a portfolio review with it. Can you score each application on technical health with enough confidence to put the scores in front of a CFO? Do you know the fully loaded annual cost of running each application, including infrastructure, licences, support contracts, and the internal staff time that touches it? Can you map each application to a business capability clearly enough that two different people would map it the same way?

If the answer to those questions is no, the problem is not that you lack a tool. The problem is that the underlying data does not exist yet, and no tool resolves that. The tool just makes the absence more expensive.

What do application portfolio management tools cost, fully loaded?

Vendors publish starting prices that reflect small deployments and exclude the work that makes the platform useful. A realistic cost model for a mid-sized enterprise implementing one of the leading platforms for the first time looks something like this.

Licence fees for an estate of 300 to 500 applications sit between £60,000 and £120,000 per year for the major platforms, though configuration and add-on modules can push that significantly higher. Implementation - configuring the data model, connecting integrations, training the team - runs between £40,000 and £100,000 as a one-time cost, though complex estates with many source systems to integrate can exceed that. These figures are based on published pricing tiers and implementation partner rate cards that are consistent across the market; treat them as a reasonable order of magnitude rather than a binding quote, because actual costs depend heavily on how complex your data sources are and how much configuration the platform requires.

The cost that almost never appears in a vendor proposal is the internal analyst effort required to populate and maintain the data. A portfolio analyst spending 60 percent of their time maintaining APM data is a real cost - in the UK, that is somewhere around £35,000 to £45,000 per year in salary terms alone, before overhead. Multiply that across a team of two or three and the internal cost of maintaining the tool exceeds the licence fee within two years.

None of this means the tool is not worth it. For a large, complex estate with multiple business units and a governance structure that runs real portfolio reviews, a well-implemented platform genuinely earns its cost by making the data accessible to the right people at the right time. The discipline is in knowing whether your estate and your governance structure are at that level before you sign the contract, not after.

Why do most APM tool implementations fail to produce useful data?

Gartner's research on application portfolio management has consistently noted that the value of APM as a discipline depends less on tooling and more on the governance structures that sustain the data. That observation has been in the literature for over a decade. It has not changed how most implementations begin.

The failure pattern is consistent. The tool is purchased. An implementation partner is engaged to configure it. The first task is populating the application inventory. At that point, three problems surface simultaneously. Nobody has a complete list of what applications exist. Nobody has agreed on how to define the fields - does "technical health" mean the platform team's view, the development team's view, or a formal assessment result? And nobody has established who is accountable for keeping each record current once the implementation partner has left.

The result is a database that is accurate as of the go-live date and gradually becomes less accurate every quarter thereafter. By the time the tool reaches its first annual review, the records are stale enough that the portfolio team spends the review correcting data rather than making decisions. By the second review, the platform is quietly referred to internally as the system nobody trusts.

This is not a tool failure. The platforms work as designed. It is a sequencing failure, and it is entirely predictable and entirely avoidable. The sequence that works is: agree the data model first, populate it manually or in a spreadsheet to test whether the model produces useful decisions, run one or two portfolio review cycles to validate the governance, and only then select a tool that fits the data model and the governance cadence you have already proved out. That sequence is slower. It produces a tool implementation that actually works.

What is the right sequence before selecting an APM tool?

The practical starting point is an inventory. Not a perfect one - a perfect one will take longer than any steering committee will wait and will be out of date by the time it is finished. A rough one, built from the sources that already exist: the IT service management system, the licence management records, the infrastructure cost reports, the finance system's vendor payment data. Combining those sources typically surfaces 70 to 80 percent of the application estate within a few weeks. The remaining 20 to 30 percent - the shadow IT, the departmentally managed tools, the integrations that live in someone's head - emerges over time as the governance model gives people a reason to declare what they are running.

Once the inventory exists, the data model question becomes concrete. You are not designing abstract fields; you are looking at a list of 180 applications and asking what you actually need to know about each one to make a funding decision. For most organisations, the essential fields are fewer than ten: application name, primary owner, business capability served, annual fully loaded cost, user count, technical health rating, and strategic fit classification. That is enough to run a meaningful portfolio review. Everything beyond that is refinement.

Run one portfolio review cycle with that data in a spreadsheet before you evaluate any tool. That review will tell you whether the data model is right, whether the governance works, and whether the output is decision-grade. If the CFO looks at the output and says "I would fund this on the basis of that data," the data model is right. If the response is "where did these numbers come from and can I trust them," the data model needs work, and the tool you were about to buy would have inherited that problem.

Konnectedly's application estate assessments follow this sequence: inventory, data model validation, one review cycle, then a recommendation on whether a tool is warranted and - if it is - what specification it needs to meet. The recommendation is sometimes "a governed spreadsheet is enough." That is not a disappointing answer. It is frequently the right one.

Which application portfolio management tools are worth evaluating for large estates?

For organisations that have passed the threshold where a spreadsheet genuinely breaks down - multiple business units, automated cost feeds required, audit trail needed - the evaluation should start with the governance requirements, not the feature comparison matrix.

LeanIX is well suited to organisations that are already running cloud-native infrastructure and want integrations that pull data automatically from AWS, Azure, or GCP alongside HR and finance systems. Its strength is reducing manual entry for estates where the infrastructure data is already clean and structured. Its weakness is that the data model is opinionated, and organisations with complex or non-standard capability taxonomies sometimes find it constraining.

Planview's strength is the connection between portfolio data and investment and resource planning. If the primary use case is feeding portfolio decisions into the annual budgeting process - which application investments get funded and which do not - Planview's integration of portfolio management with financial planning is genuinely useful.

Alfabet has historically served large regulated enterprises in financial services and utilities where the audit trail and the data governance features matter as much as the analysis. It is not the most intuitive platform to operate, but for organisations where the regulator may ask who changed which record and when, that audit capability has real value.

ServiceNow's APM module makes most sense when the organisation is already running ServiceNow for IT service management, because the application data already lives in the Configuration Management Database and the APM module sits on top of it rather than requiring a parallel data population exercise. If you are not already a ServiceNow customer, it is rarely the right starting point for APM alone.

None of these tools is a reasonable purchase before the data model and governance questions are resolved. They are all capable of hosting good data well. They are equally capable of hosting bad data expensively.

Frequently Asked Questions

What do application portfolio management tools actually do?

They give you a structured place to record, score and visualise what applications you run, what they cost, and how well they serve the business. The better ones connect to your financial and HR data to surface cost-per-application automatically. The weaker ones are expensive spreadsheets with a nicer interface and a sales team behind them.

When does an organisation need a dedicated APM tool rather than a spreadsheet?

When the estate exceeds roughly 200 applications, when multiple business units need to submit and view data simultaneously, or when the portfolio review happens more than twice a year and manual consolidation is consuming analyst time. Below those thresholds, a well-structured spreadsheet - shared and governed - does the same analytical work for a fraction of the cost.

What do the leading application portfolio management tools cost?

Licensing for enterprise APM platforms from vendors such as LeanIX, Planview, or ServiceNow Strategic Portfolio Management typically runs from £40,000 to well over £200,000 per year depending on estate size and module selection. Implementation and data-population work frequently doubles that figure in year one. Smaller tools and open-source frameworks exist at lower price points but require more internal effort to maintain.

Why do most APM tool implementations fail to deliver useful data?

Because the tool is purchased before the organisation has agreed on what a "current state" record needs to contain, who owns each application entry, and how often the data is reviewed. A platform pointed at bad or incomplete data produces bad or incomplete reports faster. The governance model has to come before the tool, not after it.

What is the right order of steps before selecting an APM tool?

First, inventory what you have - even roughly. Second, agree on the minimum data fields that matter for your decisions: cost, owner, business capability served, technical health, and strategic fit. Third, run one portfolio review cycle manually to test whether those fields actually drive decisions. Only then does tool selection have a brief specific enough to evaluate vendors against.

Can a spreadsheet replace an APM tool for a large estate?

Not indefinitely. A spreadsheet breaks down when more than a handful of people need to update it simultaneously, when you need automated cost feeds from finance systems, or when regulatory reporting requires an audit trail of changes. For estates under 200 applications with a single portfolio owner, a spreadsheet is not a workaround - it is the appropriate tool.

What is the biggest hidden cost of an APM tool?

Data population and ongoing maintenance. Vendors rarely surface this in the sales process. Getting 150 application records to a usable state - with verified owners, accurate cost figures, and meaningful capability mappings - typically takes three to six months of analyst effort regardless of which platform hosts the data. That effort exists with or without the tool; the tool just gives it somewhere to live.

How do APM tools connect to modernization decisions?

They provide the structured inventory that makes prioritisation possible. A well-maintained portfolio view shows you which applications are expensive to run, which are technically fragile, and which serve capabilities the business no longer needs. That is the starting point for a modernization conversation - but the tool surfaces the question; it does not answer it. The answer still requires human judgement about strategy, risk and cost.