It’s true: Software projects often fizzle out or just plain fail. In fact, research has shown 55% of IT professionals claimed a failed project in the past year—usually due to a lack of engagement, poor planning, budget issues, scope creep, and developer or agency abandonment.

With every doomed project, however, there comes a time when you have to stop burning money, face reality, and move on to a new team.

When clients turn to 27Global to rescue projects that just weren’t working with their original development team, we first ask the question nobody likes to hear: Are you sure the problem lies with the project, or is it a problem with your team? Once we’ve established our client understands the problem, we then focus on three critical areas: the contract, asset separation, and handoff planning.

Contractual concerns

As your project rescue team, our first consideration is contractual. Specifically, have you addressed the fine print – such as termination fees – in your contract with your current team? Consider this the starting point for the separation journey. For more complex or high-dollar contracts, consider engaging legal assistance in the pre-planning stage. No one wants to be beat up by a contract they signed, especially one they failed to read or understand.

Asset separation

It’s common for a company to commingle private resources such as the in-house Jenkins service in the CI/CD pipeline and ownership of the hosting and cloud services account or the domain. Even though nobody launches a project intending it to fail, it’s better to be clear from the beginning how you’ll divide the assets if the project does go south. The last thing you want is for your previous team to retain ownership of your project’s linchpin asset when you walk away.  

The key to managing asset allocation is a written understanding of every service and tool required to take code from any developer’s local workstation to production. Most projects have flow charts, entity diagrams, architectural references, and master documents on the construction of your app. There’s no way for a team to operate without this type of planning, accountability, and insight. A good consultant or project manager will seek out the identification, tracking, and ultimate accountability necessary for a project move and share it with the new team immediately.

Handoff planning

Formulating a handoff plan in advance is also critical. Your plan’s immediate high-level goals should include minimizing downtime, restoration of development (the ability to commit code and release), and protecting your financial investment. It’s also important to maintain realistic expectations regarding the timeline, cost, and difficulty.

For a greenfield, or “yet to go live” project, migration is easy. Without any active users to fill up the support queue, you can tolerate losing a day or two while moving the project. By contrast, brownfield projects are more complicated. In this situation, the application is probably running and is critical for business. You may also have to consider the app’s user base. Minimizing disruption in the short term and guaranteeing stability over the long term must be front and center for every decision.

The transition to another team has three distinct flavors: pack it up, semi-acrimonious, and kind and gentle.

• Quietly pack it up and bail happens often when business entities can’t or don’t want to reconcile. No matter how much disdain the current dev team conjures up, try to engineer an overlap, where the next dev team is embedded with the client to help manage the transition. During the overlap, find ways to allow the new developers to ask questions. A few “good to know” data points can spare the new team days of work reverse engineering. Before you pull the plug, make sure you can handle the consequences; the lifeline to the old team will vanish quickly.
• Semi-acrimonious parting is when two businesses decide to go their separate ways, agreeing on terms and then finding an equitable and minimally painful handoff. As the incoming team, it’s our job to keep communications with the outgoing team open and friendly, getting answers from the old team to reduce the unknowns and liability that comes with a project in progress. If the relationship has devolved to the point where product owners are arguing, brace yourself for added expense, increased stress, and a slower separation.
• An amicable departure is ideal and occurs when the old dev team recognizes its departure is just as important as the initial project onboarding. With the new dev team in place, product owners can help route questions and manage the transition. Communication should flow freely between the old and new development companies. We can’t stress enough how a few 10-minute conversations with the former developers can help set you up for project success.

Regardless of how you transition from one dev team to another, there are a few important must-haves to save money and maximize success.

• Have your next team assembled, reviewing code, asking questions and advising the transition as early as possible.
• Keep realistic expectations, guided by the new dev team, for how long it will take to make the initial move as well as reaching parity with the previous dev team.
• Aim to get all of the environment replicated before disengaging from the outgoing dev team.
• Audit all services used and transfer ownership (including payment) at the correct time. Certain services are more time-sensitive than others.
• Assess the impact on the stakeholder company, customers and employees from the very beginning. 

A final note about lawyers

By all means, try to avoid getting attorneys involved until you’re up and running. Assertions of liability or even the mere threat of legal action will slow your transition to a crawl. First, free your code and get your app running, and let the lawyers duke it out while you’re continuing with development.

The 27Global game-changer

How is 27Global different? We adhere to the best possible pattern for asset control on projects. Unless there’s a support contract to the contrary, our customers own all the assets. Along with other anti-commingling practices, you pay for the code, we use your repository, and we build on your hosting provider. We set it up, run it, and write the code. In the event of a failed project, our clients can walk away without wasting time exfiltrating and transferring assets.

Whether we’re rescuing a project or starting it from scratch, when it comes to helping you maintain a competitive advantage, our clients always come first.

Marc Weinberg is a consultant in 27Global’s Denver office. Founded in 2008, 27Global is an AWS certified partner that designs, builds and operates custom software solutions for businesses of all sizes. The perfect pairing of a local leadership with offshore pricing, 27Global has the business acumen to understand your vision and the expertise to build your software solution. To learn more, visit 27Global.com, or connect with us on LinkedIn and Twitter.