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:
Oldest
Director of IT in Manufacturing2 months ago
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.
CIO in Services (non-Government)2 months ago
We do assess the risk of technical debt as part of our enterprise risk management practice.Global Chief Cybersecurity Strategist & CISO in Healthcare and Biotech2 months ago
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.Head of Transformation in Government2 months ago
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.
1. If the company is more focused about operations, I did calculate the risk and expressed in $$. So if the system is down for a week the impact will bet $X Milliion of lost sales and the probability of failing is x%, by multiplying those two I get the $ exposure and it can also help prioritize the legacy systems that provide a higher risk.
2. If the company understands cyber security, I highlighted the cyber exposure and risk of technical debt. We can also add some $$ calculations to support the recommendations.
It is easier for the business to understand numbers. Key recommendation use the finance / operation team to provide the impact $$ .