Introduction
Contracts are an important part of any customer-provider relationship. Specialists are used to drafting contracts for traditional supply models, but the multi-provider ecosystems that are fundamental to SIAM present new challenges. Contracts used within SIAM models should try to link service provision across the full ecosystem, encouraging acceptance of a common sets of rules, and a willingness to evolve and change to meet the needs of the customer. The second edition of the SIAM Professional Body of Knowledge includes new content on how to effectively design contracts that are fit for use in SIAM models. This blog provides a taster.
The challenges of traditional supply contracts and how to address them for SIAM
The purpose of contracts
Put very simply, a contract is a formal agreement between a customer and a service provider. Think of it as a formal record of the promises that each party is making, as a set of requirements with obligations, terms and conditions, and a framework to manage non-delivery and disputes.
Standard terms and conditions
In traditional supply models the contract comes from the provider of the goods or services. These contracts contain standard terms and conditions that apply to every customer. These are formatted into standard sections (called ‘schedules’), each focussing on specific topics such as assignment rights, termination rights, intellectual property rights, payment requirements, and ‘force majeure’ rights. A separate schedule then describes the specific goods and services that will be provided to the customer.
A challenge for contracts within a SIAM ecosystem is that these traditional supply contracts are designed from the perspective of the service provider. SIAM turns that on its head – in a multi-provider ecosystem it is better for the customer if they have the same standard terms and conditions applicable to each of the service providers. This makes it easier to understand and manage the contracts, which supports the role and responsibilities of the service integrator. In SIAM, the contracts should be designed primarily to support the customers business requirements and the role the service integrator is required to take in supporting these. They do of course, also have to consider the service provider’s perspective.
Recognizing the role of other providers
Another challenge is that traditional supply contracts rarely include any reference to working with other service providers; apart from ‘force majeure’ provisions that allow the provider to escape the consequences if a service failure is caused by someone else! In a SIAM model the contracts have to recognise the need for all providers, the service integrator, and the customer to work together. Sometimes this requirement is detailed in an appended ‘collaboration agreement’, which sets out the principles of collaboration, the objectives, and responsibilities for each party. However, just adding in a collaboration agreement isn’t enough, all of the clauses in all of the schedules should be reviewed to see where providers need to interact with other providers or with the service integrator, and if so updated to reflect this.
For example, a standard contract might have obligations on the provider to investigate breaches of IT security. In a SIAM model, this would need to be updated to reflect the requirement to work on the investigations in conjunction with other providers.
Service provider contracts must also specifically recognise the role and responsibilities of the service integrator. Even though the service integrator acts on behalf of the customer in the day-to-day management and governance of the service providers, it is a good idea to make the service integrators role explicit within each of the service provider contracts. This should include defining what interactions the service integrator will have with the providers and the providers obligations within these interactions. This is particularly important if you’ve chosen an external service integrator, as they could be a competitor to one or more of the other service providers. Where this is the case, particular attention should be given to schedules that cover confidentiality, as the service integrator will most likely require access to data and information that service providers would otherwise class as confidential and non-shareable.
Including integration
Integration is a key feature of a SIAM model, so it is crucial to reflect the requirements in the contractual obligations. These requirements should cover the different aspects of integration, including process integration, tooling integration, knowledge management, and participation in the structural elements (Boards, Process Forums and Working Groups). The integration requirements should be focused on the provision of seamless end-to-end services, not just on technical interactions. They provide the foundation for effective inter-provider collaboration. This means that the integration interactions should be designed before the contracts are written, at least in sufficient detail for the providers to understand what they are committing to. A simple requirement such as ‘The service provider shall integrate with the other providers’ is unlikely to be enough. One good approach is to derive the integration requirements from the detailed SIAM model as this will provide a framework for the governance, roles and tools that will be part of the environment in which all parties will work.
The contract with the service integrator
The service integrator has different responsibilities to the service provider, so by necessity the detail in a contract with an external service integrator will be different. One approach is to take the SIAM model and identify all activities that the service integrator is expected to do. The process model and the governance framework within the SIAM model should identify the accountabilities and responsibilities of the service integrator. These can then be used as inputs to the design of the service integrator contract, ensuring that all are covered. It is a good idea to check and balance these requirements against the service provider contracts. The aim is to ensure that all interactions between the service integrator and the providers are aligned with appropriate contractual responsibilities placed on the service provider and the service integrator.
The same principles apply if the service integrator is internal, using a documented agreement with them instead of a contract.
Getting the sweet-spot in the level of detail
One of the biggest challenges with a contract in a SIAM model is defining the appropriate level of detail in the requirements. If you go one way and stay at a high level, then the risk of misinterpretation and subsequent disputes increases. Going the other way and specifying very fine detail will clearly set out all of the requirements, but as the number of requirements increases then the contract runs the risk of becoming unwieldy to manage, and more likely to be subject to change. It can also mean there is an increased risk of omitting specific detail that later becomes apparent because the complexity within the contract overshadows important details. Including too much detail can also reduce the ability to innovate, as the provider rigidly follows exactly what the requirement says. It can also significantly increase the cost.
Take as an example the need for a provider to participate in an integrated change advisory board (ICAB). A high-level requirement might say ‘Take part in all structural elements’. That statement is very open to interpretation. Very detailed requirements might say
‘1. Review all requests for change within 48 hours of receipt.
2. Provide review comments back to the service integrator by 11am every Tuesday.
3. Attend every ICAB in the service integrators offices at 2pm every Thursday.
4. Contribute to discussions about every RFC discussed at the ICAB.
5. Review all ICAB minutes and report any errors to the service integrator within 24 hours’.
If the ICAB then moved to a Wednesday, or changed to a virtual meeting, then a contract change would be required. Clearly this is not appropriate. A possible ‘sweet spot’, balancing the needs for clarity and flexibility, could be ‘Take an active role in the structural elements for change management as defined by the service integrator’.
It is important to remember that the satisfaction of every requirement in a contract, both initially and ongoing, should be verified. Hence the workload for managing a contract will increase as the number of requirements increase. It is important to bear in mind that not all requirements will be able to be met at the time of implementation. For example, ‘Provide an annual summary of service level achievement’ clearly can’t be met until a year has passed!
Dealing with the unknown
There may be some requirements that you know will be needed in live operation, but for which you won’t know the full detail until after implementation. One example is defining the detail for how the toolsets of different providers will be integrated before you know who the providers are and what toolsets they use. Where this is the case, be honest and state it in the contract. Don’t fail to mention it, as this isn’t acting fairly. For example, ‘The service provider shall work with the service integrator to integrate their respective toolsets to enable transfer of data and information between the two parties for each of the processes defined in the SIAM process model (Appendix C). Integration shall be completed within 2 months after go-live’
Structuring the contracts
Each contract needs to reflect the chosen SIAM model, including the layers, structural elements, governance model, and process model. Adopting a generic structure for all contracts is a useful approach. The requirements that are the same across a number of service providers can then be structured into common schedules which can be re-used in individual contracts without change. Using this approach can:
- Speed up contract drafting
- Allow more time to be focused on designing any specifics
- Facilitate comparison between contracts
- Improve understanding of the contracts
- Facilitate addition and removal of specific services.
Contract structures for SIAM models typically use these components:
- A Master Services Agreement (MSA), sometimes referred to as a ‘head agreement’. This defines the overall contractual relationship between the customer organization and the service provider. The MSA can be common to the structure of all contracts in the SIAM ecosystem, or only used in the structure for the service integrator contract, with a reference to it in the service provider contracts
- A ‘common services schedule’,
which includes all of the terms and conditions that are the same for all
service providers. This schedule can then be re-used without change in each of
the individual service provider contracts. Requirements
of this type can include:
- Intellectual property rights
- Confidentiality and non-disclosure requirements
- Force-majeure statements
- Rights to assign or novate contracts
- Contract change & termination arrangements
- Payment terms
- Contractual dispute process
- A number of supporting schedules, each including the requirements for a particular topic.
Each schedule should define requirements that are not subject to regular change, and are the same for all services provided by that service provider. Supporting schedules can also be re-used across multiple service providers. Examples of supporting schedules include:
- The approach to be taken for
testing and deploying new and changed services
- Detailed security requirements
- The performance management approach
- Service management requirements
- Standards that should be followed.
Whilst it may seem logical to include some of these schedules in an MSA or common services schedule so that they are common to all providers, putting them into supporting schedules allows variation to meet the needs of particular service providers and geographies.
The design of each generic contract structure will depend on the specifics of each SIAM model, and hence cannot be finalized until the detailed SIAM model is agreed.
Takeaways
These tips should help you to be successful when designing contracts for a SIAM ecosystem:
- Contracts in SIAM models are different to traditional supply contracts
- Finalize the design of your detailed SIAM model before designing the contracts
- Wherever possible, use a generic contract structure with common, reusable schedules
- Accept that you won’t know all of the detail until after implementation, and tailor the contract requirements to accommodate this.
Finally, some of this advice might be quite overwhelming to anyone who has never designed contracts for SIAM models before. It is common to like the certainty that very specific and more traditional contracts bring. SIAM models need a different approach. Designing such contracts requires a shift in attitude, behaviour and culture to support the necessary flexibility and varying requirements driven by customer needs, continual improvement, and an evolving IT landscape.
Remember to take a look at the refreshed SIAM Professional BoK for more on this subject.
About the author
Kevin Holland is a founder member of the SIAM architect group and the Chief Examiner for the EXIN SIAM™ certification scheme. Kevin has worked in IT for 40 years in a range of roles including development, operations, management and service management, most recently in the UK public sector. He was instrumental in driving the development of SIAM thinking and its adoption through his work on the UK Government’s SIAM Blueprint and a series of whitepapers and presentations on the topic.
His eminence in IT service management led to him being made a Fellow of the British Computer Society. Outside of IT, Kevin is an accomplished musician and loves growing and cooking his own food.
