Why is it no one wants to talk about IT debt? Are they scared of saying hey I need help? Do they not have a clue that they are in debt? Maybe they feel like its job security? Maybe they are the ones putting you into debt?
Over the years I managed to put myself in IT debt, and try to start digging myself out of debt. But what is debt really. The best explanation I could find was from Gartner:
IT Debt is described as “applying a quantifiable measurement to the backlog of incomplete or yet-to-be-stated IT change projects.”
IT debt is no more than the projects that was cut short due to someone saying it works hurry up move on to the next thing. We will go back and fix that later. And little things that are miss configured for testing or troubleshooting also play a toll into this. Over the years we have all skipped a corner knowing we will all go back and fix it later and here it is two years down the road and still have not done so. I’m not to proud to admit I have done the same thing. We all have if you dig deep. The question did you learn from doing this? I know I did, my shortcut turned out to be a land mine waiting for me to step on it during a upgrade. And that little hour short cut cost twenty plus hours of work to clean up and fix. So why now talk about this. To me it seems like this is what is holding the world back.
So, what are the causes of IT debt? If you ask people its due to Budget Cuts. Gartner likes to blame it on IT Budgets but I am not a huge fan of that statement. Is it budget cuts? Or is it pure laziness? Or is it being rushed? Or is it ignorance? Or not talking ownership in your service? It believes it’s a mixture of All with Budget Cuts as the start of the chain. I see it working like so:
A project is put together with a projected cost. Things are submitted to a group of people that have no clue about IT and they say, do this for %20 less money and we will sign off. We say okay we will make it happen. Pause Here and think about this!
We take this plan back to the team and say here is what we need to get this done, and the timeline of when it needs to happen. The team sets out to acquire what is needed and start setting up what is needed. As the time line and budget is growing to exhaustion, we start cutting corners. Just doing the bare minimum to make it work. And we may skip a page in the install and best practices guides thinking we may know better. Pause Here and think about this!
Now we are in the last days of the project we have our manager hounding us to hurry up finish this project. We have other things that we need to get done. Under pressure and reluctantly we say well its ready for production. When really, we know it’s not ready and have another week’s worth of work and tweaking and testing to be done. Pause Here and think about this!
So, what happened in this situation?
First breakout, they start of the chain was the people of the board approving the projects saying we approve only 80% of your cost. Well where does that savings come from? It comes from labor to do the project. Not so much the cost of the asset, as you can only get so much of a discount. This project was doomed from the beginning. Then as good IT people we said yes, we will make this happen, this is another flaw in the chain. Sometimes you need to stand up and say no we can’t do it for this kind of cash. If you are presenting this to the board for approval its your job to keep the IT operations afloat. And running this model will only cause it to sink.
Second Breakout, cutting corners to just make it work. This ends up killing everyone in the long run. Not to mention the ignorance/laziness to properly do the task at hand. This in turn creates a huge amount of what I like to call Land Mines. A little lost change or forgot setting that comes back and blows up in your face at the most in opportune time.
Third Breakout, this is where it all comes together. This is where the pressure from above comes down hard and making sure this project is in budget and on the correct timeline. And us as fearing that there will be reproductions for missing the deadline or going over budget we say yes, we are on time and on budget. But would it really be our fault. We gave them the original numbers to make this happened and the board cut it, and the manager agreed to it. So to me I think it’s the managers fault. Why are we scared? Well it’s the old philosophy that “Shit rolls down Hill” and the stupid blame game. Now it is 100% our fault for saying this project is production ready. As in fact we know that is not. We have knowingly cut corners, not optimized, not properly tested, and so on. This is all signs that the team doing the install wants to take no ownership in it.
After this project where does this put us? This gives us a new thing, that works, but is full of so many flaws that is prone to break down. So not only did you create X amount of back log due to the short cuts your team took, but now you must fight fires on top of that, and also keep the lights on for the rest of the environment. In turn digging the IT debt hole deeper. Just to throw a number on it. Really that 20% cost savings the board thought was a great idea has cost them 5 times that. The difference is that they don’t see that cost. No one brings those numbers to them. We do not bring the numbers to them correlating that the 20% they tried to save cost us x dollars this month.
Good news we all start like the pic above. And end up like this…
So how do we solve all this brokenness? I vote Nuke it and start over! To be continued in the next post.