Selected amendos articles

amendos article from newsletter 03/2020

Outsourcing: How to make the acceptance of transition results successful

Clients know the situation: IT services were outsourced to an external provider. However, the acceptance of the IT services in the transition phase is not running smoothly. Typical weaknesses are lack of documentation, insufficient personnel resources, missing measuring equipment and, in particular, services that have not been sufficiently tested by the provider in advance.

Weaknesses identified during acceptance usually lead to a delay in acceptance. In the worst case, it is aborted because the functionality of the services cannot be fully proven. If acceptance tests are cancelled or only partially released, additional acceptance tests must be planned. This causes considerable costs for both the client and the provider.

Reasons for an unfinished acceptance are in particular

  1. no clearly defined acceptance criteria before the contract is signed
  2. the provider underestimates the effort required for acceptance of the services and therefore cannot provide the necessary resources for acceptance
  3. no adequate configuration management according to ITIL

How can you avoid such situations? In this article I would like to show ways and methods to do so. I will concentrate on essential points that are critical during the acceptance process.

The outsourcing lifecycle consists of the phases strategy, conception, RfP / award of contract, transition and operation. The foundation for a successful acceptance is laid in the RfP phase of the services. From the outset, the framework conditions for the acceptance should be defined, taking into account company-wide guidelines (e.g. quality guidelines), templates and change management specifications. In order to realize this, the general conditions of the acceptance and the responsibilities must be clearly and unambiguously formulated in the tender. Acceptance in the outsourcing life cycle is divided into three work steps:

Figure 1: Work steps for the acceptance in the outsourcing life cycle


1. Creation of the test strategy

ITIL defines the test strategy as the overall approach to organizing tests and allocating test resources. In the award phase, the provider creates the test strategy as part of the bidding process in accordance with the specifications of the RfP. The required activities include

  • translating the service concept from the service design into test requirements and test models (test plan, test procedures, list of test elements, scripts, etc.)
  • definition of the necessary test levels (component test, integration test, etc.)
  • definition of the acceptable failure rate for each test level (pass/fail criteria) as well as abort and restart criteria
  • coordination of the acceptance procedure
  • clarification of responsibilities during acceptance
  • definition of the delivery results
  • specification of the role requirements during acceptance

The client checks the test strategy for completeness and the traceability of the test requirements back to the service design criteria.

Every company has different attitudes to risk with regard to service quality. This willingness to take risks influences the degree and level of validation and testing. Depending on the risk appetite, the client may require an adjustment of the testing strategy. The aim is that a joint agreement on the acceptance of services is reached between the client and the service provider. The test strategy becomes part of the contract.

If service changes are agreed upon and lead to contract adjustments, the acceptance procedures must be adjusted with appropriate advance notice before acceptance.


2. Notification of readiness for acceptance by the service provider

In order to avoid frictional losses during the acceptance in the transition phase, an acceptance readiness test should be carried out by the client beforehand. This test ensures that all necessary preliminary work to start an acceptance procedure has been completed correctly.

According to the current project plan, the provider reports the readiness for acceptance of the service to the client. The prerequisites for reporting readiness for acceptance should already be defined in the contract. The provider delivers the relevant documentation as agreed in the acceptance procedure specified in the contract.

Depending on the type of service, the documentation includes

  • delivery bills
  • guarantee certificates
  • configuration list(s)
  • network plans
  • executed checklist(s) or test protocols
  • operating manual
  • training documents

Within the scope of the readiness for acceptance test, the client checks the documentation for completeness and correctness. The client may have several queries to the provider. When these have been clarified, the client confirms the readiness for acceptance. If the delivery is incomplete compared to the specifications, the acceptance readiness is rejected and the service provider is requested to close the open points. Depending on the situation, the readiness for acceptance can be confirmed under the condition that the service provider removes the defects by the start of the acceptance. It is important to allow enough time for the documentation to be checked and a reworking period to eliminate the defects before acceptance.


3. Acceptance by the client and declaration of acceptance

The organization of the acceptance is done by the service provider. He ensures that the infrastructure for the execution of the acceptance is created and that all participants receive the relevant information in time.

In the acceptance procedure, the service provider presents the test procedures defined in the agreed acceptance procedure to the client. Defects resulting from additional, not pre-defined tests may not lead to an acceptance abort, unless the effects of the defects are so serious by their nature or number that the service is significantly impaired.

After acceptance, the service provider must have the opportunity to rectify the defects within a realistic period of time, which is agreed upon jointly at the time of acceptance. The results of the acceptance must be recorded and identified defects must be listed with details of the defect pattern, defect class, further procedure and responsibility.

Acceptance ends with a declaration of acceptance by the client with or without open defects or with an acceptance abort according to contractually defined abort criteria. The service provider undertakes to remedy the defects in due time. It is advisable to contractually set the largest payment milestone to a successful acceptance. Otherwise, the motivation pressure on the provider cannot be maintained.



The structured approach and the applying of this approach, as well as the acceptance criteria in the contract, ensure that the service provider takes a detailed look at the expected expenses. The introduction of the acceptance test ensures that all prerequisites (e.g. configuration management, documentation and preparatory tests by the service provider) for a smooth acceptance are in place. It is important to describe the activities of the acceptance in the project plan and to update them regularly. Furthermore, it is recommended to plan an acceptance in several steps and as early as possible in order to detect defects early on, which will not occur in later partial acceptances. A careful acceptance of services also ensures service quality in the later operating phase.

Author: Michael Olaolu




amendos article from newsletter 02/2020

IT Service Manager versus Provider Manager - what is the difference?

In many companies the terms Service Manager and Provider Manager are used for roles in the IT area. Since there is no accepted standard definition for these terms, the understanding of the roles they refer to in companies varies greatly. Sometimes they are used synonymously for one and the same position in IT. Corresponding job titles also appear repeatedly in the corresponding job portals. Below, we will show on the one hand a demarcation, but also the necessary interaction between the two roles. The basic definitions are based on the most common usage in the market. Our main focus, however, is the design of customer and supplier management.

First of all, I will explain the two roles and distinguish them from each other before we come to the dependencies and the interaction of the two roles. Both roles have key functions in the service provider chain of an IT department.


The role of the Service Manager:

A Service Manager ensures that the IT services offered internally always meet the requirements of his IT customer. He has a sales-oriented role and is the first point of contact for the customer. This requires a basic understanding of the business, requirements and processes of his customers as well as soft skills for dealing with the customer. In particular, he will be responsible for the following tasks:

  • Ensuring that the service agreements concluded with the customer are adhered to - this implies representing the customer's interests in his own IT organization,
  • SLA reporting and regular service review meetings with the customer,
  • advising the customer on the existing IT service offering,
  • coordination of the demand with the customer,
  • Recording new customer requirements and initiating the resulting service changes and new services in his own IT organization.

From an ITIL point of view, this is a mixture of tasks from the management practices Relationship Management, Service Level Management and (still included in ITIL V3) Demand Management.


The role of the Provider Manager:

The Provider Manager ensures that the IT services purchased from "his" external providers always meet the requirements of the internal service portfolio. His role has a clear focus on supplier management. He is the central contact person for the provider's service manager. He must have a good overview of the current internal (i.e. defined in the service catalogue) service offering, service changes currently being planned and the entire service organization. He must also have soft skills; in this case for dealing with his providers as well as with internal colleagues from other functional areas. In particular, he will be responsible for the following tasks:

  • Ensuring that the service agreements concluded with the provider are adhered to - this implies representing the interests of the own IT organization towards the provider,
  • review of SLA reports and invoices from the provider, regular service review meetings with the provider,
  • coordination and commissioning of necessary service changes and new services on the provider side, ensuring correct implementation and commissioning of the changes,
  • ensuring appropriate risk and compliance management regarding externally sourced services,
  • management of the identification and implementation of improvement potentials and innovations in the service segment of the provider,
  • monitoring of provider-related budgets.

From the point of view of ITIL, this includes the management practices Supplier Management and Measurement & Reporting, but in some cases goes far beyond them.


Demarcation and interaction of the two roles:

As you can see, the tasks of the two roles are not so different: Both are concerned with the provision of services in accordance with agreements and - in an increasingly agile world - with the acceptance and implementation of necessary service changes. But the focus is different in each case:

The Service Manager as part of "IT sales" ensures that the internal service offering always meets the (constantly changing) needs of the customer. His goal is "sales success", i.e. to achieve planned turnover, customer satisfaction and long-term customer loyalty. Today, the latter is no longer a matter of course for the internal IT department: With quickly accessible, easy-to-order cloud services, there is a danger that internal IT customers will increasingly - bypassing the IT department and purchasing - purchase services externally (keyword: maverick buying).

The Provider Manager, on the other hand, must ensure that the services sold by IT sales that are not produced internally are purchased and provided as required from external providers contractually obliged to do so. The Provider Manager's objective is therefore to ensure that suitable external services are correctly provided to meet the demand generated by IT Sales.

The division of roles in terms of tasks already makes it clear that the tasks of one role require those of the other and must be well coordinated: The Service Manager is dependent on the services agreed with his IT customers being produced in appropriate quality and on time. If the services are provided by external providers, the responsibility for this lies with the Provider Manager: he must control or manage the providers accordingly. On the other hand, the Service Manager must always be up to date on the current status of the provider's services in order to be able to provide competent information in discussions with the customer.

To ensure this, a regular flow of information between the two roles must be ensured. In addition, processes must be established to ensure that service requests and service changes requested by IT customers are handled appropriately. In addition to the two roles, others such as service design are also involved in such processes. The clean implementation of the processes and the exchange of information becomes even more important if more than one provider is involved in service provision.



According to our definition, Service Managers and Provider Managers are at different points in the service delivery process: The service manager operates the IT department's interface to the customer, while the provider manager controls external providers at the supplier interface. Both must be coordinated so that the purchased provider services also meet the customer's requirements. Ideally, both roles are given to one instance or position. In practice, however, this is usually only possible in smaller environments. In all other cases, the interaction must be very well organized in order to achieve the goals of the IT and thus also of the IT customers.

Author: Jörg Bujotzek




amendos article from newsletter 01/2020

Managed Services versus Classic IT Outsourcing

When companies outsource IT services, they often expect the external provider to provide the same service as it was previously provided by their own IT department. This so-called classic outsourcing forces the provider into a customer-specific corset that limits the potential for optimization and cost savings. Standardized Managed Services offer an efficient and attractively priced alternative to classic outsourcing, but have limitations. Why and under which framework conditions their use can nevertheless be worthwhile is explained in the following.

First, we take a look at the two outsourcing options and highlight their main advantages and disadvantages:

 Figure 1: Comparison of the outsourcing options

1. Classic IT Outsourcing

With the classic IT outsourcing, the client expects the provider to deliver the service previously provided internally in a largely identical manner externally. The provider is often given additional process and tool specifications.

In most cases, classic outsourcing is also connected with the transfer of IT personnel to the provider. Since the provider takes over the operational tasks, the employees are no longer needed internally. The internal reduction of personnel is usually the only way to ensure the profitability of the outsourcing measure. At the provider, the staff taken over ensures customer-specific operational knowledge and service continuity.  


The main advantage of classic outsourcing is that the services to be provided externally in the future correspond exactly with services previously provided internally.

Firstly, this means that the services can be described in the request for proposal exactly as they are specified internally. Of course, the latter only applies if the services have been defined exactly internally so far. If the existing service specification can be used as the basis for the request for proposal, gray areas in the provider contract and the potential for later conflicts with the provider can be reduced.

In addition, everything remains the same for the IT users with regard to the service after outsourcing, at best only the contact persons will change. These are good prerequisites for a smooth transfer of services from the client to the provider.


In practice, however, the service transition is not always as smooth as the one just described:

·         Firstly, many companies have to describe the services to be taken over externally in writing for the first time, as they have no or no current service catalogue and no other service specifications. This can lead to many things being represented incorrectly or forgotten. The external service is soon no longer identical to the previously internal service. 

·         Secondly, the entire internal operations team does not usually switch to the provider. This means that the provider also uses employees from its existing pool to set up and operate the service. These employees are not familiar with the customer-specific service environment. Thus, even if personnel is transferred to the provider, there is still a risk potential for service setup and operation.

A permanent disadvantage over the entire operating phase is that the provider must maintain a special operating team for the customer's services. This team must be trained for the customer’s specific environment, in contrast to the standard internal processes and tools used for other customers. The scope of services and the technologies used are also often only maintained for this one customer. As a result, the provider has little potential for rationalization in the services compared to the internal service provision by the customer, and thus his margins are often lower.

The incentive for the provider to invest in service optimization is therefore low, since it usually only benefits this one customer.


2. Managed Services

Managed Services are standardized IT services of a provider, which he carries out in the same way for all customers and whose scope and service level are identical for all customers. For such a service, the provider preferably uses multitenant technology to serve multiple customers on one platform (e.g. for a managed server service, a hypervisor to provide virtual servers for each customer on the same platform). From the customer³s point of view, the provider operates the infrastructure elements included in the service remotely as far as possible. Only in exceptional cases is the provider on-site at the customer´s premises.


Since the provider provides the service identically for all customers, he can use scaling effects, an effect called "IT industrialization". This means in particular that he can offer a thoroughly optimized, efficiently provided service at a reasonable price despite advantageous margins. Due to the high turnover generated by the service, the provider has a vested interest in constantly optimizing the service delivery. It can also serve new customers at marginal cost.

Because of the economic importance of the Managed Service for the provider, he is keen to ensure that a large part of his team is highly skilled in the use of tools and processes. Furthermore, the provider will trim its operating personnel to be service-oriented in terms of competence and efficiency, with the result that the quality of managed services - despite low prices - is higher than that of customized services.

In addition, providers will provide a precise specification of the Managed Services they offer, as this generally reduces the risk of grey areas in contractual agreements. It also allows the provider to offer the same service to all customers without any major interpretation discussion with individual customers.


A Managed Services provider is generally not interested in taking over a customer's IT staff. Due to economies of scale, it requires little or no additional staff to take over a customer's services. In addition, he would have to train the new staff in processes of his Managed Services and its customer-specific service operations knowledge would lose a great deal of importance.     

Managed Services do not cover special customer-specific requirements that deviate from the market, unless they are requested in the same form by a reasonable proportion of other existing customers.


3. When are Managed Services Beneficial?

Many clients do not see any chance to use standardized Managed Services due to existing special requirements in their own company. However, the impressive advantages of Managed Services (good service quality at an attractive price) should be reason enough to question their own special requirements for each required service.

With classic commodity services (these are in particular infrastructure services such as workplace, server, storage), which every company needs in a similar basic quality, special requirements are only tenable in very few exceptional cases when viewed objectively: If other companies in the industry can manage with the basic quality, why not the own one?

Those who consistently orient their services to market standards and standardize them where possible, open up the opportunity to take advantage of managed services.

Author: Jörg Bujotzek