In one of my previous roles, I recall being called into an urgent meeting with senior management at board level. Everyone was panicky, furious, desperate for resolution. The air was thick. I was feeling those vibes too, and I didn’t even know what the issue was, but the energy was so strong I had no option but to reciprocate.
You’re allowed 5 minutes to panic, then you gotta be a planning gangster!
The problem was that the company entered a joint venture with a tech startup (that delivered really nothing prior to this project, go figure) to build an app that was meant to digitalize a part of the business. However, R15m later, all they had was a very poorly performing, limited website, demotivated staff, and a very happy business partner who enjoyed the cash flow, with no delivery. Oh, and a chatbot. They had a bot on the website. It didn’t work, but it was there.
As technology leadership, we needed to make a call, and find a resolution, keeping in mind the investment that was already made. Naturally, the sentiment was to abort, and cut all losses. But sometimes, if we look closer, there are ways of salvaging ailing projects, irrespective of the messy state they might be in. Sometimes a project can be rescued.
What is project rescue?
Project rescue refers to conducting retrospective sessions, using a methodology that can achieve the desired result in short periods of time, and thereby eliminate blockers and remediate elements of the initiative that contributed to the decline. Every project is different, therefore the methodology selected might not be a one size fits all. The methodology selected can be determined by the most contributing factors like time, budget, business requirement.
The reality is that as soon as projects are launched, there is momentum, delivery occurs at acceptable velocity, the energy is great. But somewhere down the line, particularly with agile methodologies, cohesion of features degrades, backlogs pile up, budgets run out, and morale is lost. When this happens, anxiety creeps in, and as soon as management gets wind of the issues, urgent decisions are made to try and protect the business against damage and loss.
A light at the end of the tunnel
Coming back to my example, it was challenging because I did not even hear of this venture until the day of the panicky meeting. However, we chose to rescue the project. Revisited the plan, the use cases, the code, and the skills. We derived a new MVP based on the immediate release that was needed. In a matter of a week, a remedial plan was in place, and within weeks the project was ready to go live. So, all is not always lost. As is the case with coding, sometimes a fresh pair of eyes can spot the gaps and get things back on track and most likely restore the initiative to a delivering endeavor.
