Technical Debt Management:
Making the Business Case

Adopting a program for rationally managing technical debt is a complex undertaking in organizational change. In many organizations, it affects all aspects of organizational life. This program lays out the essentials for making a business case for such an effort.

For many organizations, adopting a program for rationally managing technical debt entails organizational change. Like many organizational changes, efforts of this kind tend to be unexpectedly difficult. And unlike many organizational changes, these changes touch almost everyone in the organization, because technical debt isn't merely a technical problem.

Technical Debt Management: Making the Business Case

The Brooklyn Bridge. Some of the suspension cables contain defective wire that was delivered by an unscrupulous supplier who deviously circumvented the wire inspection regime. After the scheme was discovered, too late to replace the defective wire, additional wires were strung to compensate. Sometimes, we cannot retire all technical debt; sometimes we have no practical alternative but to live with it. Every technological artifact is potentially connected to numerous cultural, technological, social, and process artifacts, both within the enterprise and outside it. Changes in any one of them can require or induce changes in the others. To choose — or fail to make — necessary changes is to incur technical debt.

Technical debt manifests itself in technological assets, to be sure, but its causes are rarely restricted to the behavior and decisions of engineers. And that's the central reason why so many organizations have such difficulty gaining control of technical debt. We can't resolve the problem of chronically excessive levels of technical debt by changing the behavior of engineers alone. In most cases, chronically excessive levels of technical debt are the technological manifestation of an organizational problem. Technical debt is the symptom, not the problem.

An effective business case for adopting a rational technical debt management program must address the root causes of chronically excessive levels of technical debt. It must have these seven elements:

  • Definitions of technical debt and the problem of chronically excessive levels of technical debt
  • Explicit descriptions of its consequences
  • Specification of the root causes of the problem for this organization
  • Estimates of the costs of electing not to address the problem, as a function of time
  • Estimates of the costs of the measures that would address the problem, or portions of it
  • Estimates of the organizational value of deploying those measures, individually or in combination
  • Proofs that the proposed measures will produce those values for the organization

Tall order, but that's what it takes.

What we cover

A rehabilitated Green Line car of the Massachusetts Bay Transit Authority

A rehabilitated Green Line car of the Massachusetts Bay Transit Authority. Trolley cars once traveled on tracks directly embedded in surface streets in and around Boston. Many streets still contain buried trolley tracks. They comprise a technical debt, because of the decision to defer track removal. Metaphorical interest charges continue to accrue in the form of broken pavement and a near-continuous need to patch roadways, due to surface decomposition from the freeze-thaw cycle and the constant small movements of the buried tracks due to traffic loads. The concept of technical debt applies far more widely than software engineering. Photo by the Massachusetts Bay Transit Authority.

How can we possibly produce such a document? That's what this program is about. And the short answer is that this business case, unlike many business cases, cannot be captured in a document. Documents are necessary, but they aren't sufficient — the documents aren't the business case. They're only the tools we use to present the business case to organizational leaders.

But we must make this business case not only at the leadership level but also at the level of the individual contributor. Because anyone can take steps that lead to incurring technical debt, everyone must know what steps to avoid, and what steps to take. We must educate everyone. Documents don't work so well for everyone.

The reason for this is that top-down organizational change won't work very well for organizational transformations that inherently contradict messages the enterprise population receives continuously, from both management and the enterprise culture.

In this program, we explore five issues that make technical debt so difficult to manage. (The links take you to articles on this site or at my TechDebtPolicy blog):

We develop five guidelines for designing technical debt management strategies for the modern enterprise. In brief:

  • Control formation of new technical debt
  • Craft more effective communications
  • Avoid the indirect effects of technical debt
  • Make and use debt projections
  • Address outstanding cultural debt
These strategies enable the organization to gain control of the formation and retirement of technical debt.

For example, sometimes a project team realizes at the end of the project that some of what they just built could have been done better, if only they had known then what they know now. They've incurred technical debt. If here are no resources available to retire that debt, then that debt is unsecured — no resources have been pledged to retire it. The concept of securing a technical debt provides a solution to this problem. By creating a means to forward-commit budget and schedule to retire that debt, the organization enables the project team and its sponsor to retire the debt at a future time without deferring delivery of the current project.

This engaging and eye-opening program points the way to a path that leads your organization out of technical debt, to make it more adaptable, more transformable, and more agile.

Participants have an opportunity to work in a hands-on team fashion on a problem that simulates the generation of technical debt in the product development context. The problem we pose is designed to create conditions that correspond to the real-life situations that cause organizations to incur new technical debt.

Learning model

We usually think of project management skills as rather technical — free of emotional content. We hold this belief even though we know that our most difficult situations can be highly charged. Despite our most sincere beliefs, taking a project organization to the next level of performance does require learning to apply knowledge management skills even in situations of high emotional content. That's why this program uses a learning model that differs from the one often used for technical content.

Our learning model is partly experiential, which makes the material accessible even during moments of stress. Using a mix of presentation, simulation, group discussion, and metaphorical team problems, we make available to participants the resources they need to make new, more constructive choices even in tense situations.

Target audience

Because anyone in the organization can make choices that lead to incurring technical debt, this program is designed for everyone. We use examples and exercises that show how anyone — absolutely anyone — can contribute to technical debt formation, and therefore anyone can make changes in the way they work that then lead to reductions in the rate of incurring new technical debt.

Program duration

Available formats range from a one-hour survey to two days. The full-day format provides optimum value as an introduction.

Follow Rick

Send email or subscribe to one of my newsletters Follow me at LinkedIn Follow me at X, or share a tweet Subscribe to RSS feeds Subscribe to RSS feeds
The message of Point Lookout is unique. Help get the message out. Please donate to help keep Point Lookout available for free to everyone.
Technical Debt for Policymakers BlogMy blog, Technical Debt for Policymakers, offers resources, insights, and conversations of interest to policymakers who are concerned with managing technical debt within their organizations. Get the millstone of technical debt off the neck of your organization!
What People Say About Rick's Programs
  • "Rick is a dynamic presenter who thinks on his feet to keep the material relevant to the group."
    — Tina L. Lawson, Technical Project Manager, BankOne (now J.P. Morgan Chase)
  • "Rick truly has his finger on the pulse of teams and their communication."
    — Mark Middleton, Team Lead, SERS
Ebooks, booklets and tip books on project management, conflict, writing email, effective meetings and more.
Comprehensive collection of all e-books and e-bookletsSave a bundle and even more important save time! Order the Combo Package and download all ebooks and tips books at once.
If your teams don't yet consistently achieve state-of-the-art teamwork, check out this catalog. Help is just a few clicks/taps away!