How often have you been involved in a discussion in either the product development phase or later process troubleshooting and improvement where you had to make a decision between implementing a quick-fix solution to manage the problem or a longer term better correction that would make the problem go away? Often you will be expected to work on both, but time is limited and you can only have one number one priority. How do you decide which solution you work on?
This issue has been considered in computer software development. When fixing a bug or adding a new feature, the programmers would have to make a choice between adding a quick feature or patch to the existing code or completely rewriting the code. Which is best? If the feature is likely to be a once off addition, the quick fix make sense. However, if this is likely to be the first of many similar changes it would make more overall sense to rewrite.
But how do we value the relative costs? The rewrite will take longer and cost more. The patch will be quick and inexpensive but will require more work in the future. The cost of this future work is called technical debt. Technical debt is a concept in software development that reflects the implied cost of additional rework caused by choosing a quick-fix solution now instead of using a better approach that would take longer. The original idea is credited to computer scientist Ward Cunningham.
But medical devices are not computer programs. Can they be looked at in the same way, putting a technical debt value on quick fixes? There are many times when you find a fault, perhaps there is difficulty inserting a device in a patient. You could carry out a quick fix by providing more detailed instructions to the surgeon to overcome the issue, or carry out a redesign to eliminate the difficulty. The latter will take time and money for redesign, prototype build, testing, and regulatory approval. The former can be implemented relatively quickly with training and regulatory approval.
But this speed comes at a cost. The better solution is the redesign that would make the product easier to sell because of its ease of insertion. You can use the concept of technical debt to value the cost of applying the quick fix instead of the longer-term solution. Estimate how much the quick-fix costs and compare with the cost of developing the long-term solution. The major technical debt may be reduced sales if a competitor product is easier to use.
Obviously, these numbers are just estimates and if the technical debt and long-term technical development costs are similar you might as well just apply the quick fix. But if your estimate of the technical debt is much higher than the development cost this is telling you that you should work on the long-term solution.
You might choose to do both – save time with the quick-fix, and also develop the proper solution. In this case you would incur the costs of both solutions. Technical debt is a concept to help value potential solutions if resources are limited. It helps you decide which solution to focus on.
This is applicable to process improvements of existing processes. The technical debt might be reduced yield and additional labor costs. This number can be compared to the cost and time to redesign the process. In regulated industries both costs are high because of the long-life of products and long time it takes to get changes approved. You should value the quick-fix and long-term solution over the expected life of the product using net present value calculations.
Technical debt is not necessarily a bad thing. You might find that it is much lower than the costs of redesign. And if this is the case it is good to know it. So when the new big boss asks why you do not improve the process, you can say the cost is too high and the technical debt you have is more than covered by the opportunity cost of working on other projects.