See all articles

Taking over the app – best practices. Part four: partnership manager perspective

Monika Szutko-Partnerships Manager

The decision to change a software development team mid-project doesn’t come easily. Nor is the choice of a new software house or the transition that follows. The reasons for such change vary from changing the good to better, to addressing severe issues, and all that falls in between.

The “why” behind decisions to change a software development company

Before we go into best practices for clients and partnership managers facing a takeover of an ongoing project, let’s go through the many minor things that impact decisions about changing a software development company:

  • Lack of transparency and trust
  • Constant changes in team composition combined with poor/lack of knowledge transfers between the team members
  • Generating additional cost that is supposed to increase efficiency, e.g. through growing the team, but failing to achieve that
  • Missing the deadlines frequently and with no prior notice (or a last-minute notice), or even charging for the work delivered during the extra time
  • Making promises one can’t keep
  • Using legacy code as an excuse for underperformance or lack of competences
  • Taking advantage of a client’s limited technical knowledge. We often talk with clients who are frustrated with their current team because instead of providing straightforward explanations, they keep all the technical information to themselves. Their explanation is based on a comparison of software development to random examples e.g. surgery. One of the tech team’s or PM’s key tasks is to inform the client about the project details, including technicalities, in a way that’s clear to the client.
  • Exploiting and finally losing trust
  • Inefficient team communication and knowledge management

Such negative experience motivates people to change the technical team in ongoing projects. In order to choose a better, or possibly the best, software house, you should acknowledge all the deficiencies of the existing setup. Your experience combined with some industry insights we’re going to share below should give you enough information to find a partner you can trust, and secure a better contract.

Client’s perspective

Choosing the right development partner for your company is not easy, especially if you want to replace an existing provider with a new, better partnership.

Let’s take a look at the things you can do in order to maximize your chances of success:

1. The software development company:

  • Pay attention to the attitude of the new company – the biz dev representative, project manager, and the tech experts you get in touch with. If communication is difficult already at an early stage, it’s definitely a warning. Also, note how people collaborate with each other, they might be working together on your project after all.
  • Expect transparent communication. Hearing that something cannot be delivered within a suggested deadline may be a good thing. It may mean that your partner is honest and avoids empty promises.

2. The team:

  • Ask to meet the team you might be working with, in case you haven’t had the chance to talk to them already.
  • In case a new team will be recruited for your project, take it as an advantage – people will be recruited according to the specific requirements of your product. This scenario is most likely to happen when your project requires a real superhero, with particular skills, experience, or tech stack.
  • Consider starting with a small team and letting the team grow organically as the development needs arise.
  • Look for a solid team you can rely on and establish a partnership with them. Your new development team will be most effective when they feel like they’re part of your core team, rather than an outsourced workforce. A partner won’t leave you alone in case your product experiences downtime, faces security threats or deals with other vulnerabilities.
  • Trust their ideas, especially if you’re talking with an experienced team. Of course, it doesn’t mean you should ignore your priorities. Stay focused on your goals, but be flexible when it’s better for the project’s success.
  • Be open to a new way of working, a new approach to software development. Your project may benefit from such a change, especially if a skilled and already successful team will take it over and apply their best delivery process.

3. Communication:

  • Ask all the questions that concern your team, the stakeholders, and yourself.
  • Be honest about your concerns and expectations. Without the full context, a potential partner won’t be able to prove their best or honestly admit someone else would be better for the job.
  • Tell your whole story – from an idea, through the development process and different partners or people responsible for software development, until the moment you decided you needed to change the existing setup.

4. The process:

  • Start with a technical audit – let the new company assess the code quality, documentation, tests, etc. so that they know whether and potentially how they are able to assist you.
  • Plan the transition, set the milestones, and share those with your potential partners.
  • Once you start, go step by step. Try not to overwhelm your new partner with numerous improvements, new features, or bug lists from the very beginning. Remember about the onboarding period and prioritize.
  • Be patient. Handover of the maintenance of an existing application doesn’t happen overnight. In order to be effective, the new team needs some time to get familiar with the codebase, as well as the documentation, specifics of the project, past problems, etc. Treat it as an investment in the future success and uninterrupted maintenance or further product development.
  • It’s essential that you become the owner/admin of the product on AWS Production, AWS Dev, Apple App Store, Google Play Store, etc. in case it has been handled by the external provider. First of all, it will make the application takeover by the new company easier and faster. But also, it’s an important security aspect you should have in mind.
  • Prepare for the worst-case scenario, in which the previous software house isn’t willing to cooperate with you and your new tech partner. They may make the handover much more complicated by hindering the transfer of code, documentation, or accesses; or by doing it incompletely.

5. The budget:

  • Be prepared for higher costs for approximately one or two months, when you still have to cooperate with the previous company, and already start working with the new one in order to keep the app accessible and functional.
  • Last but not least, negotiate the rates with the new company to begin the cooperation with lower rates for the first 1-3 months.

The list is long, but we’re sure that you have already covered some of the points. In case something doesn’t seem right with the new company and it falls under one of the categories mentioned above, you should probably reconsider, or at least double-check that.

Partnership manager’s perspective

The business aspect of a project is naturally important to the client, and that’s why we have partnership managers or business development representatives on the other side. They take care of the business side of things and play a key role in a transition process, especially at the beginning.

If you’re a business development or partnership manager, some of the things you can do to support your client in an application takeover process are to:

  • Carefully listen to the client’s expectations. Focus on understanding the pains and frustrations of the client, as well as the problem they are aiming to address.
  • Be supportive, but stay professional – don’t go into blaming their previous software provider or glorifying your company.
  • Be reasonable and honest, e.g. if you know that bug fixing is impossible during the handover, provide the client with a relevant explanation, and suggest a possible solution.
  • Build trust through transparency.
  • Give your potential client enough time to choose the company that will take over the project. Don’t push them into rushed decisions. After all, patience and empathy build the foundation for a lasting partnership.
  • Make yourself more available to your clients. Be ready to answer their questions.
  • Always think one step ahead. Anticipating client needs and being proactive makes clients feel like you’re really paying attention and are focused on their needs.
  • Think outside the box. Be creative, especially when addressing client needs and goals, e.g. suggest workshops to support your client in transferring their ideas into an actionable plan.
  • Be approachable and flexible. Your client should feel that their needs and goals are your top priority and that you’re willing to find the best solutions adjusted to their situation.
  • Ask the client about their plans. Some of them may be linked to unexpected requirements regarding the product, e.g. increased number of active users due to an ad campaign, or a special focus on delivering certain features because of a trade show they’re planning to attend.
  • Involve your client in planning the app takeover process. Ensure they don’t only feel taken care of, but also empowered.
  • Inform the client about potential risks associated with the handover. Make sure you’re both prepared for the worst-case scenario, e.g. temporary downtime during transition or difficulties in transferring the code, documentation, or access by the previous provider.
  • Stay vigilant and be proactive. If something seems not right or may require future attention in your opinion, bring it up to the client and suggest solutions.

If you’re a client, you should definitely expect that from your partnership manager. ;)

Planning to change your software development team?

When your project faces roadblocks, sub-optimal performance, or communication issues on the part of your tech partner, it’s time to change the software development provider. Our experienced team is successful not only in bringing projects to completion but also in handling the transition process. Let’s talk!

Similar articles