CHAPTER 3: SIAM ROADMAP STAGE 2: PLAN & BUILD

The Plan & Build stage is triggered formally on completion of the Discovery & Strategy stage, when the organization confirms its intention to proceed with a SIAM transition. There may be elements that start earlier, to enable stakeholders and the team to prepare for this stage. Depending on the timescales, strategy and approach of the organization, the roadmap might proceed in a linear manner or there may be stages and activities taking place in parallel.

The governance requirements and high-level framework defined in the Discovery & Strategy stage, provide the controlling ‘guardrails’ for the Plan & Build stage. They ensure the design of the SIAM model is aligned to business requirements and provides all the expected benefits, including the ability to add and remove service providers as needed. The stage objective is to create an adaptable, scalable model that is responsive to the inevitable changes within the business and service provider environments.

The design activities are often delivered in iterations, starting with an initial definition, becoming successively more detailed to complete the design for the SIAM model and create plans for transition during the Implement stage.

3.1 Design the detailed SIAM model

The SIAM model contains many elements, including:

•Service model and sourcing approach

•The proposed SIAM structure

•Process models (including interactions between service providers – see section 3.1.4 Process models)

•Governance model

•Detailed roles and responsibilities

•Performance management and reporting framework

•Collaboration model

•Tooling strategy

•Ongoing improvement framework

When designing the detailed SIAM model, four distinct architectural viewpoints must be considered:

1.The organization structure for the retained capabilities, any internal service integrator and internal service providers. This should include the formal positions and headcounts as they relate to each other and appear in the HR system illustrating the organizational hierarchy.

2.The process model, showing roles and responsibilities, interactions between parties, ownership and structural elements.

3.The service model, showing service groupings, sourcing strategy and the scope of services allocated to the various service providers.

4.The technology model, showing technologies that will be used to support the other three viewpoints, including toolsets.

All four architectural viewpoints will have their own associated roles and resources that need to be considered, mapped and intertwined. In some cases, these will be different perspectives of the same roles and resources.

Consulting organizations that specialize in SIAM designs can often provide blueprints in the form of SIAM reference architectures. These can expedite the design phase, allowing the customer organization to move more swiftly on to the Implement stage of the SIAM roadmap. However, the suitability of the reference architecture to the customer organization and strategic outcomes must be tested and not assumed. Specialist support can optimize the effort required for the entire SIAM roadmap, particularly the early stages.

3.1.1 Service model considerations

The service model shows the hierarchy of the proposed services, the service provider for each service element, interfaces with services provided by other service providers, and the service assets and interfaces from the customer organization. Additionally, it can show interactions and activities with external agencies that have a governance or legislative influence.

Careful design of this model is critical to success. Iterations will be issued for review and feedback during the design activities. The service model starts with an initial definition and becomes successively more detailed as each iteration is agreed.

3.1.1.1 Service groupings

Adopting a SIAM model will change services and service groupings. It is crucial to first define existing services, their boundaries, groupings and service providers, and assess their suitability for the SIAM model. The design of service groups needs careful consideration, as this will define the scope of services sought from the various service providers.

The service groupings will influence subsequent procurements, with factors including:

•Availability of service providers (internal or external)

•Commercial viability of contracts for external service providers

•Suitability and alignment with common practice

•Ability to substitute service providers if needed later

•Number, and nature, of interactions with other services, service elements and service providers

•Feasibility of (technical) specifications and levels of capability required

•Locality, time zones, languages, local wage levels, economic climate and other geographically specific considerations

If these factors are not considered, it is possible to construct an arrangement that is unattractive to the market. This is a common contributor to the failure of sourcing initiatives, as these will not attract the kind of service provider sought.

It can be challenging for the customer organization to change its focus from systems and technology to services as part of the SIAM transition. The existing service provider contracts might focus on technology elements, without a link to the big picture of end-to-end service. The service model design defines the services in scope, the service hierarchy and how the services are to be grouped for sourcing.

Services are categorized, with groups then assigned to specific service providers. The aim is to minimize interactions between different service providers by grouping together similar services to be provided by one service provider. Minimizing interactions makes it easier to adjust the SIAM model if required in the future, and to onboard and offboard service providers efficiently.

The analysis of the current services and service groupings carried out in the Discovery & Strategy stage (see section 2.5.5 Existing services and service groupings) can highlight which current service groupings are effective, and which are not. This provides useful input to future considerations.

To derive optimal service groupings, the following approach is suggested:

1.From the Discovery & Strategy stage, take the services that the customer organization wants to consume.

2.Map these to the existing services that are going to remain after transformation.

3.Identify any gaps.

4.From the market analysis undertaken during the previous stage, propose services to fill the gaps. Try to avoid customizing services, instead, using those that are readily available. Focus on services, not service providers, which are considered later.

5.Create a map of proposed services – including services consumed by the business, and underpinning or technical services.

6.Assess the service providers that could provide the services required.

7.Analyze the results and tentatively group services by service provider – avoiding putting too many with one service provider or allocating a service provider to something that they do not normally carry out. Doing so creates the risk that they will be unable to deliver it well or will need to subcontract it, adding cost and complexity.

8.Consider the interactions between service providers – minimize these as much as possible.

9.Revisit and reiterate from point five – until the ‘best fit’ is obtained.

The output of this activity is the creation of a high-level service model containing all services, grouped by service provider.

Most customer organizations are used to dealing with service providers that deliver systems, email, internet access, etc. A traditional method of managing these service providers entails specifying technical requirements, with the customer organization taking an interest in the build and playing a design authority role, either as lead or as a stakeholder.

Moving to a SIAM model requires the customer organization to focus on outcome-based services, for example, a cloud-based solution that fits its requirements but requires little technical or design input from it. This can cause some initial anxiety as the direct control the customer organization is used to is no longer needed (or recommended). Moving to a SIAM model can require the customer organization to develop different capabilities, focusing on governance and supplier management, instead of technical detail.

Moving to a SIAM model is not simply a move to a multi-service provider environment (which many customer organizations already have), but is a move to integrate and control that environment to better meet business needs. This is the challenge that the service integration layer is expressly created to manage. The key to managing services, as opposed to systems, is to ensure that all parties have a clear and documented understanding of the requirements and goals and where they fit into the end-to-end service.

This is where service level agreements (SLAs), critical success factors (CSFs) and key performance indicators (KPIs) become crucial in the definition of requirements and commitments to deliver them. The links between these documents are also crucial, ensuring that the end-to-end service is understood. Figure 11 shows the relationships between these elements.

Figure 11: Relationships between targets and performance documents

A customer organization no longer needs to act as design authority for the resilience of technical components or provide lifecycle management of the infrastructure. Instead, it needs to define required levels of availability, security, performance and utilization to the service providers that will then ensure these measures are met. The contracts (or agreement with an internal service provider) will outline the consequences of failure, such as service credits.

3.1.1.2 Developing the SIAM model

The specific form in which the SIAM model is defined will vary from organization to organization. The format itself is not important. What is important is that it is in a form that enables all stakeholders to understand fully:

•The SIAM model as a whole

•Their scope and context within it

The model should be both holistic and detailed, clearly defining all service elements, touch points, roles and responsibilities. At a high level, a simple service chain diagram (see figure 12) gives an example of a ‘helicopter’ view, which provides the context for each of the individual service provider’s services and the primary engagement paths between them.

Figure 12: Service chain diagram

At a more detailed level, a range of techniques can be used to help ensure that the SIAM model is fully defined and understood.

Figure 13: Dataflow Analysis View (DAV) Reproduced under licence from OBASHI Ltd

As well as a visual representation, the SIAM model should detail how each component interacts with others. The model should include a description of each component and information on how it fits into the framework. Additionally, there should be accompanying information describing the governance mechanisms in detail using the service model diagram as a reference. Diagrams explaining escalation mechanisms, escalation flows and escalation contact information are required.

Different audiences will require different data from the SIAM model, so it is important for each stakeholder to be able to view simple or complex data, depending on their requirements.

The business context must also be clear and related to the SIAM model, for example:

•Is the business heavily regulated?

•Are there governance requirements or legislation to consider?

3.1.1.3 SIAM transition approach considerations

There are some important considerations of the likely transition approach that can affect the design of the detailed SIAM model. These should be considered initially as part of the SIAM strategy within the context of the four stages of the SIAM roadmap (see section 2.6 Define the strategy).

It is important to consider the outline implementation plan for the SIAM model at this stage. The plan should consider the situation and requirements of the customer, as well as those of the other stakeholders (see section 3.3.3 Transition planning).

The considerations include:

•The customer organization’s appetite for risk

•Incumbent service providers’ presence, power and willingness to change

•Cultural factors for all stakeholders, such as attitude to change

•Sensitivity of the customer organization’s business to disruption to service levels

•Customer capabilities, including commercial, operational, service management, business change, project, service integration and service provider management

•Service and business volatility

•Ease of substitution of services

•Duration of any existing agreements, before the next break option arises

•Availability of resources to facilitate change, manage collaboration and onboard new service providers

Each of the considerations focuses on areas of risk to the business. Managing the transition from one service model to another, or from one service provider to another, involves risks to service performance and continuity. The customer organization needs to ask:

•What is our overall approach to the implementation of the change (where do we start, where next)?

•How fast are we able to move?

•Which stakeholders do we engage first, second, third … ?

•Which services do we involve and when?

•What are the milestones in delivery?

•How do we work with the outgoing incumbents during the period of transition?

•What resources are available?

•What resources are required?

•How can any gaps in resource be bridged?

Initial planning iterations are useful to eliminate unfeasible approaches for migrating to the desired SIAM model. The final plan is likely to combine elements from several scenarios. The customer organization should not be too quick to discount options as improbable, they may have good elements or help the team to think laterally.

3.1.2 Sourcing approach and the selected SIAM structure

All SIAM models will include a variety of service providers, some that are newly appointed and some with renegotiated contacts.

A successful SIAM model should provide the ability to manage change over time. There is likely to be a mix of sourcing options in the environment and these arrangements will change over time based on the evolving needs of the customer organization. This has many implications that need to be considered as part of the SIAM model, for example, in the ownership or licensing of intellectual property (IP), tooling and exit obligations.

Figure 14: SIAM ecosystem ‘draft’

SIAM models vary considerably, but they will share common attributes, including a mix of service providers, both internal and external. The operational/functional relationships (represented by the blue and green arrows in figure 14) should be supported in a robust SIAM model and include:

•Peer-to-peer relationships between service providers

•Service provider to service integrator

•Customer organization governance and management to service integrator

The contractual relationships (represented by the red arrows in Figure 14) include:

•Contracts with the various external service providers

•A contract or agreement with the service integrator (depending on whether it is internally or externally sourced)

In a SIAM model, the customer owns the contracts with all external providers. There is no concept of a ‘prime’ vendor, which has a contract with the customer and contracts directly with and manages other providers. Some providers may still employ subcontractors, but the provider remains fully responsible for their services and all obligations in their contract. Many contracts include clauses that prevent subcontracting without approval from the customer.

The purposes of contracts are twofold in a SIAM ecosystem:

1.Establish the contractual relationship and certainty that any traditional externally sourced contract should provide

2.Support the SIAM strategy through the relationships shown in figure 14

3.1.2.1 Sourcing the service integrator

The decision about how to source the service integrator is an important one.

The financial benefits of a service integrator may be difficult to measure, as integration is mostly non-transactional and deals with issues avoided as much as benefits realized (see section 1.6 SIAM structures).

Some organizations may not see the need to seek an external service integrator, and instead source the role internally. Where a customer organization has the right capabilities, this can be a good approach. If the customer organization does not have the right capabilities, it needs to create them. For some, this challenge is modest and quickly achievable. For others, it is much more difficult.

Because an internal service integrator does not have a legal contract with the customer organization, it can be more flexible and accommodating to change than an external service integrator. However, an internal service integrator will still potentially require extra budget and resources if its role changes significantly.

If a hybrid structure is adopted, the ‘split’ between the retained and externally sourced roles in the integration layer needs to be considered. This might be established as a hierarchical structure (customer staff over external service integrator staff) or a vertical one (side by side).

3.1.2.2 Planning the role of the service desk

The sourcing of the service desk will vary from SIAM model to SIAM model. The organization providing the service desk should be considered a service provider in the SIAM model, whether it is provided by the customer organization, the external service integrator or one or more service providers. It should be managed in the same way as all other service providers.

Although a service desk can be seen as just another service to be provided, it is worth considering in detail, owing to the role it plays in contributing to customer satisfaction, information sharing, support for integration activities and managing issues across SIAM layers and stakeholders.

The service desk is often seen as a good candidate for external sourcing because of factors including high staff turnover and high management overhead. Some organizations, however, prefer to source the service desk internally or use a hybrid approach. The customer organization must decide whether it sources the service desk internally or externally.

The approaches discussed in this section are:

•Service desk provision by the external service integrator

•Service desk provision by the customer organization

•Service desk provision by an external service provider

•Multiple service providers providing separate service desks

Within a SIAM model, the service desk acts as a ‘single source of truth’ for consumer satisfaction and provides important management information about service performance. If the service integrator is not providing the service desk, it must work very closely with it and use the service data it provides.

The service desk plays an important role in the day-to-day contact with the consumers of the service, providing crucial metrics around satisfaction, both quantitative and qualitative, for the service integrator. There is no best option for the service desk, but there are a range of advantages and disadvantages to consider.

Service desk provision by the customer organization

In this option, the customer organization retains the provision of the service desk function, usually alongside an internal service integrator. The rationale for the customer organization providing the service desk is usually related to a desire for control and the benefit of internal business knowledge, shared values and culture, or where it already has an established, mature service desk capability.

There may, however, be specific reasons for the customer organization to retain the service desk in-house, such as legal or regulatory requirements in, for example, the defense industry, where sensitive information is not allowed to leave the customer organization.

Advantages

•The ability for the customer organization to control/influence the service quality and delivery from the service desk directly.

•No confusion around ownership of intellectual property (IP).

•A perception from end users of ownership and end-user orientation.

•It may be possible to provide a ‘local touch’ as service desk staff can be located in customer organization offices, rather than in an offshore or service provider location.

•The business process knowledge of service desk staff may increase competence and allow better evaluation of the severity and urgency of issues.

•Ability to address a wider scope of queries, based on a wider knowledge of the business.

•No complex contractual structures.

•The potential for a higher degree of transparency about service performance, as there is no incentive for the service desk to hide poor performance figures.

•The internal service integrator and service desk being part of the same organization helps to standardize processes and toolsets, for example, for incidents or request records, enabling a 'single source of truth'.

•Efficient collaboration and cultural orientation between the service desk and internal service integrator functions.

Disadvantages

•Quality outcomes depend, to a high degree, on the process and tool maturity within the customer organization, rather than those of a specialized service desk provider.

•It may be difficult to find appropriately skilled resources within the local labor market.

•Career path and growth opportunities for service desk team members must be considered and managed.

•Risk of the service desk operating in a silo and not building relationships with service providers.

•Staff optimization based on volume trends (upscaling/downscaling) will be more difficult with internal resources. An external service desk provider may be able to scale more easily.

Service desk provision by the external service integrator

In this option, the external service integrator provides the service desk. The service integrator acts as a lead supplier, as through the service desk it also provides a service.

This structure can provide a good alignment between the service desk and the service integrator, and will typically be chosen when the organization acting as the external service integrator has additional and mature capability to provide the service desk. Where the external service integrator directly provides the service desk, the following advantages and disadvantages should be considered.

Advantages

•The ability for the service integrator to influence the service desk outcomes, which may positively influence the end-user experience.

•The service integrator and service desk being part of the same organization helps to standardize processes and toolsets, for example, for incidents or request records, enabling a ‘single source of truth’.

•Efficient collaboration and cultural orientation between the service desk and service integrator functions.

•The combined role may be more commercially attractive for an external service provider.

Disadvantages

•The service desk needs to be considered as another provider in the SIAM model. Integrating the service desk with the service integrator layer may compromise – or be perceived to compromise – impartiality in managing service desk performance.

•If the service desk performs badly, this could affect the reputation of the service integrator and compromise its ability to perform effectively and build relationships.

•The combination of the service integrator and the service desk, especially when captured in a single contract, can provide future challenges when intending to change one without the other.

Service desk provision by an external service provider

The service desk is considered a service like any other as part of a SIAM model. Service providers in this space may bring specific expertise, tooling, flexibility, agility and scaling that would otherwise be difficult to achieve.

Advantages

•Enables the customer organization to focus on its strategic direction and business objectives rather than day-to-day user based transactional and operations management.

•The service integrator and customer organization are separate from the service desk function and, therefore, can look at service provision from an independent perspective.

•Sourcing from a specialist service provider will often provide expertise and enhanced performance.

•A more economical contract may be negotiated based on the actual volumes and can incorporate penalties/discounts, etc.

•The service desk will be treated as any other service provider and form part of the collaborative, innovative culture.

Disadvantages

•There is no guarantee that the external service provider can assimilate business knowledge effectively, it will take time.

•The service may experience stages of good or bad performance when the service provider’s staff change.

•Service desk resources might be shared across multiple customers and some customers might be given higher priority.

•Security and intellectual property (IP) considerations need to be addressed.

Multiple service providers providing separate service desks

In this option, different service providers provide their own service desks and toolsets, and the service integrator provides a consolidated view. This is only an effective choice where it is clear to the consumers of the services which service desk to contact for support. For example, the payroll department can contact the service desk of the financial application provider directly.

Note that, often, different service providers have their own existing service desk. These service provider service desks can provide a second-level escalation point for the service desk supporting the users of the services within the SIAM model. Allowing the SIAM model’s consumers to access multiple service desks removes the single point of contact and can create confusion.

Advantages

•Improved knowledge management, as these service desks are within the service provider that delivers, manages or supports the specific service.

•Possibilities for better and faster support, as each service desk’s scope is limited, driving specialization in skillset.

•Better ability to respond to volume spikes or drifts, as they will only affect one service desk, not all service desks, if related to an issue with a particular service.

•Poor performance can be addressed very specifically, as it will only apply to one service desk.

Disadvantages

•Multiple service desks will increase the risks of different processes and toolsets being used for similar activities. The service integrator must facilitate end-to-end transparency across all the service desk providers.

•There can be higher reporting overheads because the data to be processed will have to be collated from several service desks.

•Reporting may be difficult or impossible if the various service desks use and report on irreconcilable metrics.

•Risk of inconsistent end-user experience (if one service desk is providing an excellent service while others may fall short … ).

•Potential for inefficiencies when consumers contact the wrong service desk, or ‘hop’ between service desks to find a solution. This will require cross-service provider escalations and, possibly, service integrator coordination.

•Confusion and/or frustration in users struggling to know which service desk to contact.

•Risk of ‘blame culture’, where different service desks ‘bounce’ incidents or requests to one another.

•Complexities and overheads involved in evaluating and processing customer satisfaction surveys across the multiple service desks.

3.1.3 The importance of contracts in SIAM

Creating contracts that are robust, usable and appropriate for use in a SIAM environment is critical. Contracts support an environment where there is a shared understanding of requirements, and clear accountabilities and responsibilities for both parties to the contract – the customer and the service provider (see section 2.3.13 Supplier and contract management).

SIAM requires contract structures that differ from non-SIAM agreements, which focus solely on the responsibilities of a single service provider. Contracts in SIAM models should try to link service provision across the full ecosystem, encouraging acceptance of, and adherence to, a common set of delivery rules and governance, with the common purpose of supporting the customer organization’s services and desired outcomes.

As well as outlining the services and service levels to be delivered by individual providers, including any external service integrator, the contracts must address integration. This includes areas such as tooling, process integration, knowledge management, collaboration and participation in the structural elements. Integration is the key distinction between a more traditional contract and a contract appropriate for a SIAM environment.

Addressing integration in contracts underpins and reinforces the ‘one team’ approach necessary for success in SIAM. It also provides a strong foundation for the service integrator, facilitating collaborative behaviors and helping to avoid a blame culture from the outset. Contracts that are designed for use in a SIAM ecosystem provide a necessary focus on end-to-end service delivery, regardless of which service providers are involved in service provision.

The customer organization needs to provide enough detail around acceptable ways of working, collaboration and integration activities within the contracts, while still allowing for individual service provider approaches. Constraining service provider activities can lead to the customer organization not benefiting from specific provider specialisms and creating contracts that inhibit the ability for service providers to perform effectively and efficiently.

Less established or less mature service providers may not have an established service portfolio or corresponding service delivery capabilities. This has the potential to influence the overall ecosystem capabilities negatively. Consequently, however, they may adapt to the required ways of working more easily.

There are also risks associated with mature service providers. When established service providers are selected, it is often with a high emphasis on promised cost savings. The cost savings are typically based on exploiting economies of scale and offshoring models, with staff being sourced in lower-cost countries. There is a risk that these staff are highly trained on the service provider’s existing processes, tools and established, specific ways of working, but not on the specifics required for the future customer’s requirements, desired outcomes and chosen SIAM model.

Education, skills and experience can constrain a potential service provider’s ability to adapt to a SIAM model and ways of working without compromising its own benefits through economies of scale. This may result in it not bidding for the work or taking the work without fully understanding the implications for itself. It is important for the customer to assess potential service provider’s capabilities before awarding a contract.

Some customer organizations engage external consultants to assist with contract design. These consultants must focus on value, not just simplification and cost optimization.

If appointed early in the SIAM roadmap, the service integrator can work with the customer organization to review existing service provider contracts, identifying duplications, gaps and any inconsistencies with the future SIAM model. This information can then be used to design new contracts that are tailored for the customer organization’s particular SIAM model.

The contracts must contain the right level of detail. It is important to review contracts against the SIAM model before sending them to potential providers. The nature of the roles in a SIAM ecosystem require close teamwork between contract experts working on the design and service integration experts, who are often focused on implementation. Contracts must not constrain, but enable. This is possible only by using the right expertise at the strategic and planning stages.

Investing in expertise at the enterprise architecture (EA) and solution architecture levels early within the Discovery & Strategy stage allows an effective foundation to be built for the SIAM model, including appropriate contracts.

If a service provider could also be acting as the service integrator, then impartiality is essential. Separation of concerns is an important principle, as is working openly with all chosen providers in establishing the overall solution.

Many contracts in traditional sourcing environments are designed to discourage future changes to responsibilities and activities because of the expected overhead of contractual, legal and commercial considerations. SIAM contracts need to allow for regular alignment and realignment to support continuous improvement within the SIAM model. Significant change in one contract, such as the introduction of a new service provider, should be reflected in the review of neighboring contracts.

3.1.3.1 Contract arrangements

In a SIAM environment, the customer should have signed contracts that align with the SIAM model in place with all external providers. Although this might seem obvious, it is not uncommon for organizations, even of a global size, to be using service providers with whom they have no formal agreement or where a formal agreement has expired.

Often, this happens away from head office, typically in geographic areas where the organization does not have a large presence with all the supporting infrastructure and functions, so staff resort to using local services. This may begin on an infrequent, informal basis but gradually dependency grows, with the lack of any formal agreement only being highlighted when service is interrupted, and the organization is adversely affected.

Contracts need to cover responsibilities throughout the whole contract lifecycle. All too often, contracts concentrate on the initial set up and operation of the service but contain very little about ongoing improvement or what happens at the end of the contract, whether that is the transfer of services to another provider or termination of the service. This can result in handover issues, disruption, delays, loss of knowledge, loss of intellectual property (IP) and, potentially, the loss of data.

An investigation into the competence of the developer showed grounds for the customer to sue. To avoid the cost, effort and the potential for reputational damage, the parties settled out of court and parted company. A formal contract would have provided a simpler and more cost-effective way to terminate the arrangement.

Within a contract, there should be a clear indication of how the contract will be managed, including:

•Escalation paths

•Procedures for agreeing contractual changes

•Extensions

•Handling disputes

•Exit plan

It is not good practice to rely on individual contract templates, of varying quality, from a wide range of different service providers, as these will often be geared towards protecting the service provider rather than the service consumer. Organizations should look to develop their own standard contract templates that can be tailored to the specific services required, but which contain standard governance controls, lifecycle considerations and terms and conditions, all thought out in advance and checked by the organization’s legal representatives.

The service integrator needs to be recognized as the customer’s agent, and this needs to be reflected in both service integrator (where externally sourced) and service provider contracts, using ‘right to manage’ clauses to give the service integrator a legal basis for its activities. Incorporating standard, aligned service performance measures in the contracts will also assist in the end-to-end performance management and reporting.

Some service providers, for example those offering commoditized cloud services, may mandate the use of their own standard contracts. If this is the case, it can still be a significant advantage for the customer organization and the service integrator if a large proportion of the contracts in place are in a relatively standardized format and content, tailored to support the SIAM model.

Within the contracts, some of the schedules in use may vary by type of service. For example, service levels for hosting are likely to differ from application development and support. There are often differences in contracts between certain types of provider – strategic, tactical, operational, commodity. What is sensible for a large strategic provider may be unnecessary for a small operational provider.

Other contractual considerations in a SIAM environment include:

•Contract length

•Contract change triggers

•Alignment of contract start/end dates. In a perfect world, all contract start and end dates in a SIAM model would align, but this is not usually possible, as it would also cause significant overhead and risk to replace all contracted service providers at once (see section 4.1.1 Big bang approach)

•Dependencies with other service providers’ contracts or internal agreements

•Data ownership and access

•Links to supporting schedules and enabling documents

•Offboarding and cancellation charges

In SIAM, contracts are often structured in order to minimize their differences. Requirements that are the same across a number of service providers can be structured into schedules. These can then be reused in individual contracts without change.

Although there will always be unique elements in contracts between the customer organization and each external service provider, many SIAM implementations use a generic contract structure that maximizes reuse of common schedules. Using this approach can:

•Speed up contract drafting, as common requirements can be drafted once and reused, and similar requirements can be copied from another contract and then edited if necessary

•Allow more time to be focused on understanding and drafting any unique requirements for a specific contract

•Facilitate comparison between contracts

•Improve understanding of the contracts

•Facilitate the addition and removal of specific services

•Make subsequent contract changes easier to achieve, by limiting the changes to specific parts of the structure

The design and application of a generic contract structure will depend on the specifics of each SIAM model.

Table 3 shows example options for the design and application of a generic contract structure, and the advantages and disadvantages of each.

Table 3: Advantages and Disadvantages of Contract Structures

Contract structure	Advantages	Disadvantages
Same structure for all contracts	•Maximizes reuse between contracts	•Can be a challenge for some service providers (for example, commodity service providers) to adopt the same structure •Requires careful design to avoid a situation where certain contract schedules are not relevant for particular service providers (for example, some service delivery requirements are not applicable for the service integrator)
Unique structure for the service integrator contract; same structure for all service provider contracts	•Removes the need to include service delivery related schedules in the service integrator contract •Maximizes reuse in service provider contracts	•Can be a challenge for some service providers (for example, commodity service providers) to adopt the same structure
Unique structure for the service integrator contract; more than one structure for the service provider contracts	•Removes the need to include service delivery related schedules in the service integrator contract •Allows structures to be tailored to the needs of different types of service provider (for example, commodity service providers)	•Requires careful design to maximize reuse and avoid duplication between structures •Alignment between service providers is challenging
Different structure for every contract	•Allows all service providers to have a structure tailored to their unique needs	•Limited ability to reuse schedules •Difficult to compare contracts •Extends drafting time

Typically, contract structures for SIAM 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 requirements that are the same for all service providers. This schedule is then reused without change in each of the individual service provider contracts. Requirements of this type can include:

oIntellectual property (IP) rights

oNon-disclosure requirements

oForce-majeure statements

oLiabilities and waivers

oRights to assign or novate contracts

oContract change and termination arrangements

oPayment terms

oContractual dispute process

•A number of supporting schedules, each including the requirements for a particular topic. Each schedule defines requirements that are not subject to regular change and is the same for all services provided by that service provider. Supporting schedules can also be reused across multiple service providers. Requirements in supporting schedules should not also be in the MSA or anywhere else in the contract. Examples of supporting schedules include:

oThe approach to be taken for testing and deploying new and changed services

oDetailed security requirements

oThe performance management approach

oService management requirements

oDisaster recovery requirements

oService desk requirements (where appropriate)

oTechnology refresh requirements

oStandards that should be followed

•Although it may seem logical to include some of these schedules in an MSA or common services schedule so that they are applicable to all suppliers, putting them into supporting schedules allows variation to meet the needs of particular service providers and geographies.

•One or more statements of work (SoWs). These contain requirements that are specific to the services provided, for example service levels, charges and hours of service. There can be a single SoW that includes all services from that service provider or a separate SoW for each service.

•A common document that describes the way all parties should interact, for example a collaboration agreement. This is sometimes included as a contractual appendix.

Figure 15 shows an example contract structure that has a unique structure for the service integrator, including an MSA, and a common structure for the two service providers, including a common services schedule (although service provider 2 has multiple SoWs).

Figure 15: Example of a generic contract structure

It is important to ensure that contracts are unambiguous and specific. If this is not the case, there is a high risk that unnecessary effort will be spent after implementation debating specific points to avoid service credits or additional costs (see section 3.1.3.9 Dispute management). One means of avoiding or mitigating such a risk is for the contracts to include definitions of specific terms, sometimes known as standard contract terms (SCTs).

A contract might not necessarily include details related to supporting items (for example, process definitions), instead including a reference to these. This can provide flexibility when maintaining the referenced items without having to renegotiate the contract. Note that these supporting items are still subject to change control from a contractual perspective.

3.1.3.2 Non-contractual arrangements

In SIAM models, contracts can be supplemented by non-contractual ‘ways of working’ documents. These are often referred to as operational level agreements OLAs and include guidelines and common ways of working that support effective integration and delivery across the ecosystem.

OLAs tend to be specific to a particular process (for example, incident management) or practice (such as tooling), and are often developed by the appropriate process forum or working group. The use of OLAs can underpin any formal collaboration requirements and help to create a culture where service providers work fairly and honestly with each other and with the service integrator.

Although the contents of OLAs are not themselves contractual obligations, it is important to define in the contracts the basis for developing and enforcing any OLAs. OLAs should always be formal agreements that are documented and controlled.

Traditionally, OLAs are only used for agreements with internal service providers. In SIAM, OLAs can also be used with external service providers. Although some OLAs are often common across all service providers, they can also be used with a smaller subset to define how two or more service providers work together. Hence OLAs can exist between:

•The service integrator and all service providers

•The service integrator and specific service providers

•Individual service providers

OLAs must be carefully designed so that they do not conflict or overlap with contractual requirements. They can include operating level measurements (OLMs). These measurements are defined by deconstructing service level commitments, deliverables and interactions that involve more than one party and set targets for each.

OLAs can be brought together into a single operational level framework (OLF), which is managed and controlled by the service integrator and shared with all service providers. The OLF can also contain other information that describes how the SIAM model operates in practice, including a summary of service levels and common requirements. This can help to address issues where competing service providers are unwilling to share the full details of their contracts with other service providers.

The service integrator is accountable for coordinating the overall development, communication and management of OLAs, OLMs and the OLF.

OLAs can be used as a way to test that changes to ways of working achieve positive outcomes before committing to contract amendments. This can avoid the expense of making contract changes that subsequently do not provide any benefit after implementation.

OLAs, OLMs and any associated operational level framework should be defined or changed when the need is identified, ideally through workshops attended by all parties. This can be during the Plan & Build stage, or it may be during the Implementation, or Run & Improve stages.

3.1.3.3 Collaboration and contracts

Irrespective of any collaboration agreements, contracts in a SIAM ecosystem should include requirements for collaborative working. The aspects that need to be considered can be split into three categories:

1.Contractual

The contractual category includes explicit requirements that are mandated in a contract:

oPrinciples for collaboration and cooperation

oRole of the service integrator

oAssurance responsibilities

oDelegated authorities

oRight to manage/managing agent

oApproach to end-to-end service levels

oDefinition of critical deliverables

oHow culpability is determined

oApproach to shared risk/reward

2.Operational

The operational category includes items where the detail can be subsequently developed into OLAs and OLMs by process forums and working groups:

oResponsibilities for development of OLAs and OLMs

oCompliance with OLAs and OLMs

oSharing of the OLF

oInter-party dependencies

oInter-party responsibilities

3.Process

Processes are defined in the process model. The contracts should include obligations to comply with the process model (see section 3.1.4 Process models):

oOrganization and governance

oIssue resolution

oCommon toolsets

oCommon policies and procedures

Some service providers may resist accepting obligations that they perceive as being overly dependent upon others for delivery. It is very difficult to predict every possible situation when defining contracts. As well as careful design of the service groups, building collaboration requirements into contracts is one way to address these challenges.

3.1.3.4 Service integrator contract

The service integrator contract will differ from a service provider contract in a number of ways, including:

•The contract will typically have clauses that manage conflicts of interest and allow the service integrator to act as an agent on behalf of the customer organization

•The targets will focus on end-to-end performance and not just the performance of the organization acting as the service integrator

•There will be targets related to collaboration and improvement across the SIAM ecosystem

The detailed requirements in the service integrator contract should be in alignment with those in the service provider contracts, in particular, governance. There could be challenges if the service integrator has a specific governance requirement over the service providers and there is no corresponding commitment in the service provider contracts. The customer organization’s expectations of the service integrator must also be reflected in the service provider contract.

The service integrator’s contract should also be aligned with the particular SIAM model. Issues can arise if a standard contract from an external service integrator is accepted without a full review against what is required to support the efficient operation of the SIAM model.

A service integrator contract can use the components of the generic structure for SIAM described in the previous section. The schedules and SoWs would describe the specific services that the service integrator provides. If the service integrator is provided internally, an agreement structured in the same way will fulfil the function of the service integrator contract.

In a Lead Supplier structure, there can either be a single contract with one MSA, with separate schedules and SoWs for the service integrator and service provider activities; or one contract for the service integrator activities and a separate contract for the service provider activities, each with a common MSA. Having only one contract in a Lead Supplier structure can create challenges if termination is required for one of the activities that the service provider performs but not the other.

3.1.3.5 Service provider contracts

Service provider contracts typically have a similar structure to the generic structure described previously, including a common services schedule, supporting schedules, SoWs and a common collaboration agreement.

Any obligations and schedules that are the same for several service providers can be included in the contract structure using a common services schedule. SoWs can then be used to define the specific services and targets, with supporting schedules defining other unique requirements. This approach is easy to manage and change, transparent and fair. In some SIAM models the structure of contracts will vary according to whether the service provider is strategic, tactical, operational or commodity.

As well as specifying the specific requirements, a service provider contract in a SIAM ecosystem should:

•Contain the obligations information that aligns the service provider to the collaboration and end-to end process requirements. These are usually included in a common services schedule.

•Recognize the specific role of the service integrator as the agent of the customer, whether the service integrator is internally or externally sourced.

There are a variety of mechanisms that can be used to support service integration. The service integrator is responsible for maintaining standards, including any tooling or processes, with which the service providers should comply. The details of these are not in themselves part of the contract but reference can be made to them in the contract supporting their subsequent development and use (see section 3.1.2.3 on Non-contractual arrangements).

The contract must ensure that each service element is assigned to a specific service provider (see sections 2.5.5 Existing services and service groupings and 3.1.1.1 Service groupings). Where the same type of service is provided by two service providers, for example, where hosting is provided by two organizations to support service continuity, these must be treated as separate and distinct service elements within the contracts. This ensures that:

•Only one service provider (internal or external) is accountable for each service element

•All service elements have an assigned service provider and are included in the sourcing model

This is known as mutually exclusive; collectively exhaustive (MECE). Any form of assignment that does not satisfy these MECE conditions is likely to cause issues later on. Service providers tend to be very happy to be paid for work that others perform but are less happy to be held accountable for performance where others have a material influence on what happens.

Even if a service provider provides a number of different services in a service group, the individual services should be listed separately in the contract schedules and SoWs. This supports future cancellation or transfer of an individual service, provided that the contract allows for this. The recommended approach to the construction of a service provider contract is:

•Determine the initial, outline statements of work for the services to be provided.

•Determine the interfaces, interactions and dependencies between the service provider, other service providers, the service integrator and the customer, adding obligations around these to the service provider schedules as necessary.

•Ensure that the targets, processes, governance and other unifying mechanisms apply and are included in the schedules (using references where appropriate).

•Ensure that requirements to take part in collaboration are included, such as:

oParticipation in the structural elements (boards, process forums and working groups)

oReview of another service provider’s changes/release plans when required

•Include a mechanism for ‘excusing causes’, where a service level failure was because of another party.

Requirements will change over time. Targets and contracts cannot cover, nor anticipate, all future events. Each contract needs to include the ability to extend or change services and obligations to meet changing requirements and scenarios.

A contractual key concept is service accountability, where a service provider is commercially and legally accountable for compliance with all contractual obligations, including service level achievements. This is irrespective of whether it really understands its obligations or uses subcontractors to deliver its services. This needs to be defined, documented and understood at the outset of any contract. If not stated clearly, this could leave the customer organization without recourse when the service provider is not delivering the agreed outcomes.

Every contract negotiation should begin with a baseline set of expectations on both sides, to address:

•Scope

•Quality

•Services

•Cost

•Maintainability

•Governance

•Reporting

•Regulatory

•Personnel

The baseline should be sufficiently specific to begin negotiation and allow for decision making to commence, but fluid enough that terms can be reached on a variety of scenarios either at the start of the contract or over time. The baseline should be considered as the minimum requirements.

In a traditional sourcing contract, the emphasis in contractual definition typically focuses on:

•Financial model, including charges and service credits

•Targets for services delivered

•Scope of services provided

•Transition and transformation

•Liabilities, waivers, termination, breach and dispute resolution

•Further standard schedules including governance, contract change, exit and others

In a SIAM environment, these concerns should be augmented by:

•Coordination and collaboration mechanisms

•End-to-end service performance and enhancements targets

3.1.3.6 Service credits

It is important to retain a perspective on how service levels affect a service provider’s priorities under the contract, and the consequences of non-performance (often referred to as ‘service credits’). These questions should be considered.

•Damages for breach of contract are meant to put the innocent party (in this case the customer organization) in the same position as if the contract were properly performed. If a service credit does not fully compensate the customer, what is the advantage of a service credit over a claim for damages?

•Most contracts can be terminated for 'material breach', for example, a breach that has a serious or significant effect. If service credits provide remedies for certain types of breach, is it to be implied that those breaches are not material?

•Are service credits the sole remedy for certain breaches? Within a SIAM model it is far better to allow for the requirement for an offending provider to undertake a service improvement or perhaps some ‘value add’ and non-chargeable activity instead. This improves overall performance rather than simply restricting the profit of the service provider.

•Does the service credit regime lead to an implication that the customer is prepared to accept a certain amount of non-performance? Are service credits driving the desired behavior from service providers, or is it more cost effective for them to pay for poor performance rather than correct it?

•Would it be better to pay an incentive for good performance rather than a 'penalty' or adjustment for failure or partial failure?

•What is the consequence of a service provider’s failure to comply with the service credit regime itself (for example, a failure of reporting, delay or invoicing irregularities)?

•What remedies can the customer apply if a service provider fails to meet an obligation that is not associated with service credits in the contract?

One way to align the service provider’s performance to the interests of the customer is for the service level objectives and targets to directly support the customer's business objectives and goals. There are many ways in which service credits can be calculated, such as:

•Percentage rebates from the service charges for each percentage point that the service provision falls below the service level target.

•The use of service credit 'points' across a range of service level measures, which are then converted into service credits based on a formula over an agreed measurement period, usually on a monthly basis.

Service level and service credit regimes should incentivize performance under the contract. Unless the service level and service credit regimes are aligned with the objectives of the contract, there is a risk that the mechanisms can become a monthly administrative task, with relatively trivial amounts of money at stake. In these circumstances, service levels and service credits simply become a contract overhead with no real benefit to either party.

Properly constructed service level and service credit regimes can provide both early warning signs of problems in service delivery and financial incentives to rectify poor performance. To be effective, service level and service credit regimes need careful drafting, analysis of the circumstances in which the regimes will be applied and a good understanding of the legal/contractual environment in which they operate. These regimes deserve rather more attention than they are frequently given in the negotiation and drafting of contracts.

Legal status of service credits

When drafting contracts during the Plan & Build stage, country-specific guidance must be sought. It is often assumed that as service credits provide a pre-specified financial remedy in the event of poor performance, they are a form of liquidated damages. If so, in order for the service credits to be enforceable by the customer, they must not exceed a reasonable pre-estimate of the customer's likely losses in the event of poor performance. This can be quite difficult to establish, as there may be, in practice, relatively little financial impact on a customer if the service level target is missed by only a small margin.

An alternative approach that gives greater flexibility over the level of the service credits that can be levied is to make clear that the service level and service credit regime is not a form of liquidated damages, but is simply a mechanism that specifies that the customer will pay a defined service charge for a different level of performance by the service provider.

On this basis, the customer and the service provider have the freedom to enter into a contract for a varying service charge depending on the service levels that are achieved. This approach has the benefit that the level of the service credits is not constrained by a reasonable pre-estimate of the customer's likely losses if the service levels are not achieved. Although it is consistent with the preservation of the customer's common law remedies, the major drawback is that as long as the service provider's performance remains within the range defined by the service level and service credit regime, there may not be a breach of contract.

Consider the situation where there is a continually poor level of performance by the service provider, but there is no mechanism in the contract to deal with this. In these circumstances, it will be difficult for a customer to assert that a 'material breach' has occurred that would entitle the customer to terminate the contract.

Another approach is for the parties to agree a termination threshold based on the level of service credits that accrue over a particular period, to fit together with a right of termination if there are persistent defaults. In practice, however, it is not easy to decide upon an appropriate level for the termination threshold, and service providers will often seek to impose thresholds that allow latitude for failure.

An approach used for positive means is for the service provider to spend the value of the notional service credits on service improvement activities for the customer.

Capped service credits

Service credits are frequently 'capped' at an overall percentage of the monthly or annual service charges. In larger or long-term contracts, it is sometimes inferred that the service credits could remove the service provider's profit. However, given the focus of a SIAM ecosystem, working on this basis is likely to be counterproductive, especially if it causes the service provider to operate at a loss, as this is likely to lead to poor relationships and less collaboration.

A 'capped' service credit may appear to be advantageous to the service provider, as it has an almost guaranteed revenue stream despite its actual level of performance. However, if the contract also has a common law clause allowing the customer to recover its actual losses in the event of the level of performance falling below the service level and service credit regime, then the customer's position in these circumstances can be more advantageous than if there were an uncapped service credit mechanism.

Towards the end of a contract, it may be cheaper for a service provider to repeatedly receive service credits rather than invest to prevent them, for example, if its technology infrastructure is at end of life. The customer organization should seek to avoid such ‘gaming’ behavior by building end-of-life clauses into the contracts.

3.1.3.7 Incentives

The aim of designing service payment models is to reward service providers fairly for effort expended and to align interests to the greatest possible joint benefit. Most simple models suffer drawbacks, for example, the payment of a service desk on the number of incident calls logged can motivate a service provider to maximize incident record numbers.

It is often desirable to design a model that first provides fair recompense, and then overlay a second level that aligns incentives. This is an inexact science and there is no one right way to do things. Take care to avoid overcomplicated models that may become too complex to implement and administer. Perfection is of little use when it is impossible to reconcile a monthly invoice to actual activity and performance.

Ill-judged incentive schemes can quickly promote perverse behavior. There is a managerial cliché that suggests that if you wish something to be taken seriously, measure and reward upon it, indeed, this works. Just be careful what is measured. Many organizations will make mistakes and suffer consequences to service quality. Construct something with huge complexity and there is more room for argument. The most probable outcome in this case is confusion followed by inertia.

The general guidance is to be moderate in the application of incentives. Try something and, if it works, consider a modest extension. Collaborate when setting targets, allow service providers to know what is important and what the customer organization is trying to achieve.

In the context of the design of a SIAM model, a subject that frequently occurs is that of incentivizing cooperation and collaboration. Given the criticality of these behaviors, it is natural and wise to seek a variety of leading and lagging indicators and to attach value to these. The chief lagging indicator (measure of outcome) is commonly ‘end-to-end service availability’ or ‘major incident recovery time’ (see section 3.1.8.1 Coordination mechanisms).

There can be opposition from service providers if excessive weight is given to incentives where an individual service provider’s reward is dependent on the behavior of others. The appropriate response is not to discard the mechanism but to apply it modestly so that it remains an incentive to exhibit the desired behavior but does not form a core component of the service provider’s base service payment.

Incentives should look beyond payment alone. It helps greatly to know and consider how the other party’s reputation is managed within its own organization. If the customer organization or service integrator is generally cooperative and helpful, the impact is all the greater when behavior or performance means that a reprimand is sharply administered.

Ensure that there is a sensible mechanism in the contract to deal with non-achievement of a requirement. Service levels and credits are easy, but what happens if a service provider repeatedly fails to provide a service report? Unless there is a specific mechanism, all the service integrator can do is treat it as a material breach of contract and advise the customer organization to terminate the service provider, which is not necessarily the ideal way to manage the situation.

3.1.3.8 Intellectual property

Intellectual property (IP) is a commonly misunderstood area with the capacity for unpleasant surprises and dispute. Customers frequently assume that they have the right to access and use everything even vaguely connected with their service. However, in many countries, the legal rights to artefacts (for example, a design or a process) rest by default with the creator (or author). In a SIAM model, the creator is often another organization.

Outsourcing contracts commonly make provision for software licencing assignment, but do not always address areas including process, policy, design, operating methods, scripts, application maintenance tooling, knowledge articles, recovery instructions, operating schedules and the like, all of which are required to transfer a service to a different service provider. If the exit schedule and IP provisions within the outgoing service provider’s agreement are inadequate, this can create some challenges during the transition (such as unwillingness to transfer or additional charges).

What a customer organization needs is the right to use IP and associated artefacts, where particular to its service, including the right to make this available to an incoming service provider. This can be included in the contracts with external organizations.

If a customer leaks a service provider’s IP to another provider, it is a violation of trust and may expose the customer organization to a claim for damages.

3.1.3.9 Dispute management

There must be defined procedures for managing disputes between the different parties involved within the SIAM ecosystem. Disputes may occur between the customer organization and one of the other parties, between the service integrator and a service provider, or between different service providers. Whatever the case, there needs to be a defined and agreed procedure that aims to resolve the dispute as amicably as possible, but allows escalation where necessary to achieve resolution.

Settling a dispute by legal means will ideally be a last resort, particularly in a SIAM model where significant focus should be given to developing a culture of partnership and collaboration. Without defined procedures for handling disputes, there will be a tendency for minor disagreements to either linger without resolution, gradually creating increased bad feeling and preventing true partnership, or for the disagreements to escalate unnecessarily resulting in legal action that could have been avoided.

Contracts need to ensure that:

•Dispute management procedures are defined, documented and agreed

•Roles and responsibilities regarding dispute management are clearly defined and allocated

•Compliance with defined dispute management procedures is made part of service provider contracts

•Dispute management procedures actively seek to find amicable solutions that are fair to all parties

•There are clear mechanisms for triggering dispute management

•Disputes are recorded, owned and tracked through to resolution

•Legal measures are taken only as a last resort

3.1.3.10 End of contract

When the need arises, notice of termination of a service provider will be formally issued some time in advance, in accordance with contractually defined procedures. It is important to get this right and good legal advice is essential, particularly where the situation is contentious. The final closure of the service should be documented to ensure that there is minimal scope for later dispute. The closure should address:

•Stranded cost (see below)

•Settlement of debt

•External party obligation and agreement transfer

•Staff

•Assets

•Agreeing the point at which the obligations cease

•Inflight projects

•Access, permissions

•The disposal of confidential information

Avoid a ‘zombie contract’ in which most obligations to provide services cease but some remain. Some, such as enduring obligations to maintain confidence, should be maintained. Much beyond this should be avoided.

3.1.3.11 Exit services schedule

It is common practice for service provider contracts, including any external service integrator, to contain an exit services schedule that prepares for the eventuality of service exit.

As this schedule is created before the first service has been delivered, it may not be fully complete where details are not known. Without robust exit plans, it can be extremely difficult for a subsequent incoming service provider to pick up the service with the information available, so the schedule should be as complete as possible and maintained as changes occur.

3.1.4 Process models

In a SIAM model, the execution of most processes will involve multiple service providers. Each service provider might carry out individual steps in a different way, but as part of an overall integrated process model (see section 2.7.2.3 Managing process outcomes, not activities).

A process model shows process and service relationship interactions with the customer organization, the service integrator and service provider teams. A continual improvement mechanism should be built into the model. A process model could use an available industry framework, such as the ITIL Continual Service Improvement (CSI), Business Process Improvement (BPI) or other relevant approaches.

Process models are important SIAM artefacts. Individual processes and work instructions are likely to remain within the domain of the individual service providers. The process model for each process should describe:

•Purpose and outcomes

•High-level activities

•Inputs, outputs, interactions and dependencies with other processes

•Inputs, outputs and interactions between the different parties (for example, between the service providers and the service integrator)

•Controls

•Measures

•Supporting policies and templates

Techniques such as swimlane models, RACI matrices and process mapping are commonly used and are helpful for establishing and communicating process models. The process models will continue to evolve and improve as further activities are undertaken during the Plan & Build stage, and then once live in the Run & Improve stage.

Techniques such as process modeling can be used to explain the required activities more simply. Process modeling is the analytical illustration or representation of an organization’s activity or set of activities intended to support the achievement of specific goals or outcomes.

In the Discovery & Strategy stage, any existing processes are mapped to create a baseline for process improvements and integration (see section 2.5.4 Current organizational capability). Within the Plan & Build stage, process modeling allows the design of new or ‘to-be’ processes to address any gaps.

3.1.4.1 Integrated process models

Within a SIAM model, process execution is likely to involve multiple stakeholders. Despite this, it is not necessary for all service providers to use the same process documents or tools. To preserve the economic specialism and expertise of individual service providers, the service integrator needs to provide the appropriate inputs and define the expected outputs and outcomes. Each service provider might carry out individual steps in a different way, but as part of an overall integrated process model with defined interactions, rules and controls.

ISO 9001:2015 (for quality management systems) expects organizations to adopt a process approach that supports the management and control of processes, the interactions between processes, and the inputs and outputs that tie these processes together. This is the kind of approach that is required within a SIAM model, and the service integrator is responsible for managing the processes and process interactions as a coherent whole based on the agreed governance and quality management in place.

Outputs are the result of a process. Outputs include not only services, software, hardware and processed materials, but also decisions, directions, instructions, plans, policies, proposals, solutions, expectations, regulations, requirements, recommendations, complaints, comments, measurements and reports.

The output of an upstream process often becomes the input for a downstream process. The service integrator should define the controls that enable process outcomes. Where possible, interactions should be automated to provide consistency and reduce manual activity.

Within a SIAM model, multiple service providers could undertake multiple process activities, leading to multiple possible input-output relationships that tie these processes together. To manage this complexity, it is suggested that processes are visualized one at a time using a single flowchart or a single page, mapping the interactions between the stakeholders for that process. This will allow the most important input-output relationships to be specified without getting distracted by complexity and detail. Figure 16 shows, in general terms, how this can be achieved.

Figure 16: Process flowchart

The center box in Figure 16 identifies the process being described, receiving instructions from upstream processes and providing inputs to downstream processes. Arrows represent inputs and outputs, as described by the associated text.

This type of process map allows a high-level view of the stakeholders involved within the process interaction. Further, more detailed process flows may be required. These can be adopted and adapted from the service management framework of choice. For example, service providers using frameworks such as ITIL or conforming to standards such as ISO/IEC 20000, will be familiar with terms such as policy, process, procedure and work instruction. Within a SIAM model, policy and process models are defined and mandated as part of the overall governance framework, and are common to all, where possible. Procedures and work instructions are proprietary to service providers. The service integrator should focus on outcomes, rather than forcing service providers to work in a particular way.

The service integrator will set the minimum standard for documented information. However, it is good practice to allow individual service providers to:

•Provide and maintain process documentation to the extent necessary to support the operation of processes

•Retain documented information to the extent necessary to be confident that processes are being carried out as planned

Service providers should share documentation that shows the interactions for each process between the parties with the service integrator (and vice versa), and with other service providers.

This approach provides for some flexibility. It is good practice for the service integrator to use flowcharts to give other participants within a process a view of the big picture. It allows the individual service providers to develop more detailed procedures to show how the process activities should be carried out, and at which point they will be required to contribute. Smaller, less mature service providers may benefit from a more prescriptive mandate around process flow from the service integrator. Conversely, it is unlikely that a large cloud service provider would accept a prescriptive process flow or mandated toolset as part of its obligations.

3.1.4.2 Managing process outcomes and integrating processes

No process exists or can function in isolation. It is essential to clearly document and ensure understanding of the required inputs, outputs, interactions and dependencies of each of the cross-provider processes. The service integrator should also communicate appropriate outputs for certain processes, for example, demand forecasts for the capacity management process.

It is not necessary for the service integrator or service providers to understand the minutia of each other’s process. Each party, however, needs to understand the expectations of each interaction in terms of response time, data requirements, communication paths, inputs expected and outputs to be delivered. The service integrator needs to be able to provide appropriate inputs, receive agreed outputs and provide a feed into continual service improvement activities.

Pay particular attention to handovers between parties. For example, does one service provider assume that the other will provide data that the other does not think is an output? Or, does the provider of the data require confirmation that it has been received and understood?

Figure 17: House level change

Figure 18: Street level change

3.1.4.3 Operations manual

The operations manual (sometimes referred to as a run book) is typically created to provide a summary of the contract, service, deliverables and obligations in layman’s terms, and to support an understanding of process activities and objectives.

The operations manual communicates how individual service providers will engage with others and with the service integrator. It is a useful tool for developing and documenting an understanding of the goals and objectives of the customer organization, and how those goals and objectives cascade down to relevant service providers. It outlines the policies, procedures and service levels required, and how processes interact between stakeholders. In terms of output content, format and timescales (for example, operational level agreements (OLAs)), the operations manual represents guidance only and is not intended to create any legally binding duties or obligations.

3.1.5 Governance model

The Discovery & Strategy stage will provide guidance regarding the defined systems of control (see section 2.3 Establish a SIAM governance framework). In the Plan & Build stage, SIAM governance focuses on three key aspects:

1.Ensuring alignment between the SIAM strategy and the current and future needs of the customer organization

2.Ensuring that the SIAM strategy and SIAM model are planned and implemented successfully

3.Ensuring that the implemented SIAM model can be managed and operated in a controlled and collaborative manner, being both efficient and effective

The governance model should be designed based on the governance framework, roles and responsibilities. It includes scope, accountabilities, responsibilities, meeting formats and frequencies, inputs, outputs, hierarchy, terms of reference and related policies in force within the SIAM model. For each governance board, this model should include:

•Scope

•Accountabilities

•Responsibilities

•Attendees, including chair and secretariat

•Meeting formats

•Meeting frequencies

•Inputs (and who is responsible for them)

•Outputs (including reports)

•Hierarchy

•Terms of reference

•Related policies

The challenge when designing a SIAM model, is taking the complex governance structures and ensuring that these are enabled through Plan & Build and into the subsequent roadmap stages. The rules, relationships, policies, systems and processes that define authority levels within each organization must be defined, clearly stated, exercised and maintained.

The governance framework provides the guardrails that control Plan & Build activities and outcomes, helping to drive enhanced organizational performance while at the same time aiding conformity with business requirements (for example, the customer organization’s constitution, policies, controls and procedures, as well as with applicable external regulations and laws).

To realize the full value of implementing a structured governance model as part of the SIAM model, these considerations are important:

•Measure performance at a level appropriate to model maturity

•Align service provision to business objectives

•Take an Agile approach – start small and develop through iterations

•Create a tooling strategy to provide a ‘single source of truth’ for proper governance and reporting

Compliance management and audits

Within the Plan & Build stage, the roles and responsibilities of the service integrator for compliance management and audits must be clearly outlined.

Typically, these include:

•Record keeping (as an ongoing activity and in preparation for external audits)

•Verification of service provider records

•Ensuring adherence to all compliance norms

•Ensuring compliance parameters are followed during regular change management

•Ownership and accountability of all service providers meeting compliance requirements

•Ownership and accountability of maintaining compliance within the service integration layer

•Tracking and providing regular compliance reports with clear actions to address any potential/identified issues

•Ownership of performing and completing root cause analysis on any identified compliance issues

•Clear understanding of all regulatory/compliance requirements as well as all audit parameters

•Implementation and oversight of operational systems to ensure ongoing compliance adherence

•Ensuring all systems and processes conform to critical requirements, such as segregation of duties

•Ensuring that SIAM processes and systems follow the habit of separating through an ‘ethical wall’, where there are clear guidelines on the sharing of information pertaining to each service provider with other service providers

•Monitoring alignment with corporate governance requirements, for example, sustainability, visas, etc.

Audit schedules should be defined that plan the approach to assurance. These should focus on assuring delivery in line with compliance and quality requirements. They should also focus on areas with potentially high impact for non-compliance or poor performance. Audits can be undertaken either horizontally, for example, across a SIAM layer; vertically, by functions or processes; or organizationally, such as the service integrator or a service provider.

Audit schedules typically include information:

•Identifying the scope of audits over a timeline, typically a 12-month period, based on business requirements

•Detailing the processes or functions to be audited and assigned auditors

•Identifying the timeline planned to complete the audits

•Scheduling the management meetings following an audit to review findings

3.1.6 Detailed roles and responsibilities

In the Discovery & Strategy stage, the key principles and policies for roles and responsibilities are created (see section 2.4 Define principles and policies for roles and responsibilities). These should include the detailed design and allocation of roles and responsibilities for:

•Process models

•Practices

•Governance boards

•Process forums

•Working groups

•Organizational structures and locations for any retained capabilities

This work may highlight a need to review earlier design decisions.

Roles and responsibilities can be further developed or evolve in the Run & Improve stage, but the details must be confirmed in the Plan & Build stage before any service integrator or service providers can be appointed. There are three aspects about which every member of the SIAM ecosystem must be clear:

•The function or role to which it reports

•Its responsibilities and corresponding expectations

•The level of authority it requires to make decisions, and its level of empowerment to act

If the organization acting as the service integrator also takes on a service provider role (as in the Lead Supplier structure), the management structures and personnel acting within the two elements need to be distinct (see section 2.3.9 Segregation of duties). Otherwise, the impartiality of the service integrator can be questioned, with the perception that its ‘own’ service provider is being treated more or less favorably.

It is highly advantageous, however not always possible, for internal teams (service providers) to be treated in the same way as the external service providers within the SIAM model. For example, by using an operational level agreement (OLA) to map obligations of and interactions with these teams. This makes it easier for the service integrator to manage across all service providers, and avoids any concerns relating to internal service providers getting preferential treatment by the service integrator or the retained capabilities. If this is not possible, the impact of treating them differently needs to be understood and considered in the SIAM model.

Some (external) service providers may maintain a direct relationship with a part of the customer organization outside of the service integrator (for example, a payroll application service provider providing services to the finance department). As these service providers are still a part of the SIAM model, they should also be managed by the service integrator like any other service provider. If these direct relations need to persist, the service integrator may need to carefully consider how to create an inclusive forum where they can still manage the end-to-end delivery.

Capability framework and skills maps

The nature of a SIAM model requires people to demonstrate or develop very specific skills. With the complexity of the various cross-functional and cross-organizational teams working within the ecosystem, soft skills such as negotiation and influencing are important.

For example, it is essential for staff working within a 24/7, global SIAM model to develop cross-cultural competencies as they hand over instances such as incidents, changes and service requests across countries and time zones. Similarly, collaboration skills (such as communication, negotiation and mediation) may be of specific importance for certain roles in a SIAM model.

A capability framework provides a set of principles that clearly outline the expected behavior and capabilities required of staff to achieve performance. Based on this, each service provider, including the service integrator, will need to maintain a framework and systems for assessing the effectiveness of its people.

A skills map sets out all the main employability skills in a way that shows their relationships to each other. The innermost oval has primary or fundamental skills, the middle circles contain intermediate skills and the outer circles very specific skills. For example, communicating can be divided into speaking and writing, and spoken communication can be further broken down into presenting, listening and telephone skills (see figure 19).

Figure 19: Communication skills map

Having identified the levels of capability and capacity service providers need to deliver their services, the service providers will need to consider the skills they have against what they need. This will identify gaps evident by not having the right level of capability available at the right time.

3.1.7 Performance management and reporting framework

The performance management and reporting framework should provide valuable information to all stakeholders. It should be regularly reviewed and include metrics to provide information on a number of key areas, including:

•The performance of each service provider in the ecosystem against its targets

•The delivery of each service provider against its (contractual) obligations

•The end-to-end delivery of services across the ecosystem

The scope includes all internal and external service providers.

Content

The performance management and reporting framework addresses measuring and reporting on a range of items, including:

•Key performance indicators (KPIs) – these should be specific, measurable, agreed, relevant and time bound (SMART)

•Performance of processes and process models

•Achievement of service level targets

•System and service performance

•Adherence to contractual and non-contractual responsibilities

•Collaboration

•Customer satisfaction

Measurements should be taken for each service provider and its services, and also across the end-to-end SIAM ecosystem.

Designing an appropriate performance management and reporting framework for a SIAM ecosystem can be challenging. It is usually straightforward to measure the performance of an individual service provider. The challenge is in measuring end-to-end performance as experienced by the users, particularly when there may be limited consistency in how each of the providers measure and report (see section 3.5.2 Measurement practices). To avoid providing an inaccurate view of performance, the focus should be on measuring the quality of the services as experienced by users and customers.

The performance management and reporting framework should also include the standards for:

•Data classification

•Reporting formats and frequency

It is important to be clear and concise and not to overwhelm the audience with detail. A common mistake is to make reports highly detailed (sometimes this level of reporting is requested by the customer organization). The principle should be to keep reports simple and practical to show overall performance, but then allow the recipient to request more detailed information if they need to. Identifying appropriate tools to allow the right level, structure and medium of reporting is an important consideration (see section 3.1.9 Tooling strategy).

Where possible, it is important to keep a consistent format for trend analysis purposes.

There is a skill in reporting, which is an appreciation of what the audience is interested in. This extends beyond a reactive response to reporting requests (or contractual obligations), to anticipation of what the governance body should have asked for. A good report contains all that is necessary and no more, but can also recognize good performance and thank the staff responsible. Recognition is sometimes under-used, but can be a powerful motivator when included in reporting (to a higher level in the organization).

Stakeholders

The main stakeholders of the performance management and reporting framework include:

•Customer organization

•Senior management team

•Purchasing and/or finance

•Business relationship managers

•Management of service provider organizations

Although the end users of the services are also stakeholders, the performance management and reporting framework is designed primarily as a management tool for the customer organization. Many organizations use a summary of the information and reports derived from this framework to inform the end user community of service performance.

External provider obligations

It is important to distinguish between performance (how well something is being done) and delivery (of contracted commitments and the fulfilment of all obligations). Each provider will have a contract that will specify obligations (delivery) and KPIs/SLAs (performance).

Example obligations include:

•Responsibilities of the service delivery manager based on site

•Billing to be submitted by the fourth working day of the month

•Use and change of subcontractors to be notified to the customer two months in advance and subject to approval

•Attendance at and input to a collaboration/innovation forum

Typically, obligations last for the full term of the service provider contract and tend to be fixed unless updated by agreement. In some instances, not all obligations have to be fulfilled before the delivery of services can commence. Sometimes, not all requirements and possibilities are fully understood, and a period of learning is necessary. During the design of the performance management and reporting framework, it is important to define when obligations are expected to be fulfilled.

During the Implement stage, service providers should concentrate on meeting obligations that are key to delivery, such as setting up facilities, gaining knowledge and establishing processes.

Once in the Run & Improve stage, the priority should be to meet obligations that affect the ability to govern the services, such as producing performance reports, attending governance boards and other key structural elements.

Some obligations may not be able to be fulfilled without the customer organization or the service integrator taking action. Where this is the case, the service provider cannot be held liable for any delay in meeting its obligations if another party is causing the delay. Other obligations may be delayed because of their nature. For example, a requirement to provide a three-year summary of service statistics would not be possible until year four of the agreement.

Some obligations are event driven, not time dependent. For example, a technology refresh forum might only be required when a strategic change is requested, a technology refresh is due, or a technology becomes incompatible or obsolete. Attendance at a dispute resolution meeting is only required when a dispute occurs.

It is important to track obligations met and failed. The service integrator is responsible for tracking the status of the service providers in meeting obligations. The retained capabilities within the customer organization are responsible for tracking the service integrator’s status similarly.

For each service provider, the fulfilment of all obligations should be monitored and progress recorded. This should track the obligations and follow the reporting principles mentioned above. A percentage of obligations met is a good summary indicator to provide to the customer organization.

Service provider performance

Performance is commonly measured through key performance indicators (KPIs) and service level agreements (SLAs).

Example performance measures include:

•Telephone calls to the service desk are answered within 30 seconds

•A major incident management working group is set up within 20 minutes of a major incident being declared

•Configuration management database (CMDB) records are 90% accurate

•Emergency changes form less than 5% of the total changes

•Less than 5% of releases are rolled back

KPIs, SLAs and OLAs for individual service providers are usually managed through the service level management process (see also sections 2.3.13 Supplier and contract management and 3.1.3 The importance of contracts in SIAM). However, end-to-end SLAs and KPIs require an additional level of management and reporting by the service integrator.

3.1.7.1 The role of targets

Well-defined targets set expectations and promises for the delivery of outcomes and resources. They support strategic objectives and resource allocation. Effective targets require a clear understanding of the link between inputs and their contribution, and the outputs and the business outcomes they support. They must be reviewed regularly to ensure they remain appropriate and aligned to business needs.

Targets will be scrutinized by potential service providers, as they may have to adjust their internal delivery models and approach to ensure they can meet them. This can sometimes adversely affect costs and other requirements that do not have targets associated with them.

Service providers will also need to assess any subsequent changes to targets and outcomes to see if they are achievable, resources are adequate and costs can be recovered. Unless the customer is prepared to fund any necessary changes, this can adversely affect the relationship between the service provider, the service integrator and the customer. Hence, any changes to targets require an informed impact-based discussion.

With the number of organizations involved in a SIAM ecosystem, it is important to have a commonly agreed method of calculating measures, performance, outcomes and targets, including the data sources used. This can avoid arguments between parties that may have used a different dataset or a different calculation to show their desired outcome.

3.1.7.2 Develop a performance measurement plan

To measure actual performance against the set targets or benchmarks effectively, a plan must be conceived for collecting and analyzing the necessary performance data or information. This plan must describe the methods and techniques of collection and analysis, and the frequency of collection.

It also needs to clarify and confirm the roles and responsibilities for each of these tasks. The service providers will be responsible for providing measurements of specific service elements that fall within their remit. The service integrator is responsible for aggregating these to provide operational metrics to allow an understanding of service performance as well as an abstraction of the information for customer-facing end-to-end performance reports.

The plan should assess the availability of the data sources, the feasibility of the collection methods and identify any potential problems. It is a good idea to focus on or start from existing performance data and information where this exists.

A key principle is to start with a set of minimum viable reports. These provide the least amount of information necessary to understand the performance of the services. A minimum set will be more easily understood, and faster to implement than a more comprehensive set. The minimum viable reports can be used to build understanding and collect feedback before being expanded if necessary. Without this approach, many organizations generate more information than is actually required.

Information is most effective when it is visual and easy to understand. Using service dashboards and scorecards will increase the impact of reporting. A picture can be easier to understand than a long report, but it must be clear what each visual is and what it indicates. Figure 24 shows an example of a Kanban board that can support visual management.

The performance measurement plan must also determine who is responsible for gathering, analyzing and reporting on performance data or information. This might be based on the logical fit of these responsibilities with the SIAM layers, looking at existing workload, capability, ownership and timeframe. Table 4 provides an overview for capturing a performance measurement plan.

Table 4: Overview for a Performance Measurement Plan

Outcomes	Reflect those outcomes outlined in the results chain
Performance indicators	Select both quantitative and qualitative indicators, with these criteria: 1. Valid 2. Relevant 3. Reliable 4. Simple 5. Cost-optimal
Data sources	Utilize existing data sources where possible
Collection methods	Identify collection methods such as surveys, interviews, etc.
Frequency	Describe how often you will gather the performance information
Responsibility	Determine the person(s) responsible for gathering, analyzing and reporting the performance information and data

3.1.8 Collaboration model

Collaborative relationships are necessary within a SIAM model because of the number of organizations involved. A collaborative practice involves teams and functions across the SIAM layers working together to achieve shared goals. Collaboration is achieved when these various parties develop mechanisms – structures, processes and skills – for bridging organizational and interpersonal differences, and together arrive at valuable outcomes.

This section refers to the collaboration model not as an artefact or template that can be copied, but as the combination of techniques by which the objectives of collaboration between the parties are achieved. These objectives are likely to include:

•Coherent end-to-end service delivery, drawing effectively upon the service providers involved.

oThis requires the contracts in place to have collaboration at their core, which may require some contracts to be rewritten or updated. It may mean the introduction of a common set of metrics across all service provider contracts. Ideally, a standard collaboration addendum can be developed which, once accepted by all parties, can be added to the existing contracts. Experienced advisors or external support may be helpful here.

•Positive and effective interchanges between the service providers, the service integrator and the customer organization.

oConsider developing a set of ‘softer’ metrics, focused on rewarding positive behavior. For example, have incident, problem, change, development and project teams rank the service providers based upon their perception of how collaborative and helpful they have been.

oAsk service providers to praise one another for positive collaboration experiences, and target them for the frequency in which they do so (for example, a minimum number of ‘praises’ raised per month).

oCreate a clear scope for the service integration layer. It is essential to define the scope of the service integrator role so that it is clear where accountability lies, including the key considerations, the degree of authority it possesses and the level of interaction with service providers and the customer organization. One way to determine these is through scenario-based testing, which will reveal the key roles required to manage common situations such as the resolution of a major incident.

•Rapid identification and resolution of inhibitors to performance and service delivery.

oSurvey service providers to ensure that they are satisfied with the working practices. Give them an opportunity to build and improve collaboration in the processes in which they are active. This can be achieved through the appointment of process owners and creation of process improvement forums where all service providers can participate.

oCreate clarity between the SIAM layers. Ensure service provider teams understand the part they play in the delivery of business services. Instigate ‘back to the floor’ sessions where they spend time in business departments.

There is no one perfect arrangement by which collaboration can be achieved. See section 3.1.8.1 Coordination mechanisms for examples of techniques that may be useful.

The SIAM ecosystem and the relationships between the customer organization, service integrator and service providers create a unique environment. From sourcing and contractual negotiations, through to governance and operational management, there are specific SIAM considerations that must be factored in at the Plan & Build stage.

The cultural aspects of a transition to a SIAM model are one such consideration. An effective SIAM ecosystem is underpinned by relationships and appropriate behavior. Collaboration and coordination are key elements that drive a positive culture. The aim is for all stakeholders to work together in pursuit of a common goal.

The foundation of collaboration can be built and managed through tools, but collaboration is fundamentally a human activity. Collaboration does not happen spontaneously, it needs to be actively designed and supported.

The quality of collaboration is difficult to assess objectively. It is often perceived as ‘we know it when we see it’, and an assessor must frequently refer to proxies when seeking measurement, such as:

•Time taken to establish an agreed approach and to resolve issues

•Quality and value of the outcome(s) delivered

•Resources required to maintain effective performance (for example, to validate reports or establish whether evidence is consistent with claims)

Another term for this is ‘trust’. The absence of trust creates friction in relationships and interactions. Trust means parties pay fairly and deliver on their promises. They can still argue robustly to establish what is fair, indeed, ignoring differences of opinion undermines trust and promotes abuse.

Defining what collaboration means, how it should be seen in action and how it will be measured is an important consideration at this stage. Collaboration should be:

•Active and energetic

•Focused on the delivery of value

•Flexible about means and approaches

•Forgiving and learning, quick to adapt when issues are discovered

•In for the long haul, not for immediate exploitation or the ability to win

•Equitable, with all parties willing to compromise

3.1.8.1 Coordination mechanisms

Coordination and collaboration may at first appear to be ‘soft’ and irrelevant. Should opposition be encountered, one useful technique is to construct a results chain,²² a diagram that relates initiatives taken to the results they deliver in terms of outcomes for the SIAM ecosystem (for more on the results chain, see section 3.5.2.2 Develop a basic results chain).

There are many mechanisms that can contribute to collaboration. The following list is provided for input into service provider selection and for inclusion in design of the SIAM model:

•Clear communication of the business vision and objectives

•Contractual obligations – for example, collaboration schedule, innovation schedule and fund

•Incentives – payment (direct, shared pool), additional business, executive access and governance recognition

•Process

•Tooling

•Informal networks

•Risk and issue resolution

•Structural elements and participation in these

•Onboarding workshops

•Face-to-face meetings

•Role and task definition

•Dispute resolution mechanisms and skills

•Operational level agreements (OLAs)/collaboration agreements (non-legal/contractual)

•Group events and activities

•Joint working parties/continual service improvement

•Vision, belief, leadership

•Organizational change management (OCM)

•Staff behavior guidance, feedback

•Mentoring and coaching

•Behavioral/cultural (notably leadership), training in skills related to cooperation

•Leadership selection – both task and relationship centered

Within the Plan & Build stage, the designers should consider these elements, although some may be deployed later as part of the Implement, or Run & Improve stages.

For cooperation to work, all parties must play their part. This is a huge dependency that is often ignored. The customer organization is just as likely to be ill-suited to cooperation as are the service providers, with even more devastating effects.

Not all the mechanisms have to be introduced at the same time or built at the same rate. Consider selecting some for early evaluation, based on their contribution to the overall SIAM strategy. As in every strategic decision, concentrate your resources, make a choice!

3.1.8.2 Relationship management

Within a SIAM ecosystem, service providers’ flexibility can help to deliver results. Service providers that refuse to engage with the SIAM model’s process forums and working groups, or that insist, ‘I’ve done what it says in the contract’, can have a negative effect. Flexibility helps to develop the most effective collaborative working environment, which will often require changes to the way all layers within the SIAM model work.

The key features of relationship management in a SIAM context are:

•Shared vision and objectives

•Values and behaviors

•Creation of a collaborative environment:

oOrganization and governance

oRisk management

oIssues management and resolution

oKnowledge management and sharing

oSkill sets and training