Injecting life into SIAM
Ever since outsourcing was popularised in the 1990s, we’ve seen models and strategies develop and mature. Rarely, however, have we seen such models disappear completely. But with SIAM, the service integration and management model, some commentators are already writing it off.
We believe that considerable benefits can flow from the SIAM model but only if the market can learn from the mistakes of some early adopters and is prepared to challenge conventional wisdom. This article presents the lessons from earlier SIAM implementations and challenges best practice thinking to launch a new, improved version of SIAM: SIAM 2.0…
An overview of multisourcing
Multisourcing can be summarised in diagrammatical form as follows. Each arrow represents a contract. (The service component descriptions are merely examples.)
Whilst there are well documented benefits in multisourcing, asking suppliers to work together (eg for fault resolution or multi-party governance) can be problematic. A customer’s retained managed function (the “Intelligent Client”) also suffers from under-investment, causing many multisourced projects to fail to meet time and cost expectations.
SIAM was an attempt to overcome this tension by not only outsourcing non-core functions, but a key part of the Intelligent Client too.
SIAM differs from traditional multisourcing by virtue of the customer appointing one supplier to integrate and manage the other suppliers.
Why SIAM 1.0 remains unproven
We were recently asked whether we were aware of any successful SIAM implementations. This is a difficult question. Most SIAM implementations are going through transition, and whilst we can identify challenges along the way and some signs of success, it is too early to predict whether or not they will deliver the anticipated benefits.
There is, however, a track record of problems in the public sector. Why is this?
Unreasonable expectations. In the infancy of outsourcing, savings were often disappointing or unrealised due to an underestimation of the cost of managing the supplier.
You can’t outsource your entire retained IT organisation. Appointing a SIAM doesn’t mean outsourcing your retained IT organisation. On the contrary, by delegating all the retained IT organisation’s functions to your SIAM provider, you are, in some respects, creating a single point of failure.
You cannot price all risk. With a single supplier, financial risk for the entire project is typically capped to a multiple of the overall charges. With multisourcing, a service component provider’s liability is capped to a multiple of the charges relating only to that service component. One government department went to the market asking the SIAM bidders to accept a liability multiple linked to the value of the entire programme. It suggested that the SIAM bidders should price the risk. The bidders all walked away and the procurement was pulled. This makes the SIAM model look very high risk: if the SIAM provider is only willing to accept liability as a multiple of its (relatively low) charges, it is the customer who carries the lion’s share of the risk. But this is no different to any other multisourcing arrangement and can be overcome.
Inadequate planning. Once the business case is sufficiently proven, due diligence needs to be comprehensive and contingency planning is essential. For example, in many cases, service integrators are simply offering toolsets that they have developed to manage their own internal supply chains. These toolsets need to be carefully reviewed to ensure that they work for the client.
We present SIAM 2.0: a new improved version of SIAM, with the following features.
Thorough due diligence on the SIAM provider. The usual due diligence needs to be significantly more thorough than usual. For example, thorough references, pilot schemes, toolkit testing are all recommended. The cost and time required to carry out this due diligence needs to be built into the business case.
An orderly approach to implementation. Where possible, the SIAM provider should be procured first, followed by essential infrastructure, with other layers added as necessary. Where service components require staged implementations, the order of the implementation becomes more obvious.
A road map. A business that wants to implement a SIAM function should only do so once a detailed design of the new operating model and supporting organisation has been produced and approved by senior stakeholders within the business. Services should be disaggregated into a manageable number of recognised industry service components where market tension will continue to apply in terms of price, quality of service and innovation.
Roles and responsibilities that are clearly identified. The business should not commence the procurement process until it has clearly identified the roles and responsibilities of the SIAM provider, the component suppliers and the retained IT organisation. The dependencies between each of the component suppliers should be documented in Operating Level Agreements.
Retained organisation. The business should invest in the retained IT organisation which will be accountable for decisions about the overall enterprise architecture, financial and commercial considerations, security and compliance, business relationship management and overall programme management.
SIAM charges. As the role of the SIAM provider is to manage, govern and co-ordinate the delivery of services from multiple suppliers, part of the SIAM’s remuneration should be tied to the achievement of milestones and end-to-end service levels. However, the business must be realistic about the level of risk that is appropriate to be allocated to the SIAM provider.
Collaboration. We are not convinced that suppliers are willing to work together unless there is a sufficient incentive to do so – and a legal document (such as a collaboration/cooperation agreement) is not sufficient incentive alone. As part of SIAM 2.0, we are, perhaps controversially, recommending the end of the collaboration agreement. We propose to replace this with service requirements for each service component which are clear, complete and unambiguous and incentives mechanisms that link supplier success to cross-programme success.
Transparency. Service component contracts should include provisions that permit the business to share information, data, and service reports with the SIAM provider and allow the SIAM provider to perform operational and compliance audits on the service component suppliers.
Governance and dispute resolution. The business needs to consider how it will manage its suppliers individually and collectively and how to facilitate communication between suppliers, through for example joint meetings, sharing service reports, incident reporting and resolution. We also recommend that an expert determination procedure is used for inter-supplier operational disputes, with the SIAM acting as the expert up to an agreed financial threshold and a pre-agreed expert appointed for resolution of operational disputes above this limit.
Exit. End of contract complications are potentially bigger in a SIAM operating model. Each contract will need to be reviewed to ascertain what people, assets and data will transfer on exit. In addition, the business must ensure that the SIAM provider’s tools allow the business to ‘plug and play’ fit new service component suppliers and new SIAM providers.
Whilst acknowledging some genuine success stories, SIAM has had a difficult start. Often, the business case has been over-egged leading to financial disappointment. In the excitement to try something new, familiar multisourcing errors around expectation, risk and the basic pretext that suppliers will work with each other for the common good, have resurfaced in a slightly different guise.
Of course, suppliers will work together (and do) if the incentives mechanisms are sufficiently compelling. Risk can be fairly apportioned. Expectations can be lowered.
And, if an organisation wants to multisource, some form of integration will be necessary. SIAM 2.0 could be the best way forward.
About the Authors
Robert Shooter is the head of the technology, outsourcing and privacy law group at Fieldfisher and a leading expert in outsourcing and procurement law. He specialises in large-scale, often mission-critical technology and telecoms projects, both in the private sector and for central government. His client base consists of both customers and suppliers.
James Buckingham is a partner in the technology, outsourcing and privacy group at Fieldfisher, specialising in technology, media and telecommunications transactions and advisory work for clients in the financial, technology and communications and public sectors. He advises on, prepares and negotiates contracts for: information technology and business process outsourcing projects; IT service provision in single supplier and multi-supplier delivery environments; major systems implementation and procurement; software development, licensing and support; and e-commerce projects.