Handing Over the Project to Another 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 join a project to work on some pre-existing app, a project with history.

For a seasoned software engineer, especially working in a software consulting company, joining a new project is a routine event. The "new" 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 handover their app development to another team? 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 there may be freelance engineers working as independent contractors. Often the company outsources their application development project to a software consulting company, so the engineers in the team are employees or contractors of the 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. If a software engineer works on the same app for years it dulls their skills and takes all the fun and excitement out of work. So to keep the productivity up some rotation of staff is necessary. 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 change teams? 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 could possibly go wrong?

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. And 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.

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.

Transfering the Application Code

To work on the app the software 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.

As soon as we get access to the source code, we do a thorough code review. The review provides key information about the internal health of the app, what fixes and improvements must be done immediately, so the app development can be resumed safely and efficiently.

If some of 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. Later at some point in time it would be reasonable for the project owner to revoke access permissions to the code repository and to the production server for the old engineers.

What About 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.

Planning the Next Release

The to-do list is 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.

The Bottom Line

Was it the right decision to switch teams? What would be considered a successful project handover?

Overall, the goal of the project is to build an app to support the service and the business, to release a great app and then to keep improving it, addressing the needs of the users. The moment of truth is the first release of the app by the new team. Then the transition can be considered a success.