Thoughts on why one company decided not to move to Google Apps

A recent article on CIO.com asked the question “Can Google Apps Unseat Microsoft Office and Exchange?” Many similar articles are published to help advise CIOs and budding CIOs about the deep and serious choices they will have to make about technology. Take the wrong decision and your career is a bust, make the right choice and your reputation is secure and you become a CIO par excellence. Or so the theory goes.

Given the topic, I had a certain interest in the article. There’s always a possibility that you can learn something from the experiences of others, even if this article focused on a small 500-user company (New England Biolabs) in a highly specialized area (molecular biology) that might not be a good prototype for other companies that are considering making a switch.The trial to figure out whether Google Apps could replace Office and Exchange was carried out  by 24 users over 60 days. Not many companies could dedicate nearly 5% of their total user population to testing new software, so this was somewhat out of the ordinary. All of the testers were Gmail users for personal email and the company operates heterogeneous platforms (Windows, Mac, Linux).

From the text, I think that any notion to deploy Google Apps foundered on three points:

1. Disruption to user habits and potential reduction in productivity. The article said that “Email, calendar, and document management are fundamental to how people work” and reported that the testers found the work required to move to Google Apps posed an obstacle, with Gmail being particularly cited. People develop their own methods to manage information that’s necessary to do their work and forcing users to change work habits can result in a surprising loss of productivity simply because users have to think about how to do something rather than doing it automatically. Gmail’s approach to email is very different to Outlook’s. Gmail allows users to label mail for easier retrieval but depends on search to locate essential items when required. Outlook follows the more traditional folder-based mechanism where items are placed into a folder structure determined by the user. Perhaps because good search facilities are a reasonably recent innovation, email systems have used the folder-based approach for as long as I can remember.

I actually think that the importance of folder-based filing will gradually erode as time goes by for two simple reasons. First, millions of people know how to exploit the search-based model because of their exposure to Gmail. Second, the latest version of Outlook and Exchange work together better than ever before if you decide to ignore filing and depend on search. Various limitations on the number of items in a folder or mailbox size have been gradually increased and better search facilities are available through Windows Desktop Search or Exchange content-based indexing. It’s likely that the introduction of FAST-based search across Exchange, SharePoint, and Lync in Office 15 will improve matters even further.

2. IT management might not understand the features that are most important to users. This is actually pretty common and surfaces all the time in migration projects when features that users really like either disappear or are altered in such a way that people don’t understand how to get their work done (think of the introduction of the ribbon interface in Office 2010). In this case, track changes in Word, effective multi-calendar management, and good offline access were important to users. I can sympathize with the users here because I use these features extensively myself and wouldn’t move unless the alternate system offered better features in these areas. The lesson here is that IT departments need to understand what’s important to their users (and why) whenever they embark on a consideration of system changes.

3. Changing circumstances can alter decisions. In reading the report, it seemed that a major driving factor in the decision to even look at Google Apps was the multi-platform nature of the company and some problems with document management with SharePoint across Windows and Mac. But then the advent of SharePoint 2010 and Office 2011 for Mac eliminated a lot of the problems and created a completely different support environment for the IT department. Such is the nature of technology. New versions come along all the time and the bug fixes, enhancements, and new features that are included might eliminate problems that frustrate, cost, or otherwise infuriate users and IT departments alike. Given that Office 15 is on its way and is likely to be available in early 2013, it would be wise to take it into account of any project to analyze future technical directions.

I also noted the remark from users that “we really like Outlook” and wondered once again whether Google isn’t cutting its own throat by not producing a fully-functional integration between Outlook and Gmail that completely disguises the fact that Gmail is the server. Other companies (think of Zimbra Collaboration Server) seem to have done a better job than Google here, perhaps because they use a MAPI-based connector rather than depending on IMAP4. If Gmail and Outlook really worked together flawlessly, would this comparison have come down on the side of Google Apps? I don’t know, but I suspect that the result might have been closer, if only because companies find it difficult enough to change out parts of their server infrastructure (on-premises or cloud) without having to go through desktop upheaval too.

New England Biolabs decided to stay with Microsoft and move towards a hybrid platform where Office 365 will be used for remote and  international users. Some might ask why such a small company wouldn’t move completely to Office 365. I guess the reason is that the specialized nature of their work and the intellectual property that represents major assets of the company mandate the tight control and management of applications that can be better accomplished when run on-premises. At least, that’s my interpretation.

Follow Tony @12Knocksinna