I really love doing IT projects. Something about completing a project that makes everything run better really feeds that same drive that keeps me playing RPGs. In this blog post, we will tackle how your tech debt is generated.
Projects vs Operations
I was shocked when I was talking to a couple people outside of IT and they didn’t understand the difference between projects and operations. I think this is common sense in our field so feel free to skip this if you know the difference.
The main reason (I think) they found it hard to differentiate is that other professions typically don’t have people who do both in the same role. From what I’ve seen in other fields, those roles are handled by two separate people. Even if you look at software development, the idea of having the developers be a part of operations with DevOps was some novel idea.
Projects are done to build something. This could be rebuilding something existing, or entirely new to the environment. Operations is the work done to maintain a system and keep it running.
Corporate IT Does Both Simultaneously
Organizational IT is unique is that they do both maintenance and business improvement. In IT, this manifests as 2 different types of work.
- Maintenance is referred to as operations. The keep-the-lights on type of work.
- Business improvement is referred to as projects. This could be building some new capability for the business, or rebuilding something existing. The lines between project and operations can sometimes get blurry, especially when you’re doing a project that has the goal of improving operations.
This presents a unique set of challenges for IT. They have to balance doing maintenance with doing projects. With pressures from management, it’s common to see maintenance delayed or ignored.
How This Generates Tech Debt
I’m going to use some concepts from Technical Financing, so you may want to check that out if you’re not familiar with it.
A common scenario looks like this:
It starts with IT handling everything fine. You have some services you’re responsible for, but you have enough staff to handle everything.
Your team can’t save hours from last month and put it forward to the next month, so some technical capital is represented as monthly technical revenue.
Any skills they’ve gained or time invested in making the system work in can be represented as technical capital. These benefits persist through each month.
So far, we’re looking pretty good. We have §50,000 tech capital left. We could use this to invest in our technical capital by spending time on training or investing in an internal project that will streamline some of the operations for ourselves.
By the way, I chose to use the symbol for technical capital as simoleons because I found it funny, hopefully you agree!
Projects Come In
There’s some business needs that require project work. Let’s say it costs §300,000/month for 3 months.
Once that project work is completed, the maintenance of that system delivered in the project is part of day to day operations. I’ve increased our recurring technical cost by §25,000 as a result.
At the surface, this looks great. We’re fully utilizing our technical capital. Everyone is always busy and doing what needs doing. That -§5,000/month hardly goes noticed. We’re just taking small shortcuts here and there to make ends meet.
Over time, this degrades our technical capital. The operations load on the engineering team grows, meaning there’s less extra bandwidth available among the IT team. Either the team hires more people and goes back to step 1, or….
The Downward Spiral
Projects and maintenance still need to be done, but there is less time for each thing that needs to be done. More and more shortcuts are taken on projects, therefore maintenance is ignored. On our spreadsheet, this can be seen as a reduction in the technical capital your team commands, along with an increase of monthly technical cost.
The negative technical balance starts to manifest as outages, unplanned work, and all the technical difficulties that simply reduce technical agility. That last one is hard to describe because it’s something that’s everywhere in an environment when you’re deep in tech debt. Examples of this can be designs that are hard to work with, being unable to find equipment when you need it or configurations taking longer than you think should have.
If left unchecked, the unplanned workload will grow and eventually consume the IT teams entire bandwidth.
How Do I Avoid This?
The concept of technical debt does a good job of revealing what’s happening. If you’re familiar with managing your actual finances, the rest is pretty intuitive. To start though, the biggest thing you can do is make this technical debt visible to management. They need to be aware of the size of the technical checks they’re writing and how it’s affecting the team and let them decide where they want to take it from there.
I have a workflow for turning a team that’s upside-down on tech debt into a technically stable team. I’ll share that in another post soon.
Thank you for checking this out. I hope you learned something new or enjoyed reading this. If you had any comments, questions, or just wanted to share your thoughts on this article, you can contact me at blog@e-mayhem.com
e-Mayhem helps companies successfully deliver business projects. We also help companies avoid losses associated with IT disruptions and security threats. You can learn more about our services at e-mayhem.com or by emailing sales@e-mayhem.com
Comments are closed