So you live and breathe by some piece of technology. It is your everything. Or is it?
It’s buggy; it’s quirky, you have to hold your mouth right to get it to work. It keeps you up at night when you make it do anything important. So, time to throw the baby out with the bathwater? Can it be saved? How can you know?
Reason #1 to Scrap It – 80% Out-of-the-Box
Lean toward scrapping it if there is something else that will do 80% of what you need to do and you aren’t all that attached to legacy data, legacy products, legacy whatever. If it’s a no-brainer, put more in the “pro” column, run the numbers, and see if you can spare some time and effort to transition. Look very closely at any estimation of what it’ll take to implement, adapt, absorb a new technology but don’t NOT do it because it’ll be painful. You just need to understand HOW painful. 80% needs to applying to everything though so make sure everyone weighs in on that.
Reason #2 to Scrap It – Too Hard to Find the Skills
Lean towards scrapping it if you can’t find a bunch of people who work in the technology it is written in. It’s a simple law of supply and demand. The harder it is to find the skills to maintain your product the more expensive it is to maintain. Moreover, you’re looking at an ever-shrinking base that, by implication, isn’t keeping up with modern ways. If this is you then look hard at re-platforming the product into something more modern.
Reason #3 to Scrap It – No One Is Using It
Lean towards scrapping it if you haven’t been able to get it off the ground and get people using it – even in it’s hobbled state. Is it too far gone to be resurrected? Are you throwing good money after bad? Does it support your organization or are you just attached to the idea that it could?
These are pretty compelling and who doesn’t love a brand new bunch of code without all the idiosyncratic nonsense? Feels fresh. Feels clean and new and full of possibility. But there are reasons to love the one you’re with too.
Reason #1 to Keep It – The Devil You Know
You know it. You know the bugs and the issues and the worries. Sometimes it makes sense to stay with the devil you know versus switch to a brand new devil you don’t. Make an inventory of all the issue areas and concerns – those you know a lot about and those you merely suspect. Include all the things you know work well. Try to avoid a Debbie-downer approach that says “it’s broken.” What does work? To make a good assessment of next steps you need to know what could be salvaged and what needs a closer look.
Reason #2 to Keep It – Existing Committed User Base
If you have people on the system something must be working. Analyzing their patterns of use can tell you a lot about what does or does not work. Getting their direct input, looking into configuration data, surveying the user base can give you a better idea of what will, and will not, be top of mind and high priority among current users at least.
Reason #3 to Keep It – Identifiable Areas that Do Work
Try to get dispassionate and identify areas of the application that are fully functional and useful. From there you can often be clearer about diagnosing the core issues that need fixing. This is akin to a doctor asking you to put the finger on the pain. Knowing what does not hurt is as valuable as knowing what does.
Reason #4 to Keep It – Clear Path for Revenue Growth
If you can focus on a clear path to revenue growth that perspective may well clarify the core issues and concerns that plague your product. Where’s the money? What’s in the way? You needn’t fix everything today or even tomorrow. If you keep yourself focused on the objective of revenue you can produce a clarity around how to address your issues without throwing the baby out with the bathwater.