The Low Stress SAM Project

Best practice

The Low Stress SAM Project

This article has been contributed by Chris Borkert, Principal Consultant at Linium.

SAM projects can be difficult.  They may be prompted by a recent audit, realization that there is a lot of money being left on the table with vendors, or someone suddenly thinks: having unauthorized freeware available on shared drives on our network – could be a risk.

IT projects in general have their own well known set of challenges, but SAM projects in particular have to stay focused, to get the most value from the effort.

The value gained from SAM is cost savings and risk mitigation.  Having been through several large companies, over-licensing (waste) and under-licensing (risk) are not just common, they’re ubiquitous. Companies want to get this under control, and thus – in comes the SAM project.  This type of project in particular must stay focused to be successful.

The level of detail about what needs to get done varies, at different companies.  It is helpful to have a project sponsor at the highest level in the organization as possible (more on this later). A top priority is what to track.  This should be determined early on, and may even be spelled out specifically in the project charter or consulting agreement.  A large company will have several hundred to thousands of titles of software installed out there somewhere.  They don’t all need to be reported on.

In the interest of getting the greatest savings, titles can be prioritized by the greatest potential cost savings benefit.  The company may already have some insight (i.e. We know we’re overpaying Microsoft yearly, we need to do something about it!)

On the risk side of things, the insight may be, “we have a real problem, we don’t know what PCs have been deployed which patches”, or, “we have a real problem with people clogging up the network using Bit Torrent”. Prioritizing titles up front will keep the project focused on what’s important.  As we go down the list of titles by priority, we soon get the point of diminishing returns where tracking the thousand titles at the bottom of the list provides no value, and only complicates our project.  Later, our end result will be a dashboard that will show the important titles and our compliance on each.

Now that we have organized things by individual software title, each title should be analyzed to determine what does “compliance” mean for that title.  This relates to how the software is licensed.  Desktop applications are most commonly licensed by how many installations are on the network; enterprise server apps may by licensed by their number of concurrent users, or number of CPUs of the servers that the software is running on, etc.

Licensing types are determined for each title individually, so we know what metrics to collect for each. Our discovery tool is going to tell us, what software is installed where, and how many CPUs are on each server, etc.  Discovery tools are going to take inventory.  Typically in a large company there will be multiple discovery tools, which presents its own set of challenges when we get to the technical build phase.

But, going back to our prioritized list, we may find that not all of the discovery results are required for what we need to track. Multiple tools may feed the asset repository, where we will generate the reports.

On the project management side of things, we will almost certainly need input from different organizations within the company.  Operations for the discovery side of things, procurement for the purchasing and licensing information we need, tools or support teams for help with the technical implementation.  Getting their time can be difficult, especially when they report up different chains of command.  This is where a high-level project sponsor is helpful.

IT and Finance are typically totally separate organizations (i.e. different VPs).  People are busy, and you’ll need their buy-in and time to be successful.  People can be much more responsive when it’s known to be a project of a VP as opposed to Manager level.  Your risk of being denied access to people in other orgs is decreased.

We have spelled out the essential titles and how each is licensed, which can greatly simplify the technical implementation.  The technical implementation mainly revolves around the integrations of discovery tools to the asset repository, and getting our reports and/or dashboard from that repository.  Viewing things with a laser like focus, we could say that what we truly need is:

1. Inventory of computers and their attributes
2. Software titles on each of those computers
3. List of titles we need to track and the license type for each

For a first SAM project we may even limit the scope to only those titles that are licensed by number of installations, or even just Microsoft titles that are not free.  This helps us stay even more focused and can get us an easier win.  We can always build out the system more, by adding more titles, in the future.

The technical challenges are usually not trivial, although consultants may have experience with certain tools, vendors may publish information about integrating with their tools, or folks in the IT organization may have had experience, for instance have already set up database views that can be used to pull the discovery data.  Once we get the system working, we can get to our output or deliverable of the system, which are reports to determine compliance for each title.  Information can then by used in vendor negotiations, or provided to internal teams to mitigate risk.

The announcement of this kind of implementation can set off very interesting alarms among employees.  Those that have been knowingly violating company policy may rush to comply before the system is even implemented.  Actions to be taken when someone is found using unauthorized software are really outside our scope, since our goal is to just provide the information, not enforce compliance, but it is best to deal with violators respectfully, and offer them an amnesty period to uninstall any unauthorized applications.

SAM projects can go off track. Cut out what you don’t need, and stay focused on the goal.  SAM projects like all IT projects have the potential to deliver great or little value, or fail completely.  By staying focused, the chances of success are greatly increased.  Best of luck!

This article has been contributed by Chris Borkert, Principal Consultant at Linium.

Can’t find what you’re looking for?