Hiring a New Software Company

As a professional software developer, one of the most challenging tasks is the inheritance of an existing product. Whether the product is still in development or has already entered its support life-cycle, there are many pain points and possibilities for confusion and delays. However, there are several things a product owner can do to help ease the transition and make sure the new development team has a strong chance of success. If you're planning to say "Game Over" to your current team or are already moving on, read on for some advice on how to prevent some of the biggest hurdles associated with development of an existing product from interfering with the successful completion or continued support of your project.

Hosting Access

As the software industry continually becomes more web- and cloud-centric, almost every modern software project has some form of web hosting. Nothing will kill a project faster than developers not being able to push out new code, and lack of credentials for hosting accounts is a common roadblock to deployment. In order to support future deployments and troubleshooting, it is critical that your new development team receives access to hosting accounts as early as possible.

To help ensure project continuity, make sure you have all the necessary credentials to provide access to your current hosting platform. Depending on your provider, you may be able to grant specific people limited access to your hosting account. If that’s the case, work with your new team to get them the access they need as early as possible. If not, it may be necessary to provide the credentials you regularly use to them. In this case, work with them to transfer that information safely and securely. Never send this information (or any sensitive information) via email or text message.

Third Party Integration Keys

Similar to web hosting, most modern applications use some form of third-party integration. A common example is an email service like SendGrid or MailChimp. Typically, these third party services use an API Key to allow access to their services. Your application, and the teams developing and supporting it, must have access to these keys. As with hosting access, it is important that this information is provided as early as possible in the transition, via a secure channel.

Current Source Code

One of the most painful causes of delays when switching project teams is the sudden realization that the code deployed and in use by your system is more recent than the codebase you can access and share. This can happen when developers fail to escrow code appropriately. The best guard against this is to insist upon your existing development team has a secure, redundant source code repository and that they commit their code to it regularly. At a minimum, every time a new version is released, the code should be in a repository available to you. Implementing this practice ensures that the code you provide to your new team will be up-to-date and that your application will not suffer regression caused by reintroducing old code.

Requirements Documents and Product Manuals

While written requirements and product manuals hardly make for scintillating reading, they are an important source of valuable information for your new development team. During the transition, one of the largest time expenditures is having the new team review the project to answer three important questions – What does the product do? How does it do it? Why did they (the original developers) do it this way? Providing existing documentation makes answering those questions easier and faster for the new development team, reducing the transition cost significantly.

Existing Project Plans

Similar to requirements documents, existing project plans can provide valuable insight into where the project is headed. In addition to helping the development team understand the functionality of the product, project plans also provide a wonderful basis for identifying and updating expectations. If, for example, the original project plan identified a release date one week after the transition begins, there’s a good chance that this milestone will need to shift, as the early stages of a transition are typically focused on knowledge transfer and rarely produce new code. By evaluating upcoming milestones and release plans, the new team can identify priority components in order to minimize the transition’s impact on the original milestones.

Transitioning development teams when a project is already in progress can be very challenging. By implementing the suggestions above, you can reduce frustration, downtime, and the impact on your customers so that you can quickly return to business as usual.

Did you find this useful? Pass it on!