Slashdot Mirror
Guerrilla IT, Embracing the Superuser?
snydeq writes "First it's letting users manage their own PCs and now it's sanctioning the shadow IT projects they do on the down low: 'You probably know them. They're the ones who installed their own Wi-Fi network in the break room and distribute homemade number-crunching apps to their coworkers on e-mail. They're hacking their iPhones right now to work with your company's mail servers. In short, they're walking, talking IT governance nightmares. But they could be your biggest assets, if you use them wisely. The reason superusers go rogue is usually frustration, says Marquis. "It's a symptom of the IT organization being unable to meet or even understand the needs of its customers," he says. "Otherwise, it wouldn't be happening." The solution? Put them to work.'"
It's certainly not perfect, but my gigantic fortune 500 company does this and everything seems to be just fine. This combined with the fact that the PC support people are braindead.
Just because someone can plug a device into a data jack does NOT mean they're a "SuperUser".
Yeah, that might work at HOME. But in the OFFICE someone (me) has to be responsible for security of our data. That includes YOUR social security number in HR's database.
If you do not like the "restrictions" you are working under, then explain to YOUR boss how much more money you'll make for the company if you get X. And your boss will talk to my boss and I will explain how much it will take to implement X (money, time, security changes, etc).
If the net is an increase in profits, we'll probably do it.
If it will open us up to a new risk WITHOUT an increase in profits, I don't care how much you love your idea. It's not going to happen.
Writing code which floods the network with packets? Crashes workstations? Worse, crashes servers?
Deletes logfiles? Rewrites config files?
Sorry - if it's my name on the line for a given piece of equipment, I want control of that piece of equipment. I left a place last February where that wasn't strictly true - and I'm relatively certain my fellow outsourced contractors were breaking stuff. I never did decide if it was accidental or intentional, but the missing log files made me go "hmmm . . .".
Remind me why we even have an IT dept. again? IT is really good at providing a network and workstations for you to work on.
Getting inside your head to know what software to write, to help you be the trading assistant working for the high yield bond traders is a little tougher. It kind of takes an IT person with a financial degree and trading experience. A person with a financial degree and trading experience _isn't going to be a workstation monkey making half what they could otherwise_.
The only way to know what those needs are is to ask someone who's too busy to give you the time of day, let alone help build requirements for the software you need.
If you are such a trading assistant, and know how to program, who better to prototype the application? You are the only one that can possibly do a good job, not some guy with an MCSE cert that knows a lot of TCP/IP or some programmer fresh off the boat from Bangalore.
The phrase "destined for failure" comes to mind. If you wrote a spreadsheet that did what you needed, that's a perfect blueprint for a full blown application. Your requirements are expressed in a working example.
Then your IT staff can turn that into a reliable program with a database back end, and it will work far better than if you were asked what you needed and gave at most 25% of the important details.
That is the single biggest problem and why projects fail. The requirements are never complete and nobody ever supplies the details you _really_ need until the application is built. By then it's possible for the additional details to completely break the project and require a refactoring, which blows away the deadlines.
If it happens more than once, the project is often doomed.
-AC