We’ve all been to this movie. Luke Skywalker and company find themselves in an Imperial garbage disposal unit. You know the scene: Leia in a white dress; Han and Luke in white stormtrooper armor. Then the walls start closing in.
We’ve all seen it. It is possibly one of the most iconic scenes in cinematic history.
THIS IS YOUR IT DEPARTMENT.
Here is proof.
A NYU professor took revenue data from 7,582 global companies. It’s a big pool and neither country nor industry specific. The Compound Average Revenue Growth Rate (CAGR) over 5 years for this pool?
9.6% CAGR
What is the average annual IT budget increase across all sectors?
3.1% Increase in IT Budget
That’s it. That’s the whole article. You can stop reading if you want to. But the takeaway is this:
All IT departments have an efficiency mandate. Every decision about how the IT department is run, every assignment, every project must minimally result in a 6.3% efficiency gain. That’s just to keep heads above water.
Think about this. You are busy—easily working 10 hours a day without a break. If you had a 6.3% efficiency mandate, it’d mean that this year you’d need to do the same amount of work in a day, but in 37 minutes faster.
Next year, do it again. And again. Over a decade you will have to figure out how to do your job in about 4 hours. What about the big boys & girls in the S&P 500? Easily a 2% efficiency mandate. And that’s the thing. This is an average. It’s never a steady 6.3%.
But this compactor does not care. It does not care about the economy. It does not care about your specific industry challenges. It does not care that your best team members just got poached to another firm. It most certainly does not care about a pandemic. Even that is absolutely brutal over time.
Why? An efficiency mandate is one thing. IT departments are expected to be bastions of innovation as well. We will get to that in a second.
How’s it going so far?
Remember that scene where Han Solo grabs a pipe and tries to prop it against the closing walls? It folded like an al dente spaghetti. Poor Chewbacca just pushed and pounded on the wall.
Most IT employees feel like Chewy. Over and over they hear that old saw inside companies that “our IT department is not responsive enough.” Why do we keep hearing that?
Because it’s true. The efficiency mandate, especially when it is not recognized, ensures everyone is stretched thin applying bandaid after bandaid. Patch after patch.
Think about last year.
Think about the projects you did last year. Think about the projects you want to do this year and next. It’s an easy thought exercise to put them on this chart.
In the interest of digital ink, we are going to primarily focus on categories A and D. For most IT departments this is where all the action is at.
But for the sake of completeness:
Category A : GRAND SLAM! Increased both IT efficiency and business competitiveness.
Category B: IVORY TOWER Increased IT efficiency but decreased business competitiveness.
Category C: LESSONS WERE LEARNED Decreased both IT efficiency and business competitiveness.
Category D: BUSINESS AS USUAL Decreased IT efficiency but increased business competitiveness.
A and D are where the action is. If you are over in category B and C ,something is going really wrong.
Like what? Well, as you can imagine, if you are in the Ivory Tower category, something like offshoring brought some IT efficiency, but at a terrible cost to the business. It’s not that offshoring itself is bad. It was just executed badly. Same goes with category C, Jobs Were Lost. The SAP project went down in flames. We’ve all seen it.
But let’s talk about the busiest category: Business As Usual. Here, the IT project causes the IT department to become less efficient. However, the business becomes more competitive. What is the business asking for? A new system? A system fix? A set of data?
It does not really matter. Once the business decides it needs something it is going to go after it. Whether the business got IT involved or not, IT is going to end up owning it at some point. Hence, these things always decrease IT efficiency.
The metaphorical Imperial garbage compactor we are in gets its power right here. Sitting in a conference room, the IT team says something to the effect of, “We hear you. Our plan is to code up a little solution and have it in production by the end of month.” There it is. Right there. The IT team just bought itself years of decreased efficiency.
Sometimes the Business as Usual category is not really even competitive. Think about regulatory obligations. The business HAS to do it. Do they want to? No. Does IT want to own it? No. Pushed up against the wall like this, many teams simply ask, “How can we do this as cheaply as possible for now?” They will figure out an elegant solution later. But there it is again. The IT department just got saddled with years of decreased efficiency.
What about the “big strategic” projects?
Big system implementation. Big system replacement. Major upgrades. Big in-house builds. Has anyone asked the question about how much a successful project will increase business competitiveness or IT efficiency? What if it fails? A failure will almost certainly put it into the Lessons Were Learned category. We mentioned SAP failed implementations. These epic failures are part of the corporate folklore now.
The more pernicious projects, frankly, are hatched from really, really smart and technically-savvy IT personnel champing at the bit for a meaty project. Out of all the project categories these are by far the most dangerous. If it has vague competitiveness outcomes and even more vague IT efficiency outcomes, be very cautious. These projects have a real chance of landing in the Lessons Were Learned category.
The take-away from the Business as Usual category is mulit-dimentsional:
- Even if IT says ‘NO” the business might do it anyway. This will end up in IT’s lap.
- Quick and cheap always has a long term efficiency cost
- Failed projects end up in Jobs Were Lost.
Let's talk about the Grand Slam!
Think back to the times you did projects that both increased IT efficiency and increased business competitiveness. What were they? What made them that way?
Remember that system replacement. If you do it right—If you pick the right vendor and the right team—it can really change a lot.
Remember server virtualization? For the uninitiated, you probably have heard about VMs. In the old days we used to buy actual servers. Does anyone want to set up a test environment? Get ready to wait weeks if not months.
Virtualization basically allowed us to take one big server and break it up into several. So instead of buying a new box we could just take one box and split it into two. Grand Slam! We are increasing IT efficiency and increasing competitiveness.
What else?
- Replaced 5 CRM systems with Salesforce SaaS
- Replaced a cube reporting OLAP system with Redshift and Tableau
- Replaced SSIS integrations with a low code integration/ETL
- Got rid of poor support vendors and replaced them with more responsive vendors
- Got rid of historical Oracle storage and replaced it with Snowflake
These are good examples of Grand Slams. Project to project, your mileage may vary. For us, things like Docker/Kubernetes/AWS/Azure/CloudFormation are all amazing in terms of IT efficiency. They help us respond to customers very quickly, which is a competitive edge. Solid Grand Slam Territory.
But there is a catch, and it’s a big one. That person or team that is managing some legacy process will fight to keep it as if their professional lives depended on it. Consciously or subconsciously, we are talking about moving the earth they stand on. It’s not comfortable. Many Grand Slam projects have died here.
The second blocker is sunk costs. Companies spent gobs of money on OLAP cube reporting technology. At the time it was amazing. Now? It’s a brick. But again, talk about replacing that with something that is far more featureful, with less maintenance, and frankly less expensive. That’s a tough conversation with the CFO who remembers shelling out millions. So here we sit with our legacy systems and process wondering why we feel like Chewbacca with the walls closing in.
What would you replace it with?
A Business Response Architecture. In our opinion the business response architecture is one of those things that substantially increases IT efficiency while also really increasing business competitiveness. Honestly, this is formalizing what is just being done a bit piecemeal these days.
This is part two of our two-part series on Business Response Architecture. Read part one, When Your Data Viz Is On Fire, to see the full scope.
Request The E-Book
Learn how to overcome data flow limitations inherent in today’s business processes and discover how to define a modern data management architecture fitted to keep pace with business demands over time.
