samx18.io

Managing The Technical Debt Risk

Managing The Technical Debt Risk

13 January 2012

The technical debt metaphor was first coined by Ward Cunningham in 1992 while drawing a comparison between the technical complexity of IT projects and debt in general. There are multiple definitions that exist and if I had to put in my own, here’s how I would lay it down.

“When technical work is delayed knowingly or unknowingly either to meet specific deadlines or  to save time and/ or effort which must be eventually done a technical debt is incurred.”

Like debt in general, where it is incurred to meet valid business objectives. There may also be valid cases where this technical debt is incurred for perfectly valid business reasons.Regardless of the reason, debt eventually needs to be paid off and a technical debt is not an exception as well.

However, unlike the financial debt, the technical debt is almost impossible to measure accurately.You do not have specific interest rates or payment schedules but nevertheless it is like any other debt and needs to be paid off (except in a few rare cases which we will touch upon later)

So How Does a Project Incur Technical Debt?

There may be a variety of causes but a few prominent ones could include

Why is Technical Debt a risk?

If I were to rephrase the question it would be why is technical debt a risk and not an issue ? After all if technical debt has been identified and recognized, it has to be paid off. In other words it has already materialized into an issue and hence should no longer be classified as a risk alone. However for now I am still inclined to manage this as a risk as I am still uncertain on its impacts and the cost to get to pay off this debt. Also often overlooked is the opportunity cost of the technical debt or the ‘positive’ risks or in simple terms just plain opportunities.

Identifying The Technical Debt

Like with other project risks, risk identification is the first step here as well. Your ability to proactively identify the technical debt early on will directly influence your ability to effectively manage the technical debt. Identification can be both proactive and reactive.

Technical Debt Assessment

Risk assessment traditionally has focused on two key variables, the severity of the risk and the probability of its occurrence. This is mathematically represented as ‘Severity * Probability’. Assessing a technical debt is a little different. The variables that play in here include

The Technical Debt Risk Strategies

Once you have identified and assessed your technical debt successfully it’s now time to have a strategy or a plan to manage these.

Avoid The Debt

If you can avoid incurring technical debt altogether in the first place, that would be an ideal scenario, but an ideal scenario is anything but common. That said, there are a certain options that the project team has like adopting for a standardized solution as opposed to a highly customized solutions will significantly reduce the probability of incurring technical debt.

Mitigate

There is a three phased approach to this strategy

Acceptance or Retention

There may be a rare scenario where you will probably end up choosing to accept the risk related to technical debt and the associate cost to pay it off. In such scenarios a trade-off is made between the risks associated with the technical debt and the cost associated to pay off the debt. These scenarios could include

Again these are rare scenarios, which need to be evaluated carefully before adopting a retention strategy. Lastly the timing and decision to pay off a technical debt will vary with organizations and departments. This will also depend on the tolerance level these organizations and departments have towards the technical debt as well as the trade-offs involved in paying -off the debt.

comments powered by Disqus