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 would start by **Identifying the ROI that the technical debt delivers** and discussing this with the business. If you can describe both value work and what John Seddon calls 'Failure Demand' in the same terms and using the same metrics then you can agree how to split your capacity across them.

**Example - Architectural Refactoring**

We have a piece of configuration information which is baked into an app (I know, I know...). This config can go unchanged for weeks and then suddenly need changing. 

If the config doesn't get changed then ads stop appearing in an application and we stop making revenue from it.

The quick and dirty solution is to change the config in the code and redeploy. This is repetitive and error prone and ultimately not sustainable.

The sustainable solution would be to factor our the config from the code and provide a mechanism for changing it independently from the code. This will take longer the first time round but will then make future config changes much quicker and less error prone.

Guess which one we have done twice already? That's right the quick and dirty. This is because the ROI on the feature is immediately visible or rather, the Cost of Delay were the work not to be done is very high.

The sell we have to make to the business is, let us spend time refactoring this to address the technical debt. That way, next time we need to change the config it will be quicker than it currently is, so quicker ROI in the future, but we will need to take some capacity away now to address the technical debt. It is deferred ROI.

**Example - Architectural Refactoring as complexity increases**

Sometimes it is hard to describe the technical debt to the business, to them it is just an implementation detail or something you should not have accrued in the first place. 

For example, as something grows in complexity it requires refactoring. In this case I do one of two things. 

I either cover the cost of the refactoring in the delivery of the feature which has required us to go back and look at the code in question. I always call this out to the business either to tell them that the feature will take longer to deliver than similar features have in the past, because we have reached a point where we need to refactor. 

Again I describe this to them as deferred ROI. There will be a greater upfront cost but by doing the refactoring now, future work in this area will be cheaper.

The other approach I take is to treat the development team as a customer of itself and reserve a percentage of capacity, agreed with the business, in each iteration for reduction of technical debt.

**Example - Platform Upgrade**

For the example you give of upgrading to a newer platform I would again look at how you can describe this in terms of ROI, or impact on ROI. 

If the existing platform is no longer supported by the vendor then the business is exposed to the risk of defects discovered in that version of the platform not getting fixed and so impacting on business functionality which depends on it.

This impact will be an increase in failure demand, that is, customers will be less able to get value out of what you as a business provide as problems with the underlying platform are getting in the way. This can be articulated as lost revenue, or potential lost revenue so the ROI is to upgrade the underlying platform.

Prioritising such an upgrade can again be done by looking at the Cost of Delay. If you were not to upgrade the platform would there be any impact on your existing products and services? Would it prevent you from launching new ones? 

If problems in the existing platform are generating failure demand now then the Cost of Delay is high and you have a compelling ROI based argument for doing the work sooner rather than later. 

If you are currently unaffected by problems in the existing platform but need to upgrade in order to add new functionality then the ROI of the new functionality will determine the ROI of upgrading the platform.