Your MSP Should Help You Eliminate Software, Not Sell You More

Tuesday morning, 9:17. The controller has a credit-card statement open on one monitor and the company password manager open on the other. She has found three project-management subscriptions, two electronic-signature products, and a reporting platform whose owner left eleven months ago. The monthly total is $18,640. Nobody in the room can explain what all of it does.

This is usually when someone asks IT for a software inventory. The export arrives, every product has a technical owner, and the original question remains unanswered: which of these bills still earns its place in the business?

I have sat through this conversation from both sides of the provider table. The awkward part is rarely finding the subscriptions. It is admitting that the technology company kept adding tools and never made removal part of the job.

In the book I tell the story of Don, the man who kept my 1988 air conditioner alive for years. Every July it died, every July he saved it, and every July I paid him for the rescue. I bragged about it at family gatherings. Then I stood on a friend's cold patio one summer and did the math.

"I stood there doing math in my head. Year one: $850. Year two: $1,050. Year three: $750. Year four: $920. Year five: $1,100. Plus higher power bills. Plus the stress. Plus my wife's frustration. I could have bought TWO new air conditioners. The realization hit me like a sledgehammer: I wasn't Don's customer. I was his annuity."

Software portfolios work the same way. Every renewal that gets rescued instead of questioned is a Don invoice. A technology partner's first job is the question nobody selling you anything will ask: which of these should not exist at all?

From The 3AM Test by Steve Copeland.

The incentive problem nobody discusses

Many managed service providers make money by reselling licenses. There is nothing inherently wrong with resale. The problem begins when the easiest recommendation is always another product and nobody is accountable for the total environment.

A useful technology partner should be able to recommend that you buy something. It should also be willing to recommend that you cancel something, consolidate two systems, change a process, or leave a working tool alone.

If the provider cannot make money unless your software count goes up, leadership should understand that incentive before treating every recommendation as neutral advice.

Software sprawl is an operating problem

The obvious cost is license waste. The larger costs are usually elsewhere.

Every additional platform creates another identity boundary, another vendor relationship, another place for sensitive data to live, another integration that can fail, another renewal date, and another workflow employees have to remember. When two systems hold the same record, somebody eventually has to decide which one is true.

That is why software rationalization cannot be an annual exercise where finance exports the credit-card statement and asks whether anyone recognizes each vendor. It has to connect cost, usage, workflow, data, risk, and ownership.

What we look for in the real world

We start with five questions.

1. What business capability is this tool supposed to provide?
2. Who owns the result after the license is purchased?
3. How many people used it meaningfully in the last 90 days?
4. What other systems provide overlapping capability?
5. What breaks if the tool disappears tomorrow?

The answers sort software into four practical groups: essential and healthy, essential but poorly implemented, redundant, and orphaned.

The second group matters. Companies often replace a good platform because it was never configured, governed, trained, or integrated properly. A new platform feels easier than fixing ownership. Six months later, the replacement has the same problem.

The decision is not always cancellation

Eliminating software sometimes means removing a product. It can also mean eliminating duplicated work.

A platform may stay while an unnecessary spreadsheet disappears. Two tools may stay but an integration removes double entry. A specialized product may replace three general tools. A process may be simplified enough that no automation is needed.

The point is not to chase the smallest possible application count. It is to create the smallest understandable system that supports the work, protects the data, and can be operated by the people you actually have.

What leadership should demand

Your quarterly technology review should include a software portfolio view: total spend, meaningful usage, business owner, renewal date, critical integrations, data classification, and the recommendation to keep, improve, consolidate, replace, or retire.

Then require the provider to show both sides of the ledger. What are we proposing to add? What are we proposing to remove? What work disappears? What risk changes? Who owns adoption?

Technology partners earn trust by improving the system, not by increasing the stack.

A worked example from the monthly bill

Consider a 75-person professional-services firm. Its software register shows 63 paid products. The annualized bill is $428,000 before Microsoft licensing and the line-of-business platform. That number looks high, but cost alone tells us very little.

The first pass finds 18 products with fewer than five active users. Seven are legitimate specialist tools. Four support a seasonal process and should keep their licenses. Three belong to former employees and can go immediately. The remaining four overlap with capabilities already included in Microsoft 365.

That pass removes $21,600 a year. Helpful, though hardly transformative.

The larger gain appears in the workflow map. Sales data is entered in the CRM, copied into a proposal tool, copied again into a project system, and retyped into invoicing. Each handoff adds delay and creates a different version of the customer's name, scope, and start date. The company pays for every product and also pays employees to reconcile them.

One integration and a small process change remove about 26 hours of monthly rework. At a loaded labor cost of $52 an hour, that is another $16,224 of annual capacity. More important, projects begin with the same approved scope that sales promised. The value came from seeing the portfolio as an operating system instead of a list of bills.

The numbers in your business will differ. The method should still separate license savings from labor, error, delay, security, and customer impact. Otherwise a small cancellation total can hide a very good rationalization decision.

The field mistake: replacing before repairing

One of the most expensive patterns I have seen starts with a true complaint: employees hate the current platform. Leadership hears that complaint and assumes the product is wrong.

Then we look closer. The implementation copied an old paper process. Required fields have no shared definition. Training ended at launch. Reports were never configured. The integration account failed months ago, so an employee exports and imports data by hand. The product might be a poor fit, but the company has never operated it well enough to know.

Replacing it first creates a clean interface for the same broken ownership. The new vendor runs discovery against the old configuration, migrates inconsistent data, and celebrates go-live. Six months later, the workarounds return.

Before approving a replacement, spend two weeks on the repair test. Fix one high-friction workflow, assign a real business owner, clean a small data set, and train the people who perform the work. If the platform still blocks the outcome, the company now has evidence for replacement and better requirements for the next product. If the workflow improves, you may avoid a migration.

That is a much better use of an advisor than collecting three quotes for the product category named in the complaint.

What the provider should bring to the review

A useful portfolio review begins before the meeting. The provider should combine billing, identity, usage, device, contract, integration, and owner evidence. No single source catches the whole estate.

Bring the register in a form leadership can read. Each line should answer plain questions: what work depends on this, who owns the decision, what does it cost, what data does it hold, when does it renew, and what would happen if it vanished? Technical details belong behind that view, available when they change the decision.

Then show the recommendations in pairs. If the plan adds an endpoint tool, show which older control it replaces. If the plan keeps two project systems, explain the distinct workflows that justify both. If the plan proposes an integration, name the manual work and error it removes. If the plan leaves a product alone, say why.

I would rather see six defensible decisions than a spreadsheet of sixty products marked green. Green is a status. A decision needs an owner and a date.

A practical 30-day rationalization sprint

During the first week, build the evidence register and flag renewals inside 120 days. Do not wait for a perfect inventory. Start with the products tied to the most money, sensitive data, or operational dependency.

During week two, interview the people who perform the work. Ask them to show a real transaction from beginning to end. The screen recording often reveals more than the feature list. Note duplicate entry, exports, personal accounts, approvals outside the system, and reports rebuilt in spreadsheets.

During week three, run decision sessions by capability. Keep, improve, consolidate, renegotiate, replace, or retire. Capture dissent. The employee defending a strange-looking tool may understand a customer requirement the inventory missed.

During week four, execute the safe removals and plan the harder changes. Export data before cancellation. Remove OAuth grants and service accounts. Update procedures. Confirm that finance stops payment. Set a date to verify the expected savings and operating result.

The sprint should finish with fewer unknowns, not merely fewer logos.

The question I use with owners

When a software discussion gets stuck, I ask: if we were starting the company today, knowing what we know now, would we buy this product and design the work this way?

Sometimes the answer is yes. The tool is odd because the business is unusual, and the unusual process makes money. Keep it and document why.

Sometimes the answer is no, yet leaving today would cost more than another year. Record that decision too. Use the year to clean the data, remove dependencies, and negotiate from a position of preparation.

And sometimes everyone laughs because the answer is so obvious. That is your retirement candidate.

Software should earn its place through the work it supports. Your technology partner should be willing to prove that, even when the result is a smaller invoice.

Questions for the next provider meeting

Ask for the total recurring technology spend in one view, including products billed through the provider, contracts paid directly, departmental cards, and major free services connected to company data. The answer may begin as a range. The important part is whether somebody can build and maintain it.

Ask which products have no business owner. A technical administrator can manage access without owning the business result. Someone in the company needs authority to decide whether the product stays, changes, or leaves.

Ask which renewals occur in the next six months and when notice is due. This turns a vague cleanup goal into a decision calendar.

Ask what the provider recommends removing this quarter. "Nothing" can be a valid answer in a disciplined environment. In a company with years of unchecked purchases, it deserves evidence.

Ask where employees copy the same information between systems. That question finds operating cost a license report will miss.

Ask what data cannot leave each platform today. A product with no usable export may have a larger exit cost than its annual fee suggests.

Do not punish local initiative

Some of the strangest tools exist because an employee solved a real problem while the official process stalled. Removing the tool without understanding the result can send the work back to email and spreadsheets.

Thank the person who built the workaround. Learn what it fixed. Then decide whether to formalize it, move it, replace it, or retire the underlying need.

This matters for trust. If every inventory becomes a hunt for rule breakers, people hide the next useful experiment. A healthy technology function gives employees a quick path to raise an idea and get a credible decision.

What good looks like twelve months later

The company has one live register shared by finance, technology, and department owners. New products enter through a proportionate review. High-risk connections receive identity and data checks. Renewal decisions begin early. Departing employees trigger ownership changes. Quarterly reviews show additions beside removals.

The software count may rise during growth. That is fine when each addition has a purpose, owner, measure, and exit path. Discipline is different from minimalism.

The outcome I care about is that leadership can explain the environment without twelve browser tabs, employees spend less time reconciling systems, and the provider has no reason to protect clutter.