What Vampires Can Tell Us About The Success of a Software Project

In life, also the business one, many things collide. Art, philosophy, craft, psychology, experience, passion, risk, and reward. It so happens that when it comes to rescuing software projects, all of the above collide at once.

Let me explain the struggle many project owners and stakeholders often face in their product’s life-cycle through the lens of philosophy and a brilliant thought experiment called the vampire problem.

This intellectual exercise wonderfully spreads to other areas, such as rescuing failed software projects and if you bear with me until the end of this article, you’ll be able to assess what you would do once at crossroads with your software project. Or whether you’d transition yourself into a vampire or not.

The Vampire Problem

Starts L.A. Paul her thought-provoking book titled “Transformative Experience”.

Let’s go deeper into this.

Would you do it? Would you become a vampire in the hopes that the life of a bloodsucking, two-legged bat is somehow better than the one you live? Would you willingly abandon everything you are and stand for? Change your habits, daily schedules, diet? Leave the comfort zone of the known for the unknown, no matter how tempting?

Explains L.A. Paul.

But here comes the kicker.

Vampire Paradox in the Software Realm

Now, forget about the whole vampire thing for a minute and pretend to be a project owner, a CTO, a CEO of a startup, or anybody who is a stakeholder of a software that is at a crossroads (unless you really are one).

You may be facing a rapidly approaching runway. Maybe there’s a technological debt stacking furiously, making the project no longer scalable (at least without an effort, resources or funding, and surely not fast enough). Perhaps you’ve already launched but the market said violently “We don’t want your product, it sucks”. But there’s a light in the tunnel so buckle up and don’t give up just yet.

You, as a business, may still transform. Not into a vampire, hopefully, but into a profitable endeavour. No guarantee, though. It will still be a risk just like it always has been. But this time it will be an informed risk, if taken into the account all the pieces you have on the table, learnings from previous failures, adjusted market reality, and humbled mindset.

In other words, this time will be heavily de-risked. But in order for this to work out you must assure the transformation to be as smooth as possible, and as informed as achievable. How do you do this?

1. Sound the alarm: Acknowledge that the project is in trouble and communicate the situation to all stakeholders.
2. Analyze the problem: Identify the root cause of the problem and determine what needs to be done to fix it.
3. Restructure the team: Reorganize the team to address the issues that led to the project’s failure. This may involve bringing in new team members or reassigning roles and responsibilities. Sometimes this means hiring an external team of experts.
4. Redefine project goals: Revisit the project goals and adjust them as needed to reflect the current situation.
5. Assess the current state of the project: Evaluate the project’s progress and determine what work has been completed and what still needs to be done.
6. Prioritize fixes: Determine which issues need to be addressed first and focus on those.
7. Consult: Seek advice from experts or other professionals who have experience in rescuing failing projects.
8. Validate the remaining project: Determine whether the remaining work is still feasible and whether it aligns with the organization’s goals as well as resources or deadlines.
9. Reconsider technology choices: Evaluate whether the technology choices made for the project are still appropriate and whether they need to be updated.
10. Keep building trust: Maintain open communication with all stakeholders and build trust by delivering on commitments.

Even if you can pull off all of this, the end result remains unknown. You may still fail and be unhappy with who you became as a business or a product. Or you might be better off than ever before.

Just as would be the case with a vampire. So, would you still do it? Would you go through all that trouble not knowing what the world will look like once you are done transforming?

There is one slight difference in all this, when comparing it to the vampire problem. Firstly, your life most probably doesn’t end with a failed project. Your job may, along with some of your hopes and dreams. But not your life so there’s that small window you may use to go back to where you were and start over with new knowledge and self-awareness.

There’s also another difference. Remember when all your vampire friends were telling you how great it is to be a vampire? When it comes to rescuing failing software projects there are no other vampires. Nobody is on the other side waiting for you and luring you into a potential trap. Nobody is in your future shoes.

There are, however, agencies such as ours, that can help you strategize and consult on the transition so that it truly is an informed one. This is a real de-risking allowing for a softer landing, even if the journey ahead appears bumpy at first.

So, again, would you turn your failing project into a successful one without the knowledge of the outcome? I’ll tell you why I would and then never look back again. If you as much as considered a transformation in the first place, it most probably means that you weren’t happy with where you were and needed to change things.

That’s the human factor if you need one. From a business perspective, however, you could either act and do everything in your power to fix things, to make them better and to adjust or, quite contrary, passively observe the imminent demise of what once was a great idea. If you did nothing and watched that brain-child of yours die with no attempt to save it, how would that feel? Personally, it would be haunting me for years.

And for that matter, if nothing else, I’d go all-in on a rescue mission to save what’s left of that project. Who knows, maybe it would turn into a toothless, wine drinking vampire (I think I actually know the guy).

That’s the beauty of it, we simply don’t know the outcome and how it would make us feel. This uncertainty is what is supposed to drive us. It may feel counterintuitive but has been proven time after time. As Emerson realised:

Rescuing failing software projects

Thankfully rescuing failing software projects is a lot more tamed. There are things that are common to most other projects of this sort, hence some best practices do exist, ensuring that rescue missions draw from experience rather than guessing. They emerge from battle-proven approaches, strategies and tactics. To give you an idea how manageable that process can be, at mente.io, we approach this in the following manner:

Step 1: Interview & Analysis

A. In-depth interview with the client (mostly a senior stakeholder like Founder, CEO, Product Manager, Product Owner along with their CTO). During this step we try to find out as much as possible from the client and project’s history, following certain, proven business logic:

1. Initial business and technical goals; the level of their achievement at the time of the conversation,
2. The project’s progress, achievements, ownership and constraints from a business and technical perspective:

• The client’s business team – who and how manages the product or the project,
• The client’s technical team involved in the project (internal or from another supplier), their technical competencies such as knowledge of specific technologies, operational competencies such as software development processes (e.g., level of implementation of CI/CD processes, etc.),
• The technology used and why it was chosen, how it performs, etc.,
• Known software issues (e.g., slow performance, crashes, etc.) and team-related issues (such as failure to deliver business-expected features on time, poor communication, low availability, failure to meet deadlines, appearing disengaged or demotivated, etc.),
• Known project risks (e.g., limited budget, competition, internal risks such as disengaged management, etc.)

B. Current goals (e.g., meeting the market launch deadline, obligations towards investors or pre-sale customers, etc.),

C. Limitations (e.g., time constraints – two months to market launch, budgetary constraints (i.e. 2/3 of the budget already spent on the project),

D. What the client’s team has done so far internally to address the challenges and with what results,

E. Other stakeholders involved, such as investors, other suppliers (whose satisfaction needs to be ensured),

F. Everything else that may play a huge role such as the business model, specific solutions that quickly come to mind, which may have been considered – if so, whether they were implemented, why not, etc.

Step 2: Presenting possibilities

1. We prepare an offer for an audit of the situation based on the provided software, data from monitoring tools (if connected) and based on the interview and analysis.
2. The result of an audit will eventually come in a form of a report that usually contains:

• The overall summary of the existing situation,
• Identifying perceived risks,
• The most visible problems and their implications,
• Possible recommended approaches with different levels of priority along with their consequences, time required for implementation, cost (not providing an exact estimate, but a magnitude comparison of the costs of different solutions).

Depending on the project size, the analysis takes 1-2 working weeks, sometimes less for smaller projects, although they can be very complicated.

3. We discuss the offer with the client and often fine-tune it based on new information (often a critical moment).

Step 3: Conducting the audit and preparing the report

After obtaining access to the client’s code, repository, systems and interacting with the client’s team, we examine everything thoroughly, looking for opportunities and dangers. Once the audit is conducted, we prepare a report and discuss it with the client.

Step 4: Planning and contract sign off

The client usually realises that they cannot handle the challenges outlined in the report on their own and with the current team’s limitations. We determine what they can do themselves and what they cannot. We prepare an offer for implementing a rescue project, specifying:

1. Project goals,
2. The scope of the involvement (client’s vs. ours),
3. Billing model.

Then:

1. We sign the agreement,
2. Plan the scope of work,
3. Set up a project management system such as Jira (ours or the client’s)
4. Project’s kick-off.

Step 5: Rescue mission

The actions we take during a rescue mission include, among others:

1. Deepening project knowledge through team discussions, documentation analysis, and software analysis,
2. Reviewing and designing new system architectures (e.g., from monolith to microservices),
3. Code repair, writing new code,
4. Patching various vulnerabilities,
5. Implementing/improving CI/CD processes,
6. Optimising infrastructure (clients often don’t see how money slips away),
7. Mentoring often young or otherwise long-established teams,
8. Bringing in new competencies,
9. Consulting with Founders, PM, CTO, etc. (education and mentoring at every business-technical level),
10. We strive to solve pressing problems, deliver tangible results.

At this stage, we strive to solve urgent problems and deliver tangible results (such as infrastructure optimization, missing features, etc.). All of this is done in close collaboration with the client, which is a prerequisite for starting (key stakeholders must be available, and all system access is essential). We continuously review the level of achievement of the client’s goals, sometimes modifying them during the process (hello, flexibility).

Psychologically, we gradually build trust among decision-makers and the team, who initially may be reluctant to share knowledge or disclose information due to fear of layoffs. However, over time, they recognize our good intentions (we don’t want anyone to be fired – we rather help them maintain their jobs), how willingly we share knowledge, and how we invest attention in these individuals and their problems. As a result, they begin to trust us. This builds their new commitment, and sometimes entirely new energy emerges to achieve the goal together.

Conclusion

Closing in, I’ll gladly give voice to L.A. Paul once again as she so perfectly summarises her own vampire paradox, shedding a light on her personal preference, too.

The question should be, then, not whether to transform or not but rather, “Hey mente, when can you start your rescue mission and how much will it cost us”.

Recommended reading & sources:

• https://www.themarginalian.org/2017/09/13/transformative-experience-vampire-problem/
• https://blog.oup.com/2014/11/vampires-transformative-experience/
• https://lapaul.org/
• https://www.oxfordreference.com/display/10.1093/acref/9780191826719.001.0001/q-oro-ed4-00004155 (for Emerson’s quote)