Scope and Software Asset Management

So you’ve bitten the bullet and decided to make the pitch to senior management as to why a Software Asset Management Programme will benefit not only IT, but the business as a whole.  Having accepted your argument, the board have given you the authority to divert valuable resource towards this latest initiative.

Your next task is to decide upon the scope of your assignment….

As previously mentioned, if you are being reactive regarding Software Asset Management it could well be that the call of a vendor audit determines the reach of install evidence and proof of licence you are expected to marry up to provide an effective licence position (ELP).  However, if you are not at the mercy of an impending vendor investigation, you have the luxury of determining the goals and objectives of the Software Asset Management programme.  First and foremost, you should honour the pledged business improvements you lauded in the Senior Management presentation; nothing would disappoint more if you went off on a track of your own making.  If Information Security is a driver for your Software Asset Management programme, then perhaps the software titles that provide ingress and egress to your company should be top of your list.  If service desk management is most important to you, then those titles which appear to need the most support should become a priority.  It may also be the case that a particular geography (i.e. office location) or cost centre needs targeting, so your scope all of a sudden becomes physical.  Mergers and acquisitions are also drivers in respect of kick-starting a Software Asset Management programme.  At the end of the day, software is an intangible asset, but one that still needs evaluating – whether you are buying a new company, or selling one on.  Typically though, a specific software vendor will be the focus of attention for most Software Asset Management Programmes that are instigated.

So now that you have an approximate fix on the target for the Software Asset Management Programme, it’s time to decide what your goals around the scope are actually going to be.  For this, SAM Charter can offer you a SAM Maturity Assessment.  Equally, a good old-fashioned risk assessment could influence the specifics of what you want your Software Asset Management Programme to achieve, but whatever analysis you decide to engage with ensure that your goals are documented and agreed to by all concerned parties.  The reason for this, is that as the Software Asset Management Programme progresses, you might begin to see business improvements take place, or even savings being made – or perhaps the visibility of the work being done comes to the attention of someone not previously engaged with; and then the requests start to come in to consider other vendors, or other elements of the business, or other processes that were scoped out at the time of the business analysis.  As the head of the Software Asset Management Programme, you need to be able to gracefully decline such requests to stay focussed on your original goals, or if you do then take on extra responsibilities be prepared to request extra resources/time to complete these revised goals.

Whatever goals are decided upon, they should be qualified using the SMART acronym from operations management:

 

  • Specific:  Be absolutely clear on what the goal is
  • Measurable: Wherever possible, ensure your goal has a very clear means by which is can be assessed as successful or not
  • Attributable:  The work required to achieve the goal, should be assigned to someone specific
  • Realistic:  The achievement of the goal should be within the professional and resource-based reach of the person/team assigned with achieving the goal
  • Time-based:  Projects can have the knack of running on indefinitely, if a goal is provided with a time-based constraint then it can act to focus efforts accordingly

 

Scoping your Software Asset Management Programme (and sticking to that scope) is one of the biggest challenges you will face, but clear communication with all concerned parties (off the back of structured communications plan) should help alleviate “out of bounds” requests for tasks or challenges beyond the scope of the Software Asset Management Programme.

A further point about scope:  When crafting your processes, make sure the processes themselves are adequately resourced to be able to match the SAM scope.  For example:  If IBM is part of your vendor scope, and you have virtualized IBM installs, do you have ILMT installed and configured to effectively report in sub-capacity licensing?  (sub-capacity is IBM’s term for virtualization).  There’s no point in crafting a process that talks of importing all inventory data if the mistaken assumption is in place that standard inventory agents will accurately report on IBM virtualization.

Would you assign a function step to a person in a department that doesn’t exist?   Or assign a task to someone that doesn’t have the skill-set to successfully complete that task?

Need more help with managing your scope?  Download our free Starter file from our whitepapers page.  Within that, you will find a template RACI chart based on our SAM Charter Process Kit.  Take it, and make it your own.  Refine the job roles and the steps within the SAM & HAM processes you choose to implement.  A further point about the RACI Chart:  We have also added (a customized) value of “U” to represent the Applications/ Systems Used in the execution of those processes.  That way, if a system is replaced then you have an at-a-glance guide as to where and how people will need to be re-trained to maintain an appropriate level of job performance.

2 thoughts on “Scope and Software Asset Management”

  1. Pingback: 10 things you should know about Software Asset Management | SAM Charter

  2. Pingback: Roles and Responsibilities – Software Asset Management | SAM Charter

Leave a Comment

Your email address will not be published. Required fields are marked *