Handing Over the Project to Another Development Team

Being a software consulting company we build apps for our customers. Sometimes our engineers start a completely new project for the customer and build a new app from scratch. Engineers love these rare "greenfield" projects. But most of the time we take over a software project to work on some pre-existing app, a project with history.

For a seasoned software engineer working in a software consulting company, joining a new project is a routine event. After a software project takeover the project is not really new - there is some code, the app already has some features. So we read the code and study the app. Then we start working on the app improvements and new features requested by the project owner.

But why did the project owner decide to resort to a software project handover? What kind of relationship connects the project owner and the engineering team? And why sometimes this relationship falls apart?

The Team

An app is built by a team of software engineers. The engineers may be employees of the company (in-house engineers) or freelance engineers working as independent contractors. Often the company outsources their application development to a consulting company. It is not unusual to have a mixed team with most engineers working remotely.

The team and the customer develop the app together. They discuss and share new ideas, they understand and support each other. The customer gets inspiration and critical feedback from the engineers. Over time the mutual trust is built. The customer relies on the team's technical expertise and the engineers trust the customer's business and domain expertise. Both the team and the customer gain more knowledge about the app, its features and its users. The collaborations become more and more productive.

Over the course of the project the team acquires a lot of knowledge of the inner workings of the app - how exactly the code works, why the technology is used in this particular way, which technical solutions work and which do not. Also the engineers become more experienced with the business domain - the service provided by the company, the industry, the requirements and expectations of the users. Meanwhile the project owner becomes more familiar with the capabilities of the engineers and the technology.

Replacing Engineers in the Team

Team composition naturally changes with time. A software engineer joins the project, works on the app for a year or two, and then moves on to work on some other app. Normally there is plenty of time for the new engineer to learn the app, get up to speed, become productive and make a significant contribution to the project. So the overall project knowledge and collective team experience is preserved.

But sometimes a radical change happens - the owner replaces their team entirely and hands over the project to a new team. Why do the project owners go for a software project handover? After all, the old team knows the app and the code, while the new team will have to spend significant time and effort to learn it to become productive. So the decision cannot be taken lightly.

Why Switching Teams?

Naturally the project owner prefers to keep their relationship with the team. But what if it is no longer possible? What potential challenges or obstacles might arise?

When we take over the project after the old team, naturally we are curious what happened. So we ask the customer to tell their story. While every story is unique, there are some patterns which repeat again and again.

Lack of Funds

Once upon a time there was a business person with an idea for an app and some budget. They found an engineering team and started building the app happily. In a year the funds become depleted, while the app is not ready yet, so it cannot earn the company any income. The project is put on hold while the owner desperately tries to find more money.

In a few months they find an investor and get some extra funds for development. This overall unpleasant experience makes the business person more careful, so before restarting development they reconsider their approach to the project and to the team. They got a word of advice from their investor to consider other options before restarting development.

Often while the project was on hold, the engineers from the old team moved to other projects and are no longer available. So restarting work on the app with the old team is not an option.

Lack of Progress

The owner outsources their project to a very affordable remote team. The owner sends the app requirements to the engineers and the team starts working. Over the first few weeks the team makes good progress. The owner gets regular reports with screenshots. Everything seems to be on track. So the project owner focuses on the other parts of their business. They keep checking the reports, but do not pay much attention to them, as everything seems to be under control.

After several months of development and a hefty amount spent, the owner gets the demo build of their app for the first time. What a disappointment! The app barely works. Many of the features reported by the team as completed are missing. Several parts of the app were clearly misunderstood by the engineers so they wasted time implementing totally unnecessary features.

While the owner has funds available to continue development, they decide to cut the spending for now and put the app development on hold, as they do not trust the team's ability anymore. They need time to reconsider their approach to the project.

The App Is Almost Done

Over the course of the project new features are added to the app. The owner checks updated builds of the app regularly and is happy with the progress. Eventually most of the planned features are completed. But there are a few critical features still missing.

Every next feature takes more time to complete. Sometimes newly added features break the old ones and the team spends weeks having those issues ironed out. The app is "almost done" but not released yet. When the planned app release gets rescheduled for the third time the owner loses their patience.

Many projects come to the notorious "90% ready" state. And, as the saying goes, the remaining 10% are going to take another 90% of time and money. Among other possible remedies, switching teams may help - provided that a new team is more qualified to finally push the app to production.

Third Party Audit

The project owner, being somewhat uneasy with the project, finds out about consulting companies offering code audit service. The owner gives it a go and an independent third party confirms their deepest fears. The app is not nearly 90% done, and the existing codebase is barely useful compared to starting from scratch.

The owner becomes naturally aversive to keep working their old team, as they deem them responsible, at least in part, for the unfortunate outcome - a year of development effort mostly wasted. They decide to find a new team of software developers and hand over the project to them.

Starting Work With a New Team

While the first phase of the project is now considered a failure, it is a valuable experience. The project owner is not going to repeat their mistakes. So they decide to find a better, more qualified engineering team and then apply much more strict control over app development. They know better now. They have a resolve.

This is where we usually meet the project owner and learn about the project and the app. How should the project move along?

When a project owner with an "almost ready" app comes to our software consulting company, there is going to be several discussions before we can start working on the app. An analysis and even soul-searching for the project owner is needed, to understand what went wrong and what were the causes of failure. We need to ensure that those causes are properly addressed, and they cannot harm the project anymore.

Enable Communication Between the Teams

For the software engineers joining the project the most natural way to learn about the app and the code is to talk to the engineers who built the system from the beginning. When the new engineers can communicate directly with the old team, it speeds up the new team's adaptation process.

If the old engineers are available it will make sense to arrange a call, so the new engineers can ask questions and learn about the details of the code. However, as existing partnerships are often abruptly dissolved, this situation is rarely possible and the burden of introducing the new team to the project rests on the shoulders of the project owner.

Provide Access to the Application Code

To work on the app, the engineers need access to the app source code. Normally the code is stored in a repository (like GitHub) under the project owner name, so the project owner has control over the codebase. But sometimes the project owner discovers that they do not have access to their own code and the repository is under control of the old team. It may require some extra persuasion by the project owner for the old team to finally give the code to the owner.

Also, it would be reasonable for the project owner to revoke access permissions to the code repository and the production server for the old engineers.

Get Access to Third-Party Services

Any modern software system uses several third-party services (API) - hosting providers, payment gateways, analytics platforms, etc. The current project team may have subscribed to third-party services on your behalf. When handing over a project to another company, the project owner should make sure they have access to third-party services used by their application.

Request a Code Audit

If the code audit wasn’t completed at an earlier stage, now is the time to do a full code review to assess the usability of the current code and identify potential problems. The review may reveal a number of issues such as significant technical debt, multiple bugs, security vulnerabilities, etc.

Based on the state of the code, the new development team should propose a suitable modernization strategy that will improve the product. The team may rely on code audit results to estimate how much work the project will require and create a list of critical issues to be addressed immediately.

Collect Available Project Documentation

Any project owner would be happy to have clear and concise app documentation to help a new team get up to speed quickly and understand how to work with the software. But the reality is that when a partnership ends, often the project owner is left with no documentation at all.

Still, you may try to contact the old team and ask them for technical specifications, design documents, user manuals and any other necessary documentation that will be useful to the new development team.

Reconsider Chosen Technology

When work on an app is resumed after a period of inactivity, the project owner often contemplates the technology choices initially made. Some recently appeared popular technology may seem attractive to be used for the app.

Should the change of the team mean the change of the app technology? Probably not. At least not immediately. The existing working app code has value and reimplementing it in a different technology would be wasteful.

If the app is running in production the new team must be able to support it and grow it gradually while preserving the features being used by the app users. After all the app users would be looking for improvements with every new release, they will not be happy if the app is missing features due to being rewritten with different technology.

Plan the Next Release

The to-do list is to be agreed between the team and the owner. If the app is not launched yet, the launch becomes the team goal and the related technical tasks assigned top-priority. All the features and improvements requested by the project owner are scheduled for the subsequent releases.

Software Project Takeover Checklist

Handing your project to another team is a lengthy and involved process. To help you not to become overwhelmed and have the smooth transition, you may use our software project takeover checklist:

• Enable communication between the old and the new teams to ensure a smooth transition and minimize knowledge gaps.
• Grant the new team access to the app code repository, so they can start working on your app.
• Revoke access permissions to the code repository and the production server for the old engineers.
• Write a list of all third-party services integrated into the app and check that you have access to all of them.
• Perform a code audit to identify potential issues, bugs or areas for improvement.
• Give the new team all available documentation.
• Discuss with the team and decide whether it is necessary to make significant changes to the technology stack.
• Plan the next release with the new development team

The Bottom Line

A successful software project handover is crucial for the future of the app. The goal of the project is to build an app to support the business by addressing the needs of the users. So what would be considered a successful software project handover? As soon as the new team delivers a new working release of the app and the users are happy with it, the transition can be considered a success.