The Interesting Concept of "Change Debt" and Its Cost

Yesterday I saw a blog by some friends of mine at Broadgate Consultants about technical debt . This is not a term I had been aware of before, but maybe that is because my focus has been on business change rather than IT.

When I mentioned it at a meeting later in the day the response I got was "Oh yes. That is a hot topic right now!" So while it doesn't quite meet my rule of three (ie if I hear something three times then I need to know more!) it seemed to warrant inspection.

Put simply it would appear that technical debt is the shortfall (relating to technology and its operation) between what should have been done to maintain an organisation's integrity and standards and what was actually done to get a change in. The sort of things are completing full documentation and procedures, elements of testing that may have been cut out or glossed over, issues that remain uncleared other than by the use of "workarounds", the use and acceptance of non-standard software components because the "right" ones could not be made to work as required, etc.

I am sure most project managers will recognise these. They are the things that someone should come back to and resolve. If you are in a mature change environment (or lucky) they will be detailed in the project closure report along with assigned responsibilities, but I see this less and less as the pressure is applied to get on with the next urgent change.

The problem is that these "debts" start compounding leading to operational inefficiency and passing an additional load to future change initiatives who may have no choice but to clean up the past problems.

If I understand it correctly, one might argue that the ATM outage that RBS suffered was as a result of "technical debt".

The blog reports "there are several theories and computational algorithms out there" that are supposed to calculate the debt and indeed the "interest" (ie price paid as a result of the debt). These sound fascinating and I may indeed look into them. I am sure the intent is good, but life has taught me to be wary of trying to reduce everything to a number that may convey a false sense of accuracy or precision.

What was more interesting is that the application of this is so much wider. I would suggest that we should not talk soley or specifically about "technical debt", but rather about "change debt" ie ALL the shortages created when implementing change of any sort. The principle of compromise and shortcuts is common to all change, often hidden behind the terms "pragmatic" and "tactical"; I have used them myself.

With a staffing model that is predominantly one of a stable complement of permanent employees, those creating the debt are often around to pay the interest. This is not true of contractors and consultants and can often be seen in their approach to issues. What is more concerning is that the shortening of permanent tenure in many organisations. Think about how many people are in the same job three years running? I would argue very few; either they have moved to a new organisation or role or the role has changed around them. This leaves the "interest" to be paid by others.

I would suggest that this can be seen vividly in many Investment Banks.

So what?

Well, my "so what?" is to start thinking about how the concept of "change debt" impacts my thinking on the delivery of business change? It definitely has a part to play at least by encapsulating and articulating an existing problem such that others can better understand the issue.

It will be interesting to see where the "third" reference crops up and I suspect it will be one of those topics I find myself musing over as I tend my autumnal bonfires. (I blogged before about The Strategy Bonfire and how some of my best thinking is down while lost in the dance of the flames.)