Back to resources

Taking Over Maintenance and Development of Existing Customer Applications From Other Vendors

Stakeholder Management
Strategy and Vision

9 December, 2021

Jan Pieczykolan
Jan Pieczykolan

Head of IT Development at Santander Bank Polska

Jan Pieczykolan, Software Engineering Director, describes how he prepared a successful transition plan for a vendor to take over responsibility for a whole customer IT domain.

Problem

The company was bidding in a tender for a 3-year long outsourcing contract. One of the initial steps was to transfer and re-build knowledge about 30 business support systems that were the subject of the contract. As a part of the offer, the vendor was expected to provide a plan and a schedule of this step with the price.

Actions taken

A team was gathered to investigate documentation that the customer made available for a short period in its premises. We ran an initial, brief analysis of those systems to understand their complexity in a minimum time better. They helped us in setting initial assumptions about the systems in question.

The methodology we used was quite similar for each system but had to be tuned to reflect specific systems characteristics. Usually, it would help if you gathered all artifacts like documentation and source code. Prepare source code repository and CI tooling to build the system. In parallel, the team may be going through source code to get acquainted with it. In the final stage, when knowledge is transferred, and tools are ready, you may be asked to solve some of the genuine production defects in the required SLA. This is a test to check if you can safely take over responsibility for this system.

Due to the scale of the endeavor – we were iteratively grouping those systems in several categories to reduce the problem and find common denominators for identified applications’ groups. This led us to identify four different groups of applications. Each group had additional complexity, and therefore the amount of work needed to re-build knowledge and set up an environment was different.

We prepared a template of a transition plan for each group, together with a schedule and workload estimate. Those templates were assigned to each application from a specific group. Thanks to that, all applications had an initial schedule and pricing. We have slightly tuned plans for specific applications to reflect their individual characteristics in the last step.

Lessons learned

  • If the problem you face is too big to solve at once, use the divide and conquer approach.
  • If you lack knowledge, try to make an assumption.
  • If you are making an assumption, write them down.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Relationships, like products, need to be designed.

7 March

3 ways leaders can cultivate relationships that lead to better products.

Leadership
Building and Scaling Teams
Career Growth
Team Management
Strategy and Vision
Guy Jenkins

Guy Jenkins

SVP Global Customer Experience at Salesforce

A Day in the Life of a Product Lead in FinTech – A Series

31 January

Discover the daily struggles, challenges, and moments of delight encountered when delivering banking products around the world. I will share my story candidly and honestly, without filter as much as I am allowed, and offer insights into my approach while providing retrospectives of the results.

Career Growth
Communication and Collaboration
Managing Stress and Burnout
Strategy and Vision
Loussaief Fayssal

Loussaief Fayssal

Director of CX at FLF PRODUCT DESIGN

V2 infrastructure project

21 December

Consideration for starting a multi year software infrastructure ( V2 ) project that involves hundreds of globally distributed engineers.

Stakeholder Management
Engineering Processes
Ahsan Habib

Ahsan Habib

VP Software Engineering at human

Myth Busting

10 December

Supporting principles on why being data led (not driven) helps with the story telling.

Leadership
Productivity
Stakeholder Management
Building and Scaling Teams
Transitioning into a New Management Role
Communication and Collaboration
Team Management
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

The Not-So-Easy Guide on How to grow and develop an Amazing A-Team

5 December

Your Org Team may as well be a Sports team. Let's explore how this cohesive, multi-skilled team can be optimized for Great Group Playoff.

Leadership
Stakeholder Management
Building and Scaling Teams
Managing Stress and Burnout
Strategy and Vision
Internal Process Optimization
Jaroslav Pantsjoha

Jaroslav Pantsjoha

Google Cloud Practice lead at Contino