The ownership question
Some of the applications costing an organisation money may no longer have anyone clearly accountable for them.
I saw this while working in a complex post-acquisition environment.
The organisation had grown through inorganic acquisitions, including acquisitions that had taken place before the one I was involved with. Each had brought systems, contracts, processes and ways of working into the environment. Over time, organisational structures changed, people moved roles and teams were reorganised. The applications remained.
My role was to help create a more efficient and manageable operating environment. Part of that work involved application rationalisation. Before we could decide which systems were still earning the money and effort required to keep them, we had to answer a more basic question: who owned them now?
In many cases, the answer was not obvious.
The system remained after the ownership moved
Applications rarely enter an organisation for no reason. Someone identifies a need. A tool is purchased or built. People learn to use it, and processes form around it. In an acquisition, the application may then enter a larger environment where a similar capability already exists.
The people who understood the original decision may leave. The acquired business may be reorganised. Technical support may move to a central team while business accountability remains unclear. A contract continues to renew because stopping it would require a decision, but nobody is certain who has the authority or the information to make that decision.
Some applications still had users but no clear business owner. Others had a technical team keeping them operational without anyone accountable for determining whether they should remain. There were systems for which several teams had a partial interest, but no single person owned the cost, value, risk and eventual retirement decision.
Taken individually, none of these situations looked alarming. Together, they represented meaningful cost, unclear risk and a more complicated environment than the organisation needed.
The first task was therefore not to compile a list of systems to remove. It was to identify and establish ownership. Who understood the business purpose? Who knew the dependencies? Who could confirm the actual users? Who was accountable for the spend? Who could accept the operational risk of retaining or retiring it?
Until those questions had answers, rationalisation would have been guesswork.
Ownership was not about finding someone to blame
Establishing ownership did not mean finding a name to attach to an old expense. It meant creating a responsible place for the decision to sit.
An owner had to be able to explain the application's current value, understand what depended on it and remain accountable for the consequences of the decision. In some cases, that meant retaining the system because the need was real. In others, it meant planning a careful retirement.
It also meant separating the value a system once provided from the value it was providing now. Retiring an application did not make the original decision foolish. The circumstances had changed, and the decision needed to change with them.
Defensible is not the same as necessary
Almost any established expense can be defended.
There will be a reason it began, a person who still uses it and a scenario in which it remains helpful. If the test is merely whether somebody can make a case for keeping it, very little will ever leave an operating budget.
The better test is more demanding. If we were designing the environment today, with no obligation to preserve its history, would we choose this system, at this cost, for the value it currently provides?
That question changed the discussion.
It allowed us to look at actual usage rather than assumption, overlap rather than organisational history, and current value rather than the effort already invested. It also helped us distinguish between removing something carelessly and retiring it responsibly.
Operational continuity left little room for careless disruption. A reduction in cost that damaged control, quality or essential work would not have solved the problem. Every change had to be practical, carefully sequenced and connected to a clear operational improvement.
The work did not involve issuing a blanket instruction that every team cut the same percentage. It involved examining systems one by one, assigning accountable owners, understanding dependencies, listening to the people who used them and keeping an application when the evidence supported it.
It also required being willing to retire one when the evidence did not.
What changed once ownership became clear
Ownership made the portfolio discussable in a way it had not been before. Each application could be examined against the same practical questions. Who actually used it? What business need did it serve? Which processes and systems depended on it? What did it cost to license, host, support and control? What would happen if it were removed?
Those answers allowed us to distinguish several very different situations. Some applications remained necessary and needed clear ownership. Some duplicated capabilities available elsewhere. Some served a valid need but could be consolidated. Others required an orderly retirement plan because the need had faded or moved.
The process was not a single review followed by a list of cuts. It required an inventory, conversations with actual users, dependency mapping, cost visibility and named business and technical owners. Decisions then needed dates, transition actions and people accountable for completing them.
As those decisions were carried through, the operating environment became simpler and easier to manage. Fewer overlapping applications meant fewer contracts, integrations and support arrangements competing for attention. Teams could see more clearly which systems mattered. Applications no longer continued without a clear home for decisions about their cost, value and risk.
Cost reduction and operational improvement had moved together. That is different from reducing a budget and leaving the organisation more fragile than before.
The distinction is important because indiscriminate cost cutting can produce an impressive number quickly. The damage appears later, often in slower work, tired teams, missed controls or expensive repairs to capabilities that should not have been removed.
Stewardship requires more patience. It asks us to protect what genuinely matters while refusing to fund what continues only through inertia.
Making the decision visible again
Once ownership was clear, the decisions became visible again. Some people understandably argued for systems they valued. Some retirement conversations created friction because teams were being asked to let go of something familiar before the benefits were fully visible.
A leader doing this work will not be universally popular. That is still preferable to leaving the decision ownerless.
I can live with that. What I find harder to accept is allowing resources entrusted to my care to be consumed year after year because questioning an established expense would create discomfort.
The money was not mine. That was precisely why it deserved care.
Leaders are often encouraged to think like owners. There is value in that idea, but stewardship carries a slightly different responsibility. An owner may choose what to do with something that belongs to them. A steward is answerable for how they treat something that belongs to someone else.
That includes money, systems, time and the attention of the people asked to maintain them.
Application rationalisation can look like a technical or financial exercise. Much of the real work is organisational. It is the work of putting responsibility back around systems that have outlived the structure that brought them in.
In that post-acquisition environment, ownership came before rationalisation. Once responsibility was visible, decisions that had drifted between teams could finally be made and carried through.