How to Change an Existing Process in Your IT Org (And Why It’s Worth the Hassle)
“IT” might as well stand for “Improving Technology”.
When you work day-in, day-out on a system, you can’t help but notice a handful of tangible changes to make it better. And when you do, only one barrier stands in the way to implementing this change—getting your boss to approve it.
In a perfect world you could just walk into your boss’ office and say “We’re doing things wrong, here’s how to do it better,” and he would immediately agree with you.
But in the real-world IT environment, we all know how these meetings usually turn out…
You enter your boss’ office, excited, holding in your hand plans for a change whose benefits seem clear-as-day to you.
You show your proposed change to your boss, expecting he’ll see things the same way and give you the green-light.
Instead, your boss pauses a moment, barely looks over your idea, then tells you, “No,” with little-to-no explanation. The change you were excited to implement never sees the light of day.
These meetings are disheartening enough on their own, but the real damage comes the next time you notice a way to improve the system you’re working on. When you stumble on that new area for improvement, are you just as likely to share the idea? Or will you not bother, knowing what happens when you do?
Like many IT pros, you’ll bury the idea and grumble about how your boss just doesn’t get it…
Which is a shame, because it isn’t actually your boss’ fault your idea got shot down.
Think about it for a minute. Imagine your CIO goes to the CEO of your organization and says, “Hey, I want to do this $250mm SAP implementation because it’s better than what we’re using now,” with no further explanation. Would you fault your CEO for shooting her down? Of course not! $250mm is a huge expense, and if your CIO wants the green light on that project it’s only reasonable she first builds a very strong case for why her proposed implementation will deliver returns that are worth earmarking a quarter of a billion dollars to make a reality.
The same holds true for every change you want to push through.
No, you aren’t asking for $250mm here—but every improvement you pitch has a cost. Sometimes it’s hard dollars-and-cents. Sometimes it’s the hours you’ll need to devote to making the change happen. Sometimes the cost appears down the line when you have to deal with confused users. Whatever these costs are, you need to paint a clear picture of what they are and why they are worth incurring before you can expect to hear a “Yes” from your boss… even if your boss has never told you he needs this sort of cost/benefit analysis to pitch a project.
A cost/benefit analysis is hard to argue with, and easy to put together.
Just follow this process.
First, ask, “Why do we do things this way?”
Before you spend too much time preparing your pitch, make sure the change you’re proposing has a fighting chance of replacing the existing process. Do some digging and figure out why things are currently done the way they’re done.
Sometimes, the answer is going to be “Just because.” When that’s the case, proceed to the next step.
But most of the time, there’s a defensible reason why systems operate the way they do—even if that reason isn’t obvious. Maybe there are compatibility issues that force your department to use a sub-optimal piece of software. Maybe it’s the only system that meets compliance requirements. Or maybe the system aligns with values your organization considers more important than maximizing efficiency.
If your proposed change disrupts core organizational values, doesn’t meet compliance requirements, or requires changing a whole host of complimentary systems, then you might want to let it go. The change probably won’t happen.
But if your proposed change doesn’t disrupt anything mission-critical, then prepare your pitch.
Second, ask, “Do the benefits outweigh the costs?”
For smaller changes, a little back-of-the-envelope math will be enough to start a real conversation with your boss.
Let’s say you want to implement a new piece of software that will only operate in the backend, that only you will touch. The software costs $500, and it will take you 8 hours to implement and adapt to. If you earn $20/hour, then the total cost of the implementation will be $660. ($500 for the software + $160 for your time.)
As long as this new piece of software provides more than $660 in value, you have a strong case you can bring to your boss.
Third, bring your analysis to your boss.
Make this pitch impersonal, and lead with your analysis. Instead of following the traditional approach and saying, “We’re doing things wrong, here’s how to do them better,” begin the conversation by telling your boss, “Our current system works, but I’ve identified this change that will cost $660 and provide $1000/year in cost-savings. Do you want to take a look at it?”
In some cases, your boss may approve the change with analysis as basic as the above.
In many cases, this sort of analysis simply starts the conversation—especially if you’re proposing a larger, more complex change.
Big changes tend to have more potential downside than smaller changes. They cost more money. They use up more manpower. They require a steeper learning curve for your users. Even if the math works out proportionally the same, a $660 change that produces $1,000 in savings will be a much easier sell than a $6,600 change that produces $10,000 in savings.
What’s more, a lot of the “costs” you run into with larger, more complex changes are difficult to quantify. How much cost-saving does your idea need to enable to offset frustrating your users for a month? How much added uptime does your new system have to provide to offset the fact your boss was the one who picked the existing system, and he feels personally attached to it?
These are hard questions to answer, and they point to a simple fact of organizational life: the larger the change you want to make, the more work you will need to put in to get it approved.
A Quick Note on Putting in the Work
Some IT pros will read all the above and say, “Why bother trying to change anything? It sounds like too much work.”
We understand if that was your first reaction. Pushing through change is a lot of work, and putting in the time to prepare your pitch doesn’t guarantee you will have your change approved. You can prepare for a month and still have your idea shot down.
So why bother?
Because organizations highly value individuals who can make change happen.
Getting your organization to adopt even a small change is going to take real thought, elbow grease, and a little political savvy.
Getting your organization to adopt a large change might require everything you’ve got.
But once you show that you are one of the few truly ambitious IT pros who not only puts in the work, but who actually makes change happen—your colleagues and stakeholders in the business will begin to look at you in a new light. They will begin to see you as a true partner with the business, and not just another frustrated “IT guy” to tell what to do.
And that’s worth not only seeing how things can improve, but also seeing how that improvement can become reality.
