Let's ignore the SaaS security issues for a second. When IT says "No" it's not like the area asking is going to go away and not try to solve their problem. Organizations are going to find ways to solve their issues and IT can either help from the beginning or help clean up the mess later. I try to take the stance of offering the right solution and a lot of the times a now solution at the same time. There is no saying "No" in the long term, either help them now or get stuck with the shadow solution the magic macro guy cobbled together that became a critical business function.
I have seen IT being unaware of and unwilling to meet requirements of highly specialized technical teams, such as network engineering. You cannot have a TELNET client because the use of TELNET is prohibited by corporate policy, test TCP connections another way. You don't need vim when you have vi. You can't have admin rights but we don't support drivers for RS232 dongle so nope. Sometimes it's quite a challenge to get some work done.
There can be a lot of steps between "help me fix this problem" and fixing the problem. They include qualifying the idea, scoping the request, possibly transforming the request into an abstract form and searching the organization for other people with forms of that abstract problem. Then you get to procurement and you need to figure out if you are getting a specific tool for a specific task or some kind of kitchen sink. Now that youve learned what the kitchen sinks do, you go back to scope and decide if other requests or projects are moving into this one, or if perfect is becoming the enemy of good. Then once your implementation project is done, you need to redesign old processes around it, communicate the change, and offer training.
Saying yes and fixing the problem quickly, without analysis, will often UNDERSERVE your company in the long run, because you only fix a specific problem for a specific person, functional group, or division.
You're essentially suggesting "properly" going through the slow and inefficient bureaucracy machine, when the underlying issue is exactly that people tried to do what you suggested but ended up getting nowhere.
You realize you need a kitchen sink, it turns out there are 2 other teams who already created their own semi functioning kitchen sink which they want you to adopt, but doesn't fit in your kitchen, and the CIO is working with Home Depot to create standardized kitchen sinks for the entire company which will be ready in 3 years (realistically 5 years, or maybe never), but your current sink is leaking and is flooding your kitchen now, so you do what you can to fix it.
Basically a principle of asking for forgiveness rather than permission. Does it cause issues? Of course, any solution to today's problem becomes tomorrow's problem. Now there are 3 semi functioning kitchen sinks in your company, but at least they are functioning
If your machine is slow and inefficient, it needs repair or resources. Fix the machine, don't build a smaller one propped against the side of the garage. A rising tide raises all boats, put your effort towards improving the company by rising the tide.
You are adding redundancy and overhead elsewhere. Now you have 30 people at your company playing account admin, managing passwords and permissions to different platforms. "Oh but it only takes me a couple minute a day" x 30 = a part time admin job.
People tend to ignore succession too. What happens if trains hit people, or they land poorly skydiving, or they move on to another job. Oh they signed up for that critical service with a personal gmail account?
Im not even advocating kitchen sinks in my post, and neither was the article. The article was pretty explicit that there are the two types of projects big and small, and to let small projects be agile, but still keep them visible and sanctioned. They dont need to be shadow projects. You are creating a false dilemma. Its not "either it goes into the kitchen sink or its shadow IT." The machine may very well recognize "hey two other teams are working on variants of this, can you all get together and share notes. We would also like copies of everything you have all learned for when we re-implement this in three years." A good IT rule might be "sure you can sign up for your SaSS service and manage it yourself, but if it supports SSO, we are implementing SSO or you dont get to sign up."
If you need a stop gap temporary project to last you until the ERP is implemented, good management will recognize that and support it as part of a continuous improvement cycle. They might buy something damn well knowing that they already have a plan started to decommission it in two-three years.
And what happens when you don't have good management? You end up with kludgy solutions and IT constantly falls behind.
As a dev, I will get my job done, and if that means breaking company policy, I'll do it. I've used SOCKS proxies to get around company firewalls because the whitelist time is measured in days, and I have minutes. I've used my phone as a hotspot when IT broke enough of the internet to be a bother. I've used SSH tunnels combined with Nginx reverse proxies to get around routing approval processes. I've even built a port forwarding service because IT took too long to approve and implement their own, and it has been in production for years (I don't think IT is aware of it, though I should probably get it all cleaned up at some point).
If management decides security is important, but not important enough to make efficient, employees will work around the limitations.
> People tend to ignore succession too. What happens if trains hit people, or they land poorly skydiving, or they move on to another job. Oh they signed up for that critical service with a personal gmail account?
Agreed. Not saying it's a good solution, just saying it's a solution. Can you get burned by that solution? Yes. Usually is the reason many companies have extremely stringent and inflexible IT policies, because they've been burned hard in the past.
> good management
I feel this is really the critical component that is needed. Management, just like any other skilled labor, like programming, will always have an overabundance of mediocre performers and a shortage of 'good' high performers. Meaning we run into issues described here.
The audience of Harvard Business Review articles are managers, probably ones with some level of self awareness with regard to self improvement, and this article is written to business management as a set of recommendations on how handle stodgy IT departments AND rule breakers.
The article we are commenting on is trying to teach management to identify when things need to move through the entire IT project lifecycle, and when to let them mostly self sustain (except obviously nobody should ever sign up for a single thing no matter what it is, if it supports SSO, until the company connects their identity management to it!!)
In my last job I tried to handle this in a similar way. The issue we ran into though was that often these managers would not properly evaluate the software. They would get wowed by the sales guys and sign up for huge contracts without, sometimes, even checking with IT or testing other vendors.
Whenever I'm wearing my IT hat at work, a big part of it is being a detective looking for clues that somebody, somewhere, is about to do this. Then I can insert myself into that process. It would be preferable to be included in the beginning, but one must work within the reality of the situation.
