Last updated on July 15th, 2021 at 10:47 am
When we first set out to plan a large technical debt retirement project (DRP), a question arises very early in the planning process. It is this: Which assets are carrying the kind of technical debt we want to retire? And a second question is: Which operations will be affected—and when—by the debt retirement work? Although these questions are clear, and easily expressed, the answers might not be. And the answers are important. So where is the technical debt?
The challenges of identifying debt-bearing assets
Determining which of the enterprise’s many technological assets might be carrying the Technical Debt In Question (TDIQ) can be a complex exercise in itself. It’s challenging because inspecting the asset might be necessary. Inspection might require temporarily suspending operations, or determining windows of time during which inspection can be performed safely and without interfering with operations. Further, inspection might require knowledge of the asset that the DRP team doesn’t possess. Moreover, access to the asset might be restricted in some way. In these cases, staff from the unit responsible for the asset must be available to assist with the inspection.
Although asset inspection might be necessary or preferable, it might not be sufficient for determining which assets are carrying the TDIQ. This is easy to understand for physical assets. For example, physical inspection cannot determine the release version of the firmware of the hydraulic controller electronics of a tunnel boring machine. But asset inspection might also be insufficient for purely software assets. For determining the presence of the TDIQ in software assets, reading source code might not be sufficient or efficient.
To locate the technical debt, it might be easier, faster, and more accurate to operate the asset under special conditions. For example, an inspector might want to provide specific inputs to various assets and then examine their responses. As a second example, we might use automation assistance to examine the internal structure of an asset, searching for instances of the TDIQ. And as with other assets, the assistance of the staff of the business unit responsible for the asset might be necessary for the inspection.
Which enterprise operations depend on debt-bearing assets?
Knowing which assets bear the TDIQ is useful to the DRP team as it plans the work to retire the TDIQ. But part of that plan could include service disruptions. If so, it’s also necessary to determine how those disruptions might affect operations. That information enables the team to control the effects of the disruptions and negotiate with affected parties. Thus for each asset that bears the TDIQ, we must determine what operations would be affected by service suspension.
Observations of actual operations in conditions in which the asset is out of service in whole or in part can be valuable. Such observations might be the only economical way to discover which enterprise functions depend on the assets that carry the TDIQ. Other techniques include examining historical data such as trouble reports and outstanding defect lists, and correlating them across multiple asset histories and operations histories.
In some cases, these investigations produce results that have a limited validity lifetime, or “shelf life.” The short shelf life is mainly due to ongoing evolution of the debt-bearing assets and the assets that interact with them. That’s why the work of retiring the TDIQ must begin as soon as possible after the inventory is complete. This suggests that the size of the DRP team is a critical success factor. Larger size teams can complete the inventory inspections rapidly. Speed is important because of the validity lifetime of the team’s research results.
Managing teams of great size is a notoriously difficult problem. One approach that can help involves delegating some of the DRP research effort. The people most qualified for this work are in the business units that own the assets in question. Properly motivated, they can provide the labor hours and expertise needed for the research. In this way, the DRP can deploy a team-of-teams structure, known as a Multi-Team System (MTS) [Mathieu 2001] [Marks 2005]. The DRP team can then bring to bear a large force in a way that renders the overall MTS manageable.
[Marks 2005] Michelle A. Marks, Leslie A. DeChurch, John E. Mathieu, Frederick J. Panzer, and Alexander Alonso. “Teamwork in multiteam systems,” Journal of Applied Psychology 90:5, 964-971, 2005.
[Mathieu 2001] John E. Mathieu, Michelle A. Marks and Stephen J. Zaccaro. “Multi-team systems”, in Neil Anderson, Deniz S. Ones, Handan Kepir Sinangil, and Chockalingam Viswesvaran, eds., Handbook of Industrial, Work, and Organizational Psychology Volume 2: Organizational Psychology, London: Sage Publications, 2001, 289–313.
Other posts in this thread
- Retiring technical debt from irreplaceable assets
- Auxiliary technical debt: Rules of engagement
- Legacy technical debt retirement decisions
- Retiring localizable technical debt
- Controlling incremental technical debt
- Automation-assisted technical debt retirement
- Outsourcing Technical Debt Retirement Projects
- Refactoring for policymakers
- The trap of elegantly stated goals