Transition applications. How do we take support apps
A little about us, the customer, projects and background Our
team provides an application support service for 80+ German customer applications. Over 5 years of cooperation, we have developed trusting relationships. About once a year, the customer knocks out expenses, looks at how much our team costs and what quality it works with, and decides to outsource us a dozen or two more internal applications.
Our customer is a major manufacturer of servers and office equipment. The applications that come to us are mainly created for accounting, sales planning, orders and reporting at different levels. We also support an internal corporate portal on SharePoint and everything that is usually wound on SharePoint in a large organization (recruitment, document management, etc.).
Our team provides 2, 3, 4 lines of support for SharePoint and .NET applications. We solve incidents, fix bugs and problems, and change application code when necessary. We are also engaged in development from scratch, but this is the story of another article.
During these 5 years, we carried out the transfer of knowledge 4 times, and we have the experience that we want to share. Internal practices, how to plan the transfer, so that later fit into the budget and schedule, and avoid problems in the future when the service starts.
Planning for the transfer of services
Before we sit down for planning, we request two documents :
We also request the entire set of available documentation, code, and all incident records, if possible. Please make some review presentations for each application, where you can ask questions to those who understand it.
After the scale of thedisaster of the transmitted volume is cleared up in your head , it's time to open up MS Project and put together a plan.
For each of the transferred applications, we plan:
Planning a service transfer is similar to a regular project plan. The difficulty is that you set the line that you will reach in the analysis of the application yourself. How thoroughly the code will be understood, how seriously you need to understand business processes, how accurately you intend to reproduce the environment in which the application works. I have no special recommendations where to stay. We stop when, in general, how it works is clear, and we are able to figure out the details on our own. These details are just what will distinguish you the first six months - a year from the current service provider. At first you will solve problems longer, sometimes much longer. It is necessary to explain to the customer that at first the service will be very slow if the transfer of knowledge is inexpensive, and vice versa. Looking for a middle ground is better with the customer,
In addition to the plan, this stage involves the creation of a register of risks for which we laid down in the assessment.
Important : all the necessary amount of information should be brought to all interested people on time. It can be very uncomfortable to outsource the service, especially for the first time. It is important that people learn to trust you, for this your actions should be as clear and transparent as possible for them. Reports on the status of work should go regularly. If you do not meet the deadline, or messed up, the customer should find out about this as soon as possible.
Started.
After the plan is ready, the contract is signed and the team is assembled, you can start.
Knowledge transfer looks like any other project going according to plan. You can use the management methodology that suits your heart. We took 2-week Scram iterations, and they worked perfectly. A stack of project documents was prepared according to Prince 2.
As with any project, it happens that you suddenly need to do something that is not in the job description (oh, we forgot that this is not one business case, but three). It happens that you somewhere underestimated the complexity of the work. If you are an experienced manager, you also have a buffer for this risk.
But there is a difficulty that we encountered only on the project of knowledge transfer: strong resistance. The customer’s environment is not homogeneous; there are often people who are not very happy with the decision of the management to outsource the projects. Often, the current service provider boycotts the transfer of documentation, does not attend a knowledge transfer session, or does not tell you everything you need to know. In this case, all you can do is escalate, and if nothing happens, increase the cost of the transshipment. This situation and ways of working with it should be discussed before the transfer of knowledge has begun, of course, this item should be in the risk register.
At the exit from the service translation project, we also provide:
In addition, an official sign-off should take place, acceptance of work from the project manager for the transfer to the service manager.
The service manager, of course, begins to work much earlier than at the time of sign-off. Even before the transfer of knowledge, the size of the escort team usually pretends to be along with it, by the time of sign-off our assumptions regarding the team are only confirmed and adjusted. The service manager is involved in creating a preliminary version of the main service processes.
These processes describe:
The first months of service, these processes will be debugged and changed. From the preliminary version, they will develop into finished working versions. This is another transparency tool: no matter what we do, we are predictable for the customer.
When we train the service team and try to provide the service under the supervision of the current support service, the load of the service manager sometimes becomes even greater than that of the translation project manager. Well, of course, he should discuss the SLA and write a contract for the provision of the service. So, we can say that the service manager works tirelessly throughout the entire project for the translation of the service.
In order to have even fewer problems, people who will later work in the service team will necessarily participate in the transfer of knowledge. This is the core of the future team. After completing the translation project, they help the team master new knowledge.
When the service settles down a little, somewhere in 3-6 months, we start the process of improving the service. It is based on kanban. This process helped us to reduce the cost of the service one and a half times, but this is the topic of the next article.
Posted by: Fkleto4ku
team provides an application support service for 80+ German customer applications. Over 5 years of cooperation, we have developed trusting relationships. About once a year, the customer knocks out expenses, looks at how much our team costs and what quality it works with, and decides to outsource us a dozen or two more internal applications.
Our customer is a major manufacturer of servers and office equipment. The applications that come to us are mainly created for accounting, sales planning, orders and reporting at different levels. We also support an internal corporate portal on SharePoint and everything that is usually wound on SharePoint in a large organization (recruitment, document management, etc.).
Our team provides 2, 3, 4 lines of support for SharePoint and .NET applications. We solve incidents, fix bugs and problems, and change application code when necessary. We are also engaged in development from scratch, but this is the story of another article.
During these 5 years, we carried out the transfer of knowledge 4 times, and we have the experience that we want to share. Internal practices, how to plan the transfer, so that later fit into the budget and schedule, and avoid problems in the future when the service starts.
Planning for the transfer of services
Before we sit down for planning, we request two documents :
- Description of the service for each application, including:
- brief description of the application: what is it for;
- What business processes automates;
- what approximately tasks we have to do: close incidents and do regular maintenance work, monitor, solve problems, etc.
- a form for answering questions for each application:
- how many users use the application;
- they are internal or external;
- are there any key users;
- how many incidents are resolved on average per year, etc.
We also request the entire set of available documentation, code, and all incident records, if possible. Please make some review presentations for each application, where you can ask questions to those who understand it.
After the scale of the
For each of the transferred applications, we plan:
- regular knowledge transfer sessions;
- development environment development for the application, code parsing;
- writing or adding documentation (business processes, test plans, etc.);
- review of incidents and problems; creation of a knowledge base on incidents;
- work on incidents in the current support group (they do the work - we look);
- transfer of acquired knowledge to the support team;
- work under the supervision of the current support group (we do the work - they insure).
Planning a service transfer is similar to a regular project plan. The difficulty is that you set the line that you will reach in the analysis of the application yourself. How thoroughly the code will be understood, how seriously you need to understand business processes, how accurately you intend to reproduce the environment in which the application works. I have no special recommendations where to stay. We stop when, in general, how it works is clear, and we are able to figure out the details on our own. These details are just what will distinguish you the first six months - a year from the current service provider. At first you will solve problems longer, sometimes much longer. It is necessary to explain to the customer that at first the service will be very slow if the transfer of knowledge is inexpensive, and vice versa. Looking for a middle ground is better with the customer,
In addition to the plan, this stage involves the creation of a register of risks for which we laid down in the assessment.
Important : all the necessary amount of information should be brought to all interested people on time. It can be very uncomfortable to outsource the service, especially for the first time. It is important that people learn to trust you, for this your actions should be as clear and transparent as possible for them. Reports on the status of work should go regularly. If you do not meet the deadline, or messed up, the customer should find out about this as soon as possible.
Started.
After the plan is ready, the contract is signed and the team is assembled, you can start.
Knowledge transfer looks like any other project going according to plan. You can use the management methodology that suits your heart. We took 2-week Scram iterations, and they worked perfectly. A stack of project documents was prepared according to Prince 2.
As with any project, it happens that you suddenly need to do something that is not in the job description (oh, we forgot that this is not one business case, but three). It happens that you somewhere underestimated the complexity of the work. If you are an experienced manager, you also have a buffer for this risk.
But there is a difficulty that we encountered only on the project of knowledge transfer: strong resistance. The customer’s environment is not homogeneous; there are often people who are not very happy with the decision of the management to outsource the projects. Often, the current service provider boycotts the transfer of documentation, does not attend a knowledge transfer session, or does not tell you everything you need to know. In this case, all you can do is escalate, and if nothing happens, increase the cost of the transshipment. This situation and ways of working with it should be discussed before the transfer of knowledge has begun, of course, this item should be in the risk register.
At the exit from the service translation project, we also provide:
- code change recommendations;
- completed checklist of readiness to start the service: what is done, what is not done of the planned and why;
- preliminary version of the main processes of the new service;
- risk register of a new service, with lightened plans, of course;
- lessons learned: what went wrong and how not to get involved in it the next time.
In addition, an official sign-off should take place, acceptance of work from the project manager for the transfer to the service manager.
The service manager, of course, begins to work much earlier than at the time of sign-off. Even before the transfer of knowledge, the size of the escort team usually pretends to be along with it, by the time of sign-off our assumptions regarding the team are only confirmed and adjusted. The service manager is involved in creating a preliminary version of the main service processes.
These processes describe:
- How often event logs are checked
- how to work if you need the help of another team to close the ticket;
- how to properly close tickets in the system and much more, without which the service will not work like a clock.
The first months of service, these processes will be debugged and changed. From the preliminary version, they will develop into finished working versions. This is another transparency tool: no matter what we do, we are predictable for the customer.
When we train the service team and try to provide the service under the supervision of the current support service, the load of the service manager sometimes becomes even greater than that of the translation project manager. Well, of course, he should discuss the SLA and write a contract for the provision of the service. So, we can say that the service manager works tirelessly throughout the entire project for the translation of the service.
In order to have even fewer problems, people who will later work in the service team will necessarily participate in the transfer of knowledge. This is the core of the future team. After completing the translation project, they help the team master new knowledge.
When the service settles down a little, somewhere in 3-6 months, we start the process of improving the service. It is based on kanban. This process helped us to reduce the cost of the service one and a half times, but this is the topic of the next article.
Posted by: Fkleto4ku
Only registered users can participate in the survey. Please come in.
When outsourcing application support, you are primarily interested in:
- 36.3% In ensuring the smooth operation of applications 8
- 4.5% In application development 1
- 36.3% Using a process approach to ensure predictable results and a consistent level of service quality 8
- 22.7% In reduced application support costs 5
- 0% Other (indicate in comments) 0