A large part of what I do is quality assurance for our clients. I help them understand where their solutions are in the *-ability spectra and I help them lay out roadmaps on how to move from where they are to somewhere new.
Technical debts can be horrific
The hardest situation with technical debt I’ve been in was a solution one of our client was building with another vendor. They had spent a lot of resources in terms of time and money to replace an old system, built 2001, with only one 70-year old man alive that understood it. The reason I and my team was brought in was because of failure to deliver and my client wanted to understand if they should bring the solution into their own care and finish it themselves.
Doing the investigation we discovered something very unsettling;
The core solution was built in Visual Basic 6.
So to replace an old dead technology the vendor introduced another old dead technology. My client had correctly identified their old platform as a risk to the business, their vendor hadn’t identified theirs as such. Or as I was told:
“There hasn’t been a reason”.
This happens everywhere. This is not a unique situation.
Technical debts are really business risks and issues.
Managing technical debt is hard. Knowing what to do when is a huge challenge. Especially in the face of the two speed IT where business demand IT to respond quickly to new requirements. What do you prioritize? How do you argue for your prioritizations?
To help me with this I use a simple model for technical debt where I call manage it as risks and issues. The model is quite easy to use and the real trick here is to use the vocabulary of issue and risk management; for the business this is what it boils down to.
It is a simple model and the important thing for the business are “Business impact” and Impact”. If you can quantify this you will have a much better conversation with the stakeholders.
There is a lot of organizations that have great models for this. It all boils down to how risk savvy the company is. How far into the future they try to look and what importance they put into their IT-systems.
This model is really simplistic. It won’t stand up to the risk management requirements in a fortune 500 company. But if you don’t have a model in place, this can be a great place to start.
Manage your technical debts as risk
The main point to take away is that technical debts are not debts, they are risks and should be managed as such. When you do, you will have a lot easier arguing for what you know is the right decision. Even in the face of two-speed it.