How to Rescue a Derailed Software Project
Sometimes things just don’t go to plan. Any project can break down, but in the world of software development, there is often a layer of complexity that can make it particularly difficult to get a derailed plan back on track. So what causes a typical project breakdown – and how do you take control of a software project that’s hit a brick wall?
Reasons why a software project fails
There are many reasons why you may find yourself with a stalled or broken down software development project, but regardless of what caused the situation you’re likely to be dealing with at least one of the typical project problems listed below.
Which of these issues do you recognise?
- There’s a conflict
Efficient collaboration is a tricky thing to master, but if there are conflicts and tensions brewing under the surface it’s often impossible. There could be historic disagreements from previous projects – or perhaps the people involved simply have very differing views on how the team should operate. If the project is falling behind schedule or perhaps suffering from quality issues it’s easy to start blaming and criticising, which of course leads to further rifts in the team. This is often a sure-fire way to kill any chance of project success. - The development partner has disappeared
Another scenario which is surprisingly common in failed software projects is to do with the key developer leaving. Perhaps your external development partner has gone out of business, your main consultant has decided to exit the project, or your in-house lead programmer has resigned. Either way, you’re left with an unfinished product and nobody around to pick it up. - The software just isn’t good enough
Quality issues are a very common reason why software projects fail – especially those that depend on offshore development teams. Regardless of whether the product is poorly designed or simply has not been completely finished, many low-cost, fast-delivery promises often turn into an end result that doesn’t quite live up to the expectation. - The source code is lost or outdated
Even in this era of automated backups there are situations where original software code is lost or destroyed. This can be down to hardware failure, theft or simple negligence. In other cases, the original code may have been created using poor or outdated programming languages, which would need to be swapped out.
These situations typically occur when a software project has been running for a long time or perhaps been put on hold. Blowing the dust off an old project and restarting it can be almost as challenging as starting from a blank sheet.
Of course, however tempting it may be to identify someone to point a finger of blame at, it’s more important to move forward with the best interest of the business in mind. How critical is it to rescue the project? What can be done? And what will it cost?
Approaches to software project rescue
Regardless of the reason behind the software project stalling, it is often very useful to have another company come in and take over the reins. With a fresh set of eyes it’s easier to evaluate the problems clearly.
There are four basic sets of activities that make up a typical software project rescue.
- Audit
The best starting point for any derailed project is to perform a health check on the existing source code. This entails checking the quality of the source code, making sure it “builds” (i.e. compiles), but it also means looking at the bigger picture around the code. What does the documentation look like? Is there are a database to consider? What does the current hosting and security look like? A thorough audit will also look at the age of the software platform used and how well the software has been kept up to date. The older it is, the harder it may be to update and maintain. - Dependency evaluation
The next important aspect of rescuing a project is understanding any dependencies within the source code. A previous developer may have set up solutions that make for complicated relationships. Dependency issues could include third-party libraries that require licensing, proprietary software that needs to be stripped out, or perhaps specific user agreements with previous developers that limits what can be done in the future. - Source code support
Any reputable software project rescue partner will of course have a support package in place for providing service on the existing source code. As a customer, you should always make sure you get an offer for a retained service with complete bug fixing, day-to-day support and repair covered by a service level agreement – to make sure the software doesn’t deteriorate again in the future. In cases where source code is lost or broken, a source code recovery project can bring back missing code from compiled executables or web servers, or rebuild broken source code repositories so that in-house teams can work on the system again. Modernisation can however look different for different organisations. In one case it may be necessary to rip out the old code and replace it with new, feature-rich technology – while in another business it can be as simple as tuning old databases to maximum performance - Maintenance
Once you’ve got a software project back on track, it is of course important to keep it maintained and updated with new technology. Over time you may need to add features and replace old systems, written in obsolete programming languages, with modern code that integrates better with the rest of the business.
When to rescue a software project
Of course, not all lost software projects are worth saving. Sometimes the business requirements change over the course of a project, making the software irrelevant or less useful. We often suggest looking at it from a wider commercial perspective, to understand how the business would benefit from a functioning end product.
If it’s worth doing, it’s worth fixing.
