The Sunk Cost Fallacy for R&D Teams

Previously we addressed the sunk cost fallacy for marcom and business teams: the decision to keep an application that doesn’t work, or walk away and start over. This can be one of the more challenging decisions for leaders because, on one hand you’ve spent money to have something developed, but on the other hand, the app clearly isn’t doing what you need it to do. 

There are also implications for an R&D team that will be using the app. Even when projects seem like they could turn out disastrous, R&D teams can give themselves the best chance by understanding the considerations at stake, being prepared to salvage parts of the project, and learning from failure.

R&D considerations for starting over

The R&D team tends to be highly invested in application development — not just what it’s supposed to do, but also how it’s built. They have the responsibility to consider how continuing with the app, or walking away from it, might affect other functionality that the app was meant to support.

By the time a project gets to the point that you’re considering walking away, a lot of frustration has likely bubbled up from all stakeholders.

Here are considerations for the R&D team: 

• The requirements should reflect all relevant use cases, as well as interoperability with other systems and platforms that are needed to achieve the desired functions. Sometimes it isn’t clear that there wasn’t consensus about the requirements until the application is built out to a significant point and you’ve sunk a lot of money into it.
• Consider whether the issue is the wrong vendor, or the wrong application. Will starting over lead to a better outcome, or are you asking for the wrong solution?
• If you’re unclear on the requirements, it’s also possible that you could fall into a trap where every vendor is “the wrong vendor” because you’re not at a level of maturity to understand what you actually need.
• If you walk away, what will you be able to bring with you? Often old code isn’t helpful but the knowledge and experience gained from a past failure can lead to a future success.
• Does the vendor have long-term relationships with clients? Because custom development projects tend to have long life cycles, the longevity of client relationships can say a lot. For instance, if a vendor measures their client relationships in terms of years, that says a lot about how they are able to meet long-term needs.
• Compare how the vendor establishes expectations during development vs. how they meet those expectations.
• Another red flag is if a vendor says that their app will run so well that it won’t need support after it goes live. That’s like saying a car will never need maintenance.

Salvaging parts of an old system

Once you choose to walk away and start over, how do you salvage parts of the old system and preserve some value from everything that went into the initial implementation? 

One company – let’s call them XYZ Systems – needed a custom application to help support their device. They selected a vendor that sold them on a platform. The vendor touted their platform’s robust out-of-the-box features, as well as their ability to build widgets to address all of the client’s needs. They pointed to the amount of upfront time and development costs that they would be saving the client by onboarding them with this single tool. 

XYZ Systems purchased the platform. But soon they discovered that what they were told, and what they got, were far from the same thing. Far from solving all of their problems, the platform simply didn’t work. The user interface looked awful. The timeline kept shifting. The vendor kept missing deadlines, and by this point they were seven figures into the statement of work. 

XYZ knew they had a problem on their hands and wanted to know what, if anything, they could salvage from the build. At the time, we were maintaining a gateway, or collection of portals that was servicing different user groups. If they could use it to display the data from their system, they could at least save themselves some time rather than building something from scratch. 

To make a long story short, we were able to use our existing gateway that we had built for them in order to salvage a little bit of use out of the old system. XYZ walked away because they were able to get something better in only a couple of months, after working with a vendor that failed to deliver for over a year. 

If a company is robust and resilient enough to switch to an alternate vendor, it can lessen the sting and lead to a much more successful outcome.

Learning from failure

Walking away from any project might be considered a failure in some ways, but we can also learn a lot from it. “Failure” is a loaded term, and it often doesn’t convey the value of the lessons that come with it. It’s good to view any project as a learning opportunity that you couldn’t have experienced otherwise. The needs of your business continue to evolve, as do your methods to meet those needs. Sometimes you start on one pathway and end up on another.

It can be similar to do-it-yourself (DIY) home renovations. There is a steep learning curve when you’re first learning how to complete home renovations, and you can expect to make a lot of mistakes. But those mistakes become much more valuable over time, and your ability to succeed on future projects will often accumulate as you go. 

Failure can help us understand how to give clarity about requirements, communicate what is actually needed, and evaluate how flexible the system needs to be. It can also help you build more confidently and identify critical components for success the next time around. 

If you walk away from a project, what you tend to gain isn’t necessarily code. The code will almost certainly be dumped and rewritten. But you should have learned a tremendous amount from failing. We can learn just as much from writing code that doesn’t work as we can when it does work. The salvage tends to be less from the prior work product and more from the tremendous amount of knowledge you’ve gained and being able to channel that into the next iteration. And who knows; maybe you can create a 2.0 or 3.0 version based on what’s left. 

Experience is what you get when you don’t get what you want, so the adage goes. Sunk costs don’t have to sink your project. It’s worth taking the time to evaluate your options in order for the project’s long-term success.