Slashdot Mirror
Who Makes the Decision To Go Cloud and Who Should?
Esther Schindler writes: It's a predictable argument in any IT shop: Should the techies — with their hands on their keyboards — be the people who decide which technology or deployment is right for the company? Or should CIOs and senior management — with their strategic perspective — be the ones to make the call? Ellis Luk got input from plenty of people about management vs. techies making cloud/on-premise decisions... with, of course, a lot of varying in opinion.
If you can't have a rational discussion between your architects (who are most likely just really senior guys slinging code) and your product managers (who are most likely just sales and account reps without a market vision) you are already screwed.
Shit. I just described my own company.
Tell people that instead of saying "in the cloud" they say "on somebody else's computer" and see how that goes--
"We store the company's most important information on somebody else's computer"
"We control access to that data by storing it on somebody else's computer"
"We back up all our mission-critical information to somebody else's computer"
"Our data is secure because we store it on somebody else's computer"
Doesn't sound so good, eh?
It's not necessarily that so much as the head honchos usually have grandiose visions that are short sighted.
For that reason, and others, IMO it is best to follow the typical procedures one does in typical successful IT project management, which may sound bureaucratic, but it avoids disasters, thus these are pretty common procedures for a very good reason:
i.e:
1) Problem statement: Why is what we're currently doing insufficient?
2) Do a productivity gap analysis: Where are we now, where do we want to be?
3) Does the proposed solution provide for long term growth (so that we don't have to ask these questions again in only a few years)?
4, 5, 6, etc, etc,
But along the way, never leave out this important step: Consult with all of the stakeholders and make sure this solution works for them early in the design phase to figure out if this solution is even worth pursuing.
The stakeholders often include: Upper management, middle management, lower management, the techies, the rank and file employees, the customers, and sometimes the shareholders.
When you consult with them, what you're looking for are things like this: Does this new system work better than the old one? Does the new system make your job more difficult in any way? Does the system make your job easier in any way? What do you like about it? What don't you like about it? What else do you think you may need? (On that last question, make sure to have well defined scope limits early on to avoid feature creep.)
I remember at one place I worked, somebody higher up decided that they wanted to move all of the sales department to Microsoft Dynamics CRM some time before I first worked there. One day while I was asked to troubleshoot a problem with it, (and believe me, MS CRM has TONS of bugs) and I was totally stumped because this person's account didn't work even though his permissions were the same as everybody else's. After I did some investigation, I found out (and the management wasn't even aware) that every salesperson had this problem, only very few of them even tried to use MS CRM at all, so nobody actually reported it until this one guy happened to try it a few years after we had already supposedly been using it.
That's a classic example of when somebody implemented a new "IT system" but completely failed to consult with the rank and file employees to see if it's something they'd even want to use at all. It's also one of many classic examples of failed IT project management.
TL;DR: Basically, everybody who it applies to should have a say in it.
Having worked my way up through every level, the biggest thing I've learned is "correct" is amassively subjective concept, based on value statements people at other levels don't see.
To take a deliberately simple case:
I would have declared a manager insane for buying Office365 licenses. After all, you can buy copies outright for less.
Except, as that manager, any savings I get are dwarfed by the pain in the ass of keeping licensing info. Some idiot loses the info and you're out far more than the difference when you have to re-buy. Or you don't re-buy and you're vulnerable to huge fines. Or you have someone dot every i and cross every t and you pay more for their salary than you save. Or Office365 keeps everyone licensed and demonstrably so.
Same goes for commenting.
Earlier in my career, commenting was slow. I could understand my code just fine without it. It was clearly readable after all. What idiot manager wants less productive code after I jumped through hoops?
Now I've paid the price of countless devs who write code no one else can follow. If watched countless more declare they have to rewrite everything because the previous guy who swore his code was readable wrote something the next guy swears is not. My perspective is completely different. I'd now rather each person codes a little slower so the company moves faster overall.
Who's right? Everyone has a good perspective but each is colored by the values that they weigh in.
I know my devs often think my calls are "wrong" because they assign different values to those I do... But I also know I've been put in the position exactly because I have the perspective I do. The best I can do is try to explain and help them understand, listening when they genuinely see something I've missed.
Of course it is easy to show how blind management is, However it IT guys are not blame less.
IT has a history of the following bad behavior, that would make management want to find a way to slim its IT Staff.
1. Personal pet projects: This is often a business related project, however there are alternatives that may work better, however it IT worker is too emotionally interested in keeping it going, then giving it up for a better solution. Hanging on to the couple features that has that the others do not.
2. Attempts to make you "Irreplaceable": Sure that program your infrastructure you support is impressive, and perhaps no one else currently will want to touch it with a ten foot pole, and it is your baby, that is keeping the organization running. However in case of accidental death or injury the company is in a bad place, so they will want a better solution. And BTW just because people don't want to touch it, if they have to they can and will be able to maintain it, no matter how hard you make it.
3. Failing to project in the future: If they move to a cloud service, then your job is antiquated. However have you been future proofing yourself. Realizing the role you need to take after that particular feature moves away?
Now I am not trying to blame us IT guys for every stupid business decision... However you need to realize our personal bad behaviors do get noticed up, and influences business decisions.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.