Have you successfully applied risk management strategies to technical debt? Do you find that leadership is more willing to address tech debt when it’s framed as a business risk?
Sort by:
Yes, risk management in essence is about identifying and monitoring risk, and then either take action to avoid it, take action to reduce it, or pass it on to someone else (usually at a cost and with arbitrage). So risk management practice is an excellent governance and analytical practice to apply to technical debt. But the first action (avoid it) is actually critical for technical debt. These decisions get taken in poor or lost political battles in governance meetings or management meetings. Or they are heat of the moment decisions by a solution providing team. Making the identification of technical debt ***risk*** during design and development is actually a critical practice for architectural review boards and project or product teams. For example, adding an interface, taking on an add-on product, or leveraging custom software code, are all things that can be identified before they happen and avoided. But listing them in the risk registry under technical debt category is critical. Which leads to governance and technical management discussions on reduction....
Technical debt is not easily insured or transferred, but one can leverage political might by putting accountability where it belongs. I have indeed, and very unfortunately because it is a last resort, allowed for technical debt to occur, but under the responsibility of the business team that lobbies for it. E.g., "Yes, you can buy that hairy beast, but having been warned it won't work, we cannot provide support or improvement process. Good luck and should the thing not work, we are more than happy to start over with the right solution." That is a form of risk transfer. Not a good one as internal conflicts are unavoidable but never a welcome thing.
As others have pointed out, this requires a financial estimation and visualisation technique in addition to the management practice and incorporation of corporate governance. For all technical debt (before it occurs!) put a price tag and a probability on it.
Yes and yes. At a past position, we had mounting delays and higher costs due to technical debt in our main software. When we highlighted the potential impacts like customer dissatisfaction and longer time-to-market for new features, leadership quickly realized it was a serious operational risk. This shift in perspective helped us get the resources and support needed to tackle the technical debt effectively.
We do assess the risk of technical debt as part of our enterprise risk management practice.
When we address funding from risk perspective, it helps to get alignment from leadership.
1. Risk can be revenue or supply or Cyber or Compliance to prioritize investments.
2. Continuity/sustainability risk helps to justify legacy system upgrade/replacement strategy. Putting in $$ terms value drivers & levers will help.
3. Cloud first strategy to minimize technical debt.
I have indeed applied them successfully and failed as well at another time.
The times when it was a success were because the CxO understood that tech debt would be the company's demise ( We were a SW factory ), because we were prioritizing the present instead of the future. It was a medium-sized company, and most of the CxO had a great understanding of tech strengths & weaknesses. We created a risk administration matrix that allowed us to understand risks by their severity, the actions that we needed to do to minimize/mitigate the risk and who were the root cause of that risk.
The time it failed, it was a startup that valued more present the future, since we were constantly changing to obtain user growth vs anything else. So tech debt wouldn't be considered a business risk.