The 6 Key Principles to Technical Debt Risk Management
Following the ‘Organising for Digital Delivery’ report from the Digital Economy Council, there has been recent press coverage of the issues facing the public sector in managing the legacy computing estate. This is a challenge we have been addressing with both public and private sector clients.
Most large organisations, regardless of their sector, have a large amount of technical debt that has been accrued over many years. On top of this, most of these organisations do not have a good handle on where their technical debt is and struggle to understand the risk associated to the technical debt that they are carrying.
Many have an awareness that they have some mounting technical debt, but find their hands tied when trying to do something about it as it can often be a topic that does not list highly on the senior leaders or decision makers within organisations. Therefore, finding the time to discuss these topics or to secure funding can be difficult if not done in a smart way.
Our approach is to turn the conversation about technical debt on its head and away from focusing on the technology side and instead creating a common language to discuss the issues in business terms, referring to Business Services and applications as opposed to bits of infrastructure and operating systems.
Improving the conversation on Technical Debt within your organisation
Having a set risk tolerance level for your technical debt is not only critical from an internal audit or regulatory perspective but this can also be a powerful mechanism to manage the right decision making when it comes to application or infrastructure remediation.
By discussing the impact of your technical debt in terms of the risk of how it can impact the important business services within your organisation it immediately garners the interest of the key decision makers as it enables them to relate to the problem at hand. Having established risk tolerances for technical debt that you can constantly assess against to highlight breaches takes this one step further as you once again remove the need for any inefficient conversations around qualifying the impact of technical debt and replacing this with getting directly to the key discussions on the decisions that need to be made. Actually defining and setting a relevant and actionable risk tolerance level, however, can prove to be very challenging.
Having a set risk tolerance level for your technical debt is not only critical from an internal audit or regulatory perspective but this can also be a powerful mechanism to manage the right decision making when it comes to application or infrastructure remediation.
By discussing the impact of your technical debt in terms of the risk of how it can impact the important business services within your organisation it immediately garners the interest of the key decision makers as it enables them to relate to the problem at hand. Having established risk tolerances for technical debt that you can constantly assess against to highlight breaches takes this one step further as you once again remove the need for any inefficient conversations around qualifying the impact of technical debt and replacing this with getting directly to the key discussions on the decisions that need to be made. Actually defining and setting a relevant and actionable risk tolerance level, however, can prove to be very challenging.
The challenges with setting a technical debt risk tolerance
- How do I ensure that it is relevant to my organisation?
- How do I regularly report on this once established?
Wavestone’s approach to defining technical debt risk tolerances
A fundamental approach that we champion when it comes to technical debt risk management is that whatever you do must be rooted in solid foundations of data-driven and quantifiable outputs. A round of qualification of the quantifiable results should be overlayed on top of any reporting that is produced as data can only go so far in telling the story. This can be achieved via the following principles:
Underpinning everything is the quality of the configuration data within the CMDB or other data sources. It is very common for the quality, completeness and consolidation of configuration data to be poor in a given organisation so it is important that when you are defining your risk tolerance level you must ensure that it is actually achievable in the short, medium and long term. It is important that through this process any data gaps or issues are highlighted and fed back into the source systems of record.
It is important to have clear messaging on the risk scoring methodology to ensure that the results presented are well understood.
It is important to focus your risk tolerance and reporting on ‘getting straight to the chase’. What are the current and future issues, what impact can they have on my business and what can I do about them.
For the reporting to live within the organisation it is important to select the correct tooling to produce the reporting. This needs to be aligned to organisations technology strategy and designed in a way that is manageable for the BAU teams to operate on a regular basis.
The nature of technical debt means that as time goes on, more and more debt is accrued. It is therefore imperative to not only show the current issues the organisation is facing today, but also present the pipeline of future technical debt issues to enable the proactive management of these.
There is likely to be a number of remediation projects in place in an organisation that will either directly or indirectly address the technical debt profile. It is key to have an accurate picture of the impact of these projects in order to create a consolidated view of the ever-changing technical debt profile.
Bringing these components together can enable your organisation to create an efficient, proactive, dynamic and ultimately powerful technical debt risk management machine as part of your day to day operations.
This will not only save you time when it comes to gathering, processing and presenting the data and information on your risk profile but will expedite any meeting or discussion on the topic of technical debt to the key conversations and/or decision points around whether new funding is required, existing remediation programmes can be expedited or whether items can be risk accepted.
It will give you the power to view your entire technology estate and quickly compare and prioritise the key problem areas you have today and will have in the future, ultimately leaving you with the feeling of control over your technical debt.
Related Insights
Federico Chiarelli 
Simon Weber 
Federico Di Mauro 
Keith Worfolk
Samuel Lyou
Tom Lawrie
Steve Glasgow
Pallvi Gautam