“Technical Debt” is the concept of creating a list of recognised tasks to be completed on a project at some future time. Usually, the delivery team will have been unable to complete the task for one of a number of reasons: Unclear requirements or conflicting requirements mean that a design conflict can’t be resolved, so the decision is made to implement a compromise. An addition to the technical debt recognises that the conflict is not resolved. A dependency on a factor external to the delivery team, such as the availability of another team’s deliverable or definition of a wider system paradigm such as authentication or data access, means that work can’t be completed but a mitigation or work-around is implemented instead. An addition to the technical debt recognises that there is an incomplete or unresolved dependency and that rework will be necessary at some future point when the dependency is resolved. A lack of overall design control may mean that different delivery teams implement individual solutions to design questions affecting the overall project or programme. Again, an addition to the technical debt recognises that decisions have not been made or communicated in a timely fashion and that some, or all, of the individual deliveries will require rework at some future time. Keeping a register of technical debt isn’t a Bad Thing. It’s important to keep a list of unresolved problems, and the concept of “technical debt” seems to resonate well with delivery-oriented mindsets (analysts, programmers, technical writers and so on) – but just because the language used is the language of technology rather than risk doesn’t mean the concept of risk has been removed. In its aggregate, technical debt represents a risk to your project: if the technical debt is not repaid then the project will not be completed within scope, time, cost or quality constraints. Each individual item logged as a technical debt represents an unresolved issue, and the resolution of the issue needs to be factored in to future work planning. The state of technical debt is a good overall indicator of the health of a project. If the items listed as technical debts come with sound justifications (perhaps the deferral of a major change to the codebase to a future release) and planned mitigation (“we will address this issue in the next release but one, and the planning/budgeting reflects this) then it’s a positive indication that issues have been identified, logged and a strategy to resolve them is in place. On the other hand, if technical debts do not have a justification but merely reflect poor working practices (such as “we really need to document this because only Alice and Bob understand it, and we’re at risk if for some reason they are no longer available to work on it” or “we can’t do X until Y is delivered/designed/resolved”) then it’s a negative, a warning that the project has endemic problems which need to be addressed. Technical debt, then, is a technologist-centric way of measuring and managing project-centric problems of risk and issue management, and we ignore it or blindly add to it at our peril.