The experimental phase is also the first opportunity to increase user buy-in. This is the reason why user training and support should already be planned in the pilot.
The initial phase should teach the principles of the Google Apps solution. This step is essential, since the Google Apps cannot be used exactly like a traditional mail client and because its specifics are precisely what makes its strength. Users with no knowledge of the Google Apps and without prior preparation are not likely to become spontaneous advocates for the new solution: giving them adequate information and preparation increases the likelihood that they'll want to spread the good word later on.
Training may be adapted to various populations depending on their needs. You might want to consider sessions of the following kinds:
- User training on Gmail and Google Calendar.
- User training on Google Sites, Google Docs, and Video.
- Administrator training for the Google Apps console.
- Administrator training for the Postini services.
An example of training session for users and administrators
Many sources of information are available. Online help is available directly from within each tool, although it seems best suited to technically savvy users. There also exist numerous video tutorials for non-technical users.
Google's help center
The next level of support is provided by "ambassadors." These are users that have Google Apps expertise that they obtained either by taking a special training course or through prior use of the tools.
While the pilot project is going on, it is a good idea to organize work sessions to answer user questions. The sessions can be prepared easily by sharing a spreadsheet (see Chapter 4 for a presentation of the tool). Each pilot user enters the details of the problems he or she encountered in the spreadsheet. Ambassadors should try to qualify the user questions according to what relates to user interface and what are genuine defects. In this case, the spreadsheet can also be used to centralize the positive feedback from users (see the next section, devoted to the results of the pilot).
Example of a user scorecard as a Google Spreadsheet
Creating a more complete communication workspace is another possibility (FAQ, forums, wiki, mailing list, and so on). A moderator from the IT department should however monitor the platform to ensure it is working properly and also to identify the most active users and then rely on them to propagate information.
Getting assistance from an integrator among Google's partners can help with the development of support capabilities. Google's own support is also available to anyone who has subscribed to the Google Apps Premium Edition.
Support organization with a Google approved service provider
The purpose of experimentation is to assess the level of user satisfaction in the pilot group. For this purpose, you should define a set of criteria and sub-criteria weighted with their importance and use them to evaluate the solution. These same criteria can be applied to the existing solution as a means of comparison.
Here is a possible classification:
"Features" designates the set of criteria and sub-criteria related to features. Ideally, the minimal coverage in terms of requirements is defined by the existing solution. Additional or missing features in the new solutions will count as positive or negative points in the final evaluation. Criteria should be weighted.
"Usability" is about human factors, such as user experience or the quality of documentation. Most user feedback is on user experience.
"Reliability" refers to reliability and availability aspects. Google is committed to 99.9% availability of the Google Apps solution, which is equivalent to 8 hours unavailability in one year. In the event of unavailability of its services, Google is committed to compensating its customers. More detailed information on SLAs can be found in the introduction of Part 2 of this book.
Google ensures the privacy of all communications between you and Google Apps. The data is stored in fragments in many servers, which increases privacy and safety. These issues were discussed in detail in Chapter 2.
"Performance" includes criteria and sub-criteria such as response time and resource consumption. Evaluation of the solution using these criteria is usually the administrator's responsibility. Bandwidth consumption, storage space, and archiving abilities should be evaluated.
"Supportability" covers criteria such as adaptability, maintainability, interoperability, or portability of the solution.
The level of interoperability with other application in the IS should be assessed separately. The Google Apps solution offers a set of programming interfaces using standard protocols and architectures. These APIs facilitate integration and improve interoperability (XML, REST, and so on) between Google components and other applications. Furthermore, the Google Apps solution complies with standard authentication architectures (SSO, OpenID). Google takes full responsibility for the maintenance and evolution of its solution.
Results can be summarized in a radar diagram, an example of which is depicted in the following figure:
An example of comparative evaluation between Google Apps and an existing solution