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.
Fascinating discussion, and very relevant to me. I believe that technical debt is a PM's concern. 

One could argue that a project is a coordinated effort to produce a specific outcome/change; if the project produces the outcome, the project is successful, and technical debt doesn't enter into the equation. But I think that is shortsighted; at a minimum, the PM is obliged during the closeout procedures to document lessons learned and update the corporate process assets. Technical debt should fall into that category. Beyond that, the PM has an ethical obligation to do the best for the company within the constraints, and leaving a company saddled with unknown, undocumented technical debt is unconscionable. 

Alternatively we could consider that technical debit is a quality control problem. Technical debt is a aberration that falls within control limits, but if it can be eliminated, the quality (and presumably value) of the product rises. 

Multiple ways to look at the problem, but each of them convinces me that although the PM can ignore technical debt, prudence dictates that the PM estimate, document and manage technical debt.

I think the key challenge is establishing the value of technical debt. I think that companies/industries/teams should establish reference values and refine as they go. Just as the PM is obliged to assess & estimate the impact of every proposed change on schedule/scope/quality, the PM should assess & estimate the impact of technical debt. I think that an interesting corrallary to @Jmort253's question is "Change proposals go to the CCB. Who is accountable for changes that are intrinsically outside the scope of the project?"

As I said, excellent, thought provoking question.