There are a lot of things that happen to bad software. Back in the early 80’s, Atari decided to bury their bad software in the New Mexico desert. Literally, bury it.
It’s not 1983, but bad software still gets buried. It gets buried in a different sense. It gets bought by another vendor and “updated”, it’s “transformed” from a server-side application to a “cloud-based platform”, and lest we forget the “let’s customize the heck out of it until it’s unrecognizable and works better” (or worse in many cases) approach.
If you’ve been in technology for any length of time, you’ve probably worked with bad software. What makes it so bad? The bugs? The worthless GUI? The endless hours of futile user acceptance testing? To me, it seems that there’s a gradual tipping point for bad software where the project goes from “Wow, let’s buy it” to “Well, let’s see how the requirements and design phases play out” to “did they even unit test this?” to “the end users hate user acceptance testing because the bugs are so bad”.
How can bad software be fixed? Or, can it be fixed at all? Honestly, bad software is a real challenge. You’ve got users who are being told by their managers that they have to use it, senior managers who are trying to ensure that they’re not scalped by their CEO / CFO for purchasing bad software, and a technical team managing so many workarounds related to the bad software that there are workarounds to the workaround.
If your project is using the Waterfall software development life cycle approach, the decision to pull or somehow salvage bad software has to be made early. Don’t attempt optimism in the case of bad software. If it’s broken and you know it, go back to the vendor and work with them to fix it before you roll it out to your end user population. Keep in mind that this will probably throw your project into the red and you won’t be the most popular person until you get the project back on track, but it’s worth it. Talk to your stakeholders and explain the situation, because end users shouldn’t be held responsible for unit testing a bad software product. However, if your project is using an Agile approach, you’re usually in a better place, as the 30 day sprints are more flexible and allow iterative changes to be made to the product.
As project managers, we’re responsible for the entire project, including (unfortunately) bad software. So, come up with a game plan to work with your vendors, stakeholders and project team to ensure that you aren’t rolling out bad software. Your end users will thank you!