Technical Debt Assessment: How to Measure It for CFO Buy-In

Introduction

Most of the time, you won’t see a line item called ‘Technical Debt’ on the balance sheet. You’ll just see its effects: on application maintenance, lost productivity with delayed projects, production outages, fixing security issues, suboptimal infrastructure, and engineering hours consumed to maintain it.

These challenges are something most CIO/CTOs know about. Applications take up most of your team’s time, take longer to release, and modernizing them takes more time than initially thought. Due to Technical Debt, your organization may not realize how much its applications are costing it.

What about the CFO? How do I quantify this debt? What are my losses if I continue to have this debt? What can I gain financially if I remediate this debt?

To help your CFO ask these questions, you’re going to need more than a static code analysis tool or list of applications. Understanding where you can quantify your technical debt and what areas of your business can be quantified is imperative when evaluating technical debt.

You can use the framework below to calculate how much your applications cost your business today and understand if remediating those applications would be worth the investment.

By building out your technical debt, you can begin to compare those solutions with other opportunities.

What is Technical Debt, and Why Should CFOs Care?

There are many factors that can lead to Technical Debt. When your applications have characteristics that cost you time or money, they may have Technical Debt. Your tech debt could come from technical decisions made in the past, old tech, lack of automation/testing, too many similar applications, etc.

Technical debt can have a similar principle to debt and interest. But don’t take the correlation too far. Technical debt isn’t going to be considered as debt on your books, and there may not be a dollar value for it.

When talking to your CFO about Technical debt, there are three things to keep in mind.

• Principal of Technical Debt: Estimate your cost to remediate the weakness you have found.
• Interest of Technical Debt: What are you paying each year to maintain this debt?
• How does this affect my business: If I were to continue to have these issues, what would happen to my business?

CISQ has done some work on calculating your principal of technical debt here.

Once you know the cost to fix the issue, you can begin to build out the ROI story for your organization. Some debts will cost you money to remediate, but the principal of interest is very low. There may be other applications with a large remediation cost that you know you are getting rid of in 6 months. Knowing the principal and interest of your debt will help you and your CFO understand if an application is worth investing in.

Remember you are not just looking at how much it will cost to fix an issue but the consequence of not fixing it or when to fix it.

Why Technical Debt is Hard to Quantify

As you’ve seen, your organization probably has many metrics around applications. Whether it’s from Static code analysis, applications you are tracking in your APM tool, or other forms. None of these will give you a big-picture view of your technical debt.

Technical Measures Do Not Automatically Translate into Financial Impact

With tools, you can measure the complexity of an application, how old it is, or test coverage. All of those numbers can show you where there are weaknesses in your code. But it doesn’t tell you how much money your organization is losing by having those weaknesses.

There might be an application with a high amount of complexity, but that may be OK if the business is getting no incidents or lost revenue from it.

Costs are Distributed Across Multiple Budgets

As you look at applications, you will notice there are many factors that go into maintaining your technology landscape. Cost to fix technical debt may fall under many categories such as App Support, Infrastructure, Cybersecurity, Engineering, Incident Response, and Technology Transformations.

You may find yourself double-counting some of these costs or not having the big picture on what it costs to maintain your applications.

Benefits are Often Counterfactual

As we mentioned above, you will have areas that cost you money today to maintain your applications. But some gains won’t be known until they occur. Maybe you reduced the cost to run your infra by 30%; you can quantify that. How about the new product you were able to deploy because of the improvements you’re making? That’s hard to put a dollar amount on.

There is a difference between cost savings and cost avoidance. Your CFO will want to know the difference when deciding if this is worth the investment.

Not All Debt Needs Immediate Remediation

Having technical debt isn’t a bad thing. Sometimes you’re accepting trade-offs that make sense for your organization at that time. But how do you know when it’s time to fix that issue?

You’re going to want to measure how much damage you’re causing yourself and what it will take to remediate that issue. You’re going to want to continually evaluate if that issue is getting worse or better. More info on tracking your Technical Debt from the UK Gov can be found here.

How to Measure Technical Debt: Five Measurement Categories

Below are five ways you can measure your technical debt. These metrics will allow you and your CTO/CFO to have a conversation on whether this is worth fixing.

Remediation cost

As you build out your technical debt, you want to know how much it will cost you to fix that issue. This can include hours to remediate code, refactoring an application, updating dependencies, writing documentation, and deploying your solution.

Once you know the number of hours it will take to remediate that issue, you can multiply it by your average hourly cost.

Estimated remediation cost = Remediation effort × Fully loaded delivery cost

If you had an application with 800 hours to remediate, that would cost you $700/hr to deploy your solution. That would equate to 800 x $700 = $560k to fix that issue.

You can use this number as a benchmark to see if your estimates are close to the real-world cost. This can be used for a quick, high-level estimation to determine what your Technical Debt will cost.

Recurring Cost of Carrying Debt

Now that you know how much it will cost you to remediate your debt, let’s look at what that debt is costing you today. Some things to consider when calculating the cost of your debt each year:

• Maintenance on applications
• Manually working around issues
• Infrastructure spend
• Time to recover from incidents
• Extra effort to test/release applications due to technical debt
• Maintaining specialized skill set for a technology

As you go through your cost structure, find ways to correlate hours with technical debt. If you aren’t sure of your estimates, make sure to communicate that to your leadership team. You may have to assume some costs that correlate to your Technical Debt.

Delivery Friction and Opportunity Cost

Applications can cause your engineers to spend more time maintaining existing functionality than creating new features. Understanding how your engineers are spending their time will help show if your debt is impeding your business.

You can measure productivity loss with many different metrics. Lead time to change, how often your teams are releasing, and failing releases. If your team spends most of its time fixing bugs, you may have Technical Debt. Below are a few examples.

• How long does it take your team to change your code and get it to production
• Frequency of deployments and fail rate
• Time spent maintaining your application vs. building new features
• Bugs your teams spend time fixing due to poor test coverage or tightly coupled dependencies
• How long does it take you to add new products/features/services to your organization

If your organization can reduce some of these metrics, it may be a sign that you should invest in your Technical Debt. Remember, if you can free up 100 hours per engineer to work on a feature that was stuck because of Technical Debt, you’re gaining 100 hours of productivity per engineer. This doesn’t mean you are saving $100k in hours, but you’re giving your engineers the ability to deliver value to your business faster.

Operational and Security Exposure

Technical Debt can lead to production outages. There may be patterns in your data that show how much money your incidents cost you over time. Once you have your incident cost, you can start to build out an average.

Some examples to measure would be.

• Major incidents that led to lost revenue
• Time it took to recover from an outage
• Using out-of-date software or dependencies
• Security vulnerabilities that took a long time to patch
• Lost customer data
• Inability to recover systems

Once you have your historical cost from these examples, you can start to project future cost if you continue to have these issues. Remember, it’s just an estimate, and you will have to build that assumption out to your leadership.

Don’t oversell your cost if an incident occurred in your worst-case scenario that could have happened. You want to make sure you have a solid plan on why this will help prevent that from happening again.

Strategic Constraints and Application Fitness

Some Technical Debt can impact your ability to run your business. If you have applications that are limiting you from expanding your business, you may have some technical debt. Perhaps your application can’t scale with your users or isn’t compatible with new platforms you’re trying to implement.

Once you find that your Technical Debt is impacting your business, you will want to quantify the risk. Understanding your application’s business importance and what it will take to keep that application alive. How many dependencies rely on this app, what support status does your application have, and how much life do you have left in this app?

These are some of the questions you will want to evaluate when discussing if it’s worth fixing your debt with your business.

A Technical Debt Framework CFOs Can Use

When building your framework, remember you’re looking for something your organization can maintain over time. You don’t want to build something too complicated that will be difficult to calculate your debt with.

Below is an example of a framework you can use to build your technical debt out.

Step 1: Establish the Application Portfolio Baseline

Building a baseline of your applications is a great way to start measuring your debt. What applications do I have, who owns them, are they mission-critical, and what does it cost me to run these applications?

Once you have that list, you can start building your Technical Debt out. Many organizations will have architecture diagrams that can help with this or use a tool to scan your code.

Step 2: Identify and Classify Debt

List the weaknesses you have in your applications. It can be helpful to have your developers involved when identifying these weaknesses. You may have an application with a dependency that you no longer support or have too many similar applications that are tightly coupled together.

Step 3: Estimate Cost, Risk, and Business Impact

Once you have listed out your weaknesses, you want to start quantifying your debt. You can use some of the metrics above to help with this step. Make sure to define what each metric means to your organization so everyone is on the same page when building your estimates.

If you’re not confident in your estimate, show a range of numbers that you think will apply to your organization.

Step 4: Prioritize With Transparent Criteria

Now that you have calculated your debt, you want to know what’s important to your organization. Below are some questions you can ask when trying to figure out what to prioritize.

• How does this affect my business?
• What does it cost me to fix the issue?
• What am I risking by continuing to have this technical debt?
• Can I fix this issue within my timeframe?

You may find out that some of your debt isn’t going to be fixed in the near future. That may be ok if you know you are retiring that application in the next year or it has minimal business impact.

Step 5: Compare Remediation Options

Once you have identified your top debt, you want to look at how you can reduce that debt. Each solution will have its own costs that will need to be calculated. By knowing the cost, you will be able to build an ROI on how much this solution will save you.

Step 6: Track Results Over Time

After you have chosen your solution, make sure to track if your efforts are reducing your technical debt. Keep the same measurement techniques that you used when calculating your debt. Now you can see if your efforts are paying off or not.

Similar to CISQ, they recommend building out a list of your Technical Debt and measuring how it’s affecting your business. Once you know what you are trying to solve, you can measure if your solution is working. More information on SEI can be found here.

Turning Technical Debt Into a Financial Business Case

Now that you have a Technical Debt framework, you’re ready to build a business case for your leadership team. To help with your ROI, there are some things to keep in mind.

Below is an example of how you can calculate the ROI on one of your technical debt solutions.

The above numbers are just an estimate and shouldn’t be used as an industry standard. When building your business case, you want to make sure you’re looking at what you can realistically reduce your annual costs by. In this example, we could expect to lower our cost by $150k/yr. So the other $100k may continue to be spent to operate this application.

Using this example, we know our cost to fix the application is $600k. By lowering our costs by $150k each year, it will take us 4 years to see our money back on the application ($600k/$150k = 4yrs). This is just a rough example of how to calculate your ROI. You will want to involve your finance team to help with this.

There are also 1000 hours that were freed up by removing that Technical Debt. Unless you know how to convert those hours to saved money, don’t include them in your business case. Those hours can be used for anything your engineering team wants to spend them on.

There are many factors that will play into your decision to fix your Technical Debt. Make sure to understand what you’re trying to fix and what benefits you are trying to achieve.

Build Three Scenarios

A stronger business case compares conservative, expected, and upside scenarios.

• Conservative: Lower cost removal, higher remediation expense, and delayed benefits.
• Expected: Benefits supported by engineering estimates, historical costs, and a credible delivery plan.
• Upside: Additional benefits from faster delivery, reduced incidents, or improved platform capabilities, clearly identified as less certain.

This gives finance leaders a way to evaluate the investment under different assumptions rather than relying on a single optimistic forecast.

Keep Savings and Risk Reduction Separate

Make sure to differentiate the money you’re saving and the money you’re preventing from being lost. Your CFO may ask you what the risk is if we don’t fix this issue. Understanding the amount you could potentially lose from your incident cost can help them understand the impact.

By understanding what your applications will save you each year, you can begin to build a stronger business case. Don’t try to over-sell your solution by adding extra hours or assumptions into the numbers. Your CFO will want to know if those numbers can be backed up by real-world data.

A CFO-ready Technical Debt Scorecard

Now that you’re measuring your technical debt, you can start to build a scorecard. Here are some metrics you can use to help build your scorecard.

Make sure each one of these has a definition of how to calculate it and who is responsible for that metric. You may want to avoid putting a number score on your technical debt. It can be hard to measure, and you may end up comparing metrics that don’t relate to each other.

Common Mistakes that Weaken CFO Buy-In

Having numbers on what your debt is costing you is great. But remember the pitfalls that will hold you back when presenting to your CFO.

Showing your code health will not be enough. You need to explain to your CFO what the business impact is.

If you’re showing 1000 hours as saved money, that may not be accurate. Find ways to convert those hours to money saved or what they can be used for.

Avoid showing industry benchmarks unless you know they can be applied to your organization. It’s best to build your own metrics so you can show your leadership how you came to that conclusion.

Make sure to calculate the cost to remediate your Technical Debt as well. Don’t forget about testing your solution and moving to production.

Know what debt is worth fixing and what debt you can live with. Some debts may not be worth the cost to fix.

Always measure if your efforts are reducing your technical debt. If you know what your problem is, you will want to know what your solution did to improve that problem.

How Hexaware Can Support Technical Debt Assessment

Hexaware currently has solutions in place that can help your business begin to measure your technical debt.

Our whitepaper Technical Debt: It’s Just Not Code. goes into more detail on some of these topics. By finding weaknesses in your code, you can build your baseline and identify where your application can cost you time and money.

Application Transformation Explained: Strategies and Best Practices can help you understand the steps you can take to build out your technical debt solution. From assessing your business to implementing solutions to help reduce your debt.

Zerovity^TM can help with finding weaknesses in your codebase. If you’re trying to identify what your legacy business logic is, Zerovity can help.

There are many ways you can go about finding your technical debt and remediating that debt. It just depends on your environment and what you’re trying to accomplish.