How to accurately measure the savings and IT Value of an IT Asset Management program is among the most common challenges reported by ITAM professionals. Implicitly, anyone who has seen a mature organization that has control of its assets and knows how to optimize them gets favourable return on their efforts and investments. However, this does not allow for a strategic and systematic approach to measuring it. Although there is no “one size fits all” solution, the below framework should allow for IT departments to not only start recording savings, but also to augment or defend the existence of IT Asset Management programs.

The Definitions

Here is perhaps the hardest part of attributing benefits and savings to an ITAM program because one needs to have unilateral agreement from not only the IT department but also from Finance and in some circumstances the supply chain department. Collaboration and coordination when dollars are being assigned for savings are a notorious “hornets’ nest” politically; however, below are some methods that will help you overcome these challenges.

Hard Dollar Savings (Mind your Ps and Qs)

These are benefits that can be traced on the general ledger and contribute to the operating costs of the organization. These are difficult to record, monitor and trace because many organizations don’t have the purchase data integrity, accuracy, or robustness needed to perform this function. Regardless of the current state, if efficient and effective use of IT dollars are an important component of IT Value, then diligence and process maturity are advised.
Asset costs (in a non-capital situation) have two component parts:

  1. price of the asset and
  2. quantity of the asset.

In order to determine the savings, one need not look further than these two elements, but instead of looking at it on a transactional basis, one needs to look at it on a period basis.


Example 1:

In FY15 the organization sources 1000 laptop computer @ an average cost of $1000/laptop. Making the total spend $1m on Laptops in FY15.

Example 1a:

In FY16 the organization sources 1000 laptop computer @ an average cost of 900$/laptop. Making the total spend $900k on Laptops in FY16. Thus the hard dollars savings in FY16 in this situation are $100k and would be attributed to the price category.

Example 1b:

In FY16 the organization sources 750 laptop computer @ an average cost of 1000$/laptop. Making the total spend $750k on Laptops in FY16. Thus the hard dollars savings in FY16 in this situation are $250k and would be attributed to the quantity category.

Example 1c:

In FY16 the organization sources 750 laptop computer @ an average cost of 900$/laptop. Making the total spend $675 on Laptops in FY16. Thus the hard dollars savings in FY16 in this situation are a total of $325k but 75k would be attributed to price and 250k would be attributed to quantity.
Organizations looking to accurately measure, monitor, and attribute hard dollar savings will need to have a common acquisition vehicle, a standard data requirement for purchase order, and a method of linking historical POs to current POs (usually accomplished by a unique identifier on the PO). Unfortunately, I’ve yet to see an IT organization that has this level of diligence and maturity for IT purchase to initially track this type of savings. Fortunately, it’s not terribly difficult to get to a point where measuring hard dollar saving is possible; however, one should realize that you require a minimum of 13 months of accurate information. This type of endeavour is NOT a sprint, but rather a marathon – an attitude that needs to be adopted when broaching the ROI discussion with the C-level leaders.


Defining “Risk” is a subjective endeavour in any context as it is an issue that has yet to occur, meaning the costs associated with it are estimates and should be treated as such. When measuring risk for IT software compliance issues, we can generally follow the following equation.


This equation can be used in two ways:

  1. the baselining of potential benefits, and
  2. an estimation of the fines that will be issued when found in breach.

If you’ve ever endured an audit you’ll know that when you are found in breach of a software agreement everything is up for negotiation and so the fines may vary. My experience has taught me to use this equation as a baseline and be thankful when you come out on top.

Cost Avoidance

Cost avoidance is nebulous but in certain circumstance a large benefit of an IT Asset Management program. Cost avoidance, is exactly as the term suggests, a cost that is avoided from the implementation of the ITAM program. These need to be measured programmatically and there are only a few instances in which I would suggest application:

  1. Harvest / Re-Deployment of Software
  2. Re-use of Hardware
  3. Decomissioning assets before their maintenance period elapses


ITAM process wherein a software title, if not used for a set period, is harvested or reclaimed by IT to be used by someone that has an immediate requirement. The next request for the title is then re-deployed to the requester.
Potential vs. Realized Cost Avoidance
The potential cost avoidance is the number of Harvests completed, whereas the realized cost avoidance is the re-deployment of the software title. It is inappropriate to claim savings on harvest because it is perhaps not needed at all by the organization and would be a good candidate to be purged or sold on the secondary market (depending on your jurisdiction).


Typically, in a mature organization, IMAC charges do not apply as these harvests and re-deployments are done systematically through a technology, such as a service portal. Unless you have such a solution, I do not suggest tackling this, as without a tool to install/uninstall software this will have a high overhead on the technical staff.

Re-use of Hardware in Asset Management

This is basically the same as “harvest/re-deploy” with one substantial difference. Unlike software where it is a grant to use the product, having legacy or old hardware makes it easy to accrue technical debt, rendering your asset management lifecycle a necessary business decision. My suggestion is to avoid pushing any end-user computing device past three years. Even in the datacenter, I’ve seen some organizations maintain a strict 4-year lifespan for their servers, network gear, and storage because they lease them. Regardless, when evaluating ROI, one should disregard all assets that fall outside of the normal lifecycle of its asset class.
Similar to IT software, there is a potential ROI component and a realized ROI component.



Decomissioning assets before their maintenance period elapses

In this scenario you would be removing these assets from the environment before a forced maintenance payment is required in order to avoid a specific maintenance payment. This particular scenario is difficult to describe because there are a multitude of variables in operation; however, my suggestion is that if you are decommissioning an asset to avoid maintenance and/or support, one must take into account the replacement system/software. For example, if you are decommissioning Oracle EBS R11 in favour of SAP, then you need to compare operating costs under normalization in both instances. This is where the scenario becomes terribly complicated and won’t be explained in this specific blog post.

Using ROI in an IT Asset Management Program

As we saw above, the definition and scenarios for ROI in an ITAM program can be complex to implement but fairly simple to understand.

  1. DO use an agile or iterative approach. Start small, fast, and easy. Then mature the measures to include the more complicated calculations that don’t have structured data (yet). This can be more than 12 months; but if you plan effectively you’ll know how to schedule your activities on the program to reflect the measurements.
  2. DO NOT attempt measurements without technology to help automate and record the savings. A spreadsheet may be adequate in the short-term, but unless you automate and integrate the calculations from the sources, you will fail. This can be as simple as having SQL scripts to extract data and then using Excel to aggregate and link distinct datasets.
  3. DO NOT bloat ROI potential. Be ethical and accurate with your ROI measures. Ie. don’t “pump” the numbers to gain political favour. I’ve seen this before and it turns out badly because you tend to over-promise and under-deliver.
  4. DO use the measures and ROI as a compass to guide you rather than a plan to strictly follow the money. As you implement and mature your ITAM program there will be cycles of high yield ROI and cycles of low yield ROI.
  5. DO present these on a regular basis. This may be monthly or quarterly, but keeping these as top-of-mind for senior leadership is really helpful in obtaining and sustaining support for your ITAM program.

Lastly, as a jump start if you want an ITAM software ROI template send us an email. We will freely distribute the version we use.