Blog

Organisations around the world start, deliver and pay for a number of projects throughout the financial year. Projects can range from “standardising our printers” to “re-laying the carpet in the CEOs office.”

When it comes to IT, there is usually a cost associated with a project. This may be in services, hardware, software or implementation fees. Whilst we naturally want the organisation to spend as little as possible, let’s focus on the software or ‘Software as a Service’ element of a project and the important relationship your Software Asset Management (SAM) team should have with the Project Management Office (PMO).

Don’t be left holding the baby

A bad or non-existent relationship between SAM and the PMO office is much like SAM being left ‘holding the baby.’ Organisations often forget that the software element of a project could have a major impact on the SAM team. This may be overlooked because they are simply unaware of the correct process, the importance of license management or that they are so focused on delivering a project on time that the Project Manager doesn’t look further than the completion date.

This means that they could purchase thousands, if not hundreds of thousands of pounds worth of software through the project or with project costs without letting the SAM team know. This then raises a number of difficult questions:

Who pays for the licenses, maintenance, support or subscription costs?

Who negotiated the financials? Did they consider price-locking new license costs, removing clauses allowing year-on-year increases?

How are they expecting to manage the licenses, or will this be a nice surprise for the SAM team further down the line?

If SAM isn’t informed, who is the application owner and responsible for the risk?

How will the users get access to the software?

How will new users request access to the software?

The list of questions goes on, and on.

The common theme is that the project implements or purchases new software without SAM engagement, and then passes the license management, governance costs, and risks to the SAM team.

The SAM team always gets left holding the baby without knowing their favourite food or how to stop them from crying…

Getting the process right – when does SAM need to be involved?

As part of the Project Management Office process, people like the Software Asset Management team, finance, procurement and even a Hardware Asset Manager should be made of the potential impact right at the conception of the project. At least then they are made aware of what might be happening and it is on their radar.

These stakeholders can then also have their input as to what needs to be considered – something that the project may not have thought about. For example, the project may require a new software application that needs 8GB RAM (like AutoCAD) for anyone that uses the software. The users existing machines may not be able to run the software, which leaves them with an additional cost to purchase or upgrade the hardware device.

It may also be the case that the SAM team actually has spare licenses for the project, that can be passed over and re-charged back to the project. Whilst there may be re-charging, the overall organisation doesn’t have to purchase any new licenses, but must consider software maintenance.

The additional licenses may also mean that your next anniversary date or agreement sees a significant increase in costs and license quantities. That needs to be considered and the budget holders must be made aware of the potential increase so they can factor in the additional costs when it comes to renewal.

It’s also important to explain what project relates to the increases, so it doesn’t look like it’s SAM just increasing the numbers to rectify a risk or non-compliance – it’s for a specific project that will require the licenses for X amount of years

Project Considerations

Let’s look back at the original questions we were considering at the start of the blog. All of the questions need an answer and comprehensive answer so the SAM teams knows their level of involvement, roles and responsibilities and budgets.

Who pays for the maintenance, support or subscription costs?

It depends on the structure of the organisation, but this may come straight out of IT’s budget, a project budget or a specific cost-centre. What works well is that the project budget pays for all costs related to year 1 – getting the project off the ground and delivering if possible – and then the relevant cost centre /IT pays from year 2 onwards.

Having this structure means that IT isn’t compromised by software/SaaS that they weren’t expecting and SAM knows what to expect from year 2 onwards for budget, compliance and optimisation purposes.

Who negotiated the financials?

When following the correct process, this should be SAM & Procurement. The amount of times a ‘dud’ contract (and sometimes VERY long term) has been signed by a project manager – without any negotiations or checking the license agreement – that then puts the organisation in a difficult position occurs far too often.

Let SAM and Procurement do what they are good at and get a good price and a contract that is fit-for-purpose for the wider organisation, not just the project.

If ‘Wooden Dollar’ movements are required, then getting finance involved will also help move said dollars about internally.

How are they expecting to manage the licenses, or will this be a nice surprise for the SAM team further down the line?

When projects purchase software, manage it for a year and then expect the SAM team to know everything about it and take ownership of any risks and the licenses. I’m sure we’ve all been there. It’s like the SAM team suddenly have this plate full of contracts, licenses, costs and risks that they previously were not made aware of.

This can be a tricky situation for the SAM team, suddenly given this extra work and having to build processes and governance models on a contract they weren’t involved in with licenses they don’t know anything about.

Or, involving SAM from the start lets the SAM team build those processes from the very beginning. They know about the contract, they know the terms and conditions and they know the costs because they were part of the team that negotiated the agreement!

Best practice compliance, governance and financial processes/policies can be created and put in place. Knowledge Articles for the Service Desk can be created for how to install the software, where the keys are etc.

Doing this will help the whole organisation avert a risk from the very first day – and will allow the project and SAM team to optimise the new investment in licenses from the get-go.

If SAM isn’t informed, who is the application owner and responsible for the risk?

Regardless of SAM not being involved or informed, they are the overall holder of any compliance risks. The auditors do not care if the SAM team turns around and states that they don’t ‘own’ that application – they’re still accountable for the compliance and risks.

Therefore, as part of the PMO process, SAM should assign a ‘Software Champion’ who will be their first point of contact and a Subject Matter Expert (SME) in using the software. They can help the SAM team with future requests for a license, understand how and why the software is used and needed.

They can also provide first line support for end-users needing support and become the overall ‘Software Owner’. They are a valuable extension of the SAM team, and also makes key stakeholders feel involved and part of an important process.

Business As Usual

From a Software Asset Management / License Management perspective, the sooner you can get the licensing estate into BAU, the better. It may take a bit of work getting to that point, but once you are there it takes away the initial scramble to create processes, assign Software Champions and negotiate license agreements.

Regularly review usage and license compliance. If you follow the mantra of ‘year 1 = project pays’ then work with the Project Manager to purchase any additional licenses or support that you may require. Just remember that this additional cost will fall under the SAM/IT costs from year 2, so change your budget forecasts accordingly.

It’s also important to review the processes you created as part of the project to manage the licenses. Are they still relevant now the project has moved on? Do they still fit? If not, update them and make them relevant. There’s nothing worse than a bad process that people don’t understand.

Finally, you’ve got to a point where SAM is now notified and involved at the beginning of a project requiring software. You’ve gone through the journey with the project, and you’re now at the other side in BAU state.