Why Software Asset Management Programs Fail
“All happy families are alike; each unhappy family is unhappy in its own unique way."
The Anna Karenina Principle, as it has become known from the first line of Leo Tolstoy’s seminal 19th-century novel, is as applicable to software asset management programs today as it is to families. Adapted from Aristotle’s Nicomachean Ethics written 23 centuries earlier, this principle holds that successful endeavors succeed because they lack deficiencies in key areas. In Aristotelian terms,
“It is possible to fail in many ways…while to succeed is possible only in one way…to miss the mark easy, to hit it difficult…For [ITAM programs] are good in but one way, but bad in many.”
So, what are the key areas in which software asset management programs must not be deficient in order to be successful? Or rather, what are the primary reasons why software asset management programs fail? In working with hundreds of organizations big & small, public & private, across the gamut of industries and the globe for over a decade, I have found that in ALL CASES, ITAM programs that fail are deficient in at least 1 of the following ways:
1) Software Asset Management Programs Fail Because of Inadequate Governance
Let me say this in no uncertain terms: the ITAM program director that neglects the hard work of gaining and maintaining necessary support from leadership will ultimately fail. Period. The term “governance” can come to take on very different meanings within various organizations, so let’s define it here relative to ITAM.
ITAM program governance is all of the sponsorship and informed decision-making, action, & accountability from executive stakeholders necessary for a chartered ITAM program to accomplish its stated and approved objectives.
When ITAM programs undertake a grassroots-only effort without such governance, inevitable roadblocks surface that inhibit progress and require proper escalation to and action from program sponsors.
Consider the amount of coordination and cooperation that is necessary to remediate server infrastructure, drive accountability to application owners, enforce policy compliance, re-engineer processes, address process leakage, etc. Without the right support from the right level of leadership, the ITAM program’s ability to affect change and accomplish tangible results is greatly diminished. This lack of governance shortens the ITAM program’s effective life. Similarly, leaders that fail to play an active role in governing the ITAM program they sponsor will never have the consistent, productive results they seek. We can sum up this failure like this:
ITAM programs can only affect lasting, positive change to the degree those changes are effectively sponsored by informed leaders.
In trying to help organizations put the necessary structure, communication, and habits in place that enable good ITAM program governance, I’ve been told a lot of things from naysayers—"we don’t do that here”, or “governance is a dirty word at our company”, or “we don’t need this right now, we just need to get going with a tool”…and on, and on. Thankfully, after some reasoned discussion, most practitioners come to see early on, the necessity of good governance to their long-term success. However, acknowledging the need for good governance is very different from actually accomplishing and operating within good governance. The latter takes real and consistent effort from a competent program director that can effectively communicate and “manage up” with their executive leadership.
Establishing effective program governance can be significantly complicated when dealing with executive sponsors that lack the ability or motivation to govern well, which are usually symptoms of broader systemic issues with organizational dysfunction. Whatever the reason, most ITAM programs struggle in this area of governance at one point or another, which, if misgoverned long enough, will eventually result in a program becoming severely under-funded, and dying a slow and painful death.
2) Software Asset Management Programs Fail Because of Unclear or Unrealistic Goals and Objectives
A particularly painful software compliance audit is commonly what gives impetus to forming an ITAM program. It’s an all-too-familiar scenario: an executive who was made to feel much of that pain (i.e., the audit settlement came out of their budget), throws up their hands in frustration that they don’t have the data they need, taps a capable manager, and gives them budget and a directive to put a tool in place by a certain date, and a charge to prove that the tool is saving them money.
This scenario, however, is problematic as it typically misaligns the program right from the start. For example, the problem of managing IT assets is framed by leadership as a data issue, with the “solution” being thought of as simply implementing a tool. What’s more, the knee-jerk reaction to the painful audit, combined with the chronic myopia of budget cycles, often puts the tool implementation project on an overly-aggressive timeline. And to make matters worse, our unsuspecting manager, as capable they may be, typically lacks knowledge and experience with the intricacies of software licensing and has little idea of just how unrealistic the task is that they’ve been handed.
I’ve probably seen it a hundred different times. Without time or budget to properly gather and rationalize requirements, the program rushes blindly down a tooling RFP spiral with the manager’s head buried in sandy denial, insisting to their executive they are making good progress towards an unrealistic goal. Fast forward 2-3 years, however, and the manager is burnt out, having spent their reputation (and millions of dollars) on a tool that produces data many stakeholders find unreliable, with the auditors finding essentially the same compliance issues, despite the rash of costly activity.
3) Software Asset Management Programs Fail Because of Overdependence on a Tool
Closely related to unclear and unrealistic goals and objectives is the tendency to look to an ITAM tool as a panacea. You see this manifested in the absurd naiveté of some “must-have” requirements in tooling RFPs, such as (these are actual written requirements I have encountered): “System must be able to auto-discover cloud computing environments”, “The ITAM tool must automatically reconcile licenses according to specific contracts”, and “The solution must perform continuous license reconciliation in real-time”. Sure, we all want a solution that will automagically find rogue Azure tenants, read our contracts, and (my personal favorite) reconcile all data in real time. We also all want no-calorie ice cream, limitless energy from cold fusion, and to be the only one that can bend the space-time continuum with a Time-Turner. However, ITAM managers (and their executive sponsors) must responsibly ground their expectations in reality. The ITAM manager that doesn’t understand what a given tool really does and really does not do, must educate themself by consulting with someone that does. Indeed, a fool with a tool is still a fool. And there’s simply no need to be a fool.
An ITAM tool alone can never fix all your process and people problems. Even as difficult as implementing an ITAM tool can be, the organizational change management required to implement policies, re-engineer processes, and win individual hearts and minds to change culturally-engrained habits and modes of thinking, is often much more difficult to accomplish. But this difficulty in no way negates its necessity. And putting it off until you have a fully functioning tool that meets all the well-meaning, but unfounded “requirements”, places the ITAM program on an unstable foundation that will eventually give way if not addressed appropriately.
As with a family, for an ITAM program to have sustained success, you have to get the fundamentals right. The ITAM program must not be deficient in the core areas of governance (as defined herein), the proper calibration of goals and objectives, and having realistic expectations about the jobs that ITAM tools are expected to perform. Take the time to reflect on your ITAM program through these lenses, identify any corrective action that you should take, and then go and do it. Your program, and you as an informed and conscientious practitioner, will be better for it.
Kris Johnson is Anglepoint’s resident expert on all things ITAM. As a reformed software license compliance auditor, Kris’s passion for the last 10+ years has been helping organizations put the people, processes, and technologies in place to prevent the problems that auditors typically find, while driving cost optimization and operational efficiency within successful ITAM programs.
