Technical debt is a term coined by Ward Cunningham in 1992 to describe the software engineering phenomena of how expedient, short-term decisions can have negative, long-term consequences that accumulate and make updating and maintaining software difficult.
The technical debt metaphor is also a good way of looking at how businesses and their business processes mature. Businesses growing from Excel to accounting software and to ERP systems aren’t just incurring new costs, but also paying off the debt accrued by the defensible, short-term decision to run the business in Excel or accounting software. Those short-term solutions become onerous as the business grows dragging down productivity.
Businesses accrue technical debt whether they are conscious of it or not. The results of technical debt are typically inefficiencies and, in software products, bugs.
The best-run businesses manage technical debt choosing to take it on while planning to pay it off. Their levels of debt fluctuate in a saw-tooth pattern as they set aside time to manage the most expensive and damaging debt.
Poorly run businesses don’t manage technical debt and keep taking it on until it grows out of control. Just like the costs of servicing interest can completely consume revenue so too can the costs of technical debt virtually eliminate productivity if left to grow un-checked. When you see a software product and wonder why they can’t do something that seems simple, often it is technical debt that is holding them back.
One good example of technical debt that illustrates some of the problems surrounding it is software architecture. A well-architected piece of software is easy to maintain while a poorly-architected one is a nightmare.
However, spending weeks at the beginning of a software project planning the architecture is all time that delays product launch. The problem is further compounded by the difficulty in communicating the importance of good architecture to business managers. Delays, on the other hand, are understood all too well.
Usually the best solution lies somewhere in between perfect architecture and rapid time to market.
Spending a lot of time architecting a new software product for an unproven market, for example, is not wise. That is why most software startups try to quickly prove that their product has a market before investing in the long-term success of their product.
However, when that product takes off, they need to invest in architecture. Twitter is an excellent example of a software product that was quickly thrown together taking on technical debt before experiencing explosive growth that exposed their architecture problems. Twitter’s Fail Whale is now an endangered species thanks to their post-launch investment in fixing technical debt.
Software architecture is just one of many decisions that defer costs to a later date. If expediency always wins out and no effort is made to pay off the debt by improving the code or the architecture, then a software product will become unwieldy. Simple modifications will break things in seemingly unrelated areas of the product.
This is why debt is such a good metaphor. Taking on debt is a good thing. Used wisely it lets you grow faster than you could have without debt. But at some point you have to pay off that debt. Letting it accrue infinitely is not an option.
The technical debt metaphor also describes the challenges of businesses maturing from inception to a company that can make a good business case for ERP and beyond. You could term this as operational debt, but technical challenges underpin these business challenges. Really, it is just another form of technical debt but with a lot more operational visibility to the problems that result from outgrowing your current accounting solution.
With software projects, technical debt is usually invisible to all but the software engineers. With ERP projects, the technical debt is visible throughout the organization, but, unlike software engineering projects, we tend to think of technical debt in ERP projects as an expense when in fact we are just paying off debt.
New businesses face a lot more pressing challenges than choosing an ERP system—they need to find suppliers, cashflow, and customers to name just a few more important challenges. The cheapest, most expedient choice is to run the business with Excel or an entry-level accounting system while growing the business.
Business processes evolve around these tools and the people that use them as the business grows. These business processes are not going to be the most efficient way of operating, but they are good enough.
Until they are not.
One day the accountants will realize that they spend a full week doing month end; or the company will start bleeding customers because the customer service doesn’t know what is in stock; or the warehouse manager will do a stock count and have to pay good money to haul away expired inventory.
These problems are all costs associated with the accumulated debt. The technical debt on the many, defensible, short-term decisions has accrued to the point where the business needs to pay off that debt and upgrading from an entry-level accounting package to ERP is how you do it.
The saw-tooth pattern continues after you implement your first ERP system. Compromises that you make to finish the ERP project under budget grow and drag on the company until they become too much of a drain on productivity and you decide to have the system customized and pay off more debt.
Other business process improvements, like lean manufacturing initiatives, are similar debt payments. The time and expense of implementing lean doesn’t make sense to a new manufacturer with just one or two machines. However, productivity begins to suffer as the business grows and decisions are made for short-term expediency without thought to long-term planning. Then, suddenly, spending time on lean manufacturing begins to make sense and can pay for itself through increased efficiency.
There is nothing wrong with making decisions based on what is expedient in the short-term. Just be ready to invest in long-term solutions before the consequences become too much to bear.
Find out what your company will look like when it is ready for ERP.