One of the founding principles that often gets overlooked in software asset management is securing senior management buy-in.
The benefits of a decent SAM programme are obvious, and if acted on promptly can deliver tangible savings and improved security with relative ease.
But perhaps referring to software as an asset may be devaluing what we do as software asset managers? Given our job involves tracking the use of software on user's computers, if we were to find an application surplus to requirements, the sheer effort needed to get it removed is tantamount to a quest to Morodor in Lord of the Rings.
And so the grounds for the battle are set; on the one hand we have IT seeking to enforce common sense, proactive IT management and a sense of economic due diligence. On the other hand, we have business culture, cost centres and a "way of doing things" that has crept through the organisation like creeper vines on steroids.
As a consultant where the change we make will hopefully be an improvement, it’s quite surprising to hear how many times staff say “we do things differently to most companies”. If I were to map how companies “did things” in respect of SAM, the majority would opt for the same path of least resistance.
We have business culture, cost centres and a "way of doing things" that has crept through the organisation like creeper vines on steroids.
The cause, however, is not altogether lost. In seeking change that a new SAM programme might advocate, we can borrow a well-trusted practice technique from operations management: The Five Whys?
If, as a SAM project manager you are presented with an objection to change, then simply ask: Why? Often the resistance to change can be “that’s the way we’ve always done (or not done) SAM” – which in the cold light of day is about trying to maintain the status quo, rather than a bona fide reason to object to change.
Clearly, not every objection is going to batted away with such ease, and so a SAM project manager may have to dig a little deeper with the four remaining "whys". Experience lends us to believe that if you go beyond this number of whys, then perhaps the wrong question is being asked as the root cause of behaviour has not been identified.
A top tip here: be prepared to personalise the “why”? question - Don’t get in the habit of just asking “Why?” in a mono-syllabic fashion: eg "Why do you buy software on your company credit card when centralised purchasing would be the preferred method?"
Root cause analysis is vital to the success of cutting through culture and politics in a company.
My final piece of advice is to bring staff along with you. Do not present a fait accompli – try and win people over as you go; involve them in the analysis and modelling element of any proposed solution. It’s not enough to state that change is coming; if you can define the "Why" of the change (déjà vu kicking in yet?) then it makes implementation that little bit easier to achieve.