How to res­cue your soft­ware ap­pli­ca­tion

One thing is cer­tain in soft­ware de­vel­op­ment, and that is that un­cer­tainty is part of the process. With this comes all man­ner of po­ten­tial ob­sta­cles, from bud­get blowouts to missed dead­lines. Today I will be ex­plor­ing what to do when your soft­ware pro­ject has taken a turn for the worse.

1. Re-assess

The first thing one must do when you have recog­nised that a pro­ject is­n’t go­ing to plan is to take a step back and try to look at the big­ger pic­ture of what has hap­pened. Often it is easy to just fo­cus on the tiny minu­tiae of what is hap­pen­ing in the now’ with­out look­ing out­side of our field of view.

a. Find the source

Find the core is­sue through open com­mu­nica­tive in­ves­ti­ga­tion. It is easy to play the blame game with a failed pro­ject, how­ever, it is more con­struc­tive to col­lab­o­rate and in­ves­ti­gate as a unit to find where the is­sues are and from there you can de­ter­mine your next steps.

b. Strategic di­rec­tion

You know what has gone wrong now, and why - next you need to build out your strat­egy for as­sur­ing the same mis­takes are not made again.

Failure is in­struc­tive. The per­son who re­ally thinks learns quite as much from his fail­ures as from his suc­cesses.”

- John Dewey

Adjust time­lines and bud­gets as needed, ac­knowl­edge the un­fore­seen cir­cum­stances that brought you to this point and fo­cus on what can be de­liv­ered in the next steps.

2. Resourcing

Often time­lines are blown out through lack of proper re­sourc­ing, if you don’t have the cor­rect skillsets or enough peo­ple to com­plete the pro­ject then ob­vi­ously it is doomed from day one.

a. Evaluate cur­rent team

Unpack the list of re­quire­ments found in your strate­gic di­rec­tion and ask the team if they would be com­fort­able be­ing ac­count­able for these re­quire­ments, if not, why not? It is im­por­tant that the team feels com­fort­able to share their hon­est opin­ions on these ques­tions.

Once you un­der­stand where your skills gaps are you can go about hir­ing or out­sourc­ing to fill them.

b. Do we have enough peo­ple?

If the team has the cor­rect skill set to ac­com­plish the goals, just not in the time­frame re­quired then the next step is hir­ing peo­ple in or­der to in­crease pro­ject ve­loc­ity.

3. Technical as­sess­ment

a. Evaluate the code­base

If your soft­ware pro­ject needs to be res­cued it is strongly rec­om­mended you take the time to eval­u­ate the code­base. During step 1, it is likely you have iden­ti­fied why the pro­ject has­n’t been suc­cess­ful. Regardless of whether it was a tech­ni­cal is­sue or not, it is a good op­por­tu­nity to eval­u­ate the ap­pli­ca­tions code­base. There are in­de­pen­dent con­sul­tan­cies that pro­vide this ser­vice. Alternatively, de­vel­op­ment com­pa­nies like WorkingMouse pro­vide this ser­vice dur­ing a scop­ing en­gage­ment.

b. Determine legacy im­pli­ca­tions

After eval­u­at­ing the code­base, a de­ci­sion must be made whether to carry on with it or whether to spend time re­build­ing the ap­pli­ca­tion. This will largely de­pend on the eval­u­a­tion step above.

c. Migrate

A mi­gra­tion may be nec­es­sary de­pend­ing on steps 3 (a) and (b). If that’s the case, we rec­om­mend find­ing a de­vel­op­ment agency that has a proven mi­gra­tion process. It can of­ten be the most chal­leng­ing part of a soft­ware pro­ject. We’ve cre­ated a guide on mi­grat­ing brown­fields (legacy) pro­jects which is avail­able for fur­ther read­ing.

4. Communicate

Open com­mu­ni­ca­tion is the key in un­der­stand­ing what has hap­pened and what you would like to hap­pen mov­ing for­wards in a pro­ject. When look­ing to res­cue a soft­ware pro­ject you must en­cour­age open com­mu­ni­ca­tion lines.

a. Set goals

Everyone has heard how im­por­tant goal set­ting is both in your pro­fes­sional and per­sonal life in or­der to get from where you are to where you want to be. The same is with soft­ware pro­jects, in or­der to achieve your de­sired out­come, first you must set clear goals to keep your­self and the team on track. If you’re out­sourc­ing to a soft­ware de­vel­op­ment com­pany, en­sure that clear goals and suc­cess cri­te­ria are in place. That will al­low you and the agency to re­view the suc­cess of the en­gage­ment once a build has been com­pleted.

Lack of clear di­rec­tion is listed as the lead­ing cause of pro­ject fail­ure by em­ploy­ees, above low bud­gets and em­ployee re­sis­tance.

5. Get crack­ing

So you’ve ex­plored why your pro­ject was fail­ing. Ideally these learn­ings will be fed back into the next build. If you’re us­ing an in­ter­nal team, you’ll need to iden­tify the po­ten­tial risks based on your ini­tial ex­pe­ri­ence. More com­monly, prod­uct own­ers will have a bad ex­pe­ri­ence with a de­vel­op­ment agency. It may have failed for any num­ber of rea­sons. This ex­pe­ri­ence gen­er­ally leaves you search­ing for other agen­cies in the mar­ket. When eval­u­at­ing a new de­vel­op­ment com­pany be sure to ask how the risks you’ve iden­ti­fied will be mit­i­gated. Do they have a Way of Working or some other form of qual­ity con­trol?

All that is left is to be­gin, this can feel in­cred­i­bly daunt­ing as you are set­ting in mo­tion for the first time af­ter a fail­ure. Validate the team where you can, re­move block­ers and don’t hes­i­tate to com­mu­ni­cate quickly when plans aren’t align­ing with the set goals.

Bonus Step: Enjoy the suc­cess of a com­pleted pro­ject!


Josh Beatty

Account de­vel­oper and hair gel hoarder

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

Your vi­sion,

our ex­pe­ri­ence

Book an analy­sis call