Cutting Software Spend: a checklist

No real rocket science, but if you’ve been put in a position to try to make savings on your software spend, this is the sort of checklist i’d run down. It is straight off the top of my head, so if there are nuggets you know that i’ve missed, please throw a comment at the end, and i’ll improve it. The list applies whether you are looking at a single organisations spend, or are trying to reconcile the combined assets from any company merger or acquisition.

General rules:

1. Don’t buy new when you have redundant assets already
2. Be mindful that committing to buy in volume is lower unit cost than buying individually
3. Beware of committing to spend over several years where the vendor prices any agreement assuming straight line deployment toward your total user base at the end of the term. Assume most of the deployment will happen much faster – and that your projected spend will front-load with large true-up costs at annual contract anniversaries.
4. Don’t pay extra for software updates where no updates are planned in the license term
5. Don’t pay for software you’re not using!

So, the checklist:

1. If there is a recommended software list to be deployed for a new employee, be sure to engage HR with a weekly list of leavers, and ensure their license assets are returned to a central pool. Licenses in that central pool should be reallocated out of that pool before electing to go forward with any new purchase. I’ve seen one company save 23% of their total desktop software spend just by implementing this one process.
2. Draw up a master list of all boxed software (termed “Fully Packaged Product” or “FPP”) that appears to have been historically purchased by the organisation. The associated licenses are normally invisible to the software vendor from a purchase history point of view. Two main uses: (a) it forms a list of what should or could be purchased at more favourable terms in the future using an appropriate volume licensing agreement and (b) it’s a useful defence if your CFO receives a spurious “demand for unpaid licenses” from a vendor. I’ve seen one case of a subsequent reconciliation of previous purchases result in an unsolicited ￡6m invoice being settled for ￡1.8m instead.
3. Likewise, compile a list of the various software licenses purchased, per vendor. This is often complicated because a single vendors products can be purchased from multiple sources, and there are several licensing programs in every vendor. You will often find purchases made for a specific project, where an organisation wide reconciliation can take overall licensing and support prices down – but only if centralising the negotiation supports each projects goals. I have seen one such reconciliation of a vendors licenses in one large multinational company run to 80 pages (and a huge discount to bring in an end-of-financial year renewal), though most result in a 1-2 page reconciliation. You then have the data to explore available change options with a vendor or reseller of your choice.
4. Ensure that the support levels purchased are appropriate for the use of the products. There is no point paying “Software Assurance” for the remainder of a 3 year term if no new version is scheduled to be released in that timeframe (most effective resellers will have visibility of these release pipelines if you can’t get them directly from the vendor). Likewise, you probably don’t need 24/7/365 support on an asset that is used casually.
5. Finally, don’t buy support on products that you’re no longer using. While this sounds like a flash of the obvious, knowing what is and isn’t being used is often a lengthy consolidation exercise. There are a variety of companies that sell software that can reconcile server based software use, and likewise others (like Camwood) that do an excellent job in reconciling what is present, and used/unused, across a population of Windows PCs. Doing this step is usually a major undertaking and will involve some consultancy spend.

If the level of your buying activity is large enough to be likely to attract the attention of a vendor or reseller salesperson visiting you in person, a few extra considerations:

1. Be conscious of their business model; it is different for PC software vendors, Enterprise Software Vendors and Vendors predominantly selling “Software as a Service” or Open Source Software based subscriptions. Likewise for the channels of distribution they employ between themselves and your organisation – including the elements of the sales processes a reseller is financially incented to follow. Probably the subject for another day, but let me know if that’s of any interest.
2. Know a resellers and vendors fiscal quarter year, and particularly their end of financial year, date boundaries. The extent to which prices will flex in your favour will blossom at no other time like these. The quid pro quo is that you need to return the favour to commit your approved order to be placed before their order cut off schedule.
3. Beware getting locked into products with data formats exclusive to or controlled by one supplier; an escape route with your data assets (and associated processes) intact ensures you don’t get held to future ransom
4. Consider “Software as a Service” subscriptions wherever possible, aka pay in line with the user population or data sizes actually employed, and flex with any changes up or down. You normally absolve your IT dept from having to update software releases and doing backups for you in the price, and you should get scale advantages to keep that price low. That said, (3) still applies – being able to retrieve your data assets is key to keep pricing honest.
5. Always be conscious of substitutable products. Nothing oils the wheels of a larger than expected discount from a vendor than that of the presence of a hated competitor. If it’s Microsoft, that’s Google!
6. Benchmark. If you’re trading with a reseller with many customers, they have an unparalleled view of previous deals of similar dimensions to your own – including past discounts offered, special deal allowances and all the components needed to lower a price. At the very least, an assurance that you’re “getting a good deal”. I have seen one example of a project deferred when it became apparent that the vendor was giving a hitherto good customer a comparatively poor deal that time around.
7. For multinational companies, explore the cost differences in different territories you buy through and use the software in. I did one exercise for a well known bank that resulted in a 30% drop in their unit costs with one specific vendor – two years running.

So, what nuggets have I missed? Comments most welcome.