CHAPTER 3: THE KICK-START TO YOUR SAM PROGRAMME

For those of you unfamiliar with the concept of Mind Maps,^® the idea behind them is that you use them as a thought-provoking tool. The above proposal came about as a result of a question on LinkedIn (www.linkedin.com) from within the ITAM Review Networking Group (which is hosted by the excellent Martin Thompson – www.itassetmanagement.net). Martin started a discussion around the methods that programme managers were using to keep track of their SAM programmes. On one such project I recently worked, the programme manager used a Mind Map to keep abreast of developments. Someone then asked if such a Mind Map existed for a SAM project. Whilst the former Mind Maps I had seen were very company specific (and perhaps not ideal to act as a generic starting point), I still saw this as a challenge! So, I set about creating one, and with some creative (and constructive) input from Filipa Preston of Software Optimisation Services (www.sossuccess.com), the Mind Map on the cover of this book was created.

Please be aware that the diagram is exactly what it suggests – a playground for further ideas. It might well be worth using it as the centrepiece of an A2 piece of paper, and further branching out ideas and notes, so it suits your unique requirements. What follows is my thinking behind the inclusion of the varying elements in the diagram, perhaps considered outside the scope of ISO19770-1. One astute observation by a peer and friend, was that software asset management could, and should, form part of a wider ITAM (IT Asset Management) strategy; SAM is all about coping with the flux and change that life in IT offers, and moving hardware (as well as moving personnel), should be a requirement factored into any programme of IT management (thank you, Tim Dobson).

A quick note, too, on the composition and design of Mind Maps – the basic rule is, that there are no rules! You can include any type of picture, text, scribble, etc. What is important, is that it guides your mind in the right direction – the formality of the diagram illustrated should be viewed as representative. Equally though, please bear in mind that the context and interpretation of a drawing changes from one person to the next: if you use a drawing of a fish to suggest something is ‘fishy’ (i.e. doesn’t smell right), then make sure that other people clearly understand what you mean!

Scope

Establishing a scope is vital for the success of any SAM programme. As previously mentioned, a software vendor could have instigated an audit of your IT systems, and so your scope is determined pretty much by how much of their software you have installed, and just how many people have access to it. However, for those lucky enough to be forward-thinking in starting a SAM programme ahead of any such audits, then this provides you with the luxury of deciding what software you wish to tackle and in what order. It might be that you have a rogue department you wish to scrutinise and so tackling the development department (as an example) sets your boundary for you. Equally, your scope could be shaped by geography, and all your New York offices might need software control mechanisms putting in place prior to a sell-off.

Whatever boundary is established, ensure that your programme sticks to it, and can generate reliable and frequent SAM data prior to embarking on widening the scope.

Roles and responsibilities

This element of a SAM programme should assess what tasks are completed by whom, in both project state and BAU (Business As Usual). My recommendation, in this instance, would be to create a RACI chart (Responsible, Accountable, Consulted and Informed). Variations around this acronym exist, and you may wish to conduct some research to ensure that all processes and function steps receive the due weight of attention they deserve. To create your RACI chart, start listing ALL the activities that comprise your SAM programme in a list down the page (Y-axis), and then start listing ALL stakeholders across the X-axis. Next, go through each and every line item and decide the level to which stakeholders are involved for each task, by giving them a value of R, A, C or I. It is conceivable that a stakeholder could end up with more than one RACI value (and that’s fine too), however, ALL line items should at least be represented once by each of the RACI values, otherwise you might begin to question its contribution to the overall programme.

Data sources

Consider the mix of information that might be required to present an accurate software asset management picture that could be presentable to the board, and sufficiently workable as to add value to IT and business operations in your company …

Well, firstly, to assess what software is installed, you will require a means by which to capture inventory data. After all, if it’s installed, it will typically have to be paid for (some small print within certain contract negotiations might mitigate this; however, do not wait until a vendor audit to find that this exemption is missing).

Secondly, you will need contract data. Contracts between software vendors and companies will often qualify out-of-the-box licence terms and conditions, and offer greater benefits concerning upgrades/downgrades and technical support. It may be that your company has a dedicated contracts department, working with a bespoke application that does nothing else other than host and maintain contract data. Former experience of dealing with contracts departments (albeit from a consultant’s perspective) is that, typically, such departments are incredibly protective of this information, so gaining the endorsement/buy-in from the relevant director to release this information is vital.

Thirdly, you will need purchase data. Proof of purchase is often the first piece of evidence a software vendor will call upon to demonstrate your rights to use the software installed on your systems. Be warned: it may not be the only piece of evidence they ask for! More on this follows:

Licensing models: If you have obtained your software under a contract, or through a direct purchase programme from a software vendor, then additional proof of entitlement may well be required to justify your installs. Licences come in a variety of shapes and sizes, and such documents may well call upon additional supporting evidence to validate the licence (e.g. purchase records, certificates of authenticity, original media, original packaging and any supporting documentation). Ultimately, it is your responsibility to fully understand what evidence is required to support your rights to use your installed software, so guidance from a SAM consultant or in-house expert would be prudent. I have seen many organisations ‘create’ an instance of a software licence in their software asset management suite solely based on purchase data – just because a system says a licence exists, doesn’t necessarily make it so. SAM is all about working from a position of justifiable knowledge, not from assumption and supposition.

Contract data: Contracts will typically permit or endorse a wider-ranging spectrum of rights to move, upgrade/downgrade, or obtain support and maintenance on software titles. Leverage your relationship with your LAR/VAR (large account reseller/value added reseller) (or even the software vendor directly), to ensure that the finer points of such contracts are understood and incorporated into any licensing models (mentioned above), and that you are easily in a position to call upon the location and content of those contracts, should the need arise.

Hardware data: Increasingly, it is coming into vogue to use hardware components as a metric in determining the consumption and use of software licences. Makes and clock-speeds of processors can be used as factors in the calculation to assess cost. A word of caution here: make use of your licensing models to support any change management that takes place in the future. Factor in any moves of software titles to new platforms (and presumably upgraded processors) prior to making that change.

Finally, in addressing your licence reconciliation process, you may have to take into account usage data. Certain licence types stipulate that software is tied to a named individual. Evidence of that individual’s use of the software will need to be balanced against declared records passed on to the software vendor. Again, consult the relevant terms and conditions of the software licence before arbitrarily moving that software from one user to the next.

Tool selection

The kernel of any decisions made around the tools used to support your SAM programme, should be based on the risk assessment conducted to support the scoping assignment previously covered. If the programme has been borne out of the requirement to address all Microsoft^® software, then the requirement to audit and reconcile software on UNIX^®/Linux^® devices will be practically zero. If, however, you are required to account for all software on all systems, then the ability to cover the aforementioned devices will require you to exclude certain inventory systems as suitable for the task.

Consider too, what kinds of evidence such audit tools claim to capture – some will offer registry-only scans of PCs and servers. This, however, will not account for software that (when installed) does not write to the registry to declare its existence. Also factor in the reporting functionality of any system chosen. Exporting raw data into Excel may be a ‘nice have’, but then converting thousands of lines of raw inventory data into an executive summary may lead you to question why you studied for a college-level education in the first place! Therefore, look long and hard at the ability of SAM suites to integrate with other systems that might already be in place and the level of work required to port data automatically from one to the other (and possibly back again). Ensure too, that alongside any requirements highlighted by the risk assessment, business objectives are brought into contention. A SAM manager could very happily operate in his/her own bubble, but if the work produced is not supporting the business, then it won’t count for much.

If any tool is worth its salt, then you shouldn’t be afraid to call for a ‘proof of concept’ from the tool manufacturer. The better vendors out there will offer a report on a limited scope and sized deployment to demonstrate the functionality of the system, and to highlight the benefit of discovering just what is on your IT estate (albeit a smaller portion of it).

Policies and procedures

Clearly, we have covered in great depth the principle of policies and procedures (as they pertain to ISO19770-1). In going through this book, however, you may consider other adjacent areas you wish to write policies and procedure on, as they impact on SAM (joiners, movers, leavers process; acceptable use policy; third party/consultant’s access policy); but for now, let’s consider some of the branches in the Mind Map.

SOPs (standard operating procedures): As a sector, IT is notorious for the fluency and turnover of staff. To ensure continuity of service to the business, a company should have clear sets of instructions on what SAM objectives abound, as well as how to achieve them – SOPs offer one such means of insurance. Please do not make the mistake of assuming that access to a system and its operations manual will turn that person into an expert.

Types of employees: Rather like the opinion expressed formerly about one SAM system curing all your woes, you may well find that one policy and procedure will not cover all types of employees. You may wish to curtail all unlawful installs of software with an outright ban of anyone installing software, but does this then extend to system administrators, or developers, or to applications that might be deemed safe/friendly (e.g. Skype)? Seek to offer yourself the greatest level of control, without antagonising the greatest number of people. It may well be that some folks will have former concessions or functionality curtailed (e.g. access to iTunes), but providing you are confident in your justification as to why such curtailments are in place, then don’t be afraid to construct your policies accordingly.

Policy creation: It might be prudent to call upon SAM consultants for the finer points of policy and procedure creation, but I would equally ensure that, regardless of the approach adopted, consult with the people who will be most affected by the policy concerned. This way, any objections can be handled at the outset and, by engaging with those personnel at the start, it demonstrates more than an air of concern, i.e. that you value their opinion, but that you also don’t wish to upset their way of working (wherever possible). In my opinion, the one exception to this approach would be concerning a policy of software removal. You might advocate a removal policy which initiates removal of software titles after 90 days of non-use; if this is discussed en masse, you will always get a hard core of users who will make a point of opening and then closing each and every application on day 89 just to keep the software on their systems.

Preferred format: There is no preferred format stipulated as a requirement for ISO19770-1 (other than to align any documentation to the numbering system within ISO19770-1). However, I would always recommend the following are included as part of the document structure:

• page numbers
• paragraph numbers
• change control sheet
• document version number
• document date
• date document last reviewed
• date document due for next review
• document owner
• document sponsor.

Policies and procedures should be in a clear, legible font and should be readily available to any/all employees that they refer to (the company intranet seems to be the location of choice these days).

Legal and/or human resources (HR) review: Aside from seeking peer/stakeholder engagement, it would also be sound advice to ensure that any policies and procedures created gain endorsement from a legal department and/or a HR department. Having already identified stakeholders as part of the risk assessment/RACI assessment, this review should, by and large, be a rubber-stamping exercise; however, the value of ensuring that a policy does not ‘hamstring’ a company should not be underplayed.

An employee of Company X was under warning for having previously broken several company policies. One Thursday, having downloaded and installed a piece of software (which was, again, contrary to company policy), he was then brought to answer before HR, and then dismissed for the collection of breaches he had incurred.

The company policy regarding system audits was that they were ‘ALWAYS’ run on a Friday; however, this particular audit took place on a Thursday, due to the fact that the IT team were due a day off. In the ensuing employment tribunal the employee’s solicitor argued that because his client’s machine had been audited on a Thursday, he did not have a reasonable chance to uninstall the software prior to when he believed the audit would have taken place. Needless to say, the former employee won his case for wrongful dismissal.

Implementation

Your implementation of the SAM programme in your company will be in direct relation to the scope formally agreed upon. Depending on the size of the resource at your disposal (including systems, people, finance, time, etc.), the pace of the roll-out could also be affected. Falling out from any RACI assessment, should also be the requirement to ensure that adequate technical knowledge is in place to support and maintain the system chosen to sustain the SAM programme. Either you will have an abiding faith in the staff that will run the system, or, equally, you may have to call in contract support from the system provider.

Change management: If a change management process already exists, then this could be followed for the deployment of audit agents (if that is the preferred choice of inventory capture). Either way, whatever method of audit capture is chosen, I would recommend that such work is done when it will cause minimum/zero disruption to the employees using the systems.

Communications (comms) strategy: A glaring hole in many SAM programmes (and my own personal pet grievance!) is keeping stakeholders informed of a SAM programme’s intentions and the various waypoints reached in both project and BAU status. A communications strategy should ensure that anyone who needs to know does know how well (or indeed how badly) a SAM programme is evolving. Frequency of communication is important here – ensure communication is not so frequent that such e-mails are assigned junk status, equally, try to make sure that the content has meaning and value to the people being given the communication.

Projected deadlines: Deadlines will have to be given to tasks to ensure that the SAM programme gains acceptance as BAU, rather than as a perpetual project that is a constant drain on budgets. It is all well and good to tell people to carry out tasks; however, you gain far greater traction and enthusiasm if you explain the ‘why’ behind the ‘what’; so don’t be afraid to engage with people to explain the benefits of the SAM implementation to them. Such information then supports the ‘when’ in any requests for help that might be above and beyond what was originally asked for. (Did you ever know a project that mapped every last detail out and didn’t require a little extra effort? No, me neither!)

Technical requirements: The assessment of any technical requirements will be shaped largely by the existing infrastructure.

• What mix and variety of operating systems require auditing?
• How far and wide is a specific software vendor’s software spread?
• Does an existing method of inventory capture already exist?
• How permanent is the software that needs auditing?
• Does any of the software that needs auditing exist on non-networked devices?

This element of the Mind Map ties in very nicely with the systems integration mentioned in the Tool selection section (above).

Testing: Like any piece of software, the system devised to manage your software assets needs testing. This will require an understanding of what deliverables are deemed acceptable; and what the upper and lower limits for such acceptance are. Frequency and accuracy are also good yardsticks by which to assess performance, but do consider that this is not just a test of the software/IT system; it is also an assessment of how well the people, processes and technology come together to provide the SAM/IT information needed to support the business.

Acceptance: Having gone through the time and trouble to implement a SAM system, the project element will have to die away to be replaced by a BAU entity. Having produced acceptable and successful results to come through any testing phase, a formal sign-off process should see the system into operational and daily use. This is a worthwhile step, not least to formally announce the presence of the SAM system to the wider business, but also to let other stakeholders know that any favours or reliance on project staff/resources may no longer be called upon because the project has now closed.

Continuous review/improvement

It is contrary to the way and nature of IT for anything to stand still for any length of time. So, for that reason, it makes sense to remain mentally alert to the concept of flexibility. It may well be that the criteria passed to get the SAM system through testing and acceptance no longer hold value to the business one year after achieving BAU status. Weekly inventory imports may now no longer provide sufficient visibility and accuracy of assets, and so a process change to increase the frequency may have knock-on consequences in respect of system workload and reporting requirements.

Licensing knowledge: Monetisation seems to be a popular phrase in this day and age, and it is no less a weight to bear in the IT industry. Software vendors are forever coming up with ever more creative means by which to maximise the return on their software products, and this is typically done through varying the licensing terms and conditions under which software can be deployed. Therefore (and as prescribed by ISO19770-1), it is a necessary requirement to proactively review, maintain and update the licensing criteria by which software is deployed – and to make sure such licensing knowledge is fully understood by your SAM team. Having a process around licence education would be a prudent step here.

Policy and procedure review: Aside from using quality assurance metrics that are, hopefully, already built into your policies and procedures to measure day-to-day performance, an annual or six-monthly assessment may also be required to address the wider and more general questions of:

• Does the process actually deliver what it is supposed to deliver?
• Does the process still address a business need?
• Does the process still address an IT need?
• Has the scope/coverage of the process changed?

You may be able to consider other questions to ask around your process review (and some may drop out of the subsequent paragraphs), but taking a step back and asking the basics above, should ensure that any policy and procedures created for the initial implementation of your SAM system stay relevant.

Staff changes: To return to the basic diagram at the beginning of this booklet (see Figure 1), people/staff are every bit as important as the processes and systems that interact with them. Key members of staff will eventually come and go; as such, some degree of education will be required to ensure that new employees are fully up to speed with their roles and responsibilities, and also knowledge of the tools and resources that are at their disposal to achieve their work objectives. This point only serves to reinforce the benefit of relevant and up-to-date documentation covered in the previous paragraph.

System performance: Many criteria exist to assess how well or badly systems perform; and external factors may also have an impact on such a review. It could be that your company has acquired another, and so your IT estate has doubled or tripled in size. (Did you create a process to cover the addition of new IT equipment into your processes?) Some licence management suites/inventory systems have upper performance limits that aren’t necessarily discussed at pre-sales meetings. Again, the risk assessment conducted at the beginning of your scoping exercise should help tease out questions pertaining to the technical requirements of any system you purchase to help you with your SAM programme, but, as mentioned above, flexibility (and forward thinking) are prudent attributes to have when choosing any IT system. Some points to get you on the road towards a system review might include:

• time taken to collect inventory data
• time taken to upload inventory data
• ease of importation of inventory data into SAM system
• accuracy of information once imported into SAM system
• ability to cope with varying platform types
• ability to cope with expanding IT network(s)
• ability to cope with new/emerging licence types
• whether there are any upgrades to the existing system since last installed that might add business value
• how well the system is received by staff
• how well the reports are received by stakeholders/management.

Change of business need / reporting requirements: This is relatively straightforward: if reporting requirements change from senior management/stakeholders, then this should be communicated to the SAM team, so that a shift in expectations is smoothly addressed. This can be done via a feedback process (even a question at the bottom of a report akin to: ‘Feedback on this report is welcomed’), or via a more formal process where a meeting is held six-monthly/annually to review the quality of the reports produced and assess whether they meet business expectations. Equally, the business could have changed direction, and could have neglected to inform the SAM team of a change in expectations. As long as some degree of communication takes place, this should not be a large issue to overcome.

Governance

This is an area of IT (and business) that is somewhat harder to grasp as a concept, not least because it is not linear or metric in its assessment. Plenty of books have been written about governance and, due to the scope of this publication, I will not be offering chapter and verse on what should and shouldn’t be contained in governance documents. Needless to say though, businesses should ignore the concept of governance at their peril. If laws exist to place acceptable activities engaged by a company in pursuit of its business, then governance can be considered as the expression of its ethical soul. However, as with all expressions, these are subject to change, discretion, political pressure and ignorance.

Best practice/standards requirements: When embarking on a SAM programme, the principles, objectives and goals sought will often be augmented by adjacent standards and/or frameworks (SOX, COBIT,^® Connecting for Health, ISO27001, ITIL,^® ITAM, etc.). That is not to say that such standards and frameworks should be tackled in isolation – you will find that a lot of the objectives are complementary. Again, these standards should form the mainstay of your risk assessment, so that your SAM programme does not retread ground previously covered by former projects: why reinvent the wheel? If your company has ISO27001 controls already in place around licensing, then assess their suitability in applying them to ISO19770-1:2012.

Wherever possible, watch out for the overlap between adopted standards to save time and effort.

Industry specific requirements that need supporting: Each sector has its own unique requirements that could add an extra function step or two to any vanilla processes you might have mapped out in your mind. Ensure that the business tells you of these requirements, so that your actions within a SAM programme can be justified. For instance, your SAM programme may interact with DPA requirements (Data Protection Act, 1998), e.g. keeping next of kin details in a secure location for a company in the construction industry, and having a process in place to determine when it can and can’t be accessed; could be completely different from a company based in the chemicals industry (COSHH regulations stipulate that all employees working in the chemical industry have records kept about their employment, even after they have left that employment – and beyond the standard two-year window permitted by the DPA).

Business strategy that needs supporting: Most businesses have a mission statement, and that mission statement is typically underpinned by business strategies. Such business strategies might call upon the support of IT to ensure their success. If an Internet portal is pivotal to sales for your company, then uptime and speed of interaction with a stock-control system will be core IT demands. Within this, your SAM programme needs to ensure that all aspects of that Internet portal are properly managed through their life cycle. For example, ensuring the licences exist to account for the software used; that all patches and hotfixes are up to date; that appropriate controls and processes around release management, change management and incident management are in place; that any third-party involvement in implementing/maintaining this service is in line with ISO19770-1 requirements. Now, imagine that a new product or service comes along that falls outside this Internet portal, but that requires a new Internet site, or new IT mechanisms to support it. This has to be seamlessly integrated by IT into the business; hopefully, the processes established in the SAM programme will allow for the accommodation of such change.

IT strategy that needs supporting: Aside from supporting direct activities demanded by the business, your IT department will also have some requirements that will fall adjacent to, or in line with, the SAM programme. We have already touched on people/staff and the training required to keep abreast of licensing changes; however, the essence of a SAM programme is an IT strategy in its own right. Another might be: the accurate and timely deployment of hardware and software.

Well, if a SAM programme is in place, this will surely prevent the fire-fighting and over-purchasing that has been known to plague IT departments in the past.

Senior management buy-in: Arguably the first proactive step in any SAM programme; a presentation to senior management on the benefits of embarking on a SAM programme should not be taken lightly. From a non-IT perspective, asking for extra resources to do something that directors might believe was already taking place (or should have been taking place) could be quite a challenge. I am reminded of a saying I heard during my service in the Royal Navy: After belly-aching to a senior rate about the uncooperative attitude of my colleagues, he said to me: ‘Don’t give me problems, give me solutions’. Frankly, such a eureka moment got me to look at the same problem from a different perspective, and so my guidance would be this – do not spend 30 minutes in front of senior management telling them how awful things are in IT, and then ask for a bunch of resources (i.e. money) to make a vendor audit go away! Have a plan – demonstrate that you have considered the problem, and what the resultant benefits of a SAM programme are. This could lift information from an informal risk assessment, or the first draft of a project/programme plan (or even tips and tricks from this booklet!).

CSR (corporate social responsibility) requirements that need supporting: It may well be that your company is doing its best to acknowledge local good causes nearby and, as such, decides to donate retired/to be disposed of IT equipment to a local charity. Again, this needs to be accommodated through your policies and procedures and in acknowledgement of any licensing requirements/novation demands of the software vendors.