If you’re like the majority of marcom leaders, custom applications can be some of your greatest triumphs, as well as some of your toughest headaches. One headache that everyone hopes to avoid is the dreaded point when it becomes clear that an application is not doing what it’s supposed to do.
If you’re not careful, you can fall prey to the sunk cost fallacy and make choices that can affect your project in unintended ways, both now and down the road.
What is the sunk cost fallacy?
The sunk cost fallacy is, “I spent money up to this point on this, so I need to keep investing money.” A sunk cost comes into play when you notice a problem; something isn’t working the way in which you intended. Maybe you’ve paid to build a system, and it’s clear that it won’t solve your problem anymore.
There are numerous ways to arrive at this dilemma. Maybe the objective wasn’t clear. Maybe the requirements changed along the way. Maybe the app was up to spec, before you inherited the project, but software updates, new operating systems, or shortcomings in the code caused it to stop working. Regardless, you’ve spent money, you’ve lost time, and now you don’t have the solution that you need.
At this point, the sunk cost fallacy suggests that you’re justified in continuing to “throw good money after bad.” It can be frustrating, and it leaves you with a choice: keep the app, or walk away. Do you continue to try to throw more money and time after this, or do you cut your losses and start over?
MarCom’s role in the decision-making process
Marcom and IT teams tend to be vested in development projects differently. When it’s clear that an application is not going to solve the problem that it was designed to solve, IT tends to explore the technical considerations while marcom tends to focus on the business needs. Both are key stakeholders with differing, yet overlapping, priorities.
When the marcom team commissions a project, they may be the ultimate decision-makers on whether to proceed or start over. But regardless of who owns the project, it’s important to gain buy-in from all of the stakeholders and conduct a thorough consideration process.
Implications of walking away
The stakes tend to be high when walking away from any large investment, so it’s important to recognize that it can feel like every option is a “loss” in some way. Understanding the implications of walking away can help you consider all of the ways that it could impact the project, especially if the project is close to completion.
Deciding whether to keep a custom application can be like evaluating whether to keep a new hire who is no longer meeting expectations. Sometimes you have to go pretty far down the road to assess whether a new hire is ultimately the right fit for a position. It’s one of the reasons that some companies have a rigorous interviewing process and/or a lengthy onboarding period. And while there are costs associated with onboarding a new team member, many leaders have experienced the scenario of realizing that a new hire ultimately is not the right fit.
It can be the same with vendors (whether your “vendor” in this case is IT or an external firm). It’s easy to overlook signals early in the evaluation process, but red flags tend to be more apparent down the road.
However you decide that an application isn’t meeting your needs, there are several key factors that can help you evaluate whether to rebuild an application.
This tends to be the first consideration that’s discussed because it often feels like the most significant reason to stick with the original app. Teams are likely burning through their budget at this point, and it can feel just as painful to walk away. But the original project budget isn’t the only factor. Your comparison should include the total costs of ownership, including maintaining an application that doesn’t meet your needs. Over a period of months or years, that can add up quickly.
Another consideration is training new people on the project or, worse yet, having to figure out the intent of the original developers after they are no longer working on it. Getting new people up to speed on a system that they didn’t build tends not to be viable. It’s common for decisions to be made along the way that are difficult to pass from team to team, because they require context that is no longer available to them. It’s challenging to find all of the notes and recall all of the conversations that happened up until that point.
Today, most custom apps don’t stand alone. They integrate with data sources, security protocols, operating systems, and other apps. Dashboards are great examples: without the right data integrations, they are essentially a blank screen. While APIs are generally more open than they were 10-20 years ago, you should still consider the time and effort required to build and maintain all of the connections that are needed for your app to work.
Maintenance & support
Another challenge is keeping custom applications running once they’re built. The same specialized knowledge that was required to develop it is often required to maintain it as well. Switching to another dev team in the middle of that process can be a clunky handoff. It’s important to consider the costs of maintenance and support well before the application goes live, which means it might make sense to walk away and start over sooner rather than later in order to avoid lost productivity down the line.
Getting buy-in for a new direction
Because the stakes are high when changing directions at a late stage, you can expect resistance.
Here are some tips for gaining buy-in from all relevant stakeholders:
- Make decisions by consensus with your boss/management team throughout the project life cycle. It tends to be far easier to reverse course if you can show that starting down that road was a collective decision. The more you can show that you made a decision by consensus, the more likely you are to gain approval to change direction.
- Be ready to show how you chose the vendor. Be prepared to walk all relevant stakeholders through the process that you used for gathering requirements, how you evaluated solutions, and who gave buy-in for the initial vendor decision. Showing that vendor selection was one in a series of informed, collective decisions tends to give you a better chance of success when changing course.
- Be open about warning signals that might have existed. Hold yourself accountable and be ready to explain how a new direction gives you a better probability of success.
- Demonstrate that you set milestones and kept the vendor accountable for meeting those milestones.
- Compare the total cost of ownership for both choices. Be prepared to show that you were conscious of costs all along the way.
Sunk cost scenarios are a challenge, but it’s worth taking the time to evaluate your options in order for the project’s long-term success.
Concorde jet image courtesy of Wikimedia
Justin Bantuelle balances the responsibilities of both the Chief Operating Officer and the Web Technology Director after having worked with Health Connective for more than a dozen years. Justin regularly leads the cross-disciplinary teams in building out and updating applications for Fortune 500 companies.
Justin keeps his technical abilities sharp by contributing to an eclectic mix of open-source and personal projects on Github.
Jared builds innovative healthcare brands through digital strategy and engaging content that turns heads. He is a keynote speaker, prolific content creator, host of the Healthcare Rap podcast and author of Connect the Docs: Put Digital Health Into Practice.