A Scorecard for Technical Debt

by

Corporate technology debt (which we will refer to as technical debt) is usually the result of not considering the future effort needed after shortcuts misfire. Recently, CFOs have been taking on the responsibility of IT function, with some IT departments reporting directly to the CFO or relying on them for spending approval. Therefore, awareness of technical debt is necessary for these CFOs. Finance executives, however, will have a different perspective on technical debt than those in IT. For them, technical debt is threatening because it can results in dollars worth of lost opportunities.

One example of the costs of technical debt was at an organization where operational inefficiencies resulted in too many people needed to support transaction processing. The cause of this issue was that there were three different enterprise systems that were not communicating with one another. This ended up costing the company $300,000 per year. The IT leadership was not successful in demonstrating the value of upgrading and consolidating these systems and the organization eventually spent $1.3 million in enterprise resource planning.

This example demonstrates a few of the elements that factor into technical debt in an organization.

  • Ineffective Technology Leadership – 30% of the debt load can be followed back to poor IT leadership. This is because often CFOs do not know what qualities are needed to have a successful IT leader. While finance executives often think that solely strong computer skill are needed, a top IT leader needs to know how to implement and manage key applications, deliver important data, and develop and a positive experience for employees and customers.
  • Ineffective Oversight – 25% of technical debt stems from weak discipline, reporting, and strategic focus.
  • Outdated Systems – 20% of debt comes from systems that are not automated or difficult to integrate.
  • Mis-spending – is about 15% of debt present due to a misallocation between maintenance and spending on new projects. A spending benchmark can be set by looking for similarly sized organizations in the industry and analyzing their capabilities.
  • Process Chaos – 10% of debt is present because of processes that are incoherent that result in multiple separate systems and conflicting data.

Once the factors that contribute to technical debt are sorted out, the next step is to measure the amount that the organization has. Here is where a scorecard can come in handy. Making the scorecard include a numerical value to each of the five components and score each from 1-10 (with 10 being the best) and weight each score with the percentage it takes of technical debt (ex. 25% for ineffective oversight). Then, for each year that a component scores below five, multiply the number of years by .25 and then subtract that number from the debt load factor total. If then the score is below 6.5, there is high amount of tech debt putting the organization’s efficiency and reputation at risk.

Here is an example of the score card used in this post:

technical debt, technology debt, IT Budget, IT Risk Management

In order to get out of such an amount of debt there are several steps that need to be taken. First of all assessing IT function by looking into the department’s resources , structure, systems, and projects will help to prioritize where changes would be the most significant. Asides from this a standardized reporting procedure needs to be taken up. Such month end reports would focus on the status of prioritized IT projects and and other management issues (spending, resource allocation, etc). This would implement a source of accountability to those working on these projects and enable management to understand the status of the department. Aligning technology investments to the overall company’s organizational strategy is also another important step to reducing technical debt. Analyzing IT spending is also where technical debt reduction is also made possible. For example, switching from a email provider from a dedicated server and putting the funds to a new project.

To read the full post and the recommended strategies for reducing technical debt (from a finance executives point-of-view) click here.

Filed in: Technical Debt
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
In our 29-criteria evaluation of the static application security testing (SAST)  market, we identified the 10 most significant vendors — CAST, CA Veracode,  Checkmarx, IBM, Micro Focus, Parasoft, Rogue Wave Software, SiteLock,  SonarSource, and Synopsys — and researched, analyzed, and scored them. This  report shows how each measures up and helps security professionals make the  right choice. Forrester Wave: Static Application Security Testing, Q4 2017  Analyst Paper
This study by CAST reveals potential reasons for poor software quality that  puts businesses at risk, including clashes with management and little  understanding of system architecture. What Motivates Today’s Top Performing  Developers Survey
Load more reviews
Thank you for the review! Your review must be approved first
Rating
New code

You've already submitted a review for this item

|