I was talking with a friend of mine that runs a consultant agency, and I said, "Everyone talks about Tech Debt, but no one talks about Process Debt." He did a double-take and said, "I have never heard that phrase. Tell me more." I have known about Tech Debt for ages but have been thinking about Process Debt for about six months. So I did a Google search and found that "Process Debt" returned 26,000 whereas "Technical Debt" had one hundred times more results, 2.8 Million. This post is my thoughts on the topic.

For me, the idea of Process Debt stemmed from constantly hearing that this or that software was terrible. Do software companies with revenue over $1B annually have lousy software? Probably not. Looking under the hood, you will most likely find that its unwieldy customization made it terrible. Any customization that doesn't add value or assist the workstream increases "Process Debt." It happens when people make changes to the tool that impairs its usability. I have worked with many tools (Salesforce, Jira, SQL Server, Clarizen, Zappier, PowerBI, Alteryx, and so on). These tools are excellent, and I have seen them used beautifully and seen them "Frankensteined" into an unusable mess.

Before we dig into Process Debt, let's define its well-known brother, "Tech Debt."

Wikipedia says that Tech Debt is "the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer."

Technical debt is defined. Unfortunately, if you search for the Wikipedia page, "Process Debt" doesn't exist (or at least it didn't at the time of this writing). Maybe I should ask for a page to be created.

It looks like developers are carrying the "Process Debt" torch. However,  I want to make the case that "Process Debt" is a bigger problem in Business Operations. Therefore business operations should carry the "Process Debt" torch. The main problem stems from not having clear boundaries between reporting and workflow. Let me explain, most tools and software come with standard functionality and the ability to customize. It would be great to solve all our problems with out-of-the-box functionality. Unfortunately, this is not a reality because our problems involve too much complexity.

Below is a diagram of how Process Debt sneaks into the typical lifecycle of new software implementations. As you can see, the initial customization leads to greater efficiency until, eventually, the changes lead to exponential complexity with little value.

Typically, the new software leads to greater visibility of the problems with the process. This visibility leads to better changes to the process and greater efficiency. This improvement cycle works until the analytics addiction outpaces the potential process improvement. In the beginning, process changes can be unwound, but this becomes impossible after the process matures. Additional process changes can also be exacerbated when no team owns the software. For example, if you have a workflow tool that order takers manage, your Process Debt with grow faster than a team managing the entire process. When asked, often time, the order takers add fields or areas. They cannot know if the change will improve or harm the workflow. So they are unwittingly building "Process Debt." In short, you should never solve reporting problems by willy nilly process changes. The process and the people drive the reporting, not the other way around.

Since Wikipedia doesn't have a definition here is mine:  Process Debt - Is adding complexity to a workflow or system that doesn't have an equal or greater value to the business as a whole. Process changes must make the "whole" better. If they are not then you are introducing "Process Debt."

Questions that will prevent Process Debt

  • Does this save us time?
  • Can everyone use it?
  • Is the added complexity worth the change?
  • Are the last changes being adopted?
  • If not, will this increase the adoption of past changes?
  • Will we be doing this same process in 2 years?
  • Can this be solved by a report or dashboard?
  • How will we track the effectiveness of the change?
  • Who will the implementation of the change?
  • Do we have backing from leadership?

In the end, systems naturally head toward complexity and Process Debt. Once a process is adopted, it is worth it to take the time to analyze if a change is worth the increased effort. It is okay to say no and push back because your process could go bankrupt if you don't. One of my favorite quotes is "Bad process kills good people," and Process Debt is often the driver.