Every project starts with high hopes to deliver one or more business values. The team begins with the requirement analysis and then carries on with design and development. On the journey, many obstacles appear. The team tackles one. Later another one shows up. It seems the project is going nowhere. Sounds familiar? Stagnating project isn’t new. Before finding problems to stagnation, we should procrastinate. We should take a step back and evaluate the circumstances to avoid falling into sunk cost fallacy.
Sunk Cost Fallacy
The sunk cost fallacy is about over-investing our time, money, or energy in something. We tend to follow existing endeavors because we have already invested in them. Nevertheless, sunk costs have already been incurred. We can’t recover it. Hence, sunk costs shouldn’t be a factor in the decision-making process. If we could think rationally, then we wouldn’t take them as a factor in our future decisions. Nevertheless, it happens because we are emotional creatures.
In the context of software development, we continue working on a project because we invested development time. The efforts we put into bringing the product to life are gone. We can’t take them back. We can only make decisions about the future. Thus, we shouldn’t let our emotions corrupt our reasoning. There are times when it’s more reasonable to pull the plug from the project.
Time to Pull the Plug
When the extra time and resources outweigh the yield then it’s time to call it a day. Nevertheless, it’s never easy to make such calls. More importantly, it’s harder to take a step back and evaluate the circumstances. A project is an investment. If the market conditions change, we should reassess our position. All in all, some signs can guide us on whether we want to end the project.
- Customers are no longer interested in the project. They started using alternatives.
- The project is well beyond its schedule. It’s unclear when it can deliver value. The project has exhausted our resources.
- The project delivers value but fails to have a positive impact. In other words, the return on investment is weak.
- Stakeholders, as well as sponsors, have lost faith in the project. There’s pressure from all fronts.
- The company or department has changed its strategy. For instance, the company favors buy rather than build.
- The project has suffered a loss of expertise. The institutional knowledge has been lost. It’s hard to provide support to customers.
Although signs can help navigate the project, there may be a tendency to fall into sunk cost fallacy. It’s better to structure the project so that we can check the value proposition for the project on a regular cadence.
Avoiding Sunk Cost Fallacy
There are psychological reasons behind sunk cost fallacy. We don’t want to feel that we wasted time or resources. We want to stick to our plans. We can’t accept the loss. How can we move away from this mentality in software projects? One way is to deliver small and fast. It aligns with agile methodologies. We then establish the feedback loop with the customers. We can navigate with their suggestions. Even with an iterative approach, we might still find ourselves at dead ends. To avoid sunk cost fallacy, we should benchmark the project regularly. When the value proposition becomes questionable, we should apply a decision-making process with the following options.
- Halt the project with no alternative.
- Redirect the project.
- Evaluate goals
- Consider alternatives
- Decide on a new start
- Resume the project as returns still outweigh the cost.
In the decision-making process, we need to take the emotions away. We shouldn’t count the energy and resources we invested. They are gone. We can do very little about it. On a separate note, engineers tend to stick to the project or overrate it despite alternatives. We need to avoid it. Common arguments are about customization, covering use cases, and so forth. No product, including our solution, would cater to requirements perfectly. Therefore, it’s irrelevant. If sunsetting the project has more pros than cons, we should go with it.
Sunsetting a Project
No matter what the reason is, giving up on a project isn’t easy. Engineers build an emotional attachment to the project. They often joke about a project being someone’s baby. Besides, engineers take pride in their work. Hence, stopping a project can demoralize the team. We need to get everyone on the same page. Stopping should be a team decision.
Sunsetting a project has also technical challenges. There may be a few customers who love the product. We need to convince them to use the alternative. Or we need to explain it’s not a financially viable option to run it. Moreover, we need to set timelines for the deprecation and communicate them with stakeholders.
Recap
Software development projects sometimes go off the rails for different reasons. We need to prevent investing in projects that have lost their cause or projection. We need to avoid sunk cost fallacy. We need to check the project viability as well as its value proposition regularly. When the project’s future is in doubt, we should decide on what to do. In some cases, we need to end it. We shouldn’t make calls based on past investments.
References
Article: The Sunk Cost Fallacy
Article: How to avoid sunk cost fallacy in software projects
Article: 16 Signs It’s Time To Pull The Plug On A Tech Project