// IT Merger & Acquisitions, IT Quality Improvement
Building the „retained Organisation" as a key to success
Everybody is talking about outsourcing, scenarios for sourcing models are state-of-the-art.
If the internal IT service provider decides to outsource parts or whole areas of its provision of services to one or more external providers, i.e., to initiate an outsourcing project, then a lot of framework conditions are changing for it.
Fundamentally, it is changing its understanding of its own role. The CIO and the remaining team, i.e., the „retained organisation" take on new strategic and controlling responsibilities, operational and above all technical responsibilities are reduced. The forfeiting of pure expertise for a controlling function instead is what quite often makes the difference.
This is a change process both for the company and for the people involved in the process:
- The remaining employees have to gain clarity regarding the understanding of their future roles.
- New responsibilities and functions are necessary to provide the service performance towards the customers in at least the same quality and grade.
- The benefit of the outsourcing process must be assured
The „retained organisation" primarily has new responsibilities
Once a sourcing strategy with corresponding performance profile has been defined, a lot of new topics and exciting challenges are on the table.
Stepping into new territory, away from operational responsibilities towards strategic and controlling responsibilities is a learning process for those involved. Not only do they need information but also an active communication and an active participation in the change. The more open and the more positive the early handling and communication regarding the new responsibilities is, the better the transition will succeed. Here, targeted coaching often also will provide support.
To plan and prepare the transition period with measurable and realistic objectives promotes motivation.
It is important to create a controlling functionality for the relationship with the provider that functions as organisational and procedural interface between the customer/internal service provider and provider. A provider management bundles all service, controlling and communication relationships from and to the IT provider and takes care of all current and future IT architecture requirements.
Experience from many projects like this shows that four essential core areas need to be taken into consideration when it comes to the controlling of one or more Providers:
These core areas must be filled with life through processes, roles and responsibilities as well as a corresponding organisational form.
The question what the organisational form of a provider management (structure and setup) is going to look like depends on a variety of factors. One of the essential influencing factors for the future model is the demarcation line of the services that are going to be outsourced. The form and fashion of the demarcation of services, functionally, technologically demarcated, or from a service point of view with the outsourcing of whole services, has an impact on how intense, how comprehensive and how controlling the new responsibility is going to be.
Controlling via the line organisation – the decentralised model
This model is characterised by the fact, that relevant activities for the controlling are not handled within a central organisation but rather distributed within the customer‘s line organisation.
Thereby, all areas of business involved maintain direct communications relationships with the provider on the operational level; there are a multitude of transfer points between the provider and the customer.
One of the strengths of this model are the short, direct paths in the communications of the organisational units amongst each other. This provides for a high degree of flexibility. If the provider management utilises technical analysts who are equipped with the respective IT infrastructure know-how of the current IT service landscape, a quick translation of business requirements into functional requirements and the corresponding IT services is possible.
But, a decentralised organisational form also features a high complexity with respect to controlling and communications. A delineation of duties and responsibilities of the parties involved that is missing, not transparent, or based on individual preference, as well as the multitude of different communication channels may lead to far-reaching intransparency. Costs, ordering behaviour, activities taken care of, requirements addressed, agreements, prioritisations – important facts remain positioned next to each other without being interconnected. This, in turn, leads to inefficiency on the operational level.
The provider‘s interest in clear structures
A multitude of different requirements is addressed at the provider. To ensure an efficient processing at the transfer point, the provider can request strong, structured processes and clear roles and responsibilities on the customer‘s side in order to process requests or escalations. As a consequence, this may lead to additional, unplanned expenses for the process design on the customer‘s side that increase the costs. A prioritisation of the inquiries addressed at the provider‘s is difficult and carries the risk that different specialised departments and their requirements are played against one another.
The alternative: Setup of a central provider Management
A central provider management combines within a single organisational unit all processes, roles and responsibilities that are necessary for the controlling of one or more providers.
Thereby, all information is exchanged with the provider centrally at a few transfer points. Generally, this model features structured processes, clear roles and responsibilities and unique and transparent communications and escalation paths.
The centralistic model ensures a strong position towards the provider; the communication takes place at eye level. The channelling of all activities on the operational level ensures great transparency with respect to current requirements/orders, budgets, bills, ongoing activities in regular operations, etc.
But this may also become a boomerang for the customer: due to the strong, process-oriented structure, the model quickly becomes inflexible and rigid. Long, laborious paths for approvals and escalations are the result, which may lead to performance impacts. New impulses are difficult to process, innovative approaches are cumbersome to implement.
The creation of the „retained organisation" does not happen by itself, it has to be planned
Both models – decentralised and centralised – have inherent advantages and disadvantages. As is so often the case, the strategic perspective will decide the correct path. Does the sourcing have a long-term goal? Will a change of providers also be an option in the future? How much know-how should remain within the controlling organisation? How centralised or decentralised is the customer positioned within its own organisation? These and other questions have to be answered.
Once the contract has been signed, it is too late! The development and implementation of sourcing strategies is quite often performed under severe time constraints. As a consequence, customers do spend little or no early thought on a future organisation of controlling. When a contract has already been signed, the provider management can only „react". Experience shows that it is good to also plan the provider management and the operational regular operations within the retained organisation during the discussion of the future sourcing strategy. The concrete development of the future remaining organisation is then performed in parallel to the request for proposal or even prior to it.
Many roads lead to Rome
There is no single correct approach nor a single correct model for an organisational form for the controlling of one or more providers. But to develop the retained organisation with provider management and the operational regular operations in parallel to the request for proposal is one of the important activities early on in the project plan.