Panel only seen by widget owner
Cortex Consulting
Typically replies within a day
13:26
Hi there 
How can we help you?
Start Chat
 
 
 
10 Jun 2018

In part 1 of this series, I went through some of the issues with end user SAM practices in the datacentre, from my experience.  I also looked at a sample PMO process, something which is fairly standard in most organisations, and what each of the key stages are.  In this post, I'm going to explore how you can plug SAM into such a process to achieve some simple governance and cost efficiency.  I'm not going to look at activities that might come before or after the PMO process.

Consider the below PMO process, which includes all of the key stages of the project lifecycle.  As a refresher, I've included a brief reminder underneath of what each of those key stages represents.

 

Sample PMO Process

Sample PMO Process

 

  1. Scoping and Analysis - requirements gathering by a business analyst, ensuring the proposed project fits in with business and IT strategy
  2. Design - architecture involvement, high level design of the application and detailed designs, if applicable, of each element
  3. Build and Test - initial build of development and test environments, systems integration testing, user acceptance testing
  4. Deploy - full build of the production application and go live
  5. Handover - project closedown and handover into BAU support

So where would you add software asset management touchpoints into that process, to ensure your organisation gets the full benefit of governance, optimisation and risk prevention?  Consider the diagram below with checkpoints 1 through 5.  These do not necessarily align to standardised PMO gates (although in most cases they will); they are simply my view of the necessary checkpoints for the SAM team to maintain proper governance with relation to the end user's software assets.

 

Sample PMO Proces with SAM Checkpoints

Sample PMO Proces with SAM Checkpoints

The requirements and activities of a SAM team at each of these checkpoints, and in between them, might go something like the below.  Bear in mind, though, there will be different ways to do things and you may find a way that works better for your organisation.

 

  1. Initial analysis - many organisations expect their projects to have put together a business case by this point, in order to be able to assess the benefits to the business of this project and whether the spend is worthwhile.  In order to predict the costs accurately, you would need to have some idea of what licences may be required.  Obviously you would not be able to say, definitively, that the licences will cost a certain amount; project scopes, concepts, requirements and designs change frequently, and with them so do licence costs - if any are even required.  By this stage, the SAM team should have some awareness of the proposed application, its purpose and the platform it will be hosted on (e.g. cloud / internal datacentre, x86 / RISC architecture), so initial research into availability of spare licensing and potential costs of additional licences should be viable.
  2. Design - one of the most important parts of the entire process.  By the time you reach the 2nd checkpoint, you should have a signed off design, ready for the techs to build the development and test servers.  But what is the SAM team's role in this?  The design stage should be an iterative process whereby a SAM person would have regular contact with the architect to establish what licences are required for the application and also discuss optimal licensing methods, to reduce consumption; the architect should be open to these sorts of conversations, so you can be sure that any licence recommendations that are made are taken on board and incorporated into the design.  For this to work, stakeholder buy in is required from the PMO and architecture authority.  Once they can see the value in what you are doing, they will generally subscribe to a SAM view of the world, in my experience.  A final point on this element - I always advocate that some sort of licence statement should be produced by the SAM team (or whoever happens to be evaluating the design for licensing), and that it should be treated as a project artefact and incorporated into the design document.  It should contain several key elements - details of the licences required for the design as a whole; details of any licences that can be recycled from stock to service the application's requirements; details of any licences that would have to be procured, along with ongoing support costs; you may, if you wish, include details of potential licence risks, though there should not be any if you've done your job right.
  3. Build and Test - once the project goes into its build and test phases, you can see a lot of changes.  There could be issues with the build, elements of it may not work together as expected, system integration testing might reveal a flaw, user acceptance testing may highlight that the new application's functionality does not align to the original requirements.  All of these, and more besides, could cause a project design to be changed by the architect.  The point of having a checkpoint at the end of the testing phase, is so that the SAM team can capture any design changes (and, therefore, changes to the licence solution) and any potential licence risks.  As with the previous checkpoint, it is vital that an iterative approach be taken throughout this phase, to give the SAM team full visibility and keep them abreast of any changes AS THEY HAPPEN, rather than waiting until the checkpoint.  Dialogue must be maintained with the PM, architect, procurement and technical teams involved.  The licence statement would also need to be updated and re-issued.
  4. Deploy - once a final design is agreed and all testing successfully complete, the project will go into the deploy phase and build the full production application.  The key activity for SAM at this stage is to provide governance around any licence risks that may be created at this stage. There needs to be a check to ensure that the application has been built, as agreed, and that licences have been consumed per the allocations in the licence statement.  Have any additional servers been added that weren't previously accounted for?  Is all the software still on the same version agreed in the licence statement?  Has a database been changed from Oracle to SQL?  These are all extreme examples but the main point is that any risk should be identified, captured, reported, and a decision taken whether to treat or accept it.  Personally, I'm always of the view that if a project creates a licence risk, it should also have responsibility for mitigating it.
  5. Handover - most project managers in my experience will want to get their applications handed over to BAU support, execute the project closedown and move on to the next task; but what happens then?  This point may very well hinge on how your organisation processes decommissions but, considering most new applications are replacements for old ones, what happens to the old kit?  Does the project decommission it?  Is there a specific decommissioning process, whereby another team takes care of it?  Whichever it is, the SAM and wider ITAM team has a responsibility here to ensure that legacy applications are not left running indefinitely and tying up licences unnecessarily.  This is your opportunity to ensure that any software licences you can re-harvest and recycle for future use are dealt with, and the hardware is decommissioned and removed from the data centre.

These steps are intentionally pitched high level and open ended.  The reason for that is every organisation has their own way of doing things and this piece is more about helping ITAM and, specifically, SAM professionals to think about what level of engagement they have with their PMO and / or service introduction processes.  I have deliberately avoided mentioning procurement of licences for the same reason, though I believe that staged procurement is often the most workable solution.  Depending on the software, it may not always be viable, but procurement (if required) of the licences to cover dev and test is best done at checkpoint 2, and procurement of the production licences at checkpoint 3.  This may slow down your PMO process slightly - many PM's prefer to buy all licences in one hit to avoid wasting time - but it does ensure you don't buy software licences you may not need if the design changes during the testing phase.

The next piece in this series will focus on SAM engagement with the change management process in the data centres.  If you have any questions about this piece, please feel free to contact me through this site or Linked In.  I'm always interested to hear others' experiences.