The Discovery & Strategy stage analyzes the customer organization’s current situation, formulates key strategies and initiates a SIAM transition program, if appropriate. This enables the customer organization to:
•Confirm whether SIAM is an appropriate approach, based on expected benefits and risks
•Determine a sourcing strategy, based on existing service providers; those that can be retained and activities suitable for external sourcing
•Consider additional skills and resources that may be required for the SIAM transition and subsequent operation of the SIAM ecosystem
In an IT environment where many services are becoming commoditized (cloud, as-a-service, etc.) and where multiple vendors need to work together to provide business-critical services, many organizations are spending more time on supplier management, rather than on actually delivering services. They are increasingly considering SIAM to:
•Understand the end-to-end picture of service provision
•Coordinate the activities of multiple service providers
•Provide a single source of truth regarding service performance
•Be a trusted partner in developing new services and strategies
•Optimize delivery through people, processes, tools and suppliers
•Ensure smooth performance of day-to-day operations, enabling them to concentrate on more progressive activities
There is no one correct way of ‘doing’ SIAM. Most commissioning organizations already work with one or more service providers, and have different objectives, priorities and resources. Many elements influence the decision to adopt SIAM, along with deciding the appropriate approach for the transition to the chosen SIAM model.
Discovery & Strategy is a critical stage of the roadmap, as each customer organization’s maturity, services and level of SIAM readiness is different. For example, some organizations may already have a sourcing strategy or mature supplier management capabilities, whereas others will need to create these as part of their SIAM roadmap. If activities are missed – or are partially completed – there could be a negative impact on the remainder of the transition project activities.
Many of the outputs from Discovery & Strategy are refined and expanded in the Plan & Build stage. A SIAM program is likely to require an iterative approach. Often, completion of a task will lead to the revision of an earlier activity. For example, designing the detailed SIAM model in the Plan & Build stage may lead to a review of the SIAM strategy, an activity completed in the Discovery & Strategy stage. It is essential to revisit the approach regularly and reassess previous decisions when needed.
The sequence of activities in the roadmap is not a predefined ‘checklist’ or prescriptive approach. Rather, it is an optimal approach, based on the authors’ experience. Each element is addressed as part of a SIAM roadmap; each task’s structure, order and priority depends on the customer organization’s particular circumstances. Time pressures may require activities to happen in parallel for some organizations.
Designing without tailoring
The CIO of a small organization with 50 users created a SIAM strategy before understanding the capabilities of their internal IT team and its current services.
They engaged external consultants to design a SIAM model. They reused a model that they had created for a large, multinational organization. This included contract schedules for an external service integrator and several service providers. The CIO then brought in a separate team of external procurement professionals to run a major procurement exercise. After 12 months, the service integrator and service providers were appointed.
Because of the lack of tailoring to a ‘standard’ SIAM model to suit the needs of the smaller organization, the result was a threefold increase in the costs of the IT services.
“The SIAM transition project should be formally established using the organization’s selected project management methodology.”4
Managing the transition to a SIAM model is a significant undertaking. The time, costs, effort and resources for all parties involved should not be underestimated. This section provides some guidance on the most appropriate project management methodologies and approaches that can be used throughout the SIAM roadmap stages.
The context of this section is to provide guidance regarding the discovery, planning and implementation of a SIAM model. It is not intended to provide recommendations for the implementation of a project management framework.
There are a variety of project management standards, methodologies and frameworks available, including:
•International standards, for example ISO 21500
•Country specific standards, for example ANSI, BS 6079, DIN 69900:2009
•Generic or global methodologies, for example PMI, PMBOK, APM, SCRUM, PRINCE2
•Industry specific practices, for example HOAI, V-Model, etc.
Combining these with any existing practices within an organization provides a good starting point for managing the SIAM transition project and the activities of the SIAM roadmap.
Most organizations will already have a preferred project management methodology. It is usually better to adopt that approach, rather than impose a different method that can lead to further disruption as the organization learns SIAM principles and a new project management approach.
Successful completion of complex projects, such as a SIAM transition, almost invariably requires the selection and expert application of a number of different enabling practices, approaches and frameworks. It is important to consider the mix and the level of expertise that will be required for a SIAM transformation.
Some organizations may choose to work with an external provider of project management capabilities. This may arise when the organization has no capability in project management, no available resources or little experience of managing a project of this scale and type. In these cases, it can be helpful to work with an organization that adheres to an organizational or global project management standard. This reduces the risk of becoming over-reliant on a proprietary framework and its provider.
Regardless of the project management methodologies and practices selected, it is important to reach agreement on the principles and approaches to be used. This ensures a common understanding between the stakeholders involved in project delivery and governance.
In many organizations, the transformation to a SIAM model may be carried out as a program with several projects within it. In this case, a program management method or approach will need to be considered, in addition to a project management methodology.
Program versus project
Although programs and projects have many similarities, they also display several different characteristics and functions.
A project is well defined, with a start and end point and specific objectives that, when attained, signify completion.
A program has greater levels of uncertainty. It can be defined as a group of related projects managed in a coordinated way to obtain benefits not available from managing projects individually.
The transition to SIAM is usually a program that can span many years and includes several discrete projects. During the Discovery & Strategy stage, there will be many unknowns and variables to discover, define and resolve. The outcome of this stage is an outline business case for a SIAM transition project, and for the remainder of the roadmap stages (see section 2.7 Create an outline business case).
Agile (as detailed in the Agile manifesto5) is a set of methods and practices for software development. It is based on iterative and incremental development, and a rapid and flexible response to change. Requirements and solutions evolve through collaboration between self-organizing, cross functional teams.
Although a SIAM project is not a software development project, Agile practices can add value. This topic is discussed in more detail within the SIAM Foundation BoK, including an alignment of Agile principles and how they might be applied to SIAM.
A waterfall approach is a more traditional method of development and implementation that follows sequential stages and a fixed plan of work. For example, plan, design, build and deploy. There are many activities within the SIAM program that can be addressed in an Agile or iterative manner, whereas other activities may be more appropriately coordinated in a traditional waterfall approach that promotes more detailed planning. A hybrid approach might use waterfall to set out the overall milestones, but apply iterations within the stages to achieve them.
Waterfall and Agile
At a UK manufacturing organization, the incoming service integrator created a waterfall implementation plan.
The transfer of processes was broken down into a number of phases and rolled out to the service providers being incorporated into the SIAM model. The processes were to be documented by the service integrator and introduced to service providers through a series of workshops.
However, during due diligence it became apparent that some key processes were suitable for a single service provider, but would not work in a multi-service-provider model. It was necessary to redevelop these processes as a priority, using an agile approach, in conjunction with the new service providers. This approach helped to ensure that the processes would apply to all service providers in the SIAM ecosystem. Other processes were not implemented in full, but were developed to a state that enabled them to be adapted and used much earlier than had been expected.
The result of this collaborative development approach was that the new service providers had much better commitment to the processes and a healthy working relationship emerged between the service integrator and service providers. The customer organization had the benefit of some processes that were implemented earlier than expected and with evidence that collaboration would work effectively.
Project governance is the management framework within which project decisions are made. Project governance is separate from overall IT, organizational or SIAM governance, and provides a set of rules and regulations for all projects, irrespective of whether they are Agile or waterfall.
Project governance does not describe the governance of the SIAM ecosystem. As part of a SIAM transition project, a governance model for SIAM is created, as defined in section 2.3 Establish a SIAM governance framework.
Governance is a critical element of any project. It provides a framework of accountabilities and responsibilities associated with an organization’s projects. It is fundamental to ensuring control and contributing to the overall success of the project. The role of project governance is to provide a decision-making framework that is logical, robust and repeatable. It assures that decisions and directions occur in a correct and timely fashion. There are a variety of options available to support decision making within a project, including:
•Consensus decision making
•Delegating the decision to an expert or subgroup, allowing the SIAM governance lead to make the decision after discussion (see section 184.108.40.206 SIAM governance lead)
Governance focuses on the organization’s requirements and should be business (not IT) oriented. Governance processes should be linked to business value and measured against them. Project governance is based on the overall strategy of the customer organization. Project managers must understand the customer organization’s objectives and vision, and how these relate to the project governance framework.
The project governance framework provides a mechanism to maintain visibility of the project status and to understand and manage the risks associated with the project. The most desirable approach is to create a project governance framework that allows projects to achieve results unhindered by bureaucracy, micromanagement and unnecessary scrutiny.
Examples of project governance artefacts and elements include:
•Project initiation document
•Agreed specification for the project deliverables
•Critical success factors (CSFs)
•Clear assignment of project roles and responsibilities
•Project steering committee/board and project manager
•Stakeholder map identifying all stakeholders with an interest in the project, classified by their role and influence
•Communication plan – defining the method of communication to each type of stakeholder
•Organizational change management (OCM) approach
•Project and/or stage plans
•System of accurate status and progress reporting
•Method for comparing the completed project to its original objectives
•Central document repository for the project
•Centrally held glossary of project terms
•Process for issue management
•Risk and issue log – and a process for recording and communicating these during the project
•Standard for quality review of the key governance documents and of the project deliverables
This list may not be necessary for every SIAM project. Each one needs to consider the artefacts that are required for a successful outcome.
The organizational structure of a SIAM transition project needs to be resilient so it will remain stable throughout the entire project. Changing the project roles and responsibilities midway is disruptive and should be avoided as far as possible. Individuals fulfil roles, and although individuals can change, the roles and responsibilities within the project structure remain constant.
There should be a project team that represents the service integrator (once appointed) and representatives from the key incumbent service providers. Representation from the customer organization is also needed, especially during the early stages (Discovery & Strategy, and Plan & Build) when decisions about the SIAM model are made. As additional organizations are appointed and onboarded (for example, an external service integrator or service providers), they must be included within the project structure.
Some customer organizations choose to delegate their role in the project structure to the service integrator (once appointed), particularly if the service integrator is sourced internally. In an external service integrator structure, the customer organization may want to maintain representation in the project team to avoid becoming detached from project management and decision-making activities. Its role in the project structure is to give direction, provide oversight and be seen by the stakeholders and parties involved as supportive of, and committed to, the SIAM transition project.
Representation within the project
Not every service provider will be interested in becoming part of the project team. The level of engagement varies, depending on the service provider’s delivery model. The SIAM transition approach should be flexible enough to accommodate this.
For example, a large cloud solution provider will not, in most cases, send representatives to its customer’s project management team or meetings.
Organizations must ensure that if an external service provider is unable or unwilling to become part of the project structure (perhaps because it has not yet been appointed), there remains representation for that role, to provide input and consideration to project management. An example would be a service owner from the retained capabilities that can represent the external service provider for that service within the project structure.
Independent of the applied project management approach and governance framework, there are several structural elements that have been demonstrated to be effective in SIAM transition projects and programs.
The project board is responsible for overseeing and steering the SIAM transition project, making project decisions, adjusting the project when necessary, and providing communication and guidance throughout the transition period. It is sometimes referred to as a steering committee.
Having a functioning project board involving all relevant stakeholders is essential for effective project management and swift decision making. The project board steps in when a lower level in the project structure, for example, the project manager, needs higher authority for decisions or where they cannot resolve an issue, for example, a lack of resources.
PRINCE2 provides a definition of the roles for a project board that can be applied to a SIAM transition project:
•Executive: sponsor from the customer organization who ensures that the program/project meets expected benefits and is adequately equipped with resources.
•Senior User: someone with adequate authority to represent the consumers of a SIAM program outcome, typically from the retained capabilities.
•Senior Suppliers: representatives from the various service provider organizations, including the internal and/or external service integrator.
A service provider may also act as a Senior User, for example, for tools that they will be required to use, such as the incident management system. If its tools are being replaced, it may be useful for the service provider to help define and test the quality criteria for the new ones.
The project manager manages a project on a day-to-day basis on behalf of the project board, within specified constraints. The customer organization may provide a project manager, source a project manager for the SIAM transition project or ask the service integrator (once appointed) to fulfil this role.
Transition Review Board
A Transition Review Board is a joint board of service providers, the service integrator and the customer’s retained capabilities. It is an optional board with a role that is more operational and ‘hands on’ than the project board, and has a place between them and the project manager. This board can be useful later during the Plan & Build, and Implement stages, when the service integrator and many of the service providers have been appointed.
This board is responsible for:
•Reviewing transition progress against planned activities
•Reporting progress to the project board
•Identifying and managing project issues
•When necessary, escalating issues or decisions to the project board
•Ensuring that all parties are aligned in terms of plan execution
•Making the recommendation to the project board to accept the outcomes of one stage and commence the next, including final acceptance of the implementation and handover to operations
Once the project is completed, this board may be retired, or alternatively continue as a board within the SIAM governance framework, for example the Service Review Board (see section 220.127.116.11 Governance boards).
Project Management Office
A Project Management Office (PMO) is a group or department that defines and maintains standards for project management within the organization. The PMO strives to standardize and introduce economies of repetition in the execution of projects. The PMO is the source of documentation, guidance and metrics on the practice and execution of project management.
The PMO may have other functions beyond standards and methodology, and may participate in strategic project management, either as facilitator or as owner of the service portfolio management process within the SIAM model. It is responsible for monitoring and reporting on active projects and portfolios, and reporting progress to senior management for strategic decisions. A PMO can provide the following benefits during a SIAM project:
•Align the portfolio of projects, including the SIAM project, with other activities within the customer organization
•Provide advice on lessons learned in previous projects that can help to avoid mistakes and incorrect approaches
•Monitor and report on the progress of projects, whether they are on time and within budget, according to the defined scope, along with tracking risk and issues
•Understand the links and dependencies between projects, for example, multiple projects within a SIAM program
•Improve communication within the program and project teams and stakeholders, including service providers, the service integrator and others
•The customer organization’s PMO can provide guidance to the service integrator and service providers involved with the project to improve standardization within the SIAM environment
•Provide or assure document control and maintenance of a document repository for projects
Solution architecture and assurance function(s)
Different stakeholders are involved in the strategy, planning, building and implementation of the SIAM transition project. To support these stages, a detailed SIAM ecosystem is designed, including a process model, tooling strategy and reporting framework.
Designing a SIAM model requires specialized capabilities. Forming a solution architecture team will allow for the inclusion of stakeholders, including subject matter experts (SMEs), such as enterprise architects. Integrated architecture principles can be applied to the design of any SIAM model, as they provide a strong focus on business requirements and drivers. The need for all aspects of the architecture and all architectural decisions to be traceable back to business priorities must always be considered.
Enterprise architecture frameworks
Most enterprise architecture (EA) frameworks divide the architecture description into domains, layers or views, and offer models – typically matrices and diagrams – for documenting each view.
This allows for systemic design decisions on all the components of the system and long-term decisions around new design requirements, sustainability and support.
In addition to a solution architecture function, it is beneficial to introduce a solution assurance function early and for the life of the project. Often, early design decisions must be revisited or amended to comply with the agreed approach and principles. Sometimes, solution assurance and architecture functions are combined into a single team. Alternatively, the solution assurance team can be incorporated within the PMO, so it can provide assurance across multiple projects.
Communication is a CSF for any organizational change program. It is important to plan, structure and design communications to support change towards a SIAM culture. The dedicated communications team will be part of the project structure, spanning the affected organizations. Communication activities across the layers include:
1.Customer organization: for large organizations that operate in different geographies, regional and country stakeholders typically consume and require most communication efforts. Different forms of resistance to change can be observed within these stakeholder groups in almost all SIAM projects, and these objections need to be anticipated and addressed.
2.Service integrator: needs to execute and supervise communication activities from a central communication team’s perspective to its own personnel, as well as to the service providers in the SIAM model.
3.Service providers: ideally, communication professionals in the service provider layer should form an extension of the service integrator communications team for execution and feedback.
Procurement and contract management
Many SIAM transition projects include the selection of new service providers, and all include the creation of new contracts and the retirement or termination of existing contracts. It is important to establish structures and plans within the project for these activities.
The contract management team needs to assess existing contracts, review and learn from existing issues, understand the target SIAM model and establish appropriate new contracts. The contract management team should, therefore, be embedded into the SIAM transition project structure. If not, there is a risk that working in isolation will result in disparities between the contractual scope and what is required for the chosen SIAM model.
The contract management team can be established from within the customer organization’s retained capabilities or provided externally, if the internal capability is not sufficiently mature. Eventually, accountability for contract management for the SIAM model must reside within the customer’s retained capabilities. In situations where the initial contract management team was sourced from an external organization, a plan to form a contract management team within the customer organization must be delivered as part of the SIAM transition project.
The procurement management team should agree its approach with the project team, in line with the strategic objectives and the chosen sourcing approach (see section 3.1.2 Sourcing approach and the selected SIAM structure). It also needs to prepare procurement documentation, using artefacts from the SIAM project team and contract management teams, ensuring that it complies with legal requirements. It will then manage the procurement process. This may include dialogue with the service providers to elicit requirements that need their input or to address situations where providers are unwilling to accept particular responsibilities.
The procurement management team will conduct negotiations with potential service providers until the contracts are signed. During these negotiations, it must maintain alignment with the SIAM strategy and model. Many customer organizations use external procurement resources as they rarely have the capability or experience in sourcing providers for a SIAM ecosystem. If external resources are used, consider how this capability will be provided once the SIAM ecosystem is established.
The activities for contract management and procurement management must be embedded in the overall plan for the SIAM transition (see section 3.3.3 Transition planning) as part of the critical path to success.
It is essential that the Discovery & Strategy stage defines the behavioral expectations from all stakeholders. Building a ‘one team’ culture should start early with the project team. Culture can make a major difference to the success of SIAM activities in later roadmap stages so must be considered in detail at every stage of the roadmap.
Building trust and acting as a single team across multiple organizations can be a challenge and is discussed elsewhere in this guidance in relation to culture and behavior (see section 3.2 Organizational change management approach).
The way in which project governance is conducted will have a significant impact on the trust and behaviors instilled in the SIAM environment. The behavior of project team members and their engagement with others will set a benchmark for the service providers as they join. When managing the project, it is important to pay attention to ‘fairness’ and whether stakeholders feel their opinions are being heard. ‘Being heard’ may require a new approach to prevent some stakeholders dominating meetings.
For example, if the service integrator exhibits the desired behavior, the service providers are more likely to display the same. If a service provider feels that another service provider is being favored, it may avoid the service integrator and escalate the issue to the customer’s retained capabilities, causing project delays.
It must be clear to all service providers from the outset that they will be expected to work with other service providers on the project, and to share information about progress and issues. This can be supported by techniques such as the Chatham House Rule, where participants are free to use information received to progress the SIAM project, but not to disclose the source of information or to use it outside the SIAM project.
Chatham House Rule
The Chatham House Rule:
“When a meeting, or part thereof, is held under the Chatham House Rule, participants are free to use the information received, but neither the identity nor the affiliation of the speaker(s), nor that of any other participant, may be revealed.”6
The rule originated at Chatham House with the aim of providing anonymity to speakers and to encourage openness and the sharing of information. It is now used throughout the world as an aid to free discussion.
Collaboration and openness are crucial to the success of a SIAM model. The commitment of competing service providers to work together should be tested during procurement, to give an indication of whether service providers will be a good cultural fit.
Many commercial sensitivities need to be recognized and overcome if the project is to be successful, so the governance model for the project must address these from the outset. It is advisable to establish a cross-service provider body that focuses on partnership and collaboration as early as possible in the SIAM project (see section 18.104.22.168 Governance boards, Partnership and Collaboration Steering Board).
A ‘kick off’ event focusing on delivering the SIAM project, attended by the customer, retained capabilities, service integrator and service providers (incumbent, or if already assigned) can be a useful first step in creating the common vision necessary for the ‘one team’ culture and building trust.
It is very important to set the right expectations with senior stakeholders when creating initial project plans and securing sufficient budget for the roadmap stages. Sometimes the cost of SIAM projects is understated, the benefits are overstated or the timelines shortened to ease business-case approval. If the business case is unrealistic, there is a high risk that the customer organization will see the project as a failure because its expectations are not met.
Project management methodologies allow a project to be divided into discrete stages. Provided that the complete transformation scope has been signed off at the ‘initiation stage’ of the project, the detail of these stages can be determined later, preferably without the need to seek more funding. As suggested in section 2.2.2 Agile or waterfall?, an iterative Agile approach provides a phased implementation, with each stage learning and adapting from previous stages.
Iterations of integration – a process example
Iterative approaches must still deliver results. For processes, the important step is to establish the roles and responsibilities, and interactions and activities to support them. The first iteration for a process might be manual integration activities (for example, a ‘swivel chair’ approach for logging incident records).7 Then, the next iterations leading to data integration can be developed and implemented based on feedback and lessons learned.
Before you start
Any journey requires a good understanding of the objectives and outcomes – the ‘destination’, way points, and the starting point or ‘point of origin’. Discovery and assessment of the current state is essential. This includes baselining critical resources for the transition, including their capability, maturity, availability or any other constraints (see section 2.5 Analyze the current state).
The chosen project management approach should help set standards for project artefacts and stages, such as a business case, setting up and initiating the project. These early stages are important, because they set senior management expectations (and commitment) for the project. Those expectations, for example regarding timing, budget and quality outcomes, are not easy to change during later stages. Independent of the benefits actually achieved from the SIAM model, setting the right expectations will often determine the perceived success or failure of the project.
The project outcomes and objectives should be aligned to the strategic objectives defined by the customer organization. Quality and acceptance criteria should be defined for the project as part of a benefits map or profile, and within the project’s product descriptions and quality plans.
Transition versus transformation
Transition is the process of change from one form, state, style or place to another. A SIAM transition takes the customer organization from the previous, non-SIAM state to the start of the Run & Improve stage. Transition is a defined project with a start and end point.
Transformation is the act of transforming or the state of being transformed. It is the overall SIAM program that makes all changes, in all roadmap stages, to realize the full benefits of the SIAM model. The customer organization is transformed from its previous way of working. Organizations need to complete a transition in order to transform how they operate.
Benefits realization management provides the customer organization with a way to measure how a SIAM project adds value to the enterprise.
Benefits realization approaches are defined and embedded into many project, program and portfolio management methodologies, and cover the full lifecycle from initial idea to realization. To assess if benefits have been delivered, the scope of the SIAM project must define a point when the implementation (or an implementation phase) is complete. As SIAM models evolve and improve continually, setting this point can be challenging, but it is essential when defining how benefits and success are to be measured.
Often, it is difficult to quantify project benefits and link these to the real outcomes and objectives for a SIAM transition (see section 22.214.171.124 Choosing the right measurements).
In reality, SIAM benefits are often based on subjective indicators such as a reduction in ‘noise’ to the customer organization, including its awareness of service provider disagreements or a general feeling that things are more under control.
Although benefits of this type are more difficult to measure quantitatively, in terms of value to the customer, they are important and must be considered as part of the performance framework.
Defining expected benefits (and how and when they will be measured) supports decision making during all stages of the project. It ensures that all decisions (particularly in relation to changes) are made with the benefits in mind. Often, project managers and other project team members become too focused on the detail of the project, forgetting objectives and required outcomes. This can lead to decisions that inadvertently affect the expected benefits adversely.
A defined set of objectives and an agreed way of measuring benefits, both financial and non-financial, is important. A clear and well-communicated business case, supported by ongoing project reporting, measurement and communication, will help to ensure appropriate expectation management.
Within Discovery & Strategy (as part of the outline business case), and Plan & Build (as detail is added to the business case), expected benefits need to be identified. Measuring SIAM benefits can be challenging, so this area requires a robust approach. The business case will clarify the purpose of creating and implementing a SIAM model, and its expected outcomes and benefits. The business case is a reference document that is used to clarify direction and purpose during the latter stages of the SIAM roadmap.
Benefits realisation plan
The Project Management Institute suggests that a benefits realization plan should:
•Identify benefits – ensure that the customer organization can identify expected benefits, to identify the best project and program investments
•Execute/provide benefits – look at practices that enable organizations to capture and realize both intended and unintended benefits
•Sustain benefits – provide practices that enable organizations to sustain benefits and achieve strategic objectives, to deliver ongoing value from outputs and outcomes once they transition back to the business
The benefits realization plan for a SIAM transition program or project should be created in the early roadmap stages. Checkpoints should be planned – both during the transition and beyond – once the SIAM model is deployed. Many benefits may not be fully realized until the SIAM model has been in place for a period of time. Checkpoints ensure all activities are on schedule to deliver planned benefits at the expected time. Where this is not the case, corrective action needs to be considered to address any shortfalls and avoid affecting the return on investment (ROI) planned in the business case. Effective planning for business benefits realization is key to evaluating the success of a SIAM model.
It is important to manage stakeholder expectations regarding the new SIAM model proactively. Good expectation management will reduce surprises and can identify a requirement to adjust the project course. These activities will support expectations management
•Goal setting and review
•Creating project plans
•Reducing unverified assumptions
•Openly communicating with all stakeholders
•Publishing status reports and project key performance indicator (KPI) information
•Avoiding unachievable commitments, or saying 'no' appropriately
To manage a successful SIAM transition, set mutually agreed goals across the SIAM layers that align to the customer organization’s goals. When the customer organization’s goals are clear, they can be used to assess changes. Will the change help the customer organization to reach its goals? Or is this simply a distraction? The service integrator will refer to these goals during conversations with stakeholders.
Creating project plans
Creating a project plan is necessary for a SIAM transition. Even if the customer organization claims not to care how the model is implemented or how activities are delivered, a plan with timelines can help set expectations and identify any assumptions or areas where more clarity is needed. The customer organization should always be able to understand the status of a project.
A SIAM transition requires the involvement and coordination of many different stakeholders. Adequate lead time is required to ensure that all stakeholders (both internal and external) can plan and mobilize appropriate resources required for the project.
Lack of planning
A large government organization started its SIAM transition by appointing an external service integrator. The service integrator invited all existing service providers to assist in process definition via a series of workshops. There was no overall plan or published timetable describing when SMEs would be required. The result was a series of workshops with 30–40 people all trying to agree on the correct models and how the processes should work.
Had the service integrator developed a plan first, defining whose input was required, when their attendance was needed and the activities to be performed, there would have been a better understanding of the purpose, objectives and required outcomes for the workshops. This approach would improve the chances of success in developing processes that are effective and fit for purpose.
Reducing unverified assumptions
Assuming that all stakeholders have the same understanding of a situation, project, deadline or task, presents risks to the success of the SIAM project. This issue can be easily overcome through adequate communication to discuss what is expected, how it might be accomplished and how benefits will be measured. One of the more common causes of project failure is the miscommunication of deadlines, potentially resulting in confusion and delays.
Openly communicate with all stakeholders
One of the best ways to manage expectations is to communicate frequently and clearly with all stakeholders within the SIAM project. Important times include the early stages of a new project and when a milestone or deadline approaches. It is important to strike a balance between sufficient and too much communication (sometimes referred to as communication overload). During a SIAM transition, service providers and stakeholders may be asked to work together for the first time. Ongoing communication can help to establish trust.
‘Checking in’ with the stakeholders throughout the course of the project makes it possible to provide real-time status updates and manage any delays, risks or bottlenecks. Proactive, honest and transparent communication fosters trust and introduces flexibility for making changes as the project proceeds. Being honest about a delay is better than promising to deliver and then missing a deadline. This is an essential part of SIAM culture.
Avoiding unachievable commitments
A large part of managing expectations is assessing if the expectation is appropriate.
Under promise, over deliver
In such complex environments, with so many stakeholders from different organizations and teams, it can be hard to give guarantees. There are too many factors that can affect what is delivered.
‘Under promise, over deliver’ is an old adage. It means that it is better to promise what you are certain of and do better if possible. Promising more than you are certain of creates a risk of failure. All the stakeholders in a SIAM model need to work together to define what can be promised realistically to the customer organization.
Expectations should be realistic and achievable. If they are not, it is acceptable to say ‘no’. Being open with service customers and consumers regarding what can be delivered and, perhaps, what the plan to deliver other requirements at a later stage is, can contribute to instilling confidence and building effective long-term relationships.
This activity defines governance requirements and creates a high-level governance framework to guide the future SIAM model. This is separate from project governance, defined earlier within section 2.2.3 Project governance. The governance framework is used throughout all stages of the SIAM transition and operation (see sections 3.1.5 Governance model in Plan & Build and 5.1 Operate governance structural elements in Run & Improve).
What is governance?
Governance refers to the rules, policies and processes (and, in some cases, legislation) by which businesses are operated, regulated and controlled. There may be many layers of governance within a business, including enterprise, corporate and IT. In a SIAM ecosystem, governance refers to the definition and application of policies and standards across the SIAM layers. These define and ensure the required levels of authority, decision making and accountability.
Effective governance provides control and assurance that the SIAM ecosystem is properly aligned to the customer organization’s requirements, is responsive to changes to those requirements and operates in accordance with strategy and plans. It also enables timely decision making, discussion of risks, issues and successes, and allows the views of different parties involved in service delivery to be heard by the customer organization.
Effective IT governance addresses the challenges of IT provision. IT is a key capability and enabler for many organizations and is subject to a wide range of threats. Reliance on IT in today’s interconnected ‘always on’ cyber landscape, and the immediacy of social media and 24/7 news coverage, creates the potential for significant financial and reputational impact caused by IT failures.
There are many IT options available to the customer organization, from ‘as a service’ to the cloud. Although these options can provide a faster and ‘easier’ route to a working solution, the overall complexity of the service landscape often increases because of an expanding portfolio of service providers, architectures and ways of working. Coupled with this is the increased potential for business units to bypass centralized IT governance and procure solutions themselves, potentially creating vulnerabilities and generating ‘shadow IT’ that the IT department is then expected to support.
IT governance involves organizations having appropriate structures and processes in place to enable management to make timely decisions, understand the risks that the organization faces and take steps to monitor and control those risks appropriately. Increasingly, legislation means that this is not just an IT problem, with large fines and board-level prison sentences potentially resulting from a failure to demonstrate adequate internal controls.
The customer organization needs a well-defined and robust approach to IT governance for internally and externally sourced services. The customer organization remains accountable for ensuring that risks are assessed and that appropriate controls have been implemented and are functioning correctly. This accountability cannot be outsourced, even if the responsibility for operation of some or all of the controls has been assigned to a service integrator.
Within a SIAM ecosystem, governance ensures that there is a system of control in place across all the SIAM layers. Decisions are made considering all parties within the ecosystem and risks are clearly understood, controlled and monitored. The consequences of poor governance practices within a SIAM ecosystem can include:
•Inappropriate and sub-optimal allocation of contracts
•Breakdown of trust and relationships
•Lack of coordination when dealing with major incidents, problems and changes
•Charging based on ‘what can be got away with’
•Delays because of poor communication and poor sharing of information
•Disputes related to unclear roles and responsibilities
In a SIAM ecosystem, governance and management operates at three layers:
Governance practices involve:
•Fairness to all parties
•Openness and transparency
•Procedures to prevent conflicts of interest
These concepts fit well within the SIAM environment where there is a desire to encourage collaboration and partnership between the different organizations involved. At the highest level, SIAM governance focuses on three key aspects:
1.Ensuring alignment between the customer organization’s current and future business needs and the SIAM strategy
2.Ensuring that the SIAM strategy and SIAM model are planned and implemented successfully
3.Ensuring that the SIAM model is managed, operated and improved in a controlled and collaborative manner, in compliance with both internal policies and external legislation
Within SIAM, boards are structural elements that perform a key role in providing governance and overseeing these aspects. They function as decision-making bodies, with representation from the appropriate level of the relevant stakeholders within the ecosystem.
Guidance on effective governance can be obtained from established sources such as ISACA’s COBIT governance and management framework for information and related technology. One of COBIT’s guiding principles is that for efficient and effective governance, organizations need to take a holistic approach, focusing on seven categories of enablers that interact with and support each other as shown in figure 7. Each of these enablers needs to be considered when implementing governance within a SIAM context.
Applying these categories of enablers to the SIAM model aids the identification of key components that need to be part of an organization’s SIAM governance framework.
Principles, policies and frameworks are the steering mechanisms that guide the ongoing management and operation of the SIAM model. When properly constructed, these components inform decisions, underpin activities and ensure alignment across the ecosystem. Over time, requirements will change, so these enablers must be reviewed periodically and, if necessary, updated to maintain alignment with the customer organization.
Processes describe how particular objectives are achieved within the SIAM ecosystem, ideally aimed at ensuring an optimal mix of standardization and interoperability. Defined processes provide clarity about how things should work and enable repeatability, which, in turn, helps support desirable behaviors such as continual improvement. At the same time, within a SIAM environment, it is important to not enforce on the service providers the ‘how’ of process activities, but instead to focus on the ‘what’ (the outcome) and the interactions between different providers and with the service integrator (see section 3.1.3 Process models).
Organizational structures provide decision-making bodies with defined scopes, roles and responsibilities. Within a SIAM ecosystem, a structure of governance boards, each with defined responsibilities, ensures that decisions are made at the appropriate level and with input from relevant parties, roles and skill sets.
Culture, ethics and behaviors. The importance of considering organizational cultures and the need to demonstrate ethical practices and embed key behaviors such as fair play, cannot be understated with regard to SIAM. Some organizations may be moving from a single provider model, where negative behaviors such as an ‘us and them’ mindset have become established. In other cases, there can be a significant difference in culture, ethics and behaviors between different service providers.
Individual versus group culture
It is sometimes the case that the individuals working within the SIAM ecosystem are honest, open and reasonable, but the group or corporate culture of their individual organizations is less so. The reverse can also be true. It is important to recognize that culture is often set at the top of an organization, so cultural issues may need to be escalated before the change can flow down to an operational level.
Transforming organizational culture to one of partnership, openness and fair play can be a significant challenge and will not happen by accident. Culture change needs to be planned and worked at, with clear leadership cascading down through the management chain. It may be necessary to move people into new roles if the incumbents are unable or unwilling to accept the change.
Information is a vital resource to support effective governance. Without accurate information about what is happening, how things are working and any issues being faced, it is impossible to make timely and informed decisions.
Services, infrastructure and applications are resources that enable the SIAM ecosystem to function efficiently and effectively. In a SIAM context, it is especially important to address interoperability as part of the tooling strategy and to ensure compliance with defined technical standards and data models.
People, skills and competencies are other important considerations within the SIAM ecosystem that need to be planned, monitored, managed and governed. Effective governance should involve regular review of whether the organization has access to the correct skills, confirmation that the people performing roles or making decisions have the necessary competencies and whether headcount requirements are changing.
These enabler categories benefit from interaction with each other. For example, processes require people with the correct competencies to operate them, policies provide the ‘rules’ by which processes are operated, and applications store and allow the manipulation of information to support decision making. It is essential for organizations designing a SIAM model to review governance and management processes. Tools such as a RACI (Responsible, Accountable, Consulted, Informed) matrix can be used to show at which level of the planned SIAM model each process activity resides.
To understand governance requirements, first consider what needs to be governed (the ‘assets’), then identify and assess the risks that apply to those assets, before finally determining what controls, if any, need to be designed and implemented to manage those risks and provide assurance.
In the following sections, examples of assets and risks within a SIAM model are described at strategic, tactical and operational levels. These lists are not intended to be exhaustive, and much will depend on the specific organizations involved and the SIAM model selected. The intention is to provide common examples.
At a strategic level, examples of where governance may be required in a SIAM ecosystem include:
•SIAM business case (outline and full) and subsequent benefits realization
•Strategic risks and controls
•SIAM strategy (implementation and maintenance)
•SIAM model, including the SIAM process architecture
•SIAM tooling strategy and architecture
•SIAM organizational responsibilities
•Conformity to applicable external factors (for example, laws and regulations)
•Conformity to applicable internal factors (for example, organizational policies and standards)
•Ensuring alignment with corporate governance requirements, including any concerned with sustainability or environmental considerations
Once a list of the areas and items requiring governance has been identified, the next step is to identify the related potential risks (see section 2.3.11 Risk management). In other words, ‘What could go wrong?’.
Examples of potential risks include:
•Expected benefits from the SIAM program not being realized
•SIAM strategy and model failing to be wholly and properly implemented
•One or more parties not fulfilling their organizational responsibilities
•Unauthorized changes being made to strategic planning documents
•Sustainability or environmental obligations and targets not being met because of the actions of service providers within the SIAM ecosystem
Although in many cases it may not be necessary to carry out a full quantitative risk analysis, consideration should be given to identifying significant risks. Risks identified should be reviewed against agreed thresholds. The available resources, likelihood, potential impact and mitigation feasibility should be considered as part of decision making and risk prioritization. Attention then needs to be focused on the risks that are believed to be above the risk appetite threshold and how these might be managed, often using combinations of the governance enablers described earlier in this section.
Part of strategic governance should be to ensure that achievements are monitored and tracked against the original business case objectives (see section 126.96.36.199 Benefits realization management). There should be regular reviews of whether the organization is still on track to achieve the SIAM program’s strategic objectives and whether the intended value is being realized. The objectives will vary depending on the organization. For example, if one of the key objectives of the program was to increase business satisfaction with IT delivery, has this been achieved? If the objective was to obtain $4M cost savings over five years, is the program still on track to realize this?
In some organizations, there may already be mechanisms in place to track program benefits and value realized against business case objectives. Whether this is the case or not, the SIAM transition project/program management need to be aware of this information and track it. During the transition there will often be changes in scope, business requirements or external factors that could potentially have an impact on or alter the expected benefits. When this occurs, formal mechanisms are needed to approve the change (see section 188.8.131.52 Project roles).
Part of this approval includes understanding and agreeing any changes to expected benefits. If the scope will be altered in such a way that the original objectives or value can no longer be achieved, then revised value objectives need to be agreed as part of change approval. It may be that management decides to reject the proposed change once they understand the impact it will have on value realization.
At all times, alignment must be maintained between the SIAM transition and its intended benefits, so that targets are attainable and success can be quantified and verified. If, at any stage, benefits tracking indicates that the expected benefits may not be realized, this will be reviewed and, where necessary, corrective actions implemented to bring the program back on track.
Governance related to the tooling strategy
Each SIAM transition project must consider how to deal with the implementation and configuration of a service management toolset. This is considered extensively in the Plan & Build section (see section 3.1.9 Tooling strategy). The tooling strategy needs to be part of the governance considerations. Governance must ensure that there is a comprehensive, documented tooling strategy that includes the tooling ownership.
At a tactical level, examples of where governance may be required in a SIAM ecosystem include:
•SIAM plans (implement and operate plans for different process areas)
•SIAM tooling plans (implement and operate plans for different toolsets)
•SIAM process and tool ownership
•Service management data (ongoing ownership and governance)
•Ongoing initiatives, goals and plans, including service improvement plans
•Service provider transition plans (onboarding, handovers and offboarding)
•Management and coordination of projects
•Training and education plans
•Audit policy, plan and schedule
Governance in these areas helps create an understanding of the potential risks.
•Plans not being wholly or properly implemented
•Lack of ownership of plans, processes or tools
•Loss of valuable service management data, for example, during a change of service integrator
•Loss of key knowledge when service providers change or staff leave the organization
•Skill levels diminishing as new technologies are introduced
•Lack of coordination in multi-service provider projects, resulting in costly delays
The SIAM governance framework should include controls aimed at mitigating the risks at the tactical level.
At an operational level, examples of where governance may be required in a SIAM ecosystem include:
•Contracts and collaboration agreements
•Processes and procedures
•Capabilities, skills and knowledge
•Integrations and interfaces
•Policies and controls
•Process-related roles and responsibilities
•Access to and use of service management data
•Toolset configurations and associated documentation
•Defined KPIs and metrics covering:
oProcesses and structural elements
•Operational reporting tools, templates and procedures
•Operational risks and controls
Examples of common operational risks include:
•Lack of communication from higher governance levels causing misunderstanding and lack of buy-in for the new strategic direction
•Lack of understanding of the SIAM strategy by tactical and operational levels, leading to expected benefits of the SIAM program not being realized as actual operation does not comply with the intended strategy
•Contractual obligations not being fully understood or not being met
•Lack of collaboration and partnership
•Bypassing or lack of compliance with processes
•Interfaces between toolsets and/or processes being ‘broken’ because of unilateral changes
•Toolsets being poorly maintained or subject to unauthorized changes
•Controls not being implemented and operated
•Lack of control and discipline around the creation and governance of privileged accounts
•Lack of control and governance around the scheduling of batch jobs and backups, leading to unanticipated impacts for other providers and services
•Poorly thought-out metrics driving negative behaviors
The SIAM governance framework should also include controls to mitigate risks at the operational level.
Within a SIAM model, the customer organization always remains accountable and responsible for corporate governance, corporate risk management and governance of the service integrator. The customer organization should also be accountable and responsible for SIAM governance at the strategic level, including:
•Building and approving the SIAM business case
•Monitoring benefits realization (see section 184.108.40.206 Benefits realization management)
•Approving the SIAM strategy
•Approving key design principles and aspects of the SIAM model, such as the capabilities it will source internally
•Ensuring compliance with regulations and other corporate governance requirements
For aspects such as designing the detailed SIAM model, process architecture and tooling strategy, the customer organization may choose to use external consultants and/or delegate the work to the service integrator. It should, however, be understood that this is only delegation of the responsibility for carrying out the design work, accountability for ensuring that a properly designed solution is produced and approved will remain with the customer organization.
Both the retained capabilities within the customer organization and the service integrator have an interest in ensuring that adequate controls are in place and that services are performing according to design. Controls allow responsibilities to be shared and, where appropriate, delegated to service providers. A success factor for this approach is ensuring that retained capabilities are provided with regular assurance that controls are in place, are measurable and are working. Ownership of controls needs to be agreed, assigned and understood, as well as being maintained over time as staff move roles or service providers change.
The controls and governance enablers should form a comprehensive governance framework, where the interconnection of the components allows them to support each other. Figure 8 shows an example SIAM governance framework comprising different governance components and the relationships between them.
The exact nature of the different governance components will vary depending on the organizations, their governance requirements and the SIAM model being adopted. There are many factors that need to be considered when designing an appropriate governance framework, including tradition, industry, size, maturity and culture. It is important to understand that attempting to force an overly bureaucratic and rigid governance framework onto a smaller organization with an informal culture is unlikely to be successful. Larger and more corporate organizations may expect more formal controls.
The governance framework, along with components within it, such as the SIAM strategy, should be reviewed and maintained regularly. This should consider changing business requirements, industry trends, new technologies and emerging threats. The framework or individual components may need to be updated or adapted to meet evolving requirements and the framework itself should provide the mechanism for doing this through established governance boards.
It is important to understand the difference between the governance roles defined as part of the SIAM governance framework, and the delivery roles that perform activities within the SIAM ecosystem. The focus of the governance roles is to monitor, provide assurance and, when necessary, take decisions and/or actions to exert control and provide course corrections. The focus of delivery roles is to perform the day-to-day activities that are required for the ecosystem to function and for services to be delivered (see Figure 23: Mapping SIAM roles onto the COBIT 5 business framework).
In this section, the following areas will be discussed in further detail:
•SIAM Governance Lead
•SIAM Operational Lead
•Process Owner Roles
The SIAM Governance Lead is a senior role residing within the customer’s retained capabilities. They are primarily responsible for providing assurance regarding the implementation and operation of the SIAM strategy and operating model. The role requires the following knowledge, skills and experience:
•IT governance and risk management
•Knowledge or experience of auditing
•Experience of engaging service providers
•IT operations and large program management
•Excellent communication and reporting skills
•Ability to communicate at all levels, across multiple organizations
The SIAM Governance Lead owns key SIAM governance artefacts, including the SIAM strategy and SIAM model, and is responsible for ensuring that these items are maintained in alignment with business requirements. Responsibilities of the role include:
•Ownership of strategic SIAM governance artefacts
•Setting up the SIAM governance board structure, assuring its successful and sustainable operation, and chairing governance board meetings
•Ensuring that all governance related roles are allocated, understood and performed
•Ensuring the design, definition and implementation of a SIAM governance framework appropriate to the customer organization, culture, the SIAM model being adopted and agreed risk profile
•Ensuring review and ongoing maintenance of the SIAM governance framework
•Working with the project board to oversee governance during transition to the SIAM model
•Working with the service integrator and service providers to ensure successful ongoing operation of the SIAM governance framework
•Identification and management of risks related to governance of the SIAM ecosystem
•Providing assurance to senior management that the SIAM ecosystem is being governed effectively
•Ensuring SIAM operations align to strategic objectives
•Ensuring regular measurement and review of both service integrator and overall performance
•Continual improvement of SIAM governance
•Providing guidance and leadership with regard to governance
The role should be fully defined and its responsibilities documented and agreed formally.
Some customer organizations choose to have their retained capabilities responsible only for holding the service integrator to account and safeguarding the organizational objectives. The remaining duties (such as setting up governance boards, continual improvement, etc.) are delegated to the SIAM Operational Lead, a role often assigned to the service integrator.
Responsibility needs to be allocated for leading and managing the overall operation of the SIAM ecosystem, providing direction and acting as the escalation point for any management issues. The SIAM Operational Lead role normally sits within the service integrator layer, although there may be some exceptions where the role resides within the retained organization because more involvement or control is desired.
SIAM Operational Lead
The role may often be performed by the person with a title such as ‘Head of Service Delivery’.
The SIAM Operational Lead must work closely with delivery leads from different organizations within the ecosystem, along with the process owners and managers who are responsible for the processes being operated. The role will build, operate and improve service delivery across the ecosystem, ensuring that plans and objectives are communicated and understood, and issues resolved in a timely manner. In conjunction with the SIAM Governance Lead, the role is responsible for ensuring that operational governance is in place and followed.
Process owners will exist within the customer organization’s retained capabilities, the service integrator and the service providers. Within the service provider layer, they are responsible for governance of the process(es) within that organization, and alignment with the end-to-end processes operating within the SIAM model.
Within the service integrator, the process owner is accountable for the end-to-end governance and integration of the process or processes within their scope, ensuring that they are properly implemented, managed effectively, functioning as intended and working across all relevant providers and teams. The customer organization retains ownership of any processes that are not governed by the service integrator, for example, contract management.
Assigned process owners
There is not necessarily one individual owner per process. In practice, and depending on the size of the organization, one person could be the owner of several processes. These can be grouped by line of business, lifecycle stage, etc. Within the service integrator, these are sometimes referred to as ‘service architects’ rather than process owners.
The service integrator may need to provide support to resolve interface issues related to processes, for example where a ‘downstream’ service provider needs data from an ‘upstream’ provider. Providing this data may represent a cost with no immediate value to the upstream provider, so it may not be provided freely. The service integrator needs to be able to draw upon appropriate incentives to ensure that interface issues are addressed effectively and in a timely manner.
Process owners own their process documentation, ensuring that it is maintained and readily available to practitioners that are participating in the process. They need to ensure that all process interfaces are functioning and that, where necessary, improvement plans are developed and executed.
Process owners must work in conjunction with process managers to govern and manage processes, ensuring that:
•Staff are aware of the process, when to use it and how to trigger it
•Process documentation is well maintained and available to those who require it
•Process practitioners receive adequate and regular training
•The process, its policies and associated responsibilities are understood by all stakeholders
•Process roles are assigned and reviewed when required
•The process is monitored and controlled to ensure conformity
•Process outputs are of an appropriate quality
•Process risks are identified, assessed and managed
•Adequate resources and skills exist to allow the process to operate effectively
•All interfaces and integrations are functioning correctly
Being a process owner is not necessarily a full-time role. It is possible to be a process owner of multiple processes or combine the role with other responsibilities.
Within SIAM, boards are regarded as structural elements. These organizational entities have specific responsibilities and work across multiple organizations and layers in the SIAM ecosystem. Boards perform a key role in providing governance. They do this by acting as decision-making bodies, which are convened regularly throughout the operating lifespan of the SIAM model. Boards are accountable for the decisions that they make.
Corporate organizations often use the word ‘governance’ to describe both the way boards or their like direct a corporation, and the laws and customs (rules) applying to that direction.
For an organization embarking on the transition to a SIAM model, governance boards must be designed and implemented from the outset to ensure that an integrated, cohesive and clearly understood accountability structure is present for all service providers. Within the SIAM governance framework, there should be several different governance boards, each with its own remit in terms of areas of responsibility. The number and type of boards will vary depending on the size and complexity of the SIAM ecosystem, as well as the culture of the customer and service integrator organizations.
A global organization may require a hierarchy of boards based on geographic areas, with different boards at country, regional and global levels. This decision will need to be based on the degree of variation in terms of services, infrastructures, service providers and cultures between the different geographies.
The board structure should provide governance at strategic, tactical and operational levels. Examples include:
•Strategic: approval of funding, contractual and commercial agreements and strategy
•Tactical: approval of policies
•Operational: approval of (minor) changes to services and processes (Note that a change to a service may appear operational, but depending on the scope and impact of the change it can be deemed tactical or even strategic)
The board structure should be designed to be mutually exclusive; collectively exhaustive (MECE) so that:
•Mutually exclusive: each likely issue or topic is within the purview of one, and only one, board
•Collectively exhaustive: the boards' terms of reference together address every aspect of the service to assure effective governance
Figure 9 shows an example of a governance board structure. Many of the boards are facilitated by senior service integrator roles (such as the SIAM Operational Lead Role), while other boards are run by staff in function-specific roles (such as the lead architect or change manager). SIAM governance retains oversight to ensure that the boards are in place and operating as intended.
Examples of different types of governance boards are described below.
Executive Steering Board
The senior board responsible for strategic decisions regarding the design, transition and operation of the SIAM model. The board sets and publishes policies that describe the governance of the SIAM organization structure. These must be made available to all parties and stored in a shared repository. See section 220.127.116.11 for more details on the Executive Steering Board.
Partnership and Collaboration Steering Board
A joint board, focused on building partnerships and collaboration between the different parties within the ecosystem. The board seeks to promote, encourage, track and reward desired behaviors.
Architecture Governance Board
A board with representation from across the ecosystem, responsible for creating, agreeing and maintaining architectural standards that must be adhered to across the ecosystem. It will also review proposed service designs, identify necessary changes and approve final designs and exception waivers.
This board can be formed from the architecture function of the transition project team, as discussed earlier in this publication. The board is also responsible for actively seeking to encourage technology innovation, understanding new technologies and reducing technical debt.
CSI and Innovation Board
This is a joint board responsible for promoting and tracking continual service improvement and innovation, allowing service improvements to be investigated, prioritized, planned and implemented.
Information Security Standards and Review Board
A board responsible for agreeing information security standards in line with the customer organization’s security policies to be applied across the SIAM ecosystem. It will review proposed designs for new or changed services.
In many organizations, this board would exist outside the SIAM ecosystem. It would set policies and standards to be implemented by the operational boards.
A board responsible for reviewing and aggregating demand, understanding and agreeing priorities, and managing the allocation of resources to programs and projects. Depending on the position of the SIAM ecosystem within the IT function, this board may be positioned at a higher level, outside of the SIAM governance framework.
Service Review Board
A board responsible for jointly reviewing service level achievement, approving short- and long-term plans and activities regarding cross-provider service delivery, resolving cross-service provider delivery issues, identifying and, where necessary, escalating opportunities and issues, and managing cross-service provider risks (see section 5.1.2 Tactical governance boards).
Integrated Change Advisory Board
A joint board responsible for reviewing, assessing and advising on proposed changes that may have an impact across multiple providers, are high risk or ‘significant’ in terms of size or complexity.
In addition to the Change Advisory Board, there will be process-specific working groups and forums acting at an operational level. The groups and forums build cross-service provider partnership and collaboration between SMEs working in process areas (see section 1.7.4 SIAM structural elements).
Board membership must be defined, allocated and agreed, including chairs and vice chairs. The frequency of meetings, schedules, logistics (locations, virtual or face to face, circulation of material for discussion in advance, etc.) and standard agendas must be defined. Terms of reference must be developed for each board, defining its remit, scope and level of authority. Meeting etiquette descriptions can help to set expectations and should be included as part of the process for onboarding new staff and service providers (see also section 18.104.22.168 Onboarding and offboarding of service providers).
The service integrator must agree the SIAM governance framework (including the board structure) during the design of the SIAM model, in collaboration with the customer organization. The framework often changes during implementation. It is important to set out the desired target model and to be prepared to be flexible when required.
Given the important role played by the Executive Steering Board, it is worth exploring its purpose in more depth. Its remit is to:
•Ensure strategic and operational business alignment between the parties in the SIAM model
•Analyze customer, service integrator and service provider business plans, and oversee new or modified services
•Develop strategic requirements and plans associated with services
•Conduct periodic review of governance boards and members
•Resolve issues and exceptions escalated by other governance boards
•Review and agree the assessment of the service integrator’s performance and that of the service providers
•Provide oversight (and assurance) of:
oTransition plan, progress and achievement of critical deliverables and key activities
oOperational performance against service levels and continual improvement adjustments
oGovernance, risk and compliance obligations against policies, standards and regulations
oSecurity reporting, vulnerability and compliance dashboard
oFinancial performance and forecast
oEffective risk management and monitoring, including remediation of audit actions
oTracking against contracted deliverables and obligations
The following is an example agenda for an Executive Steering Board meeting:
•Minutes and actions of last meeting
•Review authority and membership of other governance boards
•Discuss all escalated issues
•Discuss and agree business goals and objectives, priorities and strategy
•Review reports on performance, customer satisfaction and financial issues
•Review results of internal and/or external audits
•Review the risks and issues log
•Celebrate success (many of these meetings are perceived to be ‘dry’, so it can be good to add some positivity and show that there are many things working well)
•Any other business
The Executive Steering Board must ensure that each service provider adheres to relevant company laws and regulation in the delivery of services to the customer organization, as well as to its obligations under contract. It must also confirm that business decisions affecting the SIAM ecosystem have been authorized correctly.
Each jurisdiction has specific requirements for company operation and management of people, along with governance and reporting. Where the scope of the SIAM implementation crosses jurisdictional boundaries, all applicable legal considerations must be considered.
For example, for organizations based in the UK, this may entail the Executive Board gaining assurance that all service providers are incorporated and administered in accordance with the Companies Act and general law.
Another example is that companies that are registered in the USA are subject to Sarbanes-Oxley (SOX) board-level reporting.
Compliance with required legislation is the responsibility of each service provider. The Executive Steering Board must be provided with confirmation that the service providers in each layer of the SIAM ecosystem adhere to all relevant legal requirements. Periodically, there may be changes to national or international law that affect the services and the obligations of the parties. Compliance will need to be maintained by all parties, across all applicable laws and any changes.
Changes in law
The introduction of the General Data Protection Regulation (GDPR) within Europe affects any organization trading with a European customer.
The regulation was adopted on 27 April 2016 and became enforceable on 25 May 2018 after a two-year transition period. Unlike a directive, it does not require national governments to pass any enabling legislation and is thus directly binding and applicable.
The board should have membership from senior executives within the customer organization as well as representation from the service integrator and each of the core service providers. Core service providers are those providers that are taking an active role within the SIAM ecosystem. There may be other service providers (for example, those simply providing commodity-as-a-service solutions) performing a passive role. These would not be expected to regularly attend governance boards (nor would they be likely to be interested in doing so).
Care must be taken to ensure boards are an appropriate size. Too many attendees can make a board unwieldy, whereas too few will lack legitimacy. Members need to have sufficient authority to provide effective oversight of the outputs of the SIAM model. Attendees are expected to:
•Represent and explain their organization’s performance and future plans
•Assess risks and issues to service, customer experience, regulatory concerns and other considerations, and contribute to their mitigation and resolution
•Discuss commercial and/or sensitive issues to assure the quality of the end-to-end SIAM ecosystem
The Executive Steering Board focus areas are:
•Ways of working
•Management and control methods
The Executive Steering Board is accountable for ensuring that policies relating to the delivery of services within the SIAM ecosystem are produced, and are accurate and maintained. The board may not directly create these policies, but it does ensure that appropriate policies exist and are followed.
The policies must be agreed by all service providers, with escalation to the Executive Steering Board if conflicts arise or changes are identified.
The policies must conform to the organization’s quality management standards and procedures, and be subject to review at regular intervals.
Example governance areas requiring policies include:
oApplication of financial controls to the SIAM ecosystem and its service providers
oCommercial aspects of contracts and post-contract delivery
oTimely credit control and cash management policies
•Governance risk and assurance:
oAn effective culture of risk awareness and management maintained throughout the SIAM environment
oService commitments are independently reviewed and approved, with respect to profitability and risk
oRegular monitoring of effective management of delivery
oAdherence to approved business processes through audit
oContinual improvement of business processes
•Corporate services governance:
oConformity to relevant laws and ethics
oBusiness decisions supported by relevant legal advice
oEffective and efficient provision of facilities
oConformity to procurement policies and processes
oCompliance with contractual commitments
The Executive Steering Board is also accountable for ensuring that the processes by which the SIAM model will be governed are defined, implemented and controlled. Performance and compliance with the agreed processes must be reviewed by relevant working groups and forums, with issues escalated to the Executive Steering Board for evaluation and guidance. Where process failures have been identified, corrective action and, potentially, service improvement activities, should be planned and implemented.
Ways of working
Often known as ‘culture’ or ‘custom and practice’, ways of working pertains to the methods by which services are delivered to the customer organization.
Attention must be paid to collaboration requirements from each service provider, and the Executive Steering Board must participate fully in setting the vision for the end-to-end service and the behaviors that must be displayed by each stakeholder.
Examples of planning, instilling, managing and evaluating ways of working include:
•Implementing relationship management processes – particularly focusing on interfaces between service providers and the ‘handoff’ procedures that must exist to protect end-to-end service delivery. This is in addition to processes such as contract management, supplier management and performance management.
•Agreeing methods by which people are transferred between service providers, whether internal or external. Attention must be paid to changes in roles and objectives, the commercial basis of delivering the services and the drivers that may affect decision-making processes (see also section 22.214.171.124 Outgoing resources).
•Understanding that there can be resistance to change from some stakeholders. This resistance is often based on uncertainty, but is nevertheless a legitimate concern that needs to be addressed.
•Recognizing the benefits of taking time to communicate to all affected people, enabling them to understand the objectives, outcomes and expected behavior to support the SIAM model.
•Evaluating and publicizing changes to scope. The SIAM model will change the responsibilities and accountabilities of both organizations and people – there is usually an increase in the level of complexity, and so the need for good definition and clarity around who does what is essential.10
•Applying collaboration agreements, which define a basis from which service providers work together to deliver the end-to-end service (see section 3.1.8 Collaboration model).
Depending on the customer organization and its sector, attention must be paid to the external standards and regulatory requirements that affect services delivered by the SIAM model.
Financial Conduct Authority
As an example, for organizations operating in the financial services sector in the UK, the governance model must conform to the Financial Conduct Authority’s (FCA) requirements, as described here:
“FCA regulations require that financial services (FS) businesses maintain effective control over their operations and closely manage all aspects of risk. The decision to use cloud services (or any third-party service provider) is just another risk that FS businesses must assess, quantify, justify and manage from the outset and as service provider relationships develop.”11
The FCA has recently issued guidance for companies outsourcing to the cloud and other IT services (FG 16/5), expanding on its existing outsourcing rules.
So, what do you need to think about?
•Control and data security: These are at the forefront of the FCA’s concerns. The outsourced process is still your responsibility and companies need to retain sufficient expertise to manage the outsourcing.
•Diligence: Is there a good business case for using the cloud? Is the provider reliable and competent? How will you monitor this? What will you do if it all goes horribly wrong?
•Transition and contingency: Can you effect a smooth transition to another provider, and properly manage and minimize the effect of outages?
It is not always easy to apply existing rules in a new and dynamic context, and the guidance has led to some interesting practical questions, such as:
•Jurisdiction: Can you control where your data is processed? The FCA suggests that businesses agree a data residency policy.
•Access to premises: The FCA still requires that companies, auditors and the Regulator should have physical access to service provider’s premises to monitor performance. This poses challenges with highly secure cloud facilities, but it is up to the customer organization to determine with the cloud provider how this access can be achieved.
Management and control methods
The Executive Steering Board is accountable for the definition and management of a consistent, shared vision for the SIAM ecosystem. This means that the SIAM operating model considers the impact across all stakeholders, embodied by:
•Consistent and well understood cross-service provider processes
•Contracts and service levels with each service provider that support the SIAM model, and cooperative working practices across service providers
•Effective governance boards, processes and controls that enable the customer organization to manage risk, exercise appropriate control and provide direction
•A business change lifecycle that ensures early consideration of how a new service integrates with existing services
•A consistent understanding of the roles of the stakeholders through communication and education
•The empowerment of the service integrator by the customer, with a zero-tolerance policy to non-adherence to the model and processes, ensuring that service providers interface with and support the service integrator appropriately
Many issues can be traced to a lack of clear ownership. Over time, toolsets, documentation, targets, monitoring solutions, controls and reports may become out of date because of a lack of clear ownership and responsibility for their upkeep. Ownership is a key governance concept within a SIAM ecosystem. The number of service providers and changes to service providers creates a volatile environment. A lack of clarity may lead to increased risk because of incorrect assumptions being made.
A grey area
While conducting an assessment within a SIAM model, consultants found that the term ‘that’s a bit of a grey area’ had become part of the organization’s common corporate language when asked about ownership and responsibilities. The expression was heard in almost every interview.
Artefacts within the SIAM governance framework, such as strategies, plans, policies, toolsets and processes, all need to have clear and appropriate ownership assigned, agreed and documented. Ownership needs to be assigned to appropriate roles as it is active and ongoing. There is little value in assigning ownership at either too junior a level (with no experience or authority) or too high a level (with no visibility or focus on the component being owned). The role with the responsibility for owning and maintaining a governance artefact also needs to have access to sufficient budget to support its activities.
Segregation of duties is an important governance concept that needs to be considered when defining the approaches to be used within the SIAM model and associated processes. Appropriate segregation of duties in processes, procedures and tasks ensures that two or more people are always involved in the end-to-end completion of the activity. This is particularly important for activities that might be subject to fraud or other tampering. Segregation of duties provides oversight and helps ensure that errors are identified, while also making fraudulent activities significantly more difficult to conduct.
Segregation of duties
For an internal service integrator SIAM structure, there should be segregation of duties between the internal service integrator role and the retained capabilities. This avoids potential issues, for example, the perception that internal providers are treated preferentially.
This also applies to the Lead Supplier structure, when the role of the service integrator and the service provider needs to be segregated.
Examples of common segregation of duty include:
•Orders raised by one person need to be signed off by a different person
•Requests for new or replacement equipment need to be approved by someone other than the requestor
•Changes to critical services need to be peer reviewed before being released
•Change raisers are not permitted to approve their own changes
•Travel expenses need to be approved by line managers
•Staff in an internal service integrator report to a different management line from the staff in internal service provider roles, to avoid the perception of conflict of interest
•Privileged information available to the service integrator is not shared with an internal service provider unless it is also shared with external service providers
•Reporting on an internal service integrator’s performance is kept separate from reporting on internal service providers
Conflict of interest
In an early implementation of SIAM in a very large organization, there was significant concern about the perception of conflict of interest between the proposed external service integrator and the service providers. There was even a suggestion that the people who bid for the service integrator contract should be excluded from bidding for service provider contracts.
A conflict of interest (CoI) management plan was proposed to allow a single organization to bid for multiple contracts. This included specific training on the CoI plan for all service integrator staff and the path to escalate inappropriate requests and approaches.
Often, controls such as segregation of duties are standard managerial controls that extend beyond a SIAM model and already exist. They need to be reviewed, adopted and included within the SIAM model (see section 2.4 Define principles and policies for roles and responsibilities and 3.1.6 Detailed roles and responsibilities).
Another governance consideration is how to store, control and maintain key SIAM-related artefacts, such as the SIAM strategy, SIAM model definition, plans, process definitions, contracts and policies. These documents contain valuable information that needs to be readily available to the appropriate personnel, without them having to waste time searching for it.
There is also a need to prevent any unauthorized changes to the documents and to restrict access based on roles and responsibilities.
In one example, the service integrator created a schema of classification of data and associated access rights. All operational data types were assigned a default classification. This greatly reduced the effort associated with managing access to documents and formed the basis of access policies.
Different organizations have different approaches to document storage, ranging from unstructured shared drives to complete document management systems with built-in version control and workflows.
Controlled documents are often held on corporate intranets, which may not be accessible by outside organizations, for example, external service providers. This can lead to multiple copies being downloaded and stored, making it impossible to know which version anyone is using at any one time.
SIAM project documentation governance requirements need to be identified. Any existing document management solutions can be assessed to see if they are fit for purpose, or a new solution may be put in place.
Documentation within the SIAM governance framework (such as process and policy definitions) must be reviewed periodically, at least annually and when affected by changes. Reviews ensure it is still aligned with business requirements and remains current. Where necessary, changes are made, and the new document version approved and stored appropriately. It is the responsibility of the respective document owner to ensure that reviews occur.
Although some organizations place important documentation under the control of formal change management processes, this is still not common practice. Serious consideration should be given to using any formal, existing or planned change management process, as this is likely to have impact assessment, approval and notifications of change within its workflow, as well as supporting tooling. Alternatively, organizations may turn to other solutions, such as document management tools, or in smaller organizations, simple procedures involving new document versions being emailed to members of the respective governance board for review and approval.
Governance of SIAM documentation should ensure that:
•Documents have been created, approved formally and signed off by the appropriate authority
•Documents have an assigned and active owner
•There is assurance that the version being used is the latest definitive issue
•Documents are reviewed periodically for alignment and currency
•Documents are easy to locate and visible to authorized users
•Documents cannot be viewed by unauthorized users
•Unauthorized changes cannot be made to the documents
•Changes to the documents are tracked formally, reviewed and approved
The SIAM governance framework should include policies, procedures and responsibilities for risk management. Risk management is the process of identifying and assessing risk, and taking steps to reduce risk to an acceptable level, where appropriate. It is common practice to use the customer organization’s risk management approach as a mechanism to support the transition to a SIAM model.
The organization may already have an approach for enterprise risk management. Even if that is the case, SIAM governance should ensure that there is an appropriate and effective mechanism for identifying, understanding, tracking and managing specific risks to the SIAM ecosystem. Once this is established, information regarding the level of risk may then be shared with enterprise risk management, if required. If the customer organization does not have an established approach, there are best-practice techniques available, such as M_o_R® or the ISO 31000 standard.
Management of risk
ISO 31000:2018 Risk management – Guidelines provides principles, framework and a process for managing risk. It can be used by any organization regardless of its size, activity or sector. Using ISO 31000 can help organizations increase the likelihood of achieving objectives by improving the identification of opportunities and threats, and effectively allocating and using resources for risk treatment.12
The chosen approach determines the processes, techniques, tools and roles and responsibilities for risk management. The risk management plan describes how risk management will be structured and performed on the project. Governance needs to ensure that:
•Risk management policies, procedures and a matrix, or an agreed method to prioritize risks, are defined, documented and approved
•Roles and responsibilities regarding risk management are clearly defined and allocated
•Compliance with defined risk management policies and procedures is made part of service provider contracts
•Time is allocated during process and procedural design, planning sessions, team meetings and reviews to consider, identify and discuss potential risks
•Identified risks are recorded, categorized, tracked, owned and analyzed
•Significant risks, above the organization’s risk appetite, are addressed, even if this is ‘merely’ a recorded decision by management to formally accept the risk
•Contingency plans are made where necessary for the occurrence of particular risk events
•Risks are reviewed regularly in case their nature, likelihood or potential impact has changed
The first step in creating an effective risk management system is to understand the distinctions between the types of risk that organizations face, for example:
These are internal risks, arising from within each organization, that are controllable and ought to be eliminated or avoided. Examples are risks from employees’ and managers’ unauthorized, illegal, unethical, incorrect or inappropriate actions, and the risks from breakdowns in routine operational processes.
Each organization must define ‘a zone of tolerance’ for defects or errors that would not cause severe damage to the enterprise or transition project, and for which achieving complete avoidance would be too costly. In general, they should seek to eliminate these risks.
This risk category is best managed through active prevention, monitoring operational processes and guiding people’s behaviors and decisions toward desired norms. There are many sources of information available to guide an organization through such a rule-based compliance approach, which provide adequate guidance for use within a SIAM project.
Strategic risks are quite different from preventable risks because they are not inherently undesirable. The customer organization will voluntarily accept some risk in order to generate superior returns from its strategy.
A strategy with expected high returns generally requires the organization to take on significant risks, and managing those risks is a key driver in capturing potential gains. For example, BP accepted the high risks of drilling several miles below the surface of the Gulf of Mexico because of the high value of the oil and gas it hoped to extract.
Strategic risks cannot be managed through a rule-based control model. Instead, these risks require a risk management system designed to reduce the probability that the assumed risks materialize and to improve the organization’s ability to manage or contain the risks should they occur. Such a system would not stop organizations from undertaking risky ventures, to the contrary, it would enable them to take on higher risk, higher reward ventures than they could with less effective risk management.
A transition to a SIAM model can be considered as a strategic risk, for customers, service providers and the service integrator.
Some risks arise from events external to the company and are beyond its influence or control. Sources of these risks include natural and political disasters and major macroeconomic shifts. As a transition to a SIAM model usually increases the number of different parties in an ecosystem, the external risks are likely to increase as well.
External risks require a different approach. As companies cannot prevent such events from occurring, they must focus on proactive identification and mitigation of any impact. Consider examples from the organization’s history and scenarios of its possible future, which will enhance communication and help executives understand more easily the context in which they are operating.
The scope of SIAM
Techniques such as the Cynefin™ approach are useful here. Cynefin allows decision makers to see things from new viewpoints, assimilate complex concepts and address real-world problems and opportunities.
Organizations should tailor their risk management processes to these categories. Although a compliance-based approach is effective for managing preventable risks, it is wholly inadequate for strategic risks or external risks, which require a different approach based on open and explicit risk-based discussions.
A control needs to be defined for each risk. Viable, effective controls will be:
•Appropriate to the risks they are addressing
•Aligned to the strategy
•Stable and repeatable, so that they operate in the expected manner each time
•Verifiable, so that it is possible to check the existence and operation of the control
•Collaborative, so that key stakeholders are part of decision making, control design and control implementation
•Owned, so that someone is responsible for the control being implemented and operated as designed
Figure 10 shows the relationships between assets, threats, vulnerabilities, risks and controls. A risk occurs when there is an asset that has a vulnerability to a particular threat. Where the size of the risk is above the organization’s risk appetite, and the asset or threat cannot be removed to eliminate the risk, one or more controls should be put in place to mitigate the risk.
It is good practice to use a combination of different control types when addressing a risk. Common control types are described in Table 1:
|Directive||Controls that reduce risk by providing direction and guidance||
|Preventative||Controls that reduce risk by preventing or at least reducing the likelihood or impact of the risk occurring||
•Segregation of duties
|Detective||Controls that detect when a risk event is either occurring or about to occur||
•Monitoring expenditure against budget
•Event monitoring toolsets
•Trend analysis on metrics
|Corrective||Controls that trigger some form of corrective or recovery action should a risk event occur or be about to occur||
•Defined procedures followed for security breaches
A number of controls may be aimed at managing the risk of ‘expected benefits not being realized from the SIAM program’. Example controls are illustrated in Table 2:
|Formal review and approval of business case and expected benefits||Preventative||To help ensure that the business case and its expected benefits are appropriately defined, of sufficient quality and are achievable|
|Program change approval process||Preventative||To prevent changes being made to the objectives, scope or execution of the program without proper consideration of the impact on expected benefits|
|Regular monitoring of expected and realized benefits||Detective||To determine whether benefits realization is on track to achieve expected results|
|both during and after the program|
|Regular benefits realization reviews||Corrective||Regular reviews of expected and realized benefits to identify whether any corrective actions or initiatives need to be undertaken to help ensure targets are achieved|
The risk management processes for the SIAM transition project will be similar to those that are to be used within the operational SIAM model, and can be handed over as part of the Implement stage (see section 4.2 How to transition to the approved SIAM model).
The SIAM Governance Lead should work with internal audit personnel to ensure that key controls are audited regularly to provide assurance that required controls are in place and functioning effectively. Relevant audit policies, plans and schedules should be developed and maintained. Any audit issues identified must be owned and monitored through to resolution.
Some organizations may choose to adopt standards such as ISO/IEC 20000, either purely as a reference or with the aim of achieving certification against the standard. When adopting a standard, it is important to check whether it has been written in a way that allows it to be used within a SIAM ecosystem.
The management of suppliers (including external service providers) and contracts needs to be a core capability within any SIAM ecosystem. The aim is to build an overall culture of partnership, collaboration and innovation rather than one of ‘rule by contract’. ‘Rule by contract’ is a situation where frequent debates occur around what is and is not agreed in contracts and the additional costs that may be charged or the penalties that may be levied. Ideally, better supplier and contract management starts from a foundation of cost transparency and fair pricing.
An example of unfair pricing
There is little point in entering into a contract with a service provider where prices have been driven down to such a level that the service provider cannot possibly even break-even – unless they charge extra for every small additional request not covered in the contract.
This approach almost always leads to a poor relationship, where the customer organization feels that everything it asks for comes with a price, and the service provider becomes frustrated because any small innovations or improvements it suggests are not progressed because they would have to be charged for, since the contract margins are so low.
Often, one of the aims of adopting SIAM is to move from a situation where the customer organization is very constricted, possibly by a single, monolithic outsourcing contract, to a situation where it gains more flexibility. This allows it to place different services with whichever service provider – internal or external – has the best offering or most attractive price point at the time. This flexibility requires due consideration within the strategic and design activities where EA considerations are planned and created. The ability to easily onboard, transition between and offboard service providers as requirements or offerings change, is one of the key benefits of a SIAM model.
SIAM contracts often have a shorter duration to prevent lengthy tie-ins, and are structured to allow flexibility in terms of future changes to services and how they are delivered. However, in some instances, the nature of the relationship required between the customer and service provider requires longer term contracts to provide enhanced relationships and a greater degree of stability.
The supplier and contract management function needs to subscribe to and support the SIAM model. Therefore, it is important that cooperation is established as early as possible in the SIAM implementation, between the project team and the supplier and contract management function. The project team and, once appointed, the service integrator, should obtain input and guidance from the supplier and contract management function throughout the entire lifecycle of a service provider contract. Typically, the service integrator will have a central role in aspects such as change management, service performance management and supplier management, working with the customer-retained capabilities’ contract management function.
Often, supplier and contract management will belong to a part of the organization outside IT, but this activity cannot be completely isolated from IT. Adopting a SIAM model is an organizational and cultural change initiative. SIAM often has a role in integrating services that extend beyond IT but rely upon IT, such as finance and accounting, human resources (HR) services or other business processes. As such, the whole organization, including senior management and the supplier and contract management function, needs to understand the benefits and be fully committed to the program.
Organizations planning their SIAM operating model and the future service provider landscape may want to establish design principles. These can be converted into constraints, which may restrict the scope of service that an individual service provider can bid for or take on. This prevents unhealthy monopolization by one service provider, either internal or external. Constraints may also prevent a service provider bidding across layers, for example, being the service integrator and a service provider (so removing the possibility of a Lead Supplier structure).
Although it is not uncommon in SIAM environments for organizations to be both a service integrator and a service provider, some customer organizations may make the decision to prohibit this. This allows the service integrator to focus on its integration responsibilities with no question of unfairness or potential conflicts of interest between the service providers (see section 1.6.4 Lead supplier as service integrator). Note that it can sometimes be commercially difficult to achieve profitability as a lone service integrator, and therefore this function is often bundled with other services, albeit with separate contracts.
The governance of contracts with key service providers needs to involve regular review meetings and measures to assess personnel changes. This ensures that when changes occur, in either the customer organization or a service provider, new people are engaged as early as possible and brought into the preferred way of working to assure consistency of approach (see also section 3.1.2 Sourcing approach and the selected SIAM structure).
Governance needs to ensure that:
•There is a defined and effective framework for managing service providers and contracts that is aligned with the specific requirements of SIAM
•There are appropriate levels of contract management resources, knowledge and skills in place to enable the framework to be designed and operated successfully
•Roles and responsibilities are clearly defined and allocated
•Contracts consider the full contract lifecycle, including responsibilities and deliverables
•Governance of key service providers and contracts is active and effective
•Contracts identify the service integrator as the agent of the customer organization, whether it is internally or externally sourced
•Service provider performance is measured and reported at agreed intervals against contracted commitments and service performance measures, with an agreed approach to address any shortfalls
•All service providers within the ecosystem are treated equitably
•Service provider targets are aligned with end-to-end service levels
•Controls are in place to ensure that contract review, renewal and end dates are tracked, so that timely action can be taken where necessary
•Steps are taken to prevent contractual relationships being affected when personnel or senior stakeholders change in any SIAM layer
•Contracts, wherever possible, follow a standard template with well-defined terms and conditions, escalation and dispute procedures
•Contracts incorporate clauses that promote collaboration and innovation
•Contracts allow for future flexibility in terms of changes to services and delivery mechanisms
As part of supplier and contract management, significant attention and planning must be given as to how:
•New service providers will be onboarded into the ecosystem
•Service workloads will be migrated from one service provider to another at the end of the contract
•Outgoing service providers will be offboarded
The effectiveness and efficiency of these transition projects is a good indicator of the maturity of the SIAM operation. These transition points involve risk, so the SIAM governance framework needs to ensure that they are identified, understood and managed. There should be defined procedures for onboarding and offboarding service providers, and for managing the transition of service workloads between different service providers. The procedures should be supported by clauses in service provider contracts.
Each time a service provider is onboarded or offboarded, it should be treated as an improvement opportunity with the corresponding procedures being improved over time, as lessons are learnt.
An important part of SIAM governance is being able to monitor, measure and understand how the ecosystem is performing. Without pertinent, accurate, up-to-date information, it is impossible to make timely and correct decisions, trigger effective corrective actions and understand whether plans are being successful.
Service performance measures whether a service is meeting defined business requirements. Trend analysis is vital as it is difficult to judge performance by individual numbers or metrics. Whether performance is improving also needs to be assessed.
With a SIAM environment, there should be a shift from satisfying contractual targets to focusing on end-to-end service performance, innovation, collaboration and meeting the customer organization’s changing needs. That is not to say that measurement against contractual service targets held in SLAs or operational level agreements (OLAs) is not important, but it is a basic expectation, not the primary focus. It is still important to understand and govern performance against service targets. This may include a whole range of service considerations, such as availability, incident response and fix times, resolution times for common requests and actual system response times. These measures contribute to demonstrating that business needs are being met, and may indicate opportunities for sharing innovation, good practice and lessons to be learnt.
In a SIAM ecosystem, measuring performance is important to both the customer-retained capabilities and the service integrator, but for different reasons. The customer organization is typically interested in:
•Overall performance of the SIAM model and the services being delivered, to understand whether the strategy is working successfully, providing value and meeting its needs.
•Performance of the service integrator, to understand if the service integrator is performing as expected and achieving the levels of collaboration, integration and innovation it is required to deliver.
The service integrator is responsible for providing assurance of the performance of individual service providers and the end-to-end service, so that expected outcomes are delivered to the customer organization.
The service integrator will be interested in:
•The overall status of each service being delivered, to understand how the service is performing when aggregated across all relevant service providers.
•Individual service provider performance against service targets, to understand where issues or opportunities for improvement may exist. For example, if one service provider is consistently attaining better results in a particular area, this may indicate a ‘good practice’ that can be discussed and potentially adopted by other service providers.
Although it is commonplace for contracts to have clauses that enable remedies to be applied for the failure to meet agreed service targets, it is important to remember that a SIAM ecosystem is built on a culture of collaboration and partnership, rather than a culture where there is regular debate on whether penalties should or should not apply.
When service targets are not met, the initial focus should be on working together to drive improvement and resolve any issues. Contractual remedies should be applied consistently, to ensure that all service providers are treated equally and without any ambiguity. It is desirable to reward service providers that demonstrate a willingness and capability to improve.
Penalties related to lost value
Some contracts attempt to make the remedy relative to the service failure (for example, the loss of value to the customer). If there is no relation between the failure and the loss, it can cause the service provider to resent a ‘massive’ penalty for a ‘minimal’ failure. A remedy deemed to be disproportionate could result in the reduced impact of the remedy, in terms of loss recovery and its ability to act as a deterrent.
However, this approach can also lead to issues, as it confuses penalties for service failures with consequential loss or damage. Consequential loss or damage is defined by specific legal requirements usually covered separately in a contract.
Service targets need to be created carefully, because metrics drive behavior – also known as the ‘observer effect’. People do what they think they need (or want) to do, and are more likely to pay greater attention if they know it may be inspected. However, rigid interpretations of some targets can lead to counterproductive behaviors, especially as pressure to meet the target increases.
People do what you inspect, not what you expect13
A service desk had a metric to answer 100% of incoming phone calls within a maximum of three rings.
The service desk staff soon learned not to pick up any phone that rang more than three times, leaving it to ring until the caller hung up, allowing them to achieve their target.
When designing a new measure or target, consider both the positive and negative behaviors that might arise as a result. Service providers need to adhere to the ‘spirit’ of the agreement as much as the ‘letter’, and targets should be defined in such a way as to encourage this.
Problem management targets versus outcomes
An example might be setting a target of reducing the number of open-problem records for a particular service, month on month.
Although the target might be set with good intentions, expecting to drive service improvement, it might result in the teams responsible for the service deciding not to log new problems when they find them, as that will reflect negatively on the metric.
Governance needs to ensure that:
•Defined policies and procedures are in place to monitor, measure and report on performance.
•Roles and responsibilities are clearly defined and allocated correctly.
•Appropriate toolsets are in place and configured to support monitoring, measurement and reporting of performance.
•Adequate resources are allocated.
•Performance metrics and reports are reviewed regularly and, where necessary, action is taken.
•All targets set are SMART (Specific, Measurable, Agreed, Relevant and Time bound).
•Metrics, measures and reports are maintained and updated or changed when necessary to ensure they remain relevant to business requirements.
As collaboration and partnership between the different organizations is one of the differentiators of a SIAM environment, it follows that this should be an important measure of how an organization is performing within the ecosystem. The challenge is defining what ‘collaboration’ means and how to measure it. This is not an activity that is easy to define, and different organizations will have different ideas regarding how to approach this.
A few examples are:
•Measuring attendance to collaborative process forums, for example, if a major service provider is regularly attending and participating in the governance boards
•Conducting and assessing periodic collaboration questionnaires
•Asking each organization to nominate the service provider within the ecosystem that they feel has been most collaborative during a measurement period, and recognizing the organization with the most nominations
•Monitoring the number of disputes within the last quarter related to each service provider
•Using measures to build a balanced scorecard approach, perhaps including:
oNumber of service improvements implemented
oCustomer satisfaction scores improving
oChanges in volumes, for example, a reduction in incidents, an increase in problems being identified or a reduction in failed changes
Another difficult consideration can be how to measure and compare the performance of service providers when they are delivering different services. One service provider may receive more incidents than others, but, if it is responsible for an archaic legacy service or a service that is undergoing a significant level of change, it may be justifiable. Another service provider may always take longer to fulfil requests, but this could be because of the nature of the requests it receives.
The measures and targets set must always be appropriate to the individual service provider and the services it is supporting. Then, service providers can be compared in terms of how often each provider has achieved or missed its own targets.
The SIAM governance framework must include controls to ensure that demand is recognized, validated, aggregated, monitored and allocated appropriately. Without these controls, there will always be a tendency for:
•Business units requiring new services to approach the service providers they are most familiar with, rather than those that may be able to offer the most cost-effective delivery.
•Requests not being aggregated, leading to a complex spread of many similar but non-standard services, rather than standardized services that take advantage of economies of scale.
Governance needs to ensure that:
•Demand requests for new or changed services are fed into a central point where they can be analyzed and understood (for example, the service integrator or the customer organization’s retained capabilities).
•Current and future demand for services is monitored, analyzed, anticipated and understood. This allows services to be provided, scaled up, downsized or retired to ensure that required service volumes can always be met, while excess capacity does not result in unnecessary costs.
•Where possible, demand from different areas of the business should be aggregated to enable the design and provisioning of standardized services, reducing complexity and cost.
•The impact of changes in demand is quantified and any amendments to the SIAM model necessary to accommodate the changes are reported to the Executive Steering Board and are appropriately authorized and resourced.
Changes in demand
There can be changes in demand owing to seasonal activity or events in the business cycle.
The food industry may need different SLAs around harvest time, whereas a manufacturer may require more stringent controls in the time leading up to a product launch.
Governance controls for demand management should include:
•Defined process and policies for demand management.
•Roles and responsibilities clearly defined and allocated for demand management, in all SIAM layers.
•Adequate resources allocated to performing demand management activities.
•Countermeasures to prevent business units bypassing the governance framework and creating their own ‘shadow’ arrangements.
•Regularly reviewed metrics and measures to monitor the performance of the demand management capability and drive continual improvement.
As part of the Discovery & Strategy activities, the SIAM project must define the principles and policies that will guide the definition of roles and responsibilities during the Plan & Build stage (see section 3.1.6 Detailed roles and responsibilities).
It is recommended that a baseline inventory is created so that there is a clear means to address the question, “What skills do we have?”.
Many organizations fail to define roles and supporting skills clearly, resulting in individuals being asked to perform tasks beyond their ability. Conversely, organizations may include individuals who have skills that they are not using. Creating role profiles first and assessing people against them, risks missing skills that already exist in the organization but are not being used or maintained.
It is crucial to define principles and policies for roles and responsibilities for the customer organization (including the retained capabilities), the service integrator and the service providers within the planned SIAM model. Once role profiles are created, they can be compared against available skills and plans made to develop or procure the required skills and experience.
It can be useful to use a standard framework when defining the skills for each role, as this helps to ensure a consistent understanding across all layers. Use of a ‘common language’ for describing skills is also beneficial, compared to any proprietary skill definition, which may only have relevance and understanding within one and not all parties within the SIAM environment. It is important to be clear and unambiguous about the skills and level of experience required when recruiting, whether that be for permanent staff, service providers, contractors or temporary staff.
The Skills Framework for the Information Age (SFIA®)
SFIA provides a common language for the skills and competencies related to information and communication technologies, digital, software engineering, cyber security and other technology-related roles.
SFIA is used in a number of ways, including for individual assessment to confirm the current skills inventory, definition of role profiles and job descriptions, identification of skills for projects and other change initiatives, gap analysis and development action planning to help individuals and their organizations.
Every role in a model requires a specific set of skills. Defining these and ensuring people have the right skills for each role increases the likelihood of success. This applies equally to internal and external staff (such as those from external service providers or contractors).
Japanese iCompetency Dictionary (iCD)
There are several locally developed frameworks in existence, for example the Japanese iCD. The Japanese IT Promotion Agency (IPA) that produces the iCD, has collaborated with the SFIA Foundation to map iCD to the SFIA framework.
e-Competence Framework (e-CF)
The European e-Competence Framework (e-CF) provides a reference of 40 competencies as applied at the information and communication technology (ICT) workplace, using a common language for competencies, skills, knowledge and proficiency levels that can be understood across Europe.
The following principles for defining roles and responsibilities are useful when designing the SIAM strategy and outline SIAM model. They should be used to support the definition of roles and responsibilities in the Plan & Build stage:
•Roles and responsibilities must support the goals, objectives and vision for the SIAM ecosystem, as defined in the SIAM strategy, outline and full business cases.
•All definitions must be relevant to the SIAM model. Generic definitions from another model can be a useful starting point, but must be reviewed against the design for the ecosystem to ensure relevance.
•All defined roles and responsibilities must include necessary capabilities, skills, competencies, knowledge and experience.
•There should be a set of distinct definitions for the roles within the customer organization, retained capabilities, the service integrator and the service providers with a clear demarcation.
•Definitions should recognize that the service integrator is the customer organization’s ‘agent’ and, as such, takes a governing position within the ecosystem.
•Definitions should include integration and collaboration responsibilities where appropriate.
•Roles and responsibilities must cover all stages of the SIAM roadmap, recognizing that different skills and competencies will be required at each stage.
•Where there are existing contracts that will continue to be used in the new SIAM model, any roles and responsibilities defined in them must be reviewed and, if necessary, updated.
•Clarity of roles, responsibilities and ownership is especially important when the model is operated over multiple geographies, locations (sites) and organizations. In these complex environments, there is a higher risk of roles being duplicated or not being filled.
•It is advisable to use a consistent skills framework.
•When a skills framework is used, focus on SIAM role requirements and use appropriate skills and levels to describe what is needed.
•Resources, roles and responsibilities are required to run existing services as well as developing and implementing new ways of working. It is often necessary to create role profiles for initial implementation and transition that are different from those required for ongoing operation of the SIAM model.
•When defining roles and responsibilities, consideration should be made to any changes affecting existing staff (see section 3.2 Organizational change management approach).
•Requirements for segregation of duties should be considered at all layers and for all roles (see section 2.3.9 Segregation of duties).
•The overall structure and division of responsibilities should be subject to ongoing audits, review and continual improvement, to ensure roles are conducted as defined and continue to be appropriate – reflecting changing business and customer needs.
When individuals are asked to take on roles in addition to their normal ‘day job’, it is necessary to assess whether they have the required level of authority, autonomy, influence, capacity, skills and experience to carry out what is required successfully.
It is vital to understand the current and expected future state of the organization’s internal and external environment before the SIAM strategy and the outline business case can be created, and the outline SIAM model is designed.
Mapping the landscape to create a baseline assessment provides information on the situation the SIAM transformation aims to change (the ‘as-is’ position). It provides a critical reference point for assessing changes and their impact, as it establishes a basis for comparing the situation before and after a change, and for checking the effectiveness of the project. Baseline information should be collected in such a way that the same type of data can be reacquired after the project, to compare the results and assess the extent, or lack of change achieved.
Sources of information for baseline assessments include:
•Analysis of existing documentation, including contracts, process descriptions and role descriptions
•Analysis of service performance reports
•Analysis of existing artefacts, such as toolsets, service catalogs, etc.
•Formative situation analysis
•Service management maturity assessment
•Process maturity assessments
•People capability assessments
These determine the starting position that can be used to identify any gaps in capability and resource. When mapping the landscape of the current service model, the following areas are important to establish and communicate:
•Current service providers (internal and external)
•Customer attitudes to the service, including satisfied and unsatisfied needs
•Stakeholder objectives and assessment of their position (influence and favor)
•Current service performance
•Technical landscape – including out of maintenance components, vulnerable elements, licencing and standardization
•Assets, configuration and architecture
•Existing contractual positions, including obligations and tenure
•Contractual rigidity and incentives
•Service provider and supplier cost modeling and flexibility
•Commercial, technical, service fit and obligations
•Financial model and budget
•Process, service and technical interfaces, interactions and dependencies, identifying broken links and single points of failure
•Service components that are due to change and when, including critical dates
•Flexibility – existing and required
•Existing personnel, their skills and capabilities
•Staff strengths, weaknesses, performance, aspirations and vacancies
•Critical or hard to obtain skills
•Jobs market and the ease by which resources may be recruited, disengaged or retained
•Any ‘known unknowns’ or upcoming change
It is useful to express these in terms of a statement of requirements (SoR) and a ‘data room’.
A data room is a place where all information regarding an organization or situation is stored, such as a library, where people can go to learn about the organization or situation and check facts and data. The types of data that can be stored are not limited, but examples of what could be included are:
•Organizational structure and business operating model
•Business strategy documents
•IT strategy documents
•Operating model and structure
•Charging model, including whether IT runs as a not-for-profit model, cost model or profit model
•Service catalog(s) confirming the volume of services and their users
•Service reports (ideally for a minimum of 13 months) to provide information on trends in performance
•Contracts – who supports IT, how and for what?
•HR information on number of employees and how they are split across the organization
•Risk registers, issues registers
This list is not exhaustive but illustrates that the types of data held in a data room can be as varied and as inclusive as necessary. Data rooms often support commercial activities to allow lawyers, analysts and procurement professionals to interrogate the data for information.
A data room can be physical or virtual. This will depend on the preference of the stakeholders involved. The data room will be made available during the due diligence period of contract negotiations, but is often populated as soon as the decision has been made to go to market. Access to it will be restricted as it often contains highly sensitive information. Non-disclosure agreements must be signed by all parties.
Mapping the landscape produces a picture of the services currently provided to the organization. It is also important to look externally and establish the commonly encountered market offerings outside the organization. This includes assessing what is offered, by which service providers, to organizations of a comparative size.
This analysis should include assessing potential external service providers and external service integrators, and the SIAM models in which they operate. Organizations can look outside their industry and geographic area, but they must realize that different drivers can affect choices made by organizations in those sectors.
For physical IT products, many offerings are fairly standard and comparable, for example, data center hosting and commodity cloud services. Other services may be more flexible or even include combined standard and non-standard offerings, for example, standard applications with customized levels of application integration, coupled with support and hosting.
The same is true for external service integrators. Most have a standard core offering with additional options and many also offer customization.
Caution should be taken in deviating too far from the norm. Customization creates variation and this can result in additional costs and complexity that outweigh the value achieved. A standard offering can be more easily replaced than a non-standard one, often referred to as ‘loose coupling’.
The customer organization should establish the variables in the sourcing model:
•Which services are commonly combined (for example, end-user computing and service desk) and why?
•Which services are commonly offered as standard services (for example, cloud services) and which are customizable?
Many service providers set a minimum viable size of a contract, often expressed as annual contracted value. If the contract structure that the customer organization is considering implies a smaller value than this, then the potential service provider may suggest combining services to increase the value of the contract or may decide not to bid.
As the customer organization formalizes its strategy and defines what it would like to invite service providers to bid for, a good approach is to test the plans informally with a sample of service providers. If this is carried out before proceeding further into the decision-making stage, and honest feedback is received from trusted and established service providers, this may avoid issues later on.
Open discussion to evolve understanding
A public-sector organization planned to adopt SIAM but wanted to explore possible approaches before finalizing its SIAM strategy. It used a government marketplace tool to find potential external service integrators. It was invited to attend an open discussion on the service integration marketplace and the customer’s objectives.
The customer provided information on its services, internal capabilities and desired outcomes from a SIAM implementation, and invited discussion. The service integrators gave their views and offered advice on potential SIAM models that might be appropriate for this customer.
This helped the customer to understand what its options were and to confirm its requirements before launching formal procurement notices.
Well-regarded service providers are likely to have more opportunities than they can pursue. They may be selective about the opportunities for which they bid, as the process can require significant investment in time and money, can last many months and require a strong team. Large service providers tend to prefer working with large customers. A small customer, or a small request, might not be attractive to large service providers, and it is more likely to obtain better responses from smaller service providers.
A deluded buyer
A small organization within the UK health service needed to renew its IT services across a commonly encountered set of services. It decided to adopt a SIAM model and defined six service ‘lots’.
After many months’ effort and much expenditure preparing the procurement documentation, and ensuring conformity to regulatory requirements for government procurement, it went to market.
The product of its initial market engagement was a procurement charge of £1.2m, two vaguely interested service providers and no bidders at all for one of its six lots. The procurement failed.
Some organizations like to validate a decision with research before finally making a commitment. Analysts have a role in this validation, but it is important to recognize that they often make their money by selling research to customer organizations as well as to service providers. The best analysts can accelerate a market survey and support their assertions with facts. The worst are partisan or biased, and may recycle what they have been paid by a service provider to develop, repackaging it for a customer.
Benchmarkers collect contract data and construct models that are designed to provide evidence-based price comparisons. This data can be useful in supporting ‘what-if’ analysis rapidly, to give an indication of what each option would be likely to cost in the market. Such data is a proxy for market data, being much quicker and cheaper to obtain than fully worked out quotations. Benchmark data is also used in longer agreements to ensure that the price quoted is in line with the current market price.
Advisors are often hired by organizations to support them in the design and implementation of the SIAM model. Customer organizations must check that the advisors have knowledge of a broad range of SIAM models, their procurement and implementation, and that they do not favor one model or service integrator. By being experienced in the process and aware of the leading service providers, advisors can bring rigor and methods that accelerate the process for a customer. This can reduce the costs of sale for the service providers. Advisors can also draw on and apply analysis and benchmark data.
Some external commercial organizations combine analysis, benchmarking and advisory services. It is good practice to get independent advice as organizations that are also service integrators as service providers may favor their own SIAM model over others.
“The power or ability to do something.”14
Capability includes people, processes and tooling.
To support the design of the SIAM model and the decision about which SIAM structure to adopt, it is necessary to assess the organization’s current state and existing capabilities to confirm its maturity levels. This exercise will help the organization to identify the capabilities in its current operating model that are not at the desired level of maturity, and whether it has the capability or the appetite to address the shortfall. Organizations often use an external adviser to support their maturity assessment and to provide an objective view of their capabilities.
This assessment should also be conducted as part of the later roadmap stages by potential service integrators and service providers that would become part of the SIAM ecosystem. It is recommended that all organizations assess their staff’s skills and use this as a baseline for evaluating the requirements and risks associated with the project, operation and the underlying business case and benefits.
Baseline capability assessments should be carried out before the transition project commences. These help to understand the ‘as-is’ situation and form the baseline for the desired future ‘to-be’ situation.
An honest assessment
Unfortunately, many organizations ignore assessment activities to save time or resources.
Other organizations conduct internal analysis and create outputs that are wildly different from reality. Organizations may be overly optimistic, so they receive a surprise during the Plan & Build stage when the reality does not match the assessment outcome and the required capabilities are missing.
The capability assessment consists of two major phases:
1.Creating a current state capability portfolio
The first step is to identify the organization’s current capabilities for the SIAM model. These can be a combination of service management processes, operating functions, practices, project and program methodologies, and supporting tooling and technologies. The obvious starting point is the current operating model and responsible, accountable, consulted, informed (RACI) matrices for processes. Every capability currently provided within each function and team should be identified and mapped to the operating model.
The current state capability portfolio should be compared with the SIAM vision and objectives and the target SIAM model. An objective of the capability assessment is to identify how well the current capability portfolio supports the SIAM strategy. Recommendations should be made about the capabilities to be retained within the service integrator layer, which to mature within the customer organization and those for which an external service provider should be chosen. This will help to identify which SIAM structure is most appropriate. For example, good capabilities might lead to an organization choosing an internal service integrator rather than an external service integrator or a hybrid structure.
It is important to agree the scope of any assessment, for example, the processes and functions to be included, which documentation is to be reviewed and the methods to be applied. It is also necessary to agree if the assessment is to be managed internally by a quality team or internal auditor or if an independent assessor should be used.
There are several approaches to performing an assessment, including individual or group stakeholder interviews, or process walkthrough workshops with process owners and managers. Assessments should be based on industry best-practice frameworks and standards, such as ITIL or SFIA, and should assess:
•Process adoption and consistency across the organization
•Business alignment and value
•Process metrics and measurements
•Supporting service management tooling
•People, including organization, roles and skills
•Current levels of integration for people, processes and tools
•Levels of continual improvement for processes and functions
Note that these assessments need to focus on the SIAM practices for processes, capabilities, roles, etc. and not ‘traditional’ service management maturity.
Example inputs to the assessments will be:
•Existing capability model
•Stakeholder maps – including process/capability owners and managers
•Industry frameworks and standards
•Current processes and procedures
•Current RACI matrices
•Process touch points and interfaces
The expected outputs from the capability assessments are:
•Current state assessment
•Capability heat map
•Individual capability maturity levels
•Retained organization training and development plans
•Individual process maturity levels
•The feasibility of addressing improvements or gaps with customer organization resources
•Draft future state model
A heat map is a graphical representation of data where the individual values contained in a matrix are represented as colors. Heat maps are often used to summarize findings ranging from areas that require attention (‘hot’) to those that are well established/stable/mature (‘cold’).
Health checks and maturity model assessments are forms of operational benchmarking in which the quality of an aspect of a service is compared to external norms in a structured manner. Some of this data is statistically valid and some is supported by benchmark data obtained from a variety of comparative organizations.
The purpose of conducting these assessments is to check whether the area under review functions as it should, to identify corrective actions or improvement opportunities, and to measure its effect in achieving the expected results. Typically, these actions can be managed through continual improvement activities. However, if any findings have the potential to affect the success of the SIAM model or the transformation, these will need to be addressed through the transition project. In the context of sourcing, it helps to consider checks and maturity models, such as:
•CMMI for Service (CMMI-SVC): administered by ISACA, provides an approach but not comparative data for service management. Can be independently assessed for certification purposes.
•SFIA: a framework of internationally recognized descriptions for responsibility characteristics and skills practiced at various levels of responsibility and experience by people working in IT-related roles.
•IACCM (International Association for Contract and Commercial Management): benchmark contract management process performance.
•One of many ITIL maturity assessments or the COBIT15Process Assessment Model (PAM).
There are also frameworks to which current practice may be compared. Useful examples include:
•Service management: ITIL
•Project management: PRINCE2, PMBoK or the Association for Project Management (APM)
•Program management: Managing Successful Programs®
These are non-prescriptive (as opposed to standards) and may be adopted and adapted to meet specific requirements. This is important, as these models, assessments, frameworks, practices, benchmarks and approaches are not necessarily tailored to the specific requirements of a SIAM model and so need to be adopted, used and interpreted.
The majority of SIAM transition projects do not start from a ‘greenfield’ situation. More regularly, a transformation is proposed to change one or more existing delivery models, where service providers, internal resources and services are already in place. The SIAM model and supporting processes may, in part, be based on the existing processes of current service providers and internal capabilities, or may have to operate within a wider enterprise process framework (EPF). Regardless of whether the proposed processes are entirely new or not, any parties undergoing transition to the model need to understand the starting point.
A process maturity assessment may be required, particularly if the future model is built upon or developed from an existing model. A maturity assessment can provide a baseline of the current process capabilities across the organization. It will support identification of existing good practice or weaknesses, both across the overall organization and within each part of the organization. For instance, CMMI® for Service provides a well-framed assessment, although it is more for traditional service delivery processes, not necessarily those applicable in a SIAM model.
Many SIAM projects have limited time to execute the Discovery & Strategy, and Plan & Build stages of the roadmap. If this is the case, the customer organization might have to compromise on the time spent on the current state assessment. A more pragmatic approach may be to ‘go with what is there’ and make changes as the project unfolds. However, always ensure appropriate levels of control on such changes.
A full assessment is important in order to drive an improvement or transformation program, but it may have to be carried out in tandem with operational responsibilities.
A process maturity assessment provides:
•Valuable input into the design of the future process model
•Opportunities for reuse of existing, known and proven processes
•Information about whether processes need tailoring or complete redesign
The assessment outputs will provide an understanding that is not only used during the process design activities, but also builds support among those parties who must later implement and operate the new or tailored processes.
Process models define activities, roles and responsibilities required to effectively execute the process activities. The RACI matrix is a relatively straightforward tool that can be used for identifying roles and responsibilities during a SIAM transition.
RACI stands for Responsible, Accountable, Consulted and Informed. These are the four key ‘involvements’ that can be assigned to an activity and a role.
A RACI chart or matrix shows all the activities or decision-making authorities in an organization set against all the people or roles.
Organizations may also speak to similar organizations that have adopted SIAM to collect their own reference data for SIAM and for prospective service providers and/or external service integrators. It is important to collect as much information as possible to support a decision to transform to a SIAM model. Conferences, online forums and social media can also be used to collect information about other organizations’ SIAM experiences.
Services, service components and service boundaries change, and the current services should be defined first. Following this, their suitability for current and expected business conditions is assessed. This can be a challenge as services can underpin, support or enhance other services, so the boundaries may be blurred.
The aim of service definition is to understand and map all discrete services and their dependencies in a hierarchy, and define which service provider is responsible for each service or group of services. The definition should include:
•Current service definitions (whether provided internally or externally).
•Service providers for each service and their geographical location, which includes internal operational support units or subcontractors:
oServices that are sourced from a single service provider (a service group).
oServices that are sourced from multiple service providers, for example, applications development.
•Contract terms, including terms that need to change.
•Contract expiration, with length of time left to run, implications of early termination and exit clauses.
•Agreed or contracted service levels.
•Performance against contracted service levels, usually at least 13 months’ reports and transaction data where possible (which equates to one year, plus the same month last year). This provides a snapshot and a trend.
•Service user and senior stakeholder attitudes to the services and service providers.
•Requirements that need to change. These may be derived from the analysis of which current obligations are working effectively and where change is required (See section 126.96.36.199 Assessing contracts).
•Desired service levels, including which targets are essential and whether they are currently covered:
oIf higher service levels are requested, is there funding or sponsorship for the difference?
•Seasonal variations and peak demand, key business events and requirements.
•Identified integration or handoff issues between the components or service providers that a new SIAM model would need to address. What issues cause friction?
•Data on assets, people, services and transaction volumes.
•Costs, charging models, external service provider costs, budget.
•Related services (for example, project work, catalog items, variable elements).
•Changes planned and scheduled.
•Critical events that act as a constraint (can anything be done about them?).
•External service provider support and maintenance contracts.
•Hours of cover, with a possible specification of core versus extended hours.
•Languages and other parameters covered, for example, by each operational unit or by each service.
•Software licence agreements.
Note that the gathering of information about the services is not confined to the retained capabilities, although it is likely to start there. It must include all other business areas and stakeholders, for example:
•Sponsors and executives within business units using the services
•Front-line business operations
These stakeholders may not only have information on the existing services, but they may have needs that are unfulfilled and that should be factored into the definition of the desired future state, if they are economically viable.
In some cases, business units may have unfeasible hopes that are quite uneconomic to fulfil. If presented with an expensive requirement, consider asking ‘How would we persuade the finance director of the value of this and who would pay for it?’. During requirements gathering, avoid making any commitments beyond a promise to consider what is requested.
Perceived service levels
As part of a transition to a SIAM model, an organization wanted a new wide area network (WAN) service. As customer satisfaction was good, the contract team included the service levels that were in the contract with their existing service provider as part of the specifications.
Thankfully, when the customer’s in-house service management team reviewed the schedules, they were able to point out that the service levels received were significantly better than the ones documented in the contract.
Understanding the full range of services can be a challenge, as many services can underpin, support or enhance other services, so the boundaries may not be clear. A good approach is to use service catalog techniques described in other practices (such as ITIL). Some organizations may already have a comprehensive service catalog that will provide the necessary information.
At the lowest level of the hierarchy you are likely to find ‘infrastructure’ services such as:
•Data centre hosting
•Local area networks (LANs)
•Wide area networks (WANs)
At the highest level will be the application services that are used directly by the customer organization’s users, such as:
•Service desk tool
There may also be technology services that are used to support the applications, such as:
•SMS text services
And non-technology supporting services, such as:
•Payroll support provided by an external service provider
Useful sources of information include:
•Service desk tools
•Technical architecture models
•Configuration management databases
•Individuals’ knowledge of IT, service management and the business
Some of the information gathered will be important to the procurement strategy but may need to be kept confidential. Consider what needs to be shared with whom, when and how.
Some information will be commercially sensitive and may be the intellectual property (IP) of an incumbent service provider. In this case, ensure that it grants permission to share this. It may be necessary to create new documents containing appropriate summaries that do not breach any duties of confidence.
It will be imperative that any future contracts contain clear clauses about the use and ownership of IP for all parties. Understanding those considerations at this stage will help in the Plan & Build stage later (see section 188.8.131.52 Intellectual property).
It is often difficult to dissociate services from their service providers. Consider:
•What are the attitudes to each service provider, together with those of operational, senior IT and service users? Which would be favorable to keep?
•What activities are delivered consistently well, badly or have problems?
•How often must recourse be made to the existing contract? The relationship is probably better if contracts are consulted rarely, compared to when the parties are constantly referring to contractual obligations to determine if they are operating the service correctly – or not.
•How well do the service providers collaborate with each other?
•How effective are relationships with/between service providers? Is it ‘us and them’?
•How much effort, time or money is spent with each service provider?
•How well do their service contracts align to current business needs?
•What are the key breakpoints and termination dates? How easy would it be to change them?
•Would the incumbent service provider want to continue supplying the services? If so, what would they want to change?
•What is the intellectual property (IP) position? Is it easy to change service provider and keep the service information?
•How could changes to the service provider and supply contracts be managed from the current arrangement to the future SIAM model’s needs? Why would each provider want to agree to the proposed change (remember that changes must be agreed by both parties)?
Consider the use of different teams, playing different roles, to work through scenarios to anticipate incumbent service providers’ reactions to potential changes to test which are achievable. This uses staff from the customer’s own organization in role play, to test a strategy in private before going public with it. The roles are:
Team 1 (sometimes known as ‘red team’): colleagues who are not involved but have relevant skills and experience. They pretend to be the counterparty, in this case the service provider (or if you are a service provider, they will play the role of the customer).
Team 2 (sometimes known as ‘blue team’): these are team members proposing the planned approach.
This approach can be used to quickly discover weaknesses in a plan by using the red team to attack it in private. This can also be used by service providers to assess bids before they are submitted. Here, the red team role plays either the customer or a competing bidder.
It is useful to assess the state of existing contracts and the way in which service provider performance is managed. Consider the following:
•How detailed are the service definitions?
•Are there service schedules?
•Do the schedules reflect customer needs?
•Is the provider performing consistently?
•Is there a designated point of contact responsible for managing the contract and the relationship with the provider?
•Is the cost model transparent?
•Knowledge of the cost model in use and charging elements such as:
oVariable usage (unit-based pricing)
oBy catalog item
oDynamics of the model and the flexibility to change to the model
•Strength of obligation based on relationship term and criticality of services provided.
•How compelling are the performance incentives?
•Does the contract provide value for money?
If current service provider performance falls short of expectations, and the service provider is to be retained, it is important to understand the root causes and address them. If possible, consider making changes to ensure the contract is aligned to others and is appropriate for the needs of the proposed SIAM model.
Validate that any incumbent service provider exit plans are up to date and available. For any plans that are not sufficient to conduct an exit, issue commercial notice requiring them to be updated so that they are fit for purpose. In some situations, service providers may not be contractually required to have an exit plan. If this is the case, then the customer organization (and service integrator, if appointed) will need to work with the service provider to find an acceptable outcome.
If an incumbent service provider wants to re-bid for services, there needs to be clear communication about how this is governed. There could be the impression that an informal decision has already been made (either in favor of, or against, the incumbent provider), which may discourage other (suitable) providers. In any bid, all bidders should be treated equally and fairly, including the incumbent. An ‘ethical wall’ may need to be established between the bid management team and the existing service delivery teams, with no sharing of information that is not shared with the other, potential service providers.
The customer organization includes the retained capabilities, possibly elements of the service integrator layer (for an internal or hybrid SIAM structure), and possibly one or more internal service providers. Where customer organization staff have roles in different SIAM layers, segregation of duties between layers must be clear.
The structure of the future SIAM model will be influenced by the strength of the customer organization’s capabilities and decisions associated with either retaining or externally sourcing elements of the SIAM ecosystem. The customer organization should consider its own position and how it is perceived by its own market.
Questions such as the examples below are useful discussion points:
•What would an honest service provider say about the organization and what it is like to deal with?
oWhat improvements could be made, before engaging the market and entering a new relationship?
oWould an incumbent service provider be likely to re-bid for business with the customer organization?
•What are the interactions and interfaces between current service providers and the customer organization, and how well do they function?
•Are roles and job descriptions accurate and up to date?
oAre they an accurate definition of what really happens?
oDo the customer organization’s capabilities fit well with the roles and capabilities required?
•Is the current tooling fit for purpose?
•Is there a clear understanding of the current costs associated with the service model?
•Is it acceptable to allow, or indeed is it necessary for staff to transfer to or from service providers and the customer organization?
The customer organization needs to consider its competence to manage a transition to a SIAM model. This includes time, capability and resources for the associated tasks. These roles are likely to be required:
•Current service owner(s)
•Manager for data room preparation and management
•Support staff from incumbent service providers
•Project and program managers, including the PMO
Just as a customer organization should assess its ability to fulfil these roles, either internally or externally, a prospective service provider will assess the ability of a customer to deliver the sourcing program successfully.
It is rare for there to be no other changes being made within any of the organizations involved during the period of the SIAM transition. Whether these other change activities are directly linked to the SIAM project or not, consideration needs to be given to the dependencies, constraints and the impact these changes might have on the success of the SIAM project (and vice versa). The SIAM project may support inflight projects, cut across them or be indifferent (see section 184.108.40.206 Accommodating inflight projects).
These areas must be considered:
•Too much change activity might affect elements of the SIAM project negatively
•The project timelines may need to consider other projects, operational activities or other constraints, especially where resources are shared
•Sponsors of interacting projects may be concerned that their main interest is not interfered with and that any requirements that flow from their projects to the SIAM project are accommodated
In this instance, a PMO is useful (see section 220.127.116.11 Project roles).
When deciding on the SIAM model and sourcing approach, the customer organization, service integrator and service providers must all consider not only their own strengths and weaknesses, but also other factors that will influence their success in the SIAM ecosystem. The following considerations are relevant:
•Specific organizational expectations and requirements
•Current service levels
•Information governance and privacy
•Speed and responsiveness to change
•Compliance and standards:
oSecurity and data management
oLegal and industry norms
•New methods and approaches to delivering services and the presence of new options
oWhat constraints exist?
oWhat are the obligations?
oTo whom do they apply? Who can break them and how?
oWhat are their effects?
oWhere is their flexibility?
oAre there any unspoken and unwritten rules? (Note – some may be valid and others just perception or habit)
A multinational organization will have to assess the legal and regulatory framework for each geographic area.
Some of these influences will be stable, while others change over time. All parties will need to factor these influences into their plans. They may be accommodated, overridden or ignored, while each has a risk and value associated with it that needs to be considered.
It is important to appreciate the factors that will influence a successful contract bid. An Australian government department defined that all tenders must include a local content assessment criterion with a minimum weighting of 30%. Bidders had to demonstrate the local content and benefits of their proposal in areas such as:
•Upskilling – including apprenticeships, formal and informal training
•Local industry participation
Effective collaboration and teamwork is vital between all parties within a SIAM ecosystem. The different parties must work not only to meet their own (often contracted) requirements, but also to deliver an end-to-end outcome that benefits the customer organization. It is important when mapping the landscape to include aspects concerned with collaboration (see section 3.1.8 Collaboration model).
Collaboration extends to the current state assessment and the demands for the future. Many organizations focus on the needs and challenges of a single service or service provider independently, and miss the review of collaboration needs and challenges across all areas and stakeholders affected by the SIAM model. Without collaboration, there is a risk that contracts with service providers would be based on delivery targets alone, omitting the requirements for collaboration.
Strategic objectives for SIAM
The strategic objectives for SIAM are those that SIAM will deliver in support of the long-term goals of the organization.
“A plan of action designed to achieve a long-term or overall aim.”16
Creating a strategy allows an organization to coordinate and plan activities rather than relying purely on opportunity, individual initiative or serendipity. Strategic planning is particularly important in situations where there are many parties to coordinate, where there are long lead times between the development of a competence and realization of benefits, and where there are high-stake decisions that are difficult, expensive or time consuming to reverse.
To provide clarity to stakeholders regarding the overall strategic intent, a concise strategy should include:
•Why the organization must change
•The benefits of change – money, competition, speed, customer service
•What the organization must build or change
•How much it will cost – money, people, other
•How long it will take to deliver
•Stages along the way
•Options: what could the organization do if not this
•At an individual level, an explanation of ‘What’s in it for me?’ (sometimes referred to as WIIFM)
In a SIAM project, the SIAM strategy should be used to guide all activities in the SIAM roadmap, including design of the SIAM model, sourcing decisions for the layers and as part of onboarding service providers.
The importance of strategy
“The best way to predict the future is to invent it.”
Alan Curtis Kay
“In preparing for battle, I have found that plans are useless, but planning is indispensable.”
General Dwight D. Eisenhower
Within a SIAM model, many parties need to be coordinated and often large investments with long-term commitments are needed. A strategy provides an overarching direction and high-level plan to lead the organization and its people through the transformation. A SIAM strategy must always support the organization’s corporate strategy and may even be a component of it.
Different forces influence an organization’s strategy. Strategic drivers include elements such as:
•Response to competitive threats from new entrants to a core market
•Aspiration to build a market extension by exploiting an emerging opportunity that is perceived as underserved or poorly served
•Desire to reduce ongoing costs
•Desire to improve the quality of delivered services
•Desire to better structure or source a constantly expanding services department
From these, the organization will develop a strategy to change its form, build new competencies and adjust the allocation of resources. The links between SIAM, corporate and divisional strategies must be clear, understood, documented, agreed and communicated. Decisions made in relation to SIAM (for example, approving the SIAM business case) need to support the corporate strategy. If the organization’s senior leaders can see that money and resources allocated to a SIAM project will support the corporate strategy and business outcomes, they will be more likely to approve their allocation because they support the corporate agenda.
Over time, the number of service providers – as well as the type of services being sourced externally – has increased for many organizations, creating choice and concepts such as 'best of breed'. This has led to increased complexities and management overheads for the customer organization.
Dealing with this large and fragmented service provider landscape can create many issues:
•Service providers operating in silos, focusing only on their own performance targets and not the end-to-end service
•Customer organizations managing and measuring each service provider individually, creating management overhead
•Challenges for the customer organization trying to build an end-to-end view
•Friction caused by fragmented processes, tools and service providers using different ways of working
•Additional overheads and complexities when contracts and associated legalities cause differences in reporting, invoicing, service credits, etc.
•Conflicts between service providers
•Little collaboration between service providers, limiting the efforts for the 'greater good’ of the customer organization
•Disaggregated services with no clear accountability
Some organizations believe that consolidating their service provider landscape to one, or a few, large service providers will help to alleviate these challenges.
The SIAM approach differs. It allows a customer organization to benefit from having access to a variety of service providers, while reducing its management overhead. The service integrator provides ownership and coordination across the service providers, in a consistent and transparent manner with clear accountability and responsibilities. A SIAM model makes it easier for a customer organization to onboard and offboard service providers when required.
The strategic forces (internal or external) that influence the transition to a SIAM model are likely to include corporate strategy drivers, as well as those that are more specific to the services that form the SIAM model. Examples are a corporate direction to centralize contracts to gain efficiencies or, from a services perspective, a directive to retire old technology and replace it with more efficient solutions.
Drivers may originate from outside or inside the organization. The SIAM driver types identified in the SIAM Foundation BoK include:
A good strategy will take account of these applicable driver types, but should not be defined by them alone. Ultimately, a strategy is a plan to reach a goal and advance objectives. It is implemented through tactical and operational plans and activities.
Strategy should never exist in isolation. It is often expressed in the context of:
Each of these areas can (and should) be expressed first from the perspective of the organization, and then expanded progressively through each level of the organization.
Strategic planning for SIAM
Strategic planning can be made up of four key steps:
1.Understand the current state (‘as-is’), including any issues
2.Describe the future state and how it will address issues (‘to-be’)
3.Outline the high-level stages to get to the future state
4.Detail the next steps
When carrying out strategic planning for a transformation to SIAM:
•Item 1 is achieved by conducting the activities in the Discovery & Strategy stage
•Item 2 is the SIAM model outlined during Discovery & Strategy, and detailed in the Plan & Build stage
•Item 3 is the full SIAM roadmap
•Item 4 is the detail from the Plan & Build stage
Many organizations now seek to be more agile and responsive. Speed of change can be a success factor if the lead time to strategy alignment and adoption of new services is a concern for the customer organization.
Capabilities required for the formation of a strategy are varied. They normally involve creativity, modeling, scenario analysis, pictures, words and figures. When forming a strategy, it is wise to consult widely with all stakeholders and to examine desired outcomes and options from a variety of viewpoints. A plan that has only considered limited options is unlikely to be robust.
There is a useful thought process (or cognitive exercise) that can be used in strategy formation. It involves consciously taking a series of perspectives from which to view a situation. Ideally, this is then used in a dynamic mode to work through the choices and preferred selections as a scenario unfolds.
Scenarios can be pursued as if the participants are chess players, considering, ‘What would happen if I took the queen’s rook?’, and playing through the consequences. This involves ‘walking a mile in another person’s shoes’. Sometimes the experience is painful, but the insight can be invaluable.
There is not one, perfect strategy for any organization. There are however plenty that:
•Are inconsistent: for example, ‘We want to complete xxx in six months, but we only have competence to achieve it in 18’
•Are incoherent: different units are pursuing conflicting objectives
•Focus too narrowly on goals or objectives: strategies are not simply goals, but also include plans to achieve them
•Are improbably risky: under the assumption that it will go right … this time
•Are unattractive to key decision makers: for example, if it affects their bonuses
The art of strategy formation is to consider the options widely and carefully. The resources and budget must then be secured before committing to a course of action.
The overall SIAM vision is to build a capability to manage service providers with varied interests seamlessly, to provide a cohesive and transparent service view and meet the customer organization’s objectives. This vision will be slightly different for the organizations and service providers in each SIAM ecosystem, but each one is likely to share some common elements. Every party’s vision should encourage cooperation, collaboration, trust and a culture of ‘win-win’.
From the perspective of a customer organization:
•Build the capability for services to be managed on the customer’s behalf, to meet the customer’s strategic objectives, providing a cohesive and transparent view of services
•Help the customer to move from a transactional and disjointed way of managing service providers towards strategic partnerships and improved benefits realization
•Bring consistency, efficiency and transparency in the way services are being delivered, no matter which service providers are involved
•Enable rapid adaption to change
•Integrate all aspects of service delivery, including operations, projects, service transitions, performance reporting and continual improvement
From the perspective of an external service integrator:
•Build a continuing positive and profitable relationship with the customer
•Build a continuing positive relationship with the service providers
•Win repeat business, or expand existing scope
•Obtain a referenceable engagement
•Build the capability to manage services on the customer’s behalf seamlessly, to meet the customer’s strategic objectives, providing a cohesive and transparent view of services
•Help the customer to move from a transactional and disjointed way of managing service providers towards strategic partnership and improved benefits realization
•Help the customer to realize the expected benefits of the services, within the constraints of the contract
•Bring consistency, efficiency and transparency to the way services are being delivered, no matter which service provider(s) are involved
•Enable rapid adaption to change and accelerate transition initiatives with confidence, onboarding and offboarding service providers as needed
•Integrate all aspects of service delivery, including operations, projects, service transitions, performance reporting and continual improvement
From the perspective of an internal service integrator:
•Maintain a continuing, positive relationship with the customer
•Remain as the internal service integrator (protecting its position from external alternatives)
•Build a continuing positive relationship with the service providers
•Build the capability to seamlessly manage services on the customer’s behalf, to meet the customer’s strategic objectives, providing a cohesive and transparent view of services
•Help the customer to move from a transactional and disjointed way of managing service providers towards strategic partnership and improved benefits realization
•Help the customer to realize the expected benefits of the services
•Bring consistency, efficiency and transparency in the way services are being delivered, no matter which service provider or providers are involved
•Enable rapid adaption to change, and accelerate transition initiatives with confidence, onboarding and offboarding service providers as needed
•Integrate all aspects of service delivery, including operations, projects, service transitions, performance reporting and continual improvement
From the perspective of an external service provider:
•Build a continuing positive and profitable relationship with the customer
•Develop a continuing positive relationship with the service integrator
•Maintain a continuing positive relationship with other service providers
•Win repeat business or expand the existing scope
•Obtain a referenceable engagement
•Deliver services to the customer to meet its requirements
•Help the customer to realize the expected benefits of the services within the constraints of the contract
•Provide services consistently, efficiently and transparently
•Adapt to change rapidly
From the perspective of an internal service provider:
•Maintain a continuing positive relationship with the customer
•Build a continuing positive relationship with the service integrator
•Remain as an internal service provider (protect its position from external alternatives)
•Build a continuing positive relationship with other service providers
•Deliver services to the customer to meet its requirements
•Help the customer to realize the expected benefits of the services
•Provide services consistently, efficiently and transparently
•Adapt to change rapidly
A strategy is only as good as the action it supports and enables. Action can be encouraged by communicating the strategy to others, so that they support it. There are three main forms of strategic communication, all of which must take place as soon as possible after the strategy has been approved:
1.Face-to-face communications from the sponsors and leaders of the project, inspiring and promoting the change. This should be persuasive and engaging, and needs to be repeated and referred to regularly, otherwise it may turn into ‘something someone once said’ and be forgotten or ignored.
2.The documented strategy itself, which needs to be available, understandable, compelling, as concise as possible, and explain where each party fits into the strategy.
3.A business case that expresses the approach, the outcomes, the resources, risks, approach and cost. This is essentially thoughtful and analytical, with emotional elements.
When implementing a SIAM model, the storytelling and business case precede the transition. This means that by the time of their appointment, incoming service providers fully understand what is expected and how they fit in.
Strategy launch meeting
At the end of the Discovery & Strategy stage of a SIAM transformation in a small organization, all the employees were invited to attend a launch event. This was led by the chief executive, who outlined the vision for the future. He was supported by the other members of the board, who each explained a particular element of the strategy. The event was recorded and made available on the organization’s intranet.
Once the external providers were appointed, a similar event was held, but this time attended by the chief executive and senior managers from each of the providers. After the chief executive went through their strategy, the executives from each provider talked about how they were going to support achievement of this strategy.
One potential challenge can be the degree of inertia that exists within an organization. Many organizations have no experience of making a transformational change as significant as SIAM, and many people are not motivated to change (believing that it is ‘better the devil you know’). A SIAM strategy will simply not get started or be sustained without a sufficiently powerful reason to act – and to act now. A perceived or actual crisis (positive or negative) can be utilized to show the organization that remaining in the current state is intolerable. Additionally, using stories, hopes and fears may overcome this inertia.
What happens if we do not?
The first of J.P. Kotter’s The 8-Step Process for Leading Change is to ‘create a sense of urgency’.17 This requires the organization’s leaders to explain why they are planning to embark on a particular strategy, which helps others see the need for change through a bold, aspirational opportunity statement that communicates the importance of acting immediately.
As an alternative, try reversing the statement and pose the question: ‘What happens if we do not?’.
A positive crisis
A public-sector organization had been created from several mergers over time. This resulted in four different IT departments, each with its own heads of IT, tools and ways of working. In addition, they had ten external service providers supplying managed IT services, but with no single point of management and coordination.
Two events made the need to change very apparent:
•One of the external providers failed its availability service level consistently. This prevented the organization from achieving targets set by the government.
•There was a major outage with a critical business service provided by one of the internal IT departments. This delayed the provision of key information to the government.
These events were used as part of the justification for a strategy to move to a consistent SIAM model, embracing both internal and external providers.
Resistance to a strategy can be overcome by creating awareness and gaining support from stakeholders. Stakeholders are those with an interest or concern in something. They have influence (to varying degrees) on resource allocation and decisions. When producing a strategy to transform to a SIAM model, consider the perspectives of these stakeholders, their likely reaction to the proposed approach and the effect of these on the transition plan, including:
•Customers – both existing and potential – of the customer organization
•Customer organization – senior executives, notably the SIAM sponsor
•Champions and influencers – prominent figures in the organization with an interest in the project but no direct involvement
•End users within the customer organization
•Customer organization – delivery staff, including internal service providers
•Consulting and specialist organizations that may be brought in to assist with the SIAM transition project
•Any functions and projects competing for resources that might instead be assigned to SIAM activities
•Incumbent service providers (existing contracts, obligations and their commercial strength)
•Potential service providers, including any potential external service integrator
•Competitors in the market
This list is not exhaustive, and the stakeholders will be different for each organization.
Stakeholder characteristics include:
•Degree of influence
•Degree of power
•Association and relationship
•Hopes, fears and aspirations
These characteristics may make them positively, neutrally or negatively disposed to the SIAM model. When forming a strategy for SIAM, it is helpful to identify those with power or influence over the outcomes (see section 2.5.1 Mapping the landscape).
Stakeholder buy-in can be achieved by creating a strategy that:
•Achieves the best overall value from the perspective of those with the influence to determine its ability to succeed
•Accommodates interests and priorities to the greatest degree possible (and explains where they are not)
•Is supported throughout the duration of the program and the stages of the roadmap
‘Selling’ the strategy
Techniques for stakeholder mapping, which can be useful in gaining stakeholder buy-in for a new strategy, can often be found in the sales community. Major account salespeople have developed approaches for mapping relationships and visualizing connections to develop strategies for dealing with them and winning approval for new business.
These techniques can work equally well for selling a SIAM model across stakeholders.
Not every individual will establish positive relationships with everyone. Consideration needs to be given to all members of the team when assessing who is best placed to engage with stakeholders. Success depends on trust and respect, and although ‘liking’ an individual is helpful, it is not essential.
Stakeholder mapping should then be used for stakeholder management activities throughout the lifecycle, as part of organizational change management (OCM) (see section 3.2 Organizational change management approach). The relationships built at the initial stages of the transformation to a SIAM model will also help to maintain it once it is implemented, so it is essential to consider the individuals involved.
The transition to a SIAM model involves changes that will affect many elements of the organizations involved. It requires resources to deliver it and sponsorship, won through the construction of a business case (see section 2.7 Create an outline business case).
A strategy must be seen to deliver change. The right to continue comes from the delivery of meaningful results that generate credibility. This allows the sponsor to sustain the project through various (and sometimes iterative) stages. If the SIAM project is not seen to deliver change, it may drop down the management agenda and resources, and focus will switch to other projects. The strategy should be reviewed regularly and, if necessary, changed.
Losing strategic focus
Many organizations have started the journey of transforming to a SIAM model, developing the strategy, the business case and initiating the program. However, if not actively managed, the attention of the senior stakeholders can move to newer and more exciting areas, such as new business opportunities or new digital solutions.
This means losing the long-term commitment for the SIAM transformation and can mark the beginning of the end for the SIAM transformation program and its ability to fully deliver the SIAM model and identified benefits.
Impractical or unachievable strategies need to be identified quickly and reassessed. A common reason for failure is organizations that try to move rapidly on too many fronts with insufficient resources.
A clear and understandable outline business case will clarify the purpose of designing and implementing a SIAM model, the expected costs and outcomes. This needs to be a reference document that can be used in the Plan & Build stage to create the full business case, to use in the further roadmap stages.
The business case needs to contain:
•Strategy for SIAM: this needs to outline the strategic objectives for the SIAM model, whether the intentions are to address specific pain areas, financial considerations, or operational and business requirements.
•Proposed services: the proposed services to be provided.
•Outline SIAM model: a high-level outline of the intended SIAM model.
•Current operating model: a high-level representation of the current delivery model, including current pain areas that have led to the need for change.
•Benefits expectation: the expected benefits from transitioning to the SIAM model, including defined benefits measurements along with current and target values for each measure.
•Costs: an estimate of the costs involved in the transition to the SIAM model, with the required level of detail in terms of cost types, cash flow projections and other financial techniques (often specific and established within the organization). Also, estimated total cost of ongoing operation, which can then be compared to current costs.
•High-level plan: an outline of the transition to the SIAM model with broad timelines and activities listed along with major deadlines.
•Risks: the risks of implementing (and those of NOT implementing) the SIAM model, at a high level. The risks should be classified according to the organization and delivery units affected. This may include risks to the business, risks to the IT organization, risks to service providers and risks to the SIAM environment or ecosystem.
•Critical success factors (CSF)s (see section 2.7.2 Critical success factors).
•Analysis: a documented analysis on the viability of the business case (perhaps using the pain value analysis or cost benefits analysis methodologies).
The outline SIAM model uses the information and outputs from previous activities in this stage, and in conjunction with the SIAM strategy, can form the basis of the outline business case. The outline SIAM model establishes how it aligns with the intended objectives and enables achievement of those objectives.
The outline SIAM model should include:
•Principles and policies
•Outline roles and responsibilities
•Outline of process models, practices and structural elements
•Outline of services and service model
•Service providers to be retired
The outline SIAM model will be used in the Plan & Build stage to create the detailed SIAM model (see section 3.1 Design the detailed SIAM model).
Critical success factor (CSF) is a management term for an element that is necessary for an organization or project to achieve its mission. It is a critical factor or activity required for ensuring the success of an organization.
CSFs for a successful SIAM model include:
•Well-conceived SIAM strategy
•Appropriate SIAM model design
•Managing process outcomes, not activities
•IT as a strategic partner
•Impartiality of the customer retained capabilities and the service integrator
•Clear boundaries of responsibility
•Confidence in the competence of the service integrator
•Management information and reporting the right data
The CSFs will provide an input into the outline business case, which is described further in the next section. The challenge is that it is not known whether the strategy and design are well conceived until they are implemented. Sometimes, the approach appears sensible on paper but fails because the flaws become exposed only at the implementation stage.
If the customer organization is not clear about its objectives and the value it wishes to receive, any associated policies and strategies will also be unclear, increasing the delivery challenges for the service integrator and the service providers.
To achieve the desired outcomes, the full SIAM model, including the service model and sourcing approach, should be agreed by the services customer. The customer organization must make decisions on how services will be sourced and which type of service providers, under which structure, will facilitate delivery. The customer organization must ensure that the models are scalable, so that new business processes and functions can easily be added, extended or discontinued.
When appointed, the service integrator will become involved, and the final model should be a joint enterprise. If the service integrator has more experience, the customer should leverage this rather than imposing its own (possibly flawed) model.
The design elements of SIAM incorporate the concepts of separation of concerns, modularity and loose coupling. This provides flexibility and enables the decoupling of underperforming or redundant service providers.
Within the design principles, enterprise architecture (EA) describes the relationship with enterprise goals, business functions, business processes, roles, organizational structures, business information, software applications and computer systems, and how each of these interoperate to ensure the viability and growth of the organization.
If done well, enterprise architecture (EA) identifies how to achieve separation of concerns and how to define architectural patterns or the rules of how systems communicate with one another. It provides intelligence to the SIAM strategy, bringing a clear definition of the business processes. It plays an important role in the creation and management of a reusable set of architectural domains for the organization. These domains might include business, information, governance, technology, security and others. These structures define the basic principles in which the SIAM controls can be established.
A SIAM model needs to include a delivery structure that supports process inputs and outputs, lays down governance principles, standards and controls, but does not stifle the individual procedural activities that will be proprietary to each service provider in the model. A focus on open standards and interoperability to support workflow, performance management and service management is important. Like any relationship, all parties need to know their role and both receive and provide a valuable contribution. Without this, the relationship lacks purpose or value.
The importance of relationships
In personal relationships, dissatisfaction leads to breakdown and possibly divorce. Similarly, in a SIAM context, an unbalanced relationship may end with the customer terminating a contract with a service provider or the service integrator, or the service integrator or a service provider leaving the ecosystem.
Customer organizations want the benefit of choice and access to specialized service providers that will work with other service providers in the SIAM ecosystem. By focusing on process outcomes, the SIAM model can enable the ‘loose coupling’ of service providers to allow a relatively easy method to switch them out (and in). Decoupling becomes difficult in environments that have not employed effective strategy and design:
•The transition of service providers needs to happen without affecting the end-to-end service (see section 3.3.3 Transition planning)
•Knowledge sharing is necessary between incoming and outgoing service providers
•Service providers require an effective exit strategy (see section 18.104.22.168 End of contract)
In the SIAM model, all service providers understand their role and contribution to process outcomes. They benefit from clear contracts and a relationship that should allow them to innovate and deliver service improvements.
Much of the value of integrated service management solutions is intangible and complex. The value lies in how service elements are defined, provisioned and controlled. Without a SIAM strategy and an approach to service design, the service integrator becomes nothing more than a referee. Without the ability to measure, monitor and decouple, the promised flexibility and choice is not achieved by the customer.
One rationale for adopting a SIAM model is to gain assurance that the IT and business strategies align in relation to the challenges faced and the value sought from a multi-service provider environment. The role and responsibility of the customer organization is critical here. IT leadership can contribute intelligence about technology trends, open market services, opportunities and challenges, but the IT strategy must represent the business or customer correctly.
Having a positive and productive relationship between the business and IT is crucial to effective SIAM. The service integrator acts as the agent of the customer organization and must be seen to be part of it and representing its views (even when externally sourced). Ideally, the service integrator will have representation on the customer organization’s management boards, for example, the Executive Steering Board (see section 22.214.171.124 Executive Steering Board).
The customer organization must define the strategy for services and the model for enterprise architecture (EA), as well as the control exercised through the governance bodies. This may be undertaken in conjunction with the service integrator or trusted advisors, although the customer organization retains accountability.
A challenge in a SIAM model is creating an environment where impartiality is both seen and believed to exist. The first imperative is expectation setting. This involves defining the policies and principles governing each service provider. Establishing ‘the rules of the game’ becomes easier if the service providers have been actively involved in, or at least have a full understanding of, the imperatives. This engagement helps to overcome unrealistic expectations and to confirm a clear understanding of obligations.
Boundaries of responsibility are captured in the SIAM model through service descriptions, service agreements, mandates, charters, processes and operating models. The boundaries of responsibility for each service provider must be well understood to avoid work being duplicated or left undone.
The creation and communication of a governance model or framework creates parity among service providers. It provides the basis for control and governs activities at all levels in a form to which all service providers can refer (see section 2.3 Establish a SIAM governance framework).
Probably one of the most difficult aspects in demonstrating impartiality and building credibility for the service integrator is through the demonstration of service management expertise and business alignment. When the service integrator is applying process governance and measurement of outcomes, it needs to be consistent and impartial. This will be determined by agreeing how processes are followed and measurements are applied.
Developing trust and rapport can be a challenge in a multi-sourced environment, particularly if there are legacy service providers and contracts that are not fully aligned with the SIAM model. Establishing strong cross-provider relationships, with effective mediation when challenges occur, is important.
Service providers need to trust the service integrator to act as a mediator and believe the service integrator is interested in helping all parties resolve any issues that might arise. This makes them less likely to question the impartiality of the mediator.
The relationships between the service integrator and all service providers are based on trust, as the service integrator does not own any contracts with the service providers. This does not mean that the service integrator has no authority in the management of the contract, but the service integrator would not typically own the contract management relationship.
Service agreements may be contractual commitments, operational level agreements (OLAs) or service level agreements (SLAs), depending on the service provider and customer relationship. The agreements should include explicit service integration targets that focus on service performance, usability and availability from an end-to-end perspective, not just from a service provider’s individual commercial perspective.
Service provider agreements should not dictate procedural activities, but should instead exploit service provider knowledge and promote the achievement of end-to-end outcomes and improvements.
Contracts that support integration are important, however, they are not always possible from the outset, owing to legacy or incumbent agreements. SIAM is more effectively embedded into an organization if the service provider contracts reflect the requirement to engage with other service providers and the service integration function. Service providers may refuse to engage with the service integrator if the requirement is not stated explicitly in the contract. This is where ‘good’ contracts, relationships and governance are vital.
Getting the right data, with the right level of analysis and insight (including data correlation), to the right people at the right time is critical. Effective information management is not easy. There are often many systems to integrate, service providers to manage, tooling challenges, a wide range of business needs to meet, and complex organizational and cultural issues to address. Effective tooling is essential to avoid time-consuming manual effort.
Quality assurance is essential, to help drive efficiency, support the demands of compliance and regulations, and to support decision making. If this CSF is not met, organizations may find that service providers hold on to their own data, ownership is not clear and the end-to-end status is hard to measure and manage.
“The actual application or use of an idea, belief or method, as opposed to theories relating to it.”18
Within the SIAM Foundation BoK, four types of practices are described:
These practice areas address governance, management, integration, assurance and coordination across the layers, and need to be considered when designing, managing the transition to or operating a SIAM model. This section looks at each of these practice areas and provides specific, practical considerations within the Discovery & Strategy stage. Note that the people and process practices are combined and referred to as ‘capability’.
During the Discovery & Strategy stage, relevant stakeholders need to be able to assess a wide variety of aspects for suitability, both from a current perspective and a future perspective. These aspects include:
•Business strategy, direction and priorities
•Current (internal) staff/resources/capabilities
•Existing contracts (duration, pertinence, flexibility, costs, etc.)
This will require varying capabilities and expertise, ranging from ‘inside’ knowledge of the organization and its strategic direction, to insight into current (and future) technology trends and how they would apply.
In this stage, the outline business case is written, the SIAM strategy (and outline model) created and the project established. Again, a variety of capabilities are required, not least knowledge of SIAM methods and practices, and a ‘sales and marketing’ proficiency to make sure relevant executives are committed to the SIAM strategy/case/project and are willing to allocate resources to the subsequent stages.
Additionally, a governance framework and the policies for roles and responsibilities should be created, which require further capabilities, such as knowledge of legal or contractual obligations, and HR policies and practices (see section 2.3 Establish a SIAM governance framework).
A broad approach
As much as the Discovery & Strategy stage advocates ‘outline’, high-level outputs, do not allow it to be the work of one individual (often an enthusiastic IT manager). A narrow perspective at this stage will not only result in a limited output but will also make it harder to gain acceptance from other stakeholders.
A multi-functional, multi-skilled team will enhance both the quality and the acceptance (and thus the success) of the SIAM transition.
Competence is an ability or skill to do or achieve something. If particular skills are needed for the SIAM project, but are not currently present, then common approaches include:
•Buying skills from an external service provider
•Developing skills with existing staff and capabilities
Each of the above options will have implications for time, resource, value of outcome, risk and skill. The challenge in building a SIAM model is that, if the customer organization has immature capabilities, assessing the adequacy of the current state is a challenge (see section 2.4 Define principles and policies for roles and responsibilities).
The customer organization may reduce the impact of these challenges by undertaking the following approaches (see section 2.2.2 Agile or waterfall?):
•Pilot/build incrementally, using feedback to refine the approach before building further (Agile)
•Plan, design, build quickly and deploy (waterfall)
Considering incumbent staff displacement
Within both the Discovery & Strategy, and Plan & Build stages, the customer organization must consider the legal impacts of its sourcing choices, specifically regarding incumbent staff. When building the detailed SIAM model, it is important to have a thorough and detailed workforce plan (see section 3.1.6 Detailed roles and responsibilities).
The wide variety of transfer and other laws in countries around the world can cause challenges if not fully considered. For example, in one part of Australia, there is a government mandate that requires the regional government employer to be mindful of offering opportunities to local businesses and people. The aim is to provide access to contract and job opportunities to the local community as a priority.
In any cross-border business acquisition or disposal, outsourcing, bid to deliver outsourced services or insourcing initiative, it is essential to focus early on how local employee transfer laws will apply in the affected jurisdictions. Obligations may alter the strategic direction regarding the sourcing model.
Not all situations are the same. Considering how to handle the movement and displacement of staff is necessary in situations where:
•A customer organization wishes to bring a service in-house but still assure continuity. It may wish to offer a request to transfer the provider’s staff into its organization.
•The customer wants to move a service that has previously been carried out in-house to an external service provider.
•Service providers taking on new contracts may wish to recruit employees from an incumbent provider for ease of ongoing support.
•An external service provider takes on a role previously done by an internal provider, but does not wish to take any of the existing workforce because the work will be relocated, performed in a radically different way or needs significant cost savings.
In some countries, these aims are simple to achieve, but in others are highly complex. There is no global uniformity regarding the application of the legal principles protecting employees (see Appendix D: Staff displacement legislation).
Careful approaches to these issues will help to avoid legal irregularity and protect corporate image or brand. Where legal considerations do not exist, this does not imply ‘anything goes’. Blatant disregard of any moral and social obligations may lead to former employee dissatisfaction and resulting public stories of poor treatment, leading to potential bad press and reputational damage.
Within the Discovery & Strategy stage, the customer organization should consider the possibilities and limitations of obligations related to retaining staff when the SIAM model is proposed. Input and support from the organization’s HR and legal departments, as well as other bodies such as trade unions, should be sought.
The following are considerations for the customer organization, where implications regarding staff are relevant:
•Relevant legal obligations
•Industry participation plans
•Where no legal obligations exist, consideration of moral and social responsibilities
•Lack of expertise in associated legal and HR implications
•Considering role matching between ‘as-is’ and ‘to-be’ structures, and where role matches might lead to a requirement to retain an individual
•Planning for staff consultation periods
•Retention, making sure key staff do not leave
•Natural turnover of staff
•Impacts and constraints of required notice periods
•Costs associated with:
oCost of outplacement support, retraining and back to work readiness programs for displaced staff
•Legal proceedings from unhappy staff
Industry participation plans
Within some local government areas, employers must work within guidelines provided through relevant industry participation plans. These are often created to support growth of a region and its economy, as well as providing more scope for local business and industry development.
In one Australian example, a government plan makes a specific statement regarding people:
“Local businesses are also encouraged to apply best practice approaches in employing, training and retaining indigenous employees and securing joint venture opportunities with indigenous organizations, where available.”
As the SIAM project is not formally active at this stage, there are few targets to measure and report.
From a measurement perspective, focus on the overall commitment of time, costs and resources during this stage, because there is no formally approved business case. Some form of capture and reporting on time and costs needs to be considered, in line with normal organizational practices.
It may be advisable to define the scope of the Discovery & Strategy stage as a separate project, in order to get commitment for the time, costs and resources required to develop the strategy and business case, particularly if it involves a multi-functional team (see section 2.8.1 Capability (people/process) considerations). Scoping the stage as a project enables close monitoring of time and resource spend against budget.
The most important measurements in this stage are those that will be included in the outline business case. The time and costs of the SIAM project and the quantified expected benefits (including when and how to measure these). These measurements will form the basis of the approval and commitment of the executives and sponsor of the project.
•Ensuring the correct understanding to drive decision making
•That decisions are led by data, not just speculation
•Justification and direction metrics for subsequent stages
•Capturing a baseline of end-to-end service levels and user satisfaction for future comparison
A useful approach for project status reports is red/amber/green (RAG or traffic light) reporting, where:
•Items going to plan are highlighted in green
•Items at risk of missing planned dates are highlighted in amber
•Items that have missed planned dates are highlighted in red
A further enhancement is to highlight completed items in blue (BRAG).
A high-level SIAM scorecard can be defined with individual key performance indicators (KPIs) aligned to these measurements. The scorecard can also focus on KPIs and metrics aligned to the implementation of the SIAM model, and any other operational KPIs required to achieve those benefits as well as to run operations. The scorecard will evolve and mature as the SIAM project progresses.
Technology and tooling is of limited concern during this stage. The tooling strategy is not defined until the Plan & Build stage, and will address many of the technology considerations. However, building the outline business case and outline SIAM model requires ‘an awareness of technology trends’, as well as an assessment of current capabilities, which includes technology and tooling.
Technology can have a profound effect on the strategic direction of a business. For example, consider the impact in recent years of cloud-based infrastructure, ‘Anything as a Service’ (XaaS), or digital disruption.
The outline SIAM model will provide an input to the tooling strategy and, therefore, needs to contain information such as:
•SIAM strategy, including objectives for ‘loose coupling’ and service provider integration
•Enterprise architecture (EA) assessment
Tools in use during this stage can assist in managing the project or creating an analysis for the outline business case.
4 Service Integration and Management (SIAM™) Foundation Body of Knowledge (BoK), Second edition, IT Governance Publishing, 2021. For more information visit: www.itgovernancepublishing.co.uk/product/service-integration-and-management-siam-foundation-body-of-knowledge-bok-second-edition.
7 For more information, visit: www.webopedia.com/definitions/swivel-chair-interface/.
8 Governance in a multi-supplier environment, itSMF UK SIAM Special Interest Group/Neil Battell.
9 Source courtesy of Chris Taylor-Cutter.
10 Sarbanes-Oxley, 2016.
14 Who Says Elephants Can’t Dance? by Louis V. Gerstner Jr., Harper Collins, 2009.