When it comes to outsourcing, there can be negative sentiment because people perceive the word to be linked inexorably with redundancies. There are however many positives as the outsourcing sector provides benefits and opportunities to both organisations and to individuals. Outsourcing can, for example, bring about increased staff satisfaction through a higher level of responsibility - staff tend to shift from carrying out routine operational responsibilities to managerial and problem-solving activities.
The world has changed too. Information technology has moved from being a singular function which was often experimental and outside of the business, to being a core essential to the business. IT is today meshed with and intrinsically linked to the business. For example, in 2013, during the proposed merger between mining companies Rio Tinto and Glencore, a study found that the most complex element of their business to integrate was information technology, and not the mining operations.
The benefits of outsourcing include a potential reduction in the total cost of ownership of services, efficiency gains and the benefits of specialist knowledge provided by the outsourcer. This frees the host from operational responsibilities which are often far removed from its core business.
The downsides include the overhead of having to work across organisational boundaries and a reduced ability to operate in an agile way. Organisations also need to flex according to the host’s business, given the increased distance from the business.
All this means that firms have started to ask whether they can operate IT departments effectively and economically. Indeed, some are considering whether they should even be in the business of operating IT departments.
This article was written to provide guidance on the steps necessary to make an outsourcing project successful. It will look, for example, at complex arrangements that should never be underestimated.
Further details about outsourcing
Putting in place outsourcing arrangements will make significant changes to the host organisation, and it is therefore necessary to define the target state. Outsourcers usually have many clients, and they tend to create organisation units around operations for each client.
Outsourcing often means farming out the operational layers of the IT organisation while retaining senior IT management, service management, design authority (i.e. architecture) and the project’s organisation.
The success of the outsourcing arrangements is determined not only by the performance of the supplier, but also by the strength of the delivery project, the ongoing supplier management, and the host’s financial management.
Service integration model
A service integration model should be thought of as the global forum of cooperation and coordination in which parties participate. This type of model involves the definition of integration points into which work is delivered, for example, operational integration and process integration.
Each supplier involved in the model will have a point of commercial management, service management and operational handoff. Typically, the host or suppliers will put in place arrangements whereby suppliers handoff operationally to other suppliers.
Model definition needs to consider, and can include, the following: service desks, self-service portals, interfaces to specialist functions, and the IT service management (ITSM) toolset. There may be one ITSM toolset or there could be many. If they are numerous, they could be joined, either through messages, systems integrations or an enterprise service bus intermediary data layer between toolsets.
The service integration model should be refined to define the specific relationships between parties. Key factors include: operational handoff, where resources are hosted, the systems integrations that are to be put in place, and from where - and to where - code pushes take place.
The integration model should define a common operating framework for the involved parties and this should consider everything from applicable policy and processes, to the technology aspects; infrastructure standards, and application coding practises, common tools and preferred technologies.
Working practise considerations include the physical places of working, staff interaction, meeting formats, a common desktop computing environment, document sharing portals, and possibly business training to ensure that the host’s business is understood across the delivery partners.
Supplier types
Understanding the outsourcer type is key to understanding how to integrate them. The industry has developed some terms to generalise outsourcer types. The following list summarises these:
- Colocation provider (“Colo”) - A provider that offers just datacentre accommodation, power, cooling and possibly a very basic type of technical guided machine visit service.
- IaaS (Infrastructure as a Service) - A provider of raw infrastructure such as the base build of Windows, Linux or Solaris servers with no systems management.
- PaaS (Platform as a Service) - A provider of platforms that are ready for use, and the systems management for these platforms.
- Platform Managed Service - A provider of the technology and management layer for on-premise platforms (mid-range servers, mainframes and middleware).
- Platform Managed Service: fully integrated - A provider of platform services, and additionally a wider scope that provides the backbone of IT’s service provision, including aspects such as service desks, triage to other suppliers, global support teams, ITSM toolset, global processes, desktop services, and software packaging.
- SaaS (Software as a Service) - A provider of published applications and the management layer around those applications and all underpinning elements.
- AD&M (Application Development and Management) provider - Specialist application development services which provide what is often referred to as in-house development (may exclude platforms).
- Business Process Outsourcing (BPM) A provider of the full set of capabilities and activities that are required to operate a business process, for example the outsourcing of a customer business service desk or mortgage application processing and account servicing processes.
Contracted scope
The specific service scope must be defined for each provider. This should be assessed by considering details such as: the underlying technology stack, servers, middleware, applications, technology operations processes, service processes, services, and business processes.
It is advisable to instigate a mapping exercise to ensure that all the required scope is carried out between the host and outsourcers. In addition to scope, the non-functional requirements and service levels need to be considered. This will include factors such as: hours of operation, locations and delivery levels. The latter can cover details like the availability of systems or time to remediate an outage.
Next, the host’s business requirements must be translated into service requirements. Going further, the service requirement must be mapped to all the service suppliers. Doing this will expose any gaps.
The method by which billing takes place and the supplier’s rate card must be agreed too. The most common billing methods are a flat fee system, or consumption-based billing (or a combination of these).
Once the scope and service levels have been defined, the supplier contract should be addressed. Getting the contract right early on is an important exercise as this sets the delivery expectations. The contract is also central to dispute resolution too. It’s also worth remembering that changes to the contract are very difficult after it has been produced and signed.
It is paramount that the right parties should participate in the contract production cycle. Key people can include: technicians, architects, service managers, service integrators, commercial, finance, legal and senior management.
Process design
With contracts arranged, the process level of integration with the supplier must be addressed. This starts with mapping the process parameters between the organisations. Examples of these include: incident priorities, incident scenarios, change types, or the list of standard changes possible.
Process reference data, such as the host’s list of request types, much be agreed between the parties too. These need to be broken down into their constituent steps and examined. This will enable an understanding of where the responsibility for each step sits. Where a process step crosses an organisation boundary, a definition of how the integration takes place will need to be put in place.
The support model ratifies the incident initiation and the escalation routes for each component type or application. Remember that various parties can be involved. All this should be expressly defined to ensure completeness. This will ensure that the support system understands how to correctly triage incidents. Without such work, parties will only understand the organisational framework within its own organisation. And this, of course, won’t aid successful collaboration.
The support model should include a definition of the interfaces through which incidents are initiated. These may be, for example: monitoring systems and service desks; the support routes for the various supported elements; and a definition of the flows for functional and hierarchical escalation.
The level of supervision and assurance required for the implementation and running of the supplier activities depends on the supplier type and the activities in question. Technical operations processes (patching, backups and batch file management) performed by a business process management outsourcer is assumed to operate satisfactorily under the supplier line. It will, therefore, require no oversight or assurance by the host. On the other hand, technical operations processes provided by a platform provider may interface directly with the host’s operations. It will need integration activity, assurance and oversight.
Implementation
Once design is complete, implementation is carried out using a delivery project with workstreams for all the required elements: the technology stack (datacentre, networks, infrastructure, and application), application migrations (if applicable), ITSM tooling, capability (including service desks), technical operations process delivery, and service processes.
Where supplier interactions are required between providers, agency agreements should be put in place to allow the suppliers to interact operationally. In some cases, internal or supplier capabilities will be replaced by an outsourcer’s capabilities. There may be legal responsibilities with regards to providing TUPE transfers of staff to the new supplier (TUPE stands for the Transfer of Undertakings [Protection of Employment] Regulations 1981).
Transferring staff to the new supplier is an opportunity to facilitate knowledge transfer and mitigate risks in this area. An organisation’s human resources department should be engaged early on in order to commence the TUPE transfer process and to make unneeded roles redundant.
The removal of capabilities should be considered in line with the need for retention of knowledge. Knowledge transfer activities should be carried out during the final months of retaining these capabilities. It is advisable to capture documentation or to produce documented knowledge from knowledge transfer.
This transfer from a supplier should be focused on bespoke services such as naming conventions, application release procedures and disaster recovery procedures. This is as opposed to generic operational knowledge which can be obtained off the shelf.
The project should devote time and effort to running communications. This is necessary in order to bring staff onboard with the idea of outsourcing and to keep the vast amount of moving parts - operational departments and project workstreams - joined up through frequent interactions. Staff communications should be open and honest and describe the business drivers for the move, the opportunities and the loss of opportunities.
Completion steps
The next step is to consider the reporting and governance processes. This creates a feedback loop where operational status is fed from the supplier environment to the host’s management. This allows the host’s management to identify issues, and to feed improvement activities into the supplier operational environment, as well as to agree on a position for requesting service credits or contract termination.
Supplier reports must be designed and agreed in terms of: scope, specifications, metrics and formats. They must also be delivered at routine intervals - usually monthly.
The governance process depends on regular governance meetings between the host and suppliers. These are typically structured in a hierarchical form with operational meetings feeding into executive meetings.
Testing traditionally tends to be technology focused and it’s therefore likely that the technology workstreams will carry out a testing phase. The integration workstream should define adequate test cases to cover the service layer and put these forward for system testers to execute. These may include testing business processes, service processes (such as specific request cases which span multiple parties), and non-functional requirements testing aimed at service levels, resilience and load.
Demands to use the new outsourcing arrangements may necessitate the need for an early service release interim period for the delivery project. Where environments and processes are stable and useable, it is possible for the project to declare these live for use. During the interim period the project would close the remaining gaps and complete remaining project activities such as application migration.
Conclusion
Outsourcing will, most likely, be a key part of the IT industry for many years to come. Along the way it will bring challenges and personal opportunities to many. The success of the process depends upon the strength of the implementation projects and the host’s ongoing supplier management capability. Successful implementation also requires a breadth and depth of knowledge and coordinated activity.
Finally, it is worth noting that a robust supplier integration often forces an organisation to examine its own processes and maturity. This is critical in order to ensure that the organisation will realise the benefits of outsourcing for many years to come.
