Sunken Costs: The First Step is Admitting You Have a Problem

Every manager hates to have a failing project on their resume, and will fight tooth and nail to get the necessary funds to lift the proverbial albatross from their neck. Sometimes, very rarely, a failing project can be turned into a successful project by spending your way out of it. Sometimes an organization will spend money on supporting legacy software and hardware applications because they don’t want to invest the money in upgrades, and sometimes an organization will spend millions of dollars to keep Windows XP support for a few months rather than upgrading their machines **cough** IRS **cough**

Have you ever reached a point in a project or a software support cycle where it feels like you just keep piling in more and more money without getting any tangible results? This is an all-to-common occurrence, and often there isn’t any real time to reflect on why something is continuing on the same trajectory even though it has become a money pit. There are several reasons why people will continue to pile money into failing projects or supporting end of life hardware and software, but short of it being an absolute necessary undertaking, most of the rationale for continuation is weak at best.

How can you tell if your company is stuck chasing sunken costs on a failing project? Below are my recommendations for recognizing the problem.

  1. Get an outsider’s perspective
    If you’re part of a project team, or involved in the software deployment for your organization, it is likely that you’re not far enough removed from the project in question to be able to make an analytical decision. Emotions run high on pet projects and an outsider should be able to analyze the situation better than the project team.
  2. Analyze the need Is your project absolutely necessary?
    What are the impacts of not finishing this project? It’s important to keep the end goals in sight when you’re analyzing the need for your project to come to completion.
  3. Perform a cost benefit analysis
    This is critical for determining the actual value of your project relative to the costs that you are inputting. If done properly, this should be one of the key identifiers for your team on whether a project is going to pay off in the end, or whether the continued costs will be made up for by the gains created after finishing.
  4. Identify the likelihood for a new project in the future
    If your project is focused on application or hardware deployment, knowing there is a new release dropping in 6 months might be a good indicator of whether your current project is worth the time and money. Nothing is worse than having to go through another major project on the same tool less than a year after you finish the current build.

 

The first step here is admitting you have a problem. Once this has been identified, it’s much easier to take the proactive steps to get things fixed. Check in later this week for my next installment in this series. If you have any comments on please hit the comment button at the top of this post, and be sure to follow me on twitter @burked585.

2 thoughts on “Sunken Costs: The First Step is Admitting You Have a Problem

  1. Pingback: Sunken Costs: The Second Step is Understanding and Analyzing the Problem | Re-Imagine IT
  2. Pingback: Sunken Costs: Cut Bait While You Still Can | Re-Imagine IT

Leave a comment