A case study of “going to the cloud” (SaaS)

Here’s one series of questions that’s great to ask a candidate for a senior position in IT, be it in project management, development, operations, or whatever: Tell me about a recent project or initiative for which you were responsible. What was the goal, and how did you ensure that the goal was achieved? What were the roadblocks you encountered along the way, and what did you do to address them? What mistakes did you make? What would you do differently if you were faced with a similar project or initiative again?

For this post, I’ll play candidate and outline the kind of full and detailed response I would be looking for as a hiring manager, based on a project from my own experience. Let’s use a relatively simple one: implementing off-site (Software-as-a-Service, known as SaaS) email, replacing a poorly implemented in-house email system. Today, this would loftily be called “going to the cloud.”  (Yes, I’m aware that cloud computing encompasses far more than SaaS, but that’s not my thrust here).

As the incoming CTO at an Internet social networking company several years ago, I quickly observed that an unacceptable percentage of my IT staff’s time was absorbed in administering, troubleshooting, and user handholding related to the in-house email system, a third-party substitute for Microsoft Exchange.  But far more than the high cost factor was at stake: the flakiness of the company’s email and calendaring system had become both a cultural punchline and, frankly, an easy company-wide excuse (a little like “the dog ate my homework”) for people missing meetings and failing to communicate on key initiatives. Undeniably, meetings were indeed disappearing regularly from people’s calendars, and even simple meeting scheduling required using an unintuitive workaround to guarantee that all recipients would get the meeting notice. So, our goal was two-fold: reduce cost and staff distraction significantly, AND (most importantly) give the company a solid, reliable system for internal and external communication.

The mail server package had been implemented several years before my arrival as CTO, apparently without a careful plan or study, and mostly as a gut reaction by a then-VP of IT who simply loathed Microsoft and wanted a non-Microsoft solution. A significant portion of a DBA’s time, not to mention that of the entire help desk staff, was being expended in support of the system, not to mention the high hardware and software maintenance costs. My staff, and just about all users, detested the system. But oddly, roadblocks were present nonetheless:

• staff resistance on changing out a system they regarded as part of their job;
• CFO reluctance to make changes in general, and especially reluctance to go to an external email provider (concern about loss of control).

One lesson here? Things are never so bad that people drop their innate resistance to change!  But I digress.

We countered these roadblocks via several approaches:

• We surveyed all users in the company for their views of the system and tolerance for change in this area, and fed this feedback into the resulting action plan.
• We constructed a thorough cost analysis of the status quo: how much the current solution was costing the company in both hard and soft costs. I used this analysis to obtain executive buy-in, and to specify in detail what the cost and effort would be to fix it.
• We made sure that both junior and senior staff were involved in the methodical evaluation of alternative approaches, including the alternative of keeping the status quo. This helped achieve staff buy-in.
• We brought our “short list” vendors in for week-long user proof-of-concept trial periods, getting both staff and user feedback, thus defusing a lot of the “loss of control” type of uncertainty regarding the change.
• We negotiated hard with our “short list” vendors to obtain a good deal for the company.
• We worked hand-in-hand with our excellent legal staff to make sure we were well protected in terms of vendor SLAs, security, etc.
• We constructed and followed a careful user communication plan, keeping everyone informed of the rollout schedule via FAQ-style emails.

The rollout of the chosen solution went fairly smoothly.  We failed to identify two key risk areas or areas of concern clearly enough, though:

1. Users were much more concerned about calendar migration (old appointments and their attachments) than we had anticipated, and somehow this didn’t come out in surveys etc. before the implementation; we responded not by migrating the old items (expensive and difficult), but by keeping the old system running for a period of time after system rollout of the new solution, and that seemed to be satisfactory.
2. Users had great difficulty adapting to a 250MB email space limitation, since they had effectively had “no limit” (albeit poor performance and terrible stability) under the old system.  Even though we had discussed that limit in advance, done benchmarking across similar companies about their space limits, and gotten clear user buy-in, it still might have been better to consider a higher limit (and hence more cost) as we sought expenditure approval.

Now, just three years or so later, I’d do several things differently:

1. obviously, anticipate and avoid the mistakes itemized above;
2. consider using Google’s business email offering (we ruled it out since it was brand-new as of the time of the implementation, but it offers a much greater storage limit than any other provider I’m aware of); and finally,
3. implement sooner rather than later. Why sooner? The implementation and system was such a success that despite the bumps and concerns I just named, there was no more constant hallway conversation about the email system. It had ceased to become a concern, and also ceased to become an excuse.

And bottom line for the company, besides those productivity benefits? The total cost of running our (now very stable) mail system had dropped to the equivalent of just one FTE, about a third of what it had been.  Happier staff, happier users, and much lower costs: all projects should be so fortunate.

Lagniappe:

• Maria Spínola, “An Essential Guide to Possibilities and Risks of Cloud Computing“
• Michael Coté, “Don’t confuse SaaS with Cloud Computing“