I've found that if you can provide valid numbers, managers are more likely to act. (If they can understand the logic and the cost/benefit.)
IMHO, to make a convincing case, you would need the following to show how bad it is:
- number of support incidents logged for the issues
- time spent in hours maintaining/band-aiding bad code/doing support
- time cost based on hourly rate of people doing the maintenance/band
- some way to demonstrate how mission critical these items are to the
And to make the case for refactoring, you'll need:
- time estimate to refactor and implement each of the top 3 of these
- cost estimate for implementation (same hourly rates as used above)
With these, you can make the case for time savings if the refactoring takes a whole lot less than support time for 3 incidents for each of those top 3 items. You can argue that this shorter amount of time spent will
- be less than n more support incidents
- there won't be any more of these incidents for these things (EVEN BETTER!)
However, the hardest part of this sell will be answering the following question, since lots of people don't budget time in schedules for all the support you're doing:
How much longer will I have to wait for current project Y to get done while you're spending time working on these issues with X????? (despite the current support timesinks, which can't be predicted and scheduled in Gantt charts)
This depends a lot on how well you communicate with the decision makers, and how they understand the situation.
I DEFINITELY think this is worth doing, so you get the practice of building the case with the metrics, and to save yourselves time, even if they don't go for it. Unfortunately, not everyone is easy to convince, despite the data. GOOD LUCK!