THE IT OUTSOURCING ALIGNMENT FRAMEWORK

In this publication, we introduce the IT Outsourcing Alignment Framework. This is a very effective tool for a company that is operating under an IT Outsourced model, or that is planning to move towards IT Outsourcing:

• You can use it at the start of a new outsourcing journey to make sure you design the outsourcing collaboration and contract in the right way with all elements well aligned for success, making sure detailed operating agreements are aligned with strategy, etc
• For outsourcing contracts that are in operation it gives you a tool to assess the health of the contract and the relationship, and to define recommendations for improvement.

The framework is based on the idea that all the elements need to be in sync for an IT Outsourcing to be successful. Elements not being aligned, will lead to suboptimal situation and conflicts.

• The CIO strategy and context of the company influences the Outsourcing model that is most appropriate. An outsourcing model that conflicts with the strategy or the context will at some point get challenged by leadership.
• The CIO strategy and the chosen outsourcing model dictate the shape of the different elements of the deal:
• The services scope, and roles and responsibilities
• The pricing and commercial model
• The SLA/KPI/Reporting and governance structure
• The internal versus external skills/capabilities
• The supporting technology for running and automating IT
• The Contract & Relationship Management

All these elements need to be in sync:

• E.g. a pricing and commercial model that is not aligned with the type of outsourcing model and with the overall sourcing strategy of the CIO, will not lead to the right behavior;
• E.g. a chosen pricing and commercial model require the appropriate KPI and governance routines to be in place in order to make the link between the operations, the continuous improvements, and the commercials;
• E.g. a chosen service scope and the split between in-sourced tasks versus outsourced tasks, has an impact on the internal versus external skills to have in the teams.

Finally, “what the CIO has in mind” should be same as “what is written in the contract” and “what is the reality on the ground”. Also, client and service provider leadership should share that same vision. If the contract says A, but reality executed on the ground is B, and (even worse) CIO has in mind C, then the contract cannot be successful. For a successful IT outsourcing all these components need to be “in sync”. Over the years we have seen situations where client and/or provider where not happy with the outsourcing relationship, for different reasons. The assessment mostly showed that one or more of the components where not aligned.

And change… During the life time of the contract the client objectives can change (changing business context, new CIO, …) and then again, this top down alignment between the client objectives and the shape/details of the contract should get updated. So, the alignment as presented in this paper is in fact a continuous process.

DETAILS ON EACH OF THE ELEMENTS OF THE FRAMEWORK

CIO Strategy & Context and the Outsourcing Model

The CIO strategy and context of the company influences the Outsourcing model that is most appropriate. Let’s look at some examples of outsourcing models:

• A large-scale outsourcing, one or two strategic partners for all Application Development and Support globally, one partner for Data Center Services, etc. The contracts are typically large multi-year managed-services contracts. This model is what one would say “real outsourcing”.
• As opposed to a more insourced IT, with selective outsourcing of certain niche applications/technologies or activities. So still a significant internal IT team complemented with best of breed service providers / smaller contracts for selective areas/activities
• Or a staff augmentation sourcing strategy: a situation of a client with a mix of internal and external staff from many different providers. Client chooses to go for a vendor consolidation (concentrate work with less vendors – more strategic relationships), but still in a staff augmentation mode. I.e. client and external staff work as one team on specific tasks. In this case the client is contracting the provisioning and scaling up/down of skilled staff, not services.

It is very important that all parties are in alignment on the chosen outsourcing model, since all the subsequent aspects (services scope, pricing model, SLA/KPI scheme, etc) need to be designed in line with that strategy. Otherwise the model will not work properly.

The services scope, and roles and responsibilities

• Services scope can be for example Application Support, Application Enhancements and Application Projects (three services typical in Applications Outsourcing contracts), and/or services scope can be Server Management (in Data Centre contracts), etc
• The roles and responsibilities matrix give a task-level responsibility view for that service (e.g. Application Support) what are the tasks executed by the service provider and what tasks are executed by the client
• It is important to align the scope of services between the different contracts / service providers, e.g. align scope of services between the application service provider and the data centre service provider. To make sure it covers scope end to end, there is no overlaps etc (e.g. the area of technical application management typically requires good design what is with application and what is with data centre provider)
• We recently see a new packaging of services vertically integrated. With the evolution to cloud we see contracts where the Support service not only includes the Application Support or only the Server Management, but all stacks from Functional Support down to Hosting. The service is then the support of an application environment end to end.
• Think also of innovation. Clients often complain that they do not see sufficient innovation from their service providers.
• Innovation is indeed inherent to each service (e.g. innovation in the application support process, innovation to server management, etc) and service providers will bring pro-actively innovation to their services and processes. And the contract should stipulate that the client will see that innovation as part of the regular governance, reporting/KPI, etc
• But other innovation is often defined as a service on itself (separate from support or projects), e.g. periodic innovation governance with the business to define what technology can do for the business (e.g. in digital transformation), can be a service on itself. And therefore, in the services scope it might be needed to list innovation as a service on itself (separate from projects and support). In the later chapters this innovation service will then get its own attention (e.g. as to its governance, its SLA/PI, its pricing, etc).

The pricing and commercial model

Designing the right pricing and commercial structure in line with CIO strategy and the chosen outsourcing model is crucial. The pricing structure drives “behaviour” and puts certain accountabilities with service provider and with client as to e.g. cost management.

• Alternative 1: fixed price for a given service (e.g. fixed for Application Support for application XYZ). Fixed price will typically include a yearly cost reduction (productivity gain) contractually committed. Fixed price puts most accountability for cost with the service provider and provides the client predictability of costs.
• Alternative 2: P*Q*Q models. P (unit price) times Q (quantity or number of units) times Q (quality e.g. SLA bronze/silver/gold). In P*Q*Q models it is recognized that both client and service provider influence the “number of units (consumption)” and therefore there is typically a joint responsibility and a pain/gain sharing as to volume and cost reductions.
• In the Applications Outsourcing business we often see models based on “ticket volumes” and a “price per ticket” (with a plan or commitment to reduce ticket volumes and therefore cost year by year). Both service provider and client can influence volumes so there is a joint accountability to drive volumes down.
• Example in Data Centre outsourcing world: price per server (P) times a number of servers (Q) times quality level (Q). Then total server volume reductions drive total cost down. Again, both service provider and client can influence volumes. Quality (bronze, silver, gold) is a client choice
• We now see a new P*Q*Q model: as explained above under Services, with technology evolution to cloud we see new type of contracts where the service is the Support of a full environment (including Functional Application Support down to Hosting). In this type of integrated service, the “unit” is a full environment (including all from functional to technical), and so the unit price is the price for that vertically integrated service.

The SLA/KPI/Reporting and governance structure

“What you measure is what you get”: designing the right periodic measurements is crucial to achieve certain behaviour from each party. The right measurements allow to make the link between the operational reality and the contractual discussions on an ongoing basis (e.g. continuous improvements in reality of operations and the evolution of the contractual price).

So a well-designed set of SLA and KPI are needed to steer in the right direction in line with the strategy and chosen model:

• Service Level Agreements (SLA) measure the quality of service and the service levels are typically contractually committed – SLA are “outcome based”
• Key Performance Indicators (KPI) typically are measurements that serve to e.g. improve a certain process – KPI are more “process based”

Referring back to the discussion that with cloud and other technology evolutions we see a new trend for “vertically integrated services”, it is clear that under such vertically integrated services the SLA that the provider commits is an end to end SLA (much easier to manage for the client)

Besides SLA and KPI the contract will define the governance routines (e.g. recurring meeting structures/agenda/participants) and the periodic service reporting (on what services and processes, and at what level of detail). Specific outsourcing strategies/models require specific SLA and KPI.

The internal versus external skills/capabilities

The fact of going for an outsourced model for IT drastically changes the internal skills/capabilities needed. Typically, internal core competencies evolve more towards “managing” (managing the business, managing the service providers, etc) and less of functional/technical “doing”.

Depending on the CIO strategy, the outsourcing model chosen, the way the services are packaged, and the tasks role & responsibility split internal/external, the IT leadership should review what are the core competencies needed internally, what is the current situation, and a plan to move from current to to-be skills/capabilities on the internal retained organization. This change management to an adapted skillset and different focus by the internal team (“managing more than doing”) often proves difficult.

Supporting technology for running and automating IT

Running IT is becoming more and more industrialized thanks to supporting technologies: automation of IT operations, service management tools starting with ticketing tools and integration of service management tools across service towers, tooling for cloud management e.g. orchestration & provisioning, etc.

These supporting tools are “client owned” or “service provider owned”. The latter is more and more the case in managed services contracts and with the evolution of technology for increasing IT productivity; service providers are investing heavily in new technologies (Robotics Process Automation, Artificial Intelligence) to drive more and more productivity and quality into the IT services provision. More and more this will be “service provider owned” tools (in a one-to-many model, so they serve many clients with their standard tools).

Contract and relationship management

Getting the two disciplines of contract management and relationship management right in an outsourcing situation, are crucial for getting to success.

• Contract management is a key core competence of companies when they move to IT Outsourcing. Contract management is the process (e.g. monthly contract management routine) that is crucial to keep both service provider and client to their accountabilities as far as what was agreed in the contract. The contract management routine will handle commercial topics (scope change management, ticket volume numbers and their impact on price, etc). But also other aspects like the general performance of the service provider (SLA, escalations, improvement action plans, etc) are handled. Contract management should factual, detailed, tough , but fair.
• Relationship management is about recognizing that outsourcing is a people business, a business in which good relationships, open discussions, win-win, respect for people, people engagement / satisfaction are crucial. Different people will have different relationship and people management styles, but experiences show that a “relationship management approach” in IT Outsourcing will lead to a strong long term collaboration.

“Trust” in an outsourcing is a key success factor. Trust means “service provider showing to defend long term interests of his client, “each party have objectives to meet – help each other”, “go for win win”, “give and take”, etc. Trust also means you do not micro-manage your outsourcing partner, he can manage his scope of work. Trust does not equal black box however. The contract management routines need to be designed such that it gives the client sufficient insights on the operations. E.g. we trust that our outsourcing partner is managing well topics like knowledge management, document management, compliance, etc, but it does not mean we cannot have transparency on what is done.

Another aspect where contract and relationship management is crucial is “change”. Many aspects can change (new services needed, change in SLA needed, price point changes because of evolution of technology, etc). Contract management needs elements in the contract that will allow such contract changes to be processed.

As said earlier, even the client objectives with the outsourcing can change (changing business context, changing CIO, etc). The contract and relationship management need to be such that a revisiting of the outsourcing objectives/strategy is possible, and then the different details of the contract (scope, SLA, pricing, etc) need to be changed. We advise as part of the relationship management routine to review periodically 1) if all elements of the contract are still in sync (and in line with reality) and make changes if needed and 2) review the client strategic objectives and if they have changed, then to assess whether any change to any of the elements of the contract is needed. This keeps the outsourcing healthy for the long term.

THE FRAMEWORK APPLIED TO A SAMPLE OUTSOURCING SCOPE

In below table we take as example a larger Applications Outsourcing contract. And we show how the different elements need to be aligned under different alternative models for such a contract.

Above table provides a good example on how different elements should be aligned. Even more insightful are examples where there was a mis-alignment

Some examples where the mis-alignment was already set up wrong in the contract:

• The contract had a “consumption” pricing model on a per ticket basis (price per ticket), but the CIO strategy is one where the service provider takes strong accountability for cost-reduction of the run function. This leads to many debates on yearly budget for the function. Therefore, suggestion was to adjust the pricing model: provider guarantees x% reduction in ticket volume per year, or there is a gain-sharing incentive for both parties on ticket volume reduction. Choosing the right pricing model will put the incentive in the right place.
• SLA and KPI scheme should be designed in such a way that it measures things that are relevant given the CIO strategy and the outsourcing model chosen. E.g. when the outsourcing model is one of both parties working hand in hand on continuous improvement, and the pricing model has ways to adjust cost based on continuous improvement (e.g. price/ticket) then the KPI and Governance should be aligned to that. In this case this was solved by adjustments to the contract: KPI’s that help detect continuous improvement opportunities were added, and a process around continuous improvement was added.
• We have seen a contract where a very detailed KPI and reporting scheme had been designed. KPIs around detailed support processes were designed to be reported every month. This was in conflict with the contract model i.e. managed-service and fixed price per service. This leads to the client staff still being at micro-level following up specific sub-processes in support. This leads to “wrong focus” in the daily co-operation between client and service provider. After assessing the situation, the client and service provider agreed on reducing the number of process-based KPI’s and focus on outcome based.

Let’s then take an example where the “reality on the ground” was not in line with what was defined in the contract and/or what is in line with the CIOs view on things:

The client outsourcing strategy and the contract clauses stipulated that “architecture” remains a client responsibility, but the “execution” (e.g. coding) is outsourced. Reality at client was that there still were quite some technical people that “are used to and love” being busy with configuration and coding. This led to conflicts: mis-alignment between provider and client who is responsible for the delivered quality, too much looking over the shoulder / technical discussions for the sake of discussion, client budget not optimized (double costs, …). Solution in this case is to confirm “who does what” and redirect the tasks (and the skills and mindset) of the internal staff to focus on the architectural and quality control aspects of the technical work. This change management often proves difficult.

CLOSURE

The author of this publication has been over past 20 years in many large outsourcing situations: shaping and contracting new contracts, transitioning signed contracts to the to-be situation, leading contracts in their first years, and undertaking improvement plans on contracts that are not running well. From this experience the idea for the IT Outsourcing Alignment Framework has grown.

It is experience on the ground that led us to say: root causes for issues can mostly be found is mis-alignment somewhere. So, look at the different elements, understand what the proper alignment of different elements is, and what is a potential mis-alignment. This will help to remediate the outsourcing relationship for the better.

We can only recommend applying the Framework on your situation as early as possible in the lifecycle of outsourcing. You can even do this assessment in a joint exercise with your service provider(s).

S-square also provides you the possibility for our Outsourcing Advisors to conduct such an assessment and provide recommendations.