Question: In real world, business initiatives always take higher priority as there are associated ROIs and deliver something tangible to the users. But there are technical initiatives and projects that need to be done to keep up with the different versions of software, upgrading to a newer platforms, architecture re-factoring etc., 

1. How can we plan, prioritize and manage such competing initiatives?
2. Is there a model to quantify technical debt and its impact to the business?

Answer: 
**Technical Debt isn't a PM's Responsibility:**
-----------------------------------------------

As a project manager, the short answer is, you don't. This is really a job for the technical team, which includes functional managers and the actual developers working on the project. If you're doing project management correctly, then you should be getting all of your estimates from the developers themselves. 

However, if it becomes a noticeable detriment to productivity, it may become a project management issue.

**Focus Primarily on Business Goals:**
--------------------------------------

However, here is where this can get tricky and why sometimes it is helpful for a project manager to have enough experience in the subject matter to know the difference between a good estimate and a bad estimate. New developers, fresh out of college and eager to apply their newfound knowledge, will sometimes be the first to suggest a complete rewrite to the database layer because it's a cluttered mess. 

Sure, the job may have been to write a feature that lets the customer service team sort customer data by creation date, something that helps the team improve retention efforts, but this eager dev attempts to take the issue scope to another level. By prioritizing technical debt the wrong way, the actual feature being developed is removed from focus, and management is justified in stopping this in its tracks. If revenue isn't being generated from a development operation, then there's a problem with the balance.

**Pay Back Technical Debt One Piece at a Time:**
------------------------------------------------

As a developer, I've worked with some code that I've had a pretty strong opinion about. When I told my project manager about it, he said he didn't care. He didn't want to think about it, and that it was my job to include this in the estimates in a way that didn't conflict with business goals. I've been doing that ever since, and I manage my own technical debt while still keeping management happy with the progress. In many cases, it actually makes the development faster because the impediments that would normally slow me down are removed.

Ultimately, the solution to managing technical debt and balancing it with company initiatives is to break it up into manageable, bite-sized chunks. If the database layer needs a rewrite, start with the new feature. Add it in a manner that scales, and then next time a new feature is added fix a little bit more. You should only commit to paying back a small portion of technical debt so that it doesn't stand out as a red flag to management, similar to how you should only pay down enough of your debt to where you can still pay your rent and eat your meals. ;)

In short, the way to balance technical debt against business goals and initiatives is to [refactor as you go](http://www.codinghorror.com/blog/2009/02/paying-down-your-technical-debt.html). The code will never be perfect, and that isn't the goal. Instead, the goal is to manage the technical debt to keep it from becoming an impediment, because when it impedes progress and becomes a threat to the project, then it *is* a project management issue.
I know there's an answer for this and I mostly agree with @Lunivore and @jmort253 answers but I thought I would chime in on how I have seen and heard technical debt handled?

In our company we recently started trying to allocate dedicated week-long sprints that we focus on technical debt. Unfortunately this hasn't worked super well when there are certain features that go over the course of multiple sprints, in which case it's impossible to prioritize low-priority fixes vs features that need to ship.

Kind of building on above, I believe **it's important to show and communicate communicate how technical debt is affecting the team's velocity**. This naturally starts with being able to know what your team's velocity is, and then showing it is simply a matter of process.

Recently we have started costing out all issues with [story points](https://agilefaq.wordpress.com/2007/11/13/what-is-a-story-point/) (whether it be features and the small tasks associated with features, or just nitpicky bug fixes) everything is costed out with a certain value. After a period of time, our manager is now able to give a ballpark range of how much bandwidth each engineer has and how much time they can allocate to fixing certain bugs. When we first started this, it was naturally really bumpy because we would forget that there was more to a task so its generally better to overestimate than underestimate. 

After some time though, we were able to give a good sense of what we can fit into the sprint and what we can't and we have been given dedicated time to fix bugs that makes sense (hey you have this feature but from what was costed out you seem to have time for some small bugs?). I think we are still working on a good rhythm and we have juggled between alternating people to fix bugs or just dedicating time for the entire team (especially useful if you have new devs) -- maybe I'll chime in again when we have narrowed that down but we have definitely seen an improvement in how fast we do things when given the time to fix the things that no one sees and it's nice that everyone can "see" it too now.

In regards to responsibility, I don't necessarily think it's the PM's responsibility? Our **engineering manager and tech lead drives managing technical debt** while our PM drives the projects and timeline of features. That being said, **it's important there is dedicated time for the PM and the manager to coordinate and set expectations**.