Technical Debt Management:
Making the Business Case

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 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

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):

• Unintended associations of the technical debt metaphor
• Nontechnical precursors of technical debt
• Communication challenges
• Reification of the abstract concept of technical debt
• Cultural debt masquerading as technical debt

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.