Software project rescue: How to save a project that has gone sour
'All happy families are alike; each unhappy family is unhappy in its own way.' I doubt Leo Tolstoy could ever imagine that this harsh truth from ‘Anna Karenina’ could once be applied to software development but that’s how it goes: over a half of IT projects fail. The reasons behind those failures vary tremendously, starting with the fact that the person in charge decided to go with the cheapest vendor without considering the match between the solution and his needs and up to undefined KPIs and lack of understanding of what kind of implications can be considered a success.
No matter what caused you to fail and whether you are the one to blame or not, chances are high that, if you are reading this post, you need to fix it, preferably yesterday. Because you are still in charge of the outcome. You need to report to your management. You need to make your customer happy again. You need to launch the new piece of software immediately since you have already spent all of your investments. You need to bring peace of mind to your investors. The list goes on and on, right?
I have good news: it really boils down to what you achieve in the end, not the hurdles you face in the middle. While there is life, there is hope, and there are ways out of almost any dire situation. It is indeed painful to face that something did not go the way you have expected; however, keep in mind that the company or the freelancer that has failed to deliver is not the only one in the world.
Let us have a look at a bunch of the most typical situations I have seen in my professional life and how you can potentially fix them:
1) ‘The vendor/ freelancer I worked with has delivered a piece of software that does not work at all’.
This is one of the toughest cases. Imagine someone sewed a dress for you, and this someone screwed up completely: the garment is poorly shaped, the textile is not suitable for a dress like this at all, and the stitches are so terrible they have basically ruined the fabric. It might be possible to fix it; however, it’s like patching the Frankenstein: no matter what you do, you won’t make it look like a real human being.
The best way is actually to have a look at the code in the first place to see how bad it is. When it’s too bad, you might want to dump the whole thing and start all over instead of fixing the odd pieces of clothes and trying to make them look like a fashionable item. On the other hand, if the code is not terrible and it’s OK to go on with it, the best way forward is to carry out 1-2 rounds of functional testing and see what specific problems need to be fixed. The fixes are to be followed by at least one round of defect validation (to verify that the fixes are actually done properly) and regression testing (to ensure that the fixes have not affected other parts of the functionality).
2) ‘The previous developer has dropped the project halfway, and I need to finish it as quickly as I can’.
Regardless of how and why exactly it happened and whether it was an in-house programmer or a freelancer (or maybe even a stable outsourced development company), I know one thing for sure – you are frustrated. You expected that the whole thing would be in place by now, and you end up with a piece of coding that needs more of tedious work. And if there are investors chasing you on having the product up and running, you do want to solve it as quickly as possible.
The worst part is – the code might still be so awful that you will have to start everything all over. Again, the best way out of this situation is to have a look at the code in the first place. If it is at least OK to work around it, you have two options about the next step:
- Make a gap analysis (what you have now vs. what you need to have) and get an estimation on how much it will take to complete the product up to your specification
- Start working with a dedicated developer/ a team of developers for them to complete it.
I would personally be tempted to go ahead with Option 1, since it might give you a sense of predictability with the deadline and the costs. The harsh truth is, it’s highly likely that the real costs and the time line turn out to be higher than whatever is being promised to you. In real life, if timing is your main consideration, the best option is to go ahead with a dedicated person or a group of people that have expertise in the technology stack used in your product. The thing is, whoever is going to rescue your product, they will spend a bunch of time reviewing the code, defining the gap between what has actually been introduced and what hasn’t. Trust me, if the previous developer didn’t care about adding up comments to the code to make the maintenance easier for other people, this gap analysis is where the new team sends dozens of curses his way). If they need to prepare an estimation for you, it might take a couple of weeks just for the pre-sales stage! Yet, if you do want to work with a reputable company who cares about their performance and reviews (not a needy one that picks any project just to be able to make their payroll), it’s highly unlikely they will be able to give you a fixed-price and fixed-duration contract and actually commit to it. Maintaining legacy code is similar to maintaining ‘Pride and Prejudice’: you might want to remove a mention of a tree somewhere in the novel, and then it turns out that Mr. Darcy dies in the middle of the plot simply because we have eliminated the very tree he was supposed to lean against! (No happy end it is!) Even if they do give you a fixed-price proposal, there’s still a risk of running into troubles further down the road, which means that the development company might be cutting corners to fit into the budget they are committed to.
With that in mind, allocating people with relevant experience and skill set is the quickest and, hence, a safer way out of situations like this. They will still have to dive into the code, understand how it works, get up to speed on the functionality you aspire for, etc. The good news is, they will be working on your project for quite a while, which brings you the value of having a permanent team: knowledge retention, personal relationship, more commitment to exceeding your expectations. The list goes on.
3) ‘The developer I work with is OK, but I strongly doubt that they will somehow deliver anything by the deadline’.
My first questions are, have you discussed it with the team you have hired? Are they aware of the deadline? Have they actually confirmed that they are ready to deliver within that period? What are the implications for them if they do not manage to deliver on time? Have they had any hurdles during the development at all? If yes, did they warn you about those as quickly as possible? Basically, tons of questions, but the main one is ‘What have you done to fix the problem without looking elsewhere?’ If you have been working with a person for a while, know their strengths and weaknesses and have seen their ups and downs, you don’t start looking for a replacement the moment this person stops performing as brilliantly as s/he used to, right? The first thing you do is try to fix the situation with the incumbent hire. It works pretty much the same with an outsourced development team: if there is anything you can do to get your peace of mind and get their commitment on time, do it!
If you have tried everything in your power to get things back on track and it’s still not working, well, you need to find a suitable team to back your efforts up. Again, the best way to move forward is to have a couple of interviews with suitable profiles and see who of them have the best combination of coding skills, experience and soft skills. Once you find your ‘dream team’, they can actually start working in parallel with the incumbent one. I would actually recommend doing your best to organize an in-person meeting for the teams working simultaneously, regardless of whether your time lines are tough or not. You do not get delivery from companies, vendors or whatsoever. You get delivery from real people with whom you can break the bread.
As you may guess, those recommendations are the most generic ones you can ever get. The reality might be completely different from the ‘most typical scenarios’, so feel free to reach out to me if you need help getting you software development project rescued. Feel free to leave a comment telling about the dire situations you had to get a free-of-charge piece of consulting.