The funny thing is how every regulatory change in the universe finds a way to get applied to IT. For example, when I worked in PM/IT support for a big pharma, we started to get SOX forms that asked about DR, business continuity, and even anti-virus software. Hello? Wasn't Sarbanes-Oxley implemented in response to C-level malfeasance and high-level managerial misconduct? And now it includes anti-virus measures?
People seize on these things to get resources and headcount for other purposes, and to demonstrate that they are indeed relevant. The beauty of regulatory typhoons like SOX and HIPAA, etc., is that they create a universe where you can say you have been productive when _nothing_ has happened, if you know what I mean.
And they always have numerous reasons why they cannot do what you want. I've worked in large companies where the scientists agitated and finally brought about an entirely separate IT organization. Traditional IT, along the lines you describe, was purely overhead. The scientific organization was more user-responsive, and was more involved in, you know, actually creating value.
Look at Big Pharma for some examples of this.
One way to start weaning yourself from IT bureaucracy is to first set up a "test lab". This is for testing new technologies in a location convenient for your end users. This can be gradually expanded, and used to sell your users on the idea of doing things, you know, their way. And like all empires, this can grow over time. You, in the meantime, can build a reputation for customer focus and innovation. Sure, it can take time.
The other thing you can do with hidebound IT is to first document the business requirements of your users, and then ask IT to provide a solution which meets these requirements. I usually meet with the IT group's solution architects informally to see if we can settle on something mutually acceptable. At these informal meetings, I also explain the business stakes for the users of getting what they need. In addition, always include a few wildcard requirements, such as:
"users will experience no degradation of service or performance as a result of the technical solution"
Who would argue with that? So everyone will sign on. Yet I've been able to relentlessly use this to cut away at bureaucractic "requirements" to get my users what they need.
There's more that can be done, but the key is to not approach this as a technical dilemma, but as a people problem. I'm curious to hear what other people think.
Slashdot Mirror
The funny thing is how every regulatory change in the universe finds a way to get applied to IT. For example, when I worked in PM/IT support for a big pharma, we started to get SOX forms that asked about DR, business continuity, and even anti-virus software. Hello? Wasn't Sarbanes-Oxley implemented in response to C-level malfeasance and high-level managerial misconduct? And now it includes anti-virus measures? People seize on these things to get resources and headcount for other purposes, and to demonstrate that they are indeed relevant. The beauty of regulatory typhoons like SOX and HIPAA, etc., is that they create a universe where you can say you have been productive when _nothing_ has happened, if you know what I mean.
And they always have numerous reasons why they cannot do what you want. I've worked in large companies where the scientists agitated and finally brought about an entirely separate IT organization. Traditional IT, along the lines you describe, was purely overhead. The scientific organization was more user-responsive, and was more involved in, you know, actually creating value. Look at Big Pharma for some examples of this. One way to start weaning yourself from IT bureaucracy is to first set up a "test lab". This is for testing new technologies in a location convenient for your end users. This can be gradually expanded, and used to sell your users on the idea of doing things, you know, their way. And like all empires, this can grow over time. You, in the meantime, can build a reputation for customer focus and innovation. Sure, it can take time. The other thing you can do with hidebound IT is to first document the business requirements of your users, and then ask IT to provide a solution which meets these requirements. I usually meet with the IT group's solution architects informally to see if we can settle on something mutually acceptable. At these informal meetings, I also explain the business stakes for the users of getting what they need. In addition, always include a few wildcard requirements, such as: "users will experience no degradation of service or performance as a result of the technical solution" Who would argue with that? So everyone will sign on. Yet I've been able to relentlessly use this to cut away at bureaucractic "requirements" to get my users what they need. There's more that can be done, but the key is to not approach this as a technical dilemma, but as a people problem. I'm curious to hear what other people think.