• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
Health Connective Celebrating 25 Years

Health Connective

  • About
  • Services
    • Custom Marcom Tools
    • Digital Surgery Online Portal
    • Streamline Your Product Ordering
  • Our Work
    • Surgical Case Review Portals
    • Online Product Catalog
    • Field-Based Program Tracking System
    • Account Management Dashboard
    • Surgical Device Certification System
    • Internal Resources Website for Marketing Division
    • Co-Branding Dashboard
    • Physician Locators
  • Resources
    • Marcom Insights
    • Development Insights
    • The Health Connective Show
  • Get Started
    • Schedule a Call with Health Connective
    • Security & Compliance

Don’t Fall Prey to the Sunk Cost Fallacy for MarCom Applications

by Justin Bantuelle and Jared Johnson

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?

Concorde jet taking off
Learn how to avoid ending up with the Concorde jet of custom applications.

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.

COO Justin Bantuelle

Comparing choices

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.

Budget

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.

Knowledge transfer

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.

Integrations

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: 

  1. 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. 
  2. 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. 
  3. 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. 
  4. Demonstrate that you set milestones and kept the vendor accountable for meeting those milestones. 
  5. 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
Justin Bantuelle
Chief Operating Officer & Web Technology Director at Health Connective

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.

  • Justin Bantuelle
    https://www.healthconnectivetech.com/insights/author/justinhealthconnectivetech-com/
    Developing Actionable Insights from Data
  • Justin Bantuelle
    https://www.healthconnectivetech.com/insights/author/justinhealthconnectivetech-com/
    Addressing Interoperability Challenges
  • Justin Bantuelle
    https://www.healthconnectivetech.com/insights/author/justinhealthconnectivetech-com/
    Developing Technical Solutions That Capture Physicians’ Needs
  • Justin Bantuelle
    https://www.healthconnectivetech.com/insights/author/justinhealthconnectivetech-com/
    Turning Contextless Data into Insights
Jared Johnson
Jared Johnson
Consumer Health Strategist & Podcast Producer

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.

  • Jared Johnson
    #molongui-disabled-link
    Prioritizing Accessibility
  • Jared Johnson
    #molongui-disabled-link
    Why Coding Standards Are Essential For Success
  • Jared Johnson
    #molongui-disabled-link
    Security Essentials
  • Jared Johnson
    #molongui-disabled-link
    Automation Essentials

Filed Under: Custom App Development, Marcom

Primary Sidebar

Table of Contents

  • What is the sunk cost fallacy?
  • MarCom’s role in the decision-making process
  • Implications of walking away
  • Comparing choices
    • Budget
    • Knowledge transfer
    • Integrations
    • Maintenance & support
  • Getting buy-in for a new direction

Welcome!

Michael Roberts

In our marcom articles, we share tips from our work with marketing and communication teams at medtech companies, including how to evaluate whether or not you need a custom application, how to effectively communicate what you need to developers (whether in-house or third-party), and how to demonstrate value to the C-suite and your customers.

--Michael Roberts, Marketing Director

Marcom Resources

  • Glossary for Medical Device Marketers
  • Marcom Newsletter
  • Medtech Marketing Careers
  • Building an App for That: A 3-Step Planning Guide for Medtech Teams

Recent Marcom Posts

  • How Can Medtech Companies Determine the Return on Investment for Application Development?
  • Can Cybersecurity & Compliance Be a Selling Point for a Medtech Product?
  • The Direct to Patient Marketing Trends That Are Making an Impact on the Industry
  • About
  • Insights
  • Cookie Policy
  • Privacy Policy
  • Get Started
HIPAA Seal of Compliance
Health Connective

(504) 581-4636
LinkedIn