SIAM (Service Integration & Management) provides a framework by IT organisations that have been disaggregating their IT service contracts and introducing a Service Integrator capability to manage and coordinate the delivery of IT services.
SIAM has certainly gained traction in the market over the last 5 years, lead by UK government organisations looking to buy best-in-class services whilst also introducing cost savings to their overall IT run cost. They were followed by private sector companies and interest has now spread globally.
But there’s a massive risk looming in these programmes, one I’ve seen numerous times and one that you’ll almost certainly be faced with.
As you seek to dissemble contracts that may be in place for many years, and have undergone many changes, it is imperative to ensure that you have a deep knowledge of the services provided today.
You absolutely must:
- Understand each element of the IT service provided by each of the existing IT service providers. For example, the underlying processes, tools, governance, people and standards that characterise how the service is delivered today
- Understand the tools being deployed to deliver and support the IT service, as well as who owns these tools and who pays for them
- Understand processes currently performed by the existing Service Providers, and if they’ll let you, get an insight into how they proceduralise these within your own organisation
- Understand any value-add services provided by the service provider, which are either not in the contract, or offered free of charge, or both.
- Understand details of any 3rd party dependencies or subcontractor arrangements which your IT Service Provider uses to deliver the services on your behalf
- Understand any bespoke or proprietary solutions offered by the existing IT Service Providers
- Understand any regulatory standards, principles or bodies which must be adhered to in the delivery of the IT Services
- Understand any Service Level Targets or informal expectations which are in place to deliver the service to an acceptable standard
Why do you want to mitigate this risk?
As you can see, there’s a lot to be considered. But why are these things important and what will happen if you ignore their importance?
Well, as you seek to disaggregate existing contracts and build new contracts, it’s easy for things to “fall between the cracks” if you don’t have a handle on these things. For example, there might be a service which is offered by an existing Service Provider on a “goodwill” basis today. It’s not in any contract schedule, nor does it appear on any invoice. As you move from the existing Service Provider to a new one, how do you know to include this activity in your knowledge transfer and discovery activities?
A further common issue can occur with the underlying IT management systems which support many of today’s IT services. There is often a complex model of software ownership, use and licensing here which must be understood if you are to transition it effectively from the existing Service Provider.
Failure to effectively mitigate this risk could result in costly contract scope change or program delays whilst issues are resolved. It’s critical you address it early to prevent the likelihood of this occurring.
How do you mitigate this risk?
You will never eradicate this risk, but you can mitigate it. Unfortunately, the mitigation can be costly and time-consuming, something which puts off many organisations.
In essence, your mitigation strategies are as follows:
- Conduct an audit of the existing services which includes many of the factors above in its scope. This can be done on a per-service or per-contract basis. Your audit scope should include as a guideline, the following areas:
- The Processes and procedures currently used to deliver the service. Is there anything here that requires specific or scarce skills? You’ll need to ensure that these people are included in any knowledge transfer scope or TUPE (staff transfer) obligations
- Look at the existing tools being used. Are any of this end-of-life or out of support? Are they proprietary or bespoke? These will need to either be transferred or redeveloped in the new service scope, so ensure sufficient cost and time is allowed for this to occur along with any supporting knowledge transfer activities
- What are the existing service targets / SLAs in place, and are these achievable, realistic and appropriate for the new service?
- Are there any 3rd party dependencies and subcontractors? Are these arrangements exclusive or can these services either be bought in the market or transferred within the scope of the services?
- Review the existing IT Service Provider contract scope. What do they deliver today? Are there any additional items that fall outside of the scope of the contract which must be understood?
- Ask the existing Service Provider’s support teams about the services provided today. They’ll often know more about the service scope and any activities which have grown embryonically over time
- Ask the users about the service they receive and compare it against the existing contract scope. What are the critical elements of the service from their perspective? Are there any aspects of the service which the users have modified from the agreed contract scope?
- Review the IT service provider invoices to establish a clear view of what you are paying for. This should provide a good basis to better understand the contract scope
What barriers are you likely to encounter?
I’ve included this additional section as a result of my direct experience. You’ll encounter resistance to this work on the basis that it will be picked up during the Discovery or Knowledge Transfer phases of your contract transition. However, by this time it is often too late as the contract scope is already costed and set by the IT Service Provider.
Any changes to contract scope during the contract transition phase will either result in additional time or cost. In one example I’ve encountered, the contract had to be re-tendered as the new Service Provider did not support the service which had been omitted from the original Request for Proposal.
So, you’ll need to sell the importance of this work to programme leadership. And if you fail to do this, make sure there is adequate budget and time to address any issues you encounter “in-flight”. And make sure you raise a programme risk which is scored appropriately to give you some means of addressing any issues you may encounter.