One thing is certain in software development, and that is that uncertainty is part of the process. With this comes all manner of potential obstacles, from budget blowouts to missed deadlines. Today I will be exploring what to do when your software project has taken a turn for the worse.
1. Re-assess
The first thing one must do when you have recognised that a project isn't going to plan is to take a step back and try to look at the bigger picture of what has happened. Often it is easy to just focus on the tiny minutiae of what is happening in the 'now' without looking outside of our field of view.
a. Find the source
Find the core issue through open communicative investigation. It is easy to play the blame game with a failed project, however, it is more constructive to collaborate and investigate as a unit to find where the issues are and from there you can determine your next steps.
b. Strategic direction
You know what has gone wrong now, and why - next you need to build out your strategy for assuring the same mistakes are not made again.
“Failure is instructive. The person who really thinks learns quite as much from his failures as from his successes.”
- John Dewey
Adjust timelines and budgets as needed, acknowledge the unforeseen circumstances that brought you to this point and focus on what can be delivered in the next steps.
2. Resourcing
Often timelines are blown out through lack of proper resourcing, if you don't have the correct skillsets or enough people to complete the project then obviously it is doomed from day one.
a. Evaluate current team
Unpack the list of requirements found in your strategic direction and ask the team if they would be comfortable being accountable for these requirements, if not, why not? It is important that the team feels comfortable to share their honest opinions on these questions.
Once you understand where your skills gaps are you can go about hiring or outsourcing to fill them.
b. Do we have enough people?
If the team has the correct skill set to accomplish the goals, just not in the timeframe required then the next step is hiring people in order to increase project velocity.
3. Technical assessment
a. Evaluate the codebase
If your software project needs to be rescued it is strongly recommended you take the time to evaluate the codebase. During step 1, it is likely you have identified why the project hasn't been successful. Regardless of whether it was a technical issue or not, it is a good opportunity to evaluate the applications codebase. There are independent consultancies that provide this service. Alternatively, development companies like WorkingMouse provide this service during a scoping engagement.
b. Determine legacy implications
After evaluating the codebase, a decision must be made whether to carry on with it or whether to spend time rebuilding the application. This will largely depend on the evaluation step above.
c. Migrate
A migration may be necessary depending on steps 3 (a) and (b). If that's the case, we recommend finding a development agency that has a proven migration process. It can often be the most challenging part of a software project. We've created a guide on migrating brownfields (legacy) projects which is available for further reading.
4. Communicate
Open communication is the key in understanding what has happened and what you would like to happen moving forwards in a project. When looking to rescue a software project you must encourage open communication lines.
a. Set goals
Everyone has heard how important goal setting is both in your professional and personal life in order to get from where you are to where you want to be. The same is with software projects, in order to achieve your desired outcome, first you must set clear goals to keep yourself and the team on track. If you're outsourcing to a software development company, ensure that clear goals and success criteria are in place. That will allow you and the agency to review the success of the engagement once a build has been completed.
Lack of clear direction is listed as the leading cause of project failure by employees, above low budgets and employee resistance.
5. Get cracking
So you've explored why your project was failing. Ideally these learnings will be fed back into the next build. If you're using an internal team, you'll need to identify the potential risks based on your initial experience. More commonly, product owners will have a bad experience with a development agency. It may have failed for any number of reasons. This experience generally leaves you searching for other agencies in the market. When evaluating a new development company be sure to ask how the risks you've identified will be mitigated. Do they have a Way of Working, a Legacy Modernisation Resource Hub or some other form of quality control?
All that is left is to begin, this can feel incredibly daunting as you are setting in motion for the first time after a failure. Validate the team where you can, remove blockers and don’t hesitate to communicate quickly when plans aren’t aligning with the set goals.
Bonus Step: Enjoy the success of a completed project!
