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.

Comments

The answer is yes

[Todd Knarr]

The first call comes from the technical people, and answers the question "Is the company technically able to move to the cloud, and if not what's required to get it to that point?". Once you've got that covered, then business can decide whether it makes sense to move and whether they want to invest what it'll take to make it happen. If it isn't technically possible it doesn't matter how much business wants it, and business can't make a determination about investing what's needed to make it possible if they don't know how much investment it'll take. You can't make a cost/benefit decision if you don't know the cost.

Re:The answer is yes

[CaptainDork]

I went through this.

Management and I met with the cloud salesperson and technical rep.

The tech rep was full of shit. When asked, he said response time would be FASTER. I objected on the grounds of the restriction of the speed of light.

Our current servers were in the next room via Ethernet.

The cloud was "out there."

I asked, "What fail-overs do you have?" They said that the cloud was in Austin and if it failed, Oklahoma would pick up the slack so fast, we wouldn't feel it.

After the meeting, I called the business number in Austin and asked for support. I got a kid and I asked him if the data center was there in Austin.

He said, "No, but we're thinking of building one."

I said, "How about the one in Oklahoma?" He said, "Cool. We have one in Oklahoma?"

Management loved the word, "cloud." "Cloud." "CLOUD."

It sounded good at cocktail parties and conference rooms and in front of clients.

--

I recommended that we not go with those crooks and I laid it out very plainly, calmly and stuff.

Long story short ... I told management that my recommendation was on the record and that the IT department would certainly support any decision they made.

They took the bait.

6 months later and $60,000 down the road, I got the word to buy servers and switches and stuff to and to quietly duplicate all the stuff in our old computer room.

The cloud had gone down several times and there was no fail-over. It was slower than molasses and exceedingly expensive.

The blow that cracked the nut, though, was the long list of cloud hacks and the business (law) could not risk a breach by placing client data God knows where.

We're supposed to know where God put it, right?

We do now.

lets not beat around the bush.

[nimbius]

Finance. finance declares after 4-6 quarters of overspending on marketing and travel that belts need tightening and austerity is upon us. ragged edge carpeting and burnt out sections of office that havent seen a new coat of paint or replaced bulbs since the Clinton administration are passed over and the finger is pointed squarely at the company to stop renting beamers for golf outings. IT staff with crispy mice and rubbery keyboards are glowered upon and in turn the management steps in, begrudgingly, and does what management does to get the harsh glare of 'why do you have 5 monitors' off the team. Clouds are looked at, RFQ's are drafted, 30 minute powwows with the team are conducted and the reigning PHB compiles a short-shot list of the top 3 potentials to outsource the companies infrastructure to at a greatly inflated cost savings.

then its up to "the business" which in turn will glaze over as 3 choices are paraded out and the one with the most ad-buy in the seatpocket magazines on the flight to shanghai the CEO had to memorize for 17 hours gets chosen. After 3/4ths of the infrastructure is hauled kicking and screaming into the cloud, BIS screams bloody murder and keeps their mainframe while the exchange instance now shits the bed once every week. bitchcraft from the business about slow access, lost data, weird permissions, unplanned outages and lack of any discernable support chain are summarily compiled into a ticket system and ignored as IT staff shuffle together the last mighty years of their work into a functional CV and start shoveling tradeshow trinkets from their desk into boxes 'just to clean up a bit.'

6 months later half the team bails, the last guy who knew how to handle multifactor stuffs a notebook full of scribblings into a managers mailbox, and "the cloud" suspiciously gains 3-4 new employees with an impeccable history of providing excellent service and designing robust systems.

Simple experiment--

[sillivalley]

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?

Re:Whoever pays the bills

[ArmoredDragon]

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.

"Correct" Is Subjective

[nick_davison]

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.

Re:"Correct" Is Subjective

[Jack Griffin]

Having worked my way up through every level, the biggest thing I've learned is "correct" is a massively subjective concept, based on value statements people at other levels don't see.

This pretty much sums up most Slashdot comments whenever the word management is used. Worker-bees are simply unaware of the complexities and conflicting demands that someone with responsibility faces. Instead of thinking hey that decision doesn't make sense, there most be more to it that I don't understand, the general reaction is, there's a decision I don't understand, that guy is a moron.
The ironic part is that by calling out the decision as stupid they are merely highlighting their own stupidity that they've failed to grasp the full nature of the problem.
TLDR Stupid people are usually too stupid to realise that they're stupid.

Re:Whoever pays the bills

[jellomizer]

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.

Re:Whoever pays the bills

[Endymion]

How a plan becomes policy

In the beginning was the plan.

And then came the assumptions.
And the assumptions were without form.

And the plan was without substance.
And darkness was upon the face of the workers.

And they spoke among themselves saying,
"It is a crock of shit and it stinketh."

And the workers went unto their supervisors and said,
"It is a pale of dung and none may abide the odor thereof."

And the supervisor went unto their managers and said,
"It is a container of excrement and it is very strong, such that none may abide by it."

And the managers went unto their directors, saying,
"It is a vessel of fertilizer, and none may abide its strength."

And the directors spoke among themselves, saying to one another,
"It contains that which aids plant growth and it is very strong."

And the directors went unto the vice presidents, saying unto them,
"It promotes growth and is very powerful."

And the vice presidents went unto the president, saying unto him,
"The new plan will promote the growth and vigor of the company, with powerful effects."

And the president looked upon the plan and saw that it was good.
And the plan became policy.

This is how shit happens.