What are the Steps to Rescuing a Troubled Project?

 In Software Development

As I mentioned in the Top 7 Warning Signs that your Project is Headed for Trouble, software development projects have a higher rate of failure than necessary. Lack of project management, poor communications, loosely-defined goals, budget overruns, and more have kept many great ideas and concepts from ever seeing the light of day.

The most common complaints we have seen from our Rescue & Recovery projects have surrounded poor integration, disappointing performance, and overly optimistic developers. From our perspective, software development failure is most often due to a lack of a proper solution design from the onset, which causes a constant string of iterating and attempts to retrofit a poor design. By the time the stakeholder is ready to abort the project or change to another software developer, they are frustrated and unsure as to the efficacy of the original idea.

We have also experienced rescue and recovery projects from companies that have used offshore developers that made promises and assurances that they could not keep, leaving the stakeholder with a partially developed application.

construction-project-failure

Similar to a contractor that is called in to salvage a home construction disaster, our developers are called in to fix software that has never been finished or has never worked properly. At some point along the way, stakeholders start to question the process and the experience, such as:

  • Can the latest source code be fixed to deliver the original software goals?
  • Should I spend more on a project that has already surpassed the budget and timeframe? Is it money down the drain?
  • Should I scrap the project and start over?

Those are all logical questions. When we work on a rescue, recovery, and support project, we first check to see the current stage of the application. For example, is the project…

  • Partially complete (due to mid-project failure)
  • Nearly complete (where the project is struggling to get to the finish line)
  • Ready for take-over support (where the effectiveness of the project requires improvement)

project-planning-team

If the project is in the early stages and continues to have technical issues…

Oftentimes it’s best to stop and just start over. We recommend an evaluation of the foundational architecture to see if this needs to be corrected or if it is more cost-effective and time-efficient to start the project from scratch. Although this may sound costly, it is actually less expensive than trying to resolve the issues of a project that has barely taken shape.

If the project is near the finish line or more…

If you’re near the end of your project but you can’t get that last 10% done, or the project has already gone live and your vendor is not responsive, or are at a late-stage or in post-production, you may just need some extra support to get it to the finish line.

software-support

What is the next step for all levels of rescue, recovery, and support projects?

What we have learned in the 20+ years of countless rescue situations is the importance of a proper transition between the original developer and the new software developer regardless of what stage the project has been left. A transition to a new vendor is not just a matter of digitally or manually handing over the source code. It is so much more than that, so always maintain a good relationship with the developer you are leaving behind, as information may be needed before, during, and after the transition.

haning-over-house

Transition Requirements

These are the necessary steps that will help ensure that the project will get back on track with the new developer without hitches or additional technical issues. The ultimate goal of the transition phase is to identify and rectify any common issues that would negatively impact the work that needs to be accomplished to successfully complete the application. It generally takes around four-to-seven business days but will vary depending on the project.

This is the Transition Checklist that our team uses when taking over a software project.

  1. Make sure to obtain the most current source code from the current developer.
  2. Run through a complete review of the application and the source code, note issues and errors.
  3. Conduct a test deployment to a different server to determine if there are source code issues.
  4. If there are any dependency issues from the old server they will need to be resolved or removed.
  5. After the source code is moved to the new server, the client will need to verify that the application looks the same as it did prior to the move.
  6. At the same time, it is important to verify that there are the same run time errors and not new ones.

checking-all-the-boxes

After the Transition Phase, these are the common steps that would follow:

  • Development that is focused on knocking out a punch-list of identified bugs or enhancements that have not been addressed
  • Conduct a deeper technical assessment of the existing code/application to see if it is a solid foundation upon which to invest a more significant development budget going forward
  • Design work for new enhancements and features that haven’t yet been designed
  • Development and implement new enhancements and features needed.
  • Document the application to ensure future developers can support the application if there is minimal development work to perform at the present time
  • Complete and test the application

success-project-completed

Above all, do not get overly frustrated or give up as that is one of the underlying reasons software applications fail. In most cases, the problems and issues can be resolved but have a much better chance of succeeding if the transition phase is correctly implemented.

To learn more about the full software development process and what to expect, download our eBook, Anatomy of a Software Development Timeline.

ebook-anatomy-timeline-wide

Recent Posts