How to build up Technical Debt?
Sunday, April 29th, 2012Classic case
A project ran to build a system for capturing customer details, soon after the delivery another project build the customer update system.
Now, this is just one of many ways of building technical debt, but really the culprit is the organisational thinking behind this phenomenon. What has happened?
The analysis
Ignorance is NOT a bliss – as it would turn out during the acceptance test, when customer details were captured, but they could not be modified or updated later. However, the project was coming to a close (it was already in acceptance test) and budget was running short as well. So what does one do to fix this situation? Run another project to build another system to update customer records.
Why not extend the current system on the next project, why build a new one? There could be many reasons for this. One possible reason stems from how IT projects are accounted for. New build becomes an asset (capital expense), but updates don’t (operational expense). However, this is not entirely correct. Updates that deliver new capability or functionality can become assets, but that’s too complicated to understand or to split project costs accordingly, so it is easier to launch new project for a new build and new asset.
So there you go, the organisation ended up with two systems instead of one; although it probably could have spared that single one too if the first project took the effort to look around the rest of the organisation for an existing solution.
Who cares?
Surely it is not such a big deal, it happens all the time.
Sarcasm aside, in fairness, it the big scheme to things projects are these are only a small drop. Even if the costs are doubled (two projects) and the duration has doubled (worst case) it won’t break the organisation, however this is where the spiralling starts pulled by two forces:
- Projects running late – especially in IT – is almost the norm, so projects do not even bother with much upfront planning and preparation (called the pragmatic approach) and trying to keep scope to absolute minimum. These poorly conceived projects deliver poor systems even if execution was perfect.
- Exceeding project costs are not a problem either because the business will “sweat” the assets anyway to recoup the loss and to squeeze as much out of it as possible. This is how those poor systems survive and stay around for long.
The result: technical debt.
Let’s hope they do not find that they need to delete customer records one day…


















