Know When to Stop

  • by
Know When to Stop Lodestone-LLC.com

My recent post on sticking to your core competencies reminds me of the related maxim of knowing when to stop trying to fix a fundamentally flawed endeavor. At what point do you recognize that you need to stop throwing money at a problem and change the strategy?

A Cautionary Tale

A company sold widgets.  They sold a lot of widgets — big, small, high-end, low-end, wholesale, retail.  If you wanted to buy a widget, you should go to these guys.  These guys were the biggest and the best at selling widgets.

One day, they decided that they should write some software to handle all the back-office tasks involved in selling widgets -– point-of-sale, supply chain, billing, CRM, accounting — everything widget-related.  They assumed that because they were so great at selling widgets, they were going to be great at creating software to help them sell widgets.

Keep in mind, these guys sold widgets.  They do not write software.  They didn’t even use much software in the widget-sales game besides a lot of spreadsheets.

Never mind that there were plenty of fantastic, vendor-provided software products that could be configured and customized to support the sale of widgets, and that had been successfully deployed to support the sale of just about every other product.   These guys could create better software than the SAPs and Oracles of the world.

They spun up a team to create this software.

Then they spun up an offshore team to assist in writing the software.

Release after release, the software barely worked.  It had serious reliability and scalability issues.  But those could be solved by throwing more money at the project, right?

After more releases, there were more problems, more bugs, more lines of code.  Maintenance costs skyrocketed.

Perhaps the offshore development partner was the cause.  So, they brought development back in-house.

More bugs, more instability, more spending — this went on for years.

During this time, they acquired other sellers of widgets who were using best-of-breed software for ERP, CRM, accounting, analytics, etc.  Those companies were forced to migrate to the in-house application.  When they could not, they kept their own, reducing the cost savings from the consolidation offered by the acquisition and creating more costs to support all these applications that were solving the same problem.

This continued to cost more and more money.  To feed the in-house software beast, budgets were cut to other IT domains –- telecom, networking, infrastructure -– otherwise, the Board would never approve such a high IT budget.

Everyone knew this endeavor was a terrible mistake.  But now, everyone was so invested that the admission of failure would cost jobs – executive jobs.

The widget market became more competitive.  Upstart competitors used technology to reduce the costs of selling widgets.

This story doesn’t end well.  What was once the biggest and best widget seller is now just one of many sellers of widgets, with a market share continuing to decline, led by the same scared executives, feeding the same unfinished, broken, buggy in-house software monster.

The Moral of This Story

Every successful project has a definition of success and failure from its onset.  Keep them in mind, and know when to cut your losses, admit defeat, and move on.   Know when something isn’t working and don’t be afraid to change direction.