I hate to tell you this, but IT might not have the best reputation in the company. You might be perceived as, shall we say, inflexible — and that’s a big part of the reason that users have sought ways around your department, sometimes using cloud services to avoid the conflict of getting things done with you. But it doesn’t have to be that way.
Look I understand that you haven’t put up these rules just to get in the way. Like most policies, they developed out of bitter experience. You’ve worked hard to get your systems in place and you don’t want anyone mucking that up, whether it’s the developers, the legal department or anyone else.
Sometimes it’s easy to forget in your zeal to protect your systems that IT is not an island and it should be there to serve the business and its mission. Your goals as a department revolve around keeping the systems running. If you have 100 percent up time (or something close to it), you don’t want anything put in place that could have a negative impact on that, and that means testing ahead of time to see how new tools and systems will affect the overall operation. And that takes time.
I completely understand that, but you have to find ways to accommodate the needs of your business units too. As more companies develop agile programming methods, the more likely it is that developers are going to be throwing all kinds of new systems out there, and much faster than in the past when changes took weeks or months.
And that means you need to find common ground with the business units and their requirements. The problem is that in many organizations the political hard lines have been set long ago. People get territorial about their individual department needs. Neither side thinks the other understands or cares about their requirements.
And it’s hard to get past that raw division that’s built up over many years in many organizations.
But pitched political battles really don’t advance the needs of the company. In my post yesterday, IT Ops Needs to Find a Way to Communicate Its Value, I talked about the need to communicate the value of what you do for the organization better, but you also have to try to understand what others inside the organization are trying to do too.
And that might require some given and take on your part. If you can’t find a way to do this, don’t be surprised when your developers have suddenly started sand-boxing their apps on Amazon Web Services without your knowledge or the guys in marketing have started using Box.net.
If there are paths of less resistance, people will find them and the end result is that IT Ops will be even further out of the loop. The idea is to get everyone working together. If that takes a kinder, gentler IT Ops, then so be it.