Recently the topic of “Technical Debt” came up during a project planning meeting with a customer. If you have never heard the term before I am not surprised. Although it is an important and a key metric to track it is rarely discussed or addressed.
What is it?
Originally coined in regards to traditional software development (also known as design debt or code debt) technical debt simply refers to amount of work that is still owed to the business before a group can call a project complete.
There are a wide variety of reasons that contribute to the long-term debt of a project, some of them are below:
- Meeting aggressive timelines, cutting corners, removing features
- Trying to meet internal and external business demands
- Lack of an accurate budget or negligence in managing said budget
- Sudden technology changes
- Missing key knowledge, processes or understanding
- Improper scoping and planning
- Lack of collaboration and teamwork
- Unable to pivot when the project is beyond repair
Why is this important?
It is important to know what this debt is because much like real financial debt (think credit cards) it can increase with interest over time and this interest has a compounding effect. Once you get behind on deployment keeping everything running and patched begins to become a huge challenge demanding more and more resources. Scale, adding new features and providing agility begins to become very difficult.
More often than not this liability is never truly paid back. Sooner or later the business decides to write it off and start again with a new project. Unfortunately I see repeating behaviors and can almost conclude without a doubt that the next project will suffer the same fate.
This is detrimental to your organizations efficiency and effectiveness causing such problems as:
- Longer time to market and missed opportunities
- Increased spend on repeat processes
- Ineffective resource management
- Lost productivity and decrease in morale
- Key business owners losing confidence in IT’s ability to deliver
- Shadow IT projects
How do you fix it?
First and foremost take ownership of the project and have proper understanding of the outcome and desired results. When the scope of the project is defined there is no doubt on the expectations for a successful launch. This also gives you the baseline or true cost to measure future debt against.
Second, take larger projects and break them down into the smallest deployments possible. Then develop these small deployments into repeatable operations that can be automated. Create feedback loops so you can make adjustments on the smaller deployments as quickly as possible. By the time you need to make an pivot on a larger rollout it is too late.
Third be consistently ruthless in removing waste. Inefficiencies will destroy any hopes of a successful project. Know your resources (strengths and weakness), potential bottlenecks and distractions.
Finally, don’t be afraid of failing or admitting a mistake. Not all projects turn out the way we plan and sooner or later a change is in store. It is better to admit this and make adjustments than to follow course. More times than not when I hear of a failed project there always seems to be awareness early on that something is not going correctly.
Leave a Reply