Enterprise Cost Containment

H.L. Mencken once famously wrote, “…there is always a well-known solution to every human problem—neat, plausible, and wrong.” More than just a pithy way to frame the entire concept of “cost containment” (whether network-specific cost, the broader category of IT, or the cost of anything else, to be quite honest), it’s an integral aspect of what I’ll be proposing in this and subsequent articles in this series.

To use a more common IT aphorism: Mencken’s quote isn’t a bug, it’s a feature.

Controlling cost is by its very nature neither trivial nor simple. If it were, it would already be done. More than that, it would be done and would be easy to keep in a continuous, optimal state of control. When businesses can achieve ongoing, systemic cost control, it looks elegant—almost poetic. Our desire for control causes us to confuse the perception of elegance with simplicity of execution.

Another point to keep in mind is there’s an important difference between “simple” and “easy.” Some of the suggestions you may hear from your staff; or find online; or even read in this series are, in fact, simple. That doesn’t necessarily mean they’re easy to implement—certainly not when the variables of corporate culture, leadership’s appetite for change, and the facts-on-the-ground of the current economy are added for consideration.

That something isn’t easy and has never been, and should never be, the reason (in and of itself) not to undertake a project if it will have measurable ongoing value to the business.

And this is where the Achille’s heel of IT is laid bare: “if it will have a measurable ongoing value to the business” is something IT folks have, historically speaking, had an almost allergic reaction to considering, let alone proving.

I get it. “Cost” is not an exciting, engaging, pulse-raising topic. Then again, neither are sorting methodologies, indent techniques, or how to pronounce file extensions. But you immediately and reliably create “excitement” (read: drama and conflict) in most IT conversations by expressing the “wrong” opinion about any of those. So let’s be honest: IT folks don’t need things to be empirically “exciting” to be engaged in the conversation. And cost is one of those topics that should be exciting to IT professionals because everything we do, don’t do, and want to do but can’t comes back to our ability to show its value to the business.

The problem, as I’ve written about often, is IT practitioners insist on presenting technology in terms of the features, functions, and IT merits. When a project request is declined, we dig in and double down, presuming we simply haven’t made the technical case clear enough. We begin to pull out 27-slide PowerPoint decks explaining our design in careful, loving detail.

For some folks reading this, it might be the first time someone disabused them of the notion this will ever work. It may be the first time someone directly stated that business leaders, to the very last one, are only interested in three things: how to increase revenue, reduce cost, and/or remove risk. If a request doesn’t address how it impacts one (or more) of those three things, it will be an uphill battle the entire way.

For more readers, however, this won’t come as a surprise because it’s an all-too-common experience. What those readers need isn’t a reiteration of these facts so much as some solid, clear, achievable instructions on how to re-frame common IT requests, projects, and initiatives in those elusive business-relevant terms.

That’s what this series proposes to do. For areas ranging from ITSM to edge computing; for initiatives as varied as desktop refreshes, cloud migrations, and yes, even monitoring solution implementation, we’re going to acknowledge the technical “speeds and feeds” but pivot to reveal the ROI to make your CxO wake up, sit up, and take notice.

We’re doing this not as a one-time “boss explainer” exercise. Speaking the language is a skill every IT practitioner—from desktop support all the way to enterprise architect—needs to acknowledge as important; to endeavor to learn; and to continuously work to improve throughout their career. This series is meant to make a difference in the near term—helping you adjust and improve your in-flight requests if they’re similar to the ones we’ll be using as examples—and long term by using this series as a set of practice examples you can base upcoming or future requests upon.

We feel strongly about this because it has additive benefits, and because now is a unique period in IT for tech professionals to demonstrate this under-appreciated skill.

I say it’s “additive” because in addition to explaining THIS request in a way that resonates with business leaders, and therefore makes it easier to approve, it also demonstrates you and your team have an awareness of and appreciation for the business. This makes it more likely management will include you in upcoming business initiatives to make you aware of the new goals and get the “IT perspective.” Being invited to the table where business decisions are discussed, rather than simply hearing about those decisions after the decision is made, is a game-changer for IT departments. All because you showed an interest in, and facility with, the language of business.

But what’s so unique for IT today that wasn’t true one year, five years, or a decade ago? Like so many things, the pandemic has fundamentally altered the relationship between business and IT. Prior to 2020, businesses frequently perceived IT to be a cost center, a set of services in a race-to-the-bottom path to complete commoditization, similar to electricity. The only ROI to be found in IT was its ability to make itself as cheap and invisible as possible.

Then came lockdowns of early 2020, which affected almost every aspect of almost every business across the globe. And in that moment, the business realized the only hope they had of continuing was to leverage technical capabilities and pivot as hard and as fast as possible. The first wave of changes was getting millions of homebound workers back online and back to work (a motion mirrored a few weeks later for school-age children). The second wave of technical transformation was taking on-premises applications and services and migrating them to cloud-based equivalents, making them accessible to a wider population while reducing the impact to internal infrastructure.

When the dust settled from those and their associated sub-projects, it was clear to business leaders their business didn’t just rely on their technological sophistication—in some cases their business was predicated on that technological sophistication. Without IT, there was no business at all. The illusion that “we can go back to paper and pen if we have to” was dispelled once and for all.

This understanding by the business of the fundamental, business-critical importance of technology in general and their IT teams in particular is why NOW, more than ever, is the right time for IT to step up and prove its understanding of the business. Or, as long-time IT pundit Bob Lewis has famously and frequently said, “There are no IT projects because every project is about improving the business.”

There are only business initiatives with a technical aspect. Those initiatives cannot happen without IT, but at the same time they aren’t about IT either.

With all of that said, this merely tees up the series. Future posts will dig into the particulars; use real-world, technically sound examples; and provide a kind of business-to-tech Rosetta stone you can use to improve your interactions with leadership. For now, my hope is we’ve made the compelling case for you to continue reading.