The Meaning of Technical Debt in Project Management

Technical debt in the project context

The concept of "technical debt" originally comes from the field of software development. This debt arises when rapid completion is preferred to an optimal solution. The difference between the possible optimal solution and the solution actually implemented is referred to as technical debt. Finally, the project team incurs debt in the form of errors in the software that have to be paid for later. This is precisely the case when the deficits become apparent and adjustments have to be made in order to arrive at an optimal solution after all. The time that results from the faster, inferior solution is therefore not saved, but the time expenditure is only incurred at a later point in time. Under certain circumstances, a corresponding improvement can even cause additional work.

As with the work-in-progress concept, which we recently reported on, this term from another business sector is now also used in project management. In the following, we will explain to what extent this concept can be transferred to this context and what decisive role technical debt plays in project management.

Contents

• An overview of technical debt in project management
• A definition of technical debt
• Why does technical debt arise?
• Different types of technical debt
• Opportunities and risks of technical debt

An overview of technical debt in project management

As in software development, the term technical debt refers to the fact that cutbacks are made in the planning and implementation of the project in order to save time and therefore costs. Debt is usually incurred consciously, but sometimes unconsciously, especially in stressful situations. The sacrifices that are made here can take many different forms.

For example, if you and your team are designing a plastic part from a 3D printer as part of a project, a lower-quality plastic can be used to save time, but it can be printed more quickly. The quality of the prototype or even the finished product suffers as a result.

If, in another case, the time-critical point lies in the actual development of the product, it is possible that features that appear to be of secondary importance will not be implemented. Ultimately, the benefit that the product is supposed to bring to the user suffers as a result.

However, technical debt can also be incurred in the internal organization. Under time pressure, for example, meetings can be kept very short. This has negative consequences for internal communication. In this area, there may be a need to catch up at a later date.

Technical debt can therefore occur in various forms in your project.

A definition of technical debt

In this concept, the term "debt" deliberately creates an analogy with the financial sector. This is because by taking out a loan, certain things, such as investments, can be implemented more quickly than if the amount first had to be paid in full yourself. These debts in turn have to be repaid at a later date - including interest payments. Similarly, in the project context, the team reserves the right to provide technical capacities, which must be provided at a later date. After all, previously realized savings in the performance of the product cannot be permanent and the fulfillment of the performance promise is only postponed to a later date.

This debt metaphor is used because the underlying phenomenon is very abstract. Accordingly, there are many definitions circulating on the internet that attempt to capture the essence. A very suitable, undistorted and neutral definition is given in a scientific paper by Holvitie et al. published in the Journal for Information and Software Technology in 2018. Here, technical debt is presented as the consequence of all actions that consciously or unconsciously prioritize customer benefits or project goals over a more technically sound implementation.

Why does technical debt arise?

Whether taking on technical debt is a conscious decision or an unnoticed phenomenon usually depends very little on the cause. The most common reason, namely upcoming deadlines, can lead to deliberate cutbacks being made. However, time pressure can also lead to partial aspects being unconsciously neglected and falling by the wayside. Deficits in team leadership can also ensure that certain subtasks are only handled carelessly by the team.

In addition, a lack of quality awareness can mean that improvements have to be made after the project has been completed. At the same time, an inadequate quality inspection process can be mentioned.

Expectations based on the customer or the market as a whole can also ensure that a product that has not been fully optimized leaves the company. Finally, time-to-market can be a decisive competitive advantage. After all, many solutions can still be improved after market entry, especially when it comes to digital products.

Furthermore, deficits in communication can also lead to a build-up of debt. If the expectations of the project result are not clearly communicated in advance, the client may perceive it as incomplete. As a result, technical debts are revealed that the project team has to honor afterwards.

In addition to the aforementioned and most common causes, there are many other conceivable scenarios in which the output cannot or should not be delivered in optimal quality.

Different types of technical debt

In the software industry, attempts have been made for years to categorize technical debt in a meaningful and target-oriented way. As a result, there are many types of debt in practice today. Many of these can also be applied to project management in general and not just in the software context.

For example, design debts are often incurred in projects aimed at developing a new product. This means that in the course of guaranteeing a certain basic functionality, the design of the product falls by the wayside. After all, this is not decisive for pure use and can often be improved afterwards. However, design debt should be avoided especially when the design represents a central benefit dimension of the product.

Probably the most important element of a project with regard to the learning process is the project documentation. This makes it possible to precisely trace the course of the project and identify the reasons for any inefficiencies. However, if there is a lot of time pressure in the project environment, documentation is often neglected. After all, it makes no constructive contribution to the success of the project in the short term. However, in view of its high relevance for the learning process and therefore for the success of future projects, you as the project manager should insist on paying off the documentation debt at the latest once the project objective has been achieved.

Another common cause of high time pressure in the project is the omission of extensive test phases. After all, test phases only come about when certain basic functionalities have already been fulfilled. If this is the case, the often only half-finished result already provides a benefit for the customer and can theoretically be passed on to them. In some industries, it is now normal to launch untested products on the market. For example, companies in the video games industry often publish beta versions. As a result, the technical debt is even passed on to the consumer, who voluntarily takes on large parts of the test phase. In such cases, however, it should be communicated as a matter of urgency that these are unfinished versions in order to avoid negative reactions as far as possible.

Depending on the project context, countless different types of project debt can occur. In order to manage debt effectively, it is important to understand it and to know exactly what the debt consists of. Always keep an overview of your technical debt so that it does not cause you any problems as the project progresses.

Opportunities and risks of technical debt

Although debt is often associated with negative things, technical debt is ultimately neither bad nor good. Just as in the financial corporate context, where borrowing can increase return on equity, for example, there are also opportunities that arise from taking on technical debt. As already mentioned, this can ensure that deadlines are easier to meet. However, it should not be forgotten that the possibility of skipping tasks or only completing them in a makeshift manner also creates an incentive to do so out of convenience, without any necessity. In this case, it is advisable to always have the project manager approve any incurrence of technical debt so that he or she can intervene if this practice is used too extensively.

From the management's point of view, technical debt therefore provides the opportunity to flexibly organize the time of publication of the result with a fixed workload in the project. Here again, a parallel can be drawn with taking out loans, which allows the timing of the investment to be flexible despite a fixed monetary requirement. It is often easy to keep track of financial debts. For companies, a simple glance at the balance sheet is enough. Technical debts, on the other hand, are less visible. As a result, there is often a risk of losing sight of them, which can ultimately have fatal consequences. It is also easier for those responsible to ignore them.

In conclusion, technical debt is a good way to deliver project results on time. However, it should always be remembered that this is debt and not savings. Accordingly, the corresponding service must be provided at a later date. In order to successfully manage the technical debt in your project, it is important to always have an organized overview of it. Encourage your project team to always properly document the technical debt incurred in the project. This way, you can enjoy the benefits of technical debt while minimizing the risks that arise.