I'm going to pick on @jmort253's answer, because I disagree.
ROI initiatives aren't the only kinds of project, nor should they be. Chris Matts (the analyst behind BDD, Feature Injection and Real Options) found that 80% of one of his CIO's projects were concerned with protecting existing customer revenue, rather than trying to increase it - essentially, stopping their customers leaving for a competitor.
A lot of projects also simply provide options for the future. These are often very hard to price, but very, very expensive if they're not done.
Most technical initiatives are done for this reason; to provide the business with options to change in the future. Some of them have more direct business concerns which are more easily phrased, like increasing current system performance to cope with growing demand. Others may be relevant to different parts of the business - changing from Fortran to Python to attract better talent and make it easier to recruit - but in the long run, that's still about having options in the future.
Technical Debt is, and should be, a PM's concern
Chris Matts and Steve Freeman came up with a lovely analogy. "It's not like a credit card. It's like an unhedged call option. It's like you've promised to sell all these chocolate Santas at Christmas, and then suddenly one year the price of chocolate is really high, and you have to sell the Santas anyway because you made that commitment, and now you're bust." As long as nobody makes the call, technical debt doesn't matter.
The problem is that every project has something new about it, or that project wouldn't be happening (see "Waltzing with Bears"). So every project has changes that get made as discoveries happen as a result of feedback from the new thing (see the complex domain in Cynefin). And every project is therefore seriously at risk from being called.
(Every project is also difficult to estimate for this reason; you can't estimate something you've never done before.)
The option to change is usually an unstated a business goal
I worked with one company that had a single class of 10,000 lines that took Visual Studio 5 minutes to load. When the business found out what poor quality code had been produced, they said, "Why would you ever do that? We expected you to push back if we were making you do that!"
This unstated goal is also, usually, the core goal of most projects which are replacing legacy systems. The legacy systems have become too unwieldy, and can't be changed to meet new requirements and architectural demand, so a new system is created. If I had a shiny English pound for every time I've seen a replacement system team abandon the core goal in order to meet some arbitrary deadline, I wouldn't need to work again.
By calling out this unstated goal as an explicit one, everyone involved on the project can talk about it rather than assuming it's happening.
Educate the business about the cost of technical debt
Technical debt only happens in the face of time pressure (or as a result of bad habit or lack of skill, which are a different problem, solved by having time to learn how to do the job well... so, time pressure).
By keeping track of the growing cost of the debt and making the business aware of it, you can help to show them the value of the options they're losing. This could include things like your best developers leaving, and the cost of re-hiring; how much extra time the devs reckon it took to create a new feature as a result of technical debt; how much more effective the team is when they're given the chance to take pride in their work instead of bowing to business pressure.
Also educate them about the alignment trap. "Companies in which IT was highly aligned with business but not effective were considerably worse off than companies in which IT was less aligned and merely kept the systems running."
Pay back technical debt one piece at a time
In this place I agree with @jmort253. It's even better if you can avoid falling into debt in the first place, but usually there are different skill sets on a team, people learning to code well, etc. - so having the ability to refactor as you go and help educate other developers is more important than getting it right up-front.
If the team feel pressured to churn out new features, though, they'll very quickly abandon the technical debt. It can't be seen or measured easily, and as such is usually the first victim of any pressure.
A PM's responsibility in this situation is to push back, educate, and help the business cut scope instead.