“All happy families are alike; each unhappy family is unhappy in its own 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 ITAM 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 ITAM programs must not be deficient in order to be successful? Or rather, what are the primary reasons why ITAM 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)     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)     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.