Checklist: How to Recover a Failing Project

Keeping a software project on track is something easier said than done. The mere act of bringing together a group of individuals with unique thoughts and opinions is bound to result in conflict and unforeseen problems. So is it really a surprise that a high percentage of projects eventually drift away from best-laid plans?

Don’t let yourself buckle under the pressure, let the checklist below help you guide your project back towards success.

Problem Acceptance

Knowing that you have a problem is not the same as accepting you have a problem. Without acceptance you don’t always get to see the full depth of an issue, and can start to rely on quick fixes that act like a plaster on a stab wound. Hold it together in the short term but come unstuck before the cut is closed.

The first step to successful project recovery is in both recognising and accepting that you have a problem so that you can get to the root of the issue.

  • Recognise and accept that your project is drifting

Do you know what you are trying to deliver?

Unless you really know and understand the scope of your project then you can’t say for sure that it actually needs saving. Write yourself a list of requirements, whether that be using a formal requirements management tool, agile user stories or just a list of features. Having a list gives you the means to measure the amount of the project actually completed. Ideally this list is then used to create a bunch of tests that prove you’ve met the needs of the project. After all if you can’t prove something works, then how can you say it’s done?

  • Ensure you have access to your list of requirements

  • If you haven’t already, put a series of tests in place to prove you’ve met the needs of the project

Do you know what’s been done?

With your feature list in hand, assess what’s been done and what hasn’t. Use your tests to evaluate whether it actually works or not. Just because a developer says it’s done, until you can see it working and passing your tests then it’s not.

  • If you don’t know which features have actually been completed you need to find out now

  • Ensure that developers know what they are expected to do to pass the features that remain on your list

What can be multitasked?

Having established the planned features and exactly where you stand in their completion, you will know how desperate the situation is. It’s now time to get down to solving the problem. Look at your list of requirements, are they like building a house where the foundation must be finished before starting on the wall, or is it possible to develop multiple features at once?

  • Challenge existing dependencies and break as many connections as possible

Are you doing the important stuff?

When projects get into trouble there is a huge temptation to drop all of the things that help drive the quality of a project. This then leads to fire fighting and general panic, and later burnout and still no project finished. It’s imperative to still ensure testing and reviews take place to build a foundation of stable and reliable development.

  • Don’t fall to the temptation of ‘just write the code’, keep project quality alive and kicking.

Are you putting a square peg in a round hole?

There is a gut reaction when projects begin to drift to simply throw more bodies at the problem. After all, more people working on a feature will mean it is finished faster. This could not be further from reality. All this will achieve is a mass of useless resources, maybe a fight over the best solution and a waste of time and money. Rather than try to brute force speed through numbers, it may be quicker and more cost effective to ensure that team members are allocated to tasks in areas where they are most productive.

  • Refresh your memory of the capabilities of individual team members

  • Match team capabilities to the development requirement they suit best