"Technical debt" is a nice metaphor for discussing the long-term costs of some project decisions.
For example, imagine that you are building a complex website that has a tight commercially driven deadline (e.g. it must be ready to do business by Thanksgiving/Christmas). The way you would ideally like to do the project is not compatible with that schedule, so you decide to develop faster, deliberately choosing a solution that is less easy to support in future, is less extensible, less robust, requires more maintenance, or suffers some other trade-off. Just as if you had taken out a loan to finance the project rather than take it out of revenue, you are committing yourself to future expenses (cash, staff time, more imminent replacement of the system) in order to buy short-term progress. This might, of course, be entirely satisfactory if the profits from being live by Thanksgiving are attractive enough.
Of course not all debt is deliberate - just as you can work up a big overdraft by spending carelessly, a poorly run project could get deep into technical debt by inadvertently doing work that it will be difficult to support or extend.