What’s a project handover, and when does it usually happen?

Project handover is a procedure of acquiring a project that was previously developed and discontinued by some other team or project manager. The term “takeover” is also used in this context quite a lot and the main difference is that it’s a little more aggressive. It’s widely considered one of the biggest challenges for a software development agency, but it’s an even more complex issue from the client’s perspective. The level of difficulty is highly dependent on the circumstances. The main question is, why did the previous agency stop working on the project?

The most common answers to that question are:

  • The team was repeatedly missing the deadlines
  • The team had insufficient resources or not enough skills to complete necessary tasks
  • There was a consistent lack of understanding of the project’s goals and purposes on the agency’s side
  • Multiple developers who worked on the project left the agency
  • Insufficient communication and culture-related issues

All of the issues mentioned above put the whole project at risk, and very often, the only way to save it is to find a new agency. It’s essential to identify the cause (or causes) precisely. In order to avoid any of those issues in the future, the search for a new software house must be based on a strict set of requirements in terms of communication, expertise, and experience. To put it simply, you should be able to address your core issues, so the new agency can assure you they’re capable of taking care of them.

It’s just another new project, only a little messier

The very reasons and circumstances of any project takeover always bring a particular emotional factor. Stakes are high, the project’s timeline is usually far from its initially approximated schedule, and, more often than not, there’s a lot of spaghetti code to deal with. Still, the project handover process is pretty similar to any regular project. A good software agency won’t rush to conclusions and ultimate technological solutions without meeting the client and asking a series of fundamental questions to understand the project. We’re talking about the absolute fundamentals, such as:

  • What’s the goal of the project?
  • What problems does it solve?
  • Who is it for?
  • What is its key value?
  • What potential risks are currently identified?
  • And more

If the cooperation with the previous agency didn’t work out, a little step-back and reevaluation of the project’s principles might be exactly what we need. Maybe some of those questions weren’t answered thoroughly enough? Maybe some weren’t considered at all?

For instance, a common issue for non-enterprise cheminformatics projects is commercialization. While software often has technological potential, it lacks marketability. The process is designed to identify those weak points and turn them around in the future. Moreover, this phase allows both the client and the agency to clarify two critical facts that determine everything that comes after:

1. Is the project still doable in this form/in this budget?

A good software house doesn’t do suicide missions. The process of project handover must start with forming a rock-solid idea that’s actually possible. It may turn out that the amount of spaghetti code to fix is significant enough to burn all the remaining budget. In this case, we might have to switch the strategy to build a new MVP from scratch instead of fixing existing software or just drastically limiting the number of features in the current version.

2. Is this the right team for the project?

Industry experience, technological knowledge, size of the team - all those factors matter. Same as above, a good agency should be able to determine that they have enough resources and assure you they’re the right team for the job, so if you have any doubt, consider looking for someone else.

In order to get the most detailed intel about the project, we like to use the “five whys” technique. For example, we could start with a basic premise such as “the product is valuable for lab workers.” And to that, we ask “why?”. Then, after it’s answered, we ask the same question again. It goes like this:

“The product is valuable for lab workers”
Why?
“It makes their everyday work much easier”
Why?
“It saves them time”
Why?
“They can do X, Z, and Y much faster and more efficiently”
Why?
“Because they’re able to automate processes, which previously had to be done manually. Their only job is to fill the data into our app and the rest is fully automated.”

During the process, we’re gradually getting to the root of every given issue, and we’re able to understand the client’s perspective on the whole project and what the problem was before. Of course, it doesn’t always take 5 whys. It all depends on how complex the issue is and how deeply we need to dive to fully understand it.

What exactly went wrong so far, according to both sides of the project?

It’s necessary to establish what exactly went wrong so far. Why was the project discontinued by the other company, and how do we avoid those mistakes and build stable software on legacy code. Of course, talking about past errors is never an easy subject, but project takeover works the best when it’s built on trust. The more the new agency knows about the project history, the better for the future. That’s why we always ask if there’s a chance to talk to the previous dev team. Knowing the perspective of both sides helps identify the very reason for any misunderstanding and helps eliminate any potential of repeating those mistakes.

Starting over the right way

We’re almost there, just a bit more preparation. Once we’ve established the fundamentals and key reasons we ended up in this situation, we can move to the technical phase. Two of the most significant steps of the process are verifying the scope and comparing estimations (new and the initial one).

Another critical step is gathering all necessary documentation and preparing anything that’s missing. A widely unknown rule in the industry is, you can identify a good software development agency by how diligently it approaches documentation, so make sure everything is top-notch.

The list may include documents such as:

  • Technical Documentation
  • PRD (Product Requirements Document)
  • Acceptance criteria
  • Deliverable-specific documentation
  • Requirements regarding security, data management, etc.
  • Outstanding issues
  • Version control or configuration management records (nice to have)

We also prepare a risk registry, which is especially crucial for any development with legacy code. It’s a list of technological, business, financial, and HR risks, their potential causations, and consequences. Of course, it also includes methods and tools to manage and avoid them. Risk registry is an absolute must-have if the client or previous agency didn’t have such a document.

Project handovers are Scrum-friendly

With the detailed documentation and established goals, it’s possible to outline the process. Precise requirements ensure smooth delivery, but it’s Scrum that makes the week-to-week work efficient thanks to the easy communication between the team and all stakeholders. The value of transparency and the ability to see and influence the project on a daily basis is invaluable for projects that involve working with legacy code. Therefore, when looking for an agency to take over a project, we highly recommend choosing one that’s working in Scrum by default. You can read more about how Scrum saves businesses in my article here.

Painless project handover is possible

Of course, possible doesn’t mean easy, but as a team with a decent track record of recovered software projects, we can assure you that with a correct approach, it can be a quite manageable mission. In fact, most of the projects in our portfolio were partially or (more often) entirely project handovers or team augmentations, so we’re very familiar with the ins and outs of the matter.

If you have a project in an emergency, let us know about it, and we’ll do our best to save it!