Get documents about "Google Apps Project Plan
Document Sample
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
Google Apps Education
Project Plan
Revision History
Date Version Description Author
24/11/09 1 Draft for Revision of GAE Project Group Eduardo Ossa
1/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
Content
Page
Google Apps Education Project Plan 1
Revision History 1
Content 2
Introduction 4
The Contract 6
Signing of the Contract 6
Service Term 7
Terms of Service (“TOS”) - Overview 7
Agreement 7
College Use of the Service 7
Security 8
Changes to the Contract 8
Google Ads 8
College Obligations 8
Privacy 9
Abuse and Postmaster Aliases 9
Classification of End Users in different Domains 9
Terminology 9
System Administration Responsibilities 9
College Responsibility 9
End User Administrators 10
Admin Tool 10
Technical Support 10
Technical Support Service Guidelines 10
Business Requirements 12
Objectives Scope 12
Project Management Efficiency 12
Effectiveness of Policies and Business Processes 12
Objectives for different Services 12
Objectives for different Users 12
Compliance 13
Objectives Definition 13
Objectives, Dependencies and Terms of Service Grid 13
Objectives, Dependencies and TOS Definition Process 13
Other Universities Experience 14
Anticipate likely critical issues 14
Different Sub-domains for different users 14
Change Management - Staff and Business Processes 15
2/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
Pilot Group and the UAOD function 15
Contributing to Staff Moral and to a Successful Transition to Greenwich 15
Technical Requirements 16
Infrastructure 16
Application Programming Interfaces (APIs) 17
Migrating Data (Email Migration) 17
Dynamic Grouping 17
Integration Testing 18
Implementation 19
Action Plan and Timelines 19
System Customisation 19
Marketing Issues 19
System Name and Logo 19
College Re-branding and Google Apps Project 19
Implementing the Business Objectives 19
Business Processes 20
End User Administration 20
College Wide Business Processes Supported by Google Apps 20
Populate Rooms in Google 20
Email Client 21
Dependencies 21
HR System – Directory Server Synchronisation 21
Accounts De-Provision 21
Single Sign-On (SSO) Further Developments 22
CELCAT Timetables plug-in 22
Awareness Campaign 22
Check Lists 23
Going Live 23
Live Manage - Life after Implementation 23
Appendixes 25
Appendix One – Glossary of Terms used in Google Contract 25
Useful clarification of terms for managing the Google project / service, as defined in the
agreement - (Section 15): 25
Appendix Two – Stakeholders, Objectives, Policies, Dependencies Definition table 27
Appendix Three –Google Apps Education Project Assessment -18/11/09 30
3/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
Introduction
The replacement of the current email and calendaring systems is imminent. The
current servers IPlanet Sun Messaging and Oracle Calendar can no longer support
these vital operations of the College for both staff and students.
It was decided some time ago, to replace these systems with Google Apps
Education, a package which comprises more than the two services requiring
replacement and that, in consequence, could introduce new business functions to
the College.
The project was initially planned to be delivered last summer (see more details in
the appendix number three: “Google Apps Education Project Assessment by
18/11/09”)
In a meeting of 18 Nov 09 1 it was concluded that this implementation urgently
needed project management2. Relevant information is required to enable a
decision in this respect.
The present document intended as a discussion input, aims at providing such
information.
It does not enter into details but aspires to be complete as a basis for a project
plan. When the most critical factor is the lack of time it is extremely important to
1
Present: the Director of Quality and Academic Services, the Director of Transition Operations and
Delivery, the Director of Information Services, the Head of IS and the Head of ICT, the Technical
Programme Manager, and ICT‟s Digital Infrastructure Operations Manager and Security Administrator
2
See the assessment of the situation, as per 18/11/2009, presented by the Head of IS when
requesting the meeting.
4/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
redouble care and to focus on the important. Lack of information and rush could
easily lead to costly errors or even failure.
5/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
The Contract
1. The College subscribed to the Education Edition, which is free (no fees) for
accredited institutions. See the summary of its main features compared to the
other type of contracts in the table copied below3
Signing of the Contract
3
Source: http://services.google.com/apps/resources/overviews/welcome/topicWelcome/page15.html
6/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
2. The agreement was signed on line, on (date – effective date of the
agreement), by (name of the employee of the College) duly authorised by the
Director as the legal representative of the College on (date – or MC meeting,
email, etc).4
3. With the subscription the College received from Google the password and the
Admin Account and set a “Notification Email Address” for the college to be
officially notified by Google of any changes or issues pertaining to the contract.5
Service Term
4. The duration of the contract is four years beginning on the Service
Commencement Date;6 it will be automatically renewed for consecutive twelve
month terms. To stop the automatic renewal we must tell Google sixty days prior
to the end of the applicable term.
Terms of Service (“TOS”) - Overview
Agreement
5. The Agreement binding the College and Google, which governs our access to,
and use of the service, also known as “Terms of Service” (TOS), can be found at:
http://www.google.com/apps/intl/en/terms/education_terms.html
College Use of the Service
6. The agreement states, in general, that the College can use the service to:
a) provide End User Accounts to our End Users; and
b) administer End User Accounts through the Admin Console
4
Section 10.1: signing meant each party had full power and authority to enter into the Agreement
5
The administrative credentials (user name and password) and email address were documented at…?
6
End User Accounts requested after the Service Commencement Date will have a prorated term
ending four years from the Service Commencement Date.
7/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
Security
7. Google is obliged to reasonable security standards, no less protective than the
security standards at the facilities where Google stores and processes its own
information of a similar type.
Changes to the Contract
8. Google can modify the services making reasonable efforts to notify the
customers. Google can also modify the terms of the contract but for this they
must notify the College via the “Notification Email Address” or alerting via the
Admin Console. If we do not accept the contract changes (only because the
change had a material adverse impact on us) we can continue under the previous
contract until the end of the current term but Google won‟t renew the next term.
Google Ads
9. The default setting for the Services is one that does not allow Google to serve
Ads. Customer may authorize Google to allow Ads. If Google gives the College the
capability to show Ads only to particular sets of End Users, then we must enable
Google‟s to serve Ads to users who are not students or staff (and must enable the
serving of Ads to Alumni).
College Obligations
10. We have to comply with the Agreement (quoted above [5]) and the
Acceptable Use Policy (“AUP”) as defined in the following URL:
[http://www.google.com/apps/intl/en/terms/use_policy.html] Basically the AUP
states that the College won‟t, and won‟t allow its End Users, to use the services
for any unlawful, invasive, infringing, defamatory, or fraudulent purpose; and
other more specific uses restrictions set by Google7; see the AUO. We are bound
7
As for example unsolicited bulk commercial email, or circumvent any aspect of the services, or to
test or reverse-engineer the services to find vulnerabilities or evade filtering capabilities; or to use a
component of the services in a manner not authorized by Google.
8/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
to all reasonable efforts to prevent or terminate any unauthorized use of the
Service; and to promptly notify Google of any such case of which we become
aware (section 2.5 of the Agreement).
Privacy
11. We also agreed to protect the privacy rights of the End Users, and to obtain
and maintain their consent for us to monitor, use or disclose data, and for Google
to provide us with the ability to do so. We are also responsible for obtaining any
authorizations from the user to enable Google to provide the Services (see
section 2.4 of the Agreement).
Abuse and Postmaster Aliases
12. The College will be solely responsible for monitoring, responding to, and
otherwise processing emails sent to the “abuse” and “postmaster” aliases for
Customer Domain Names, but Google reserves the right to be copied on emails
sent to these aliases for Ravensbourne Domain Names.
Classification of End Users in different Domains
13. The College can choose to separate different classifications of End Users by
domain.
Terminology
14. For a more effective communication it is useful to clarify the terminology used
in this project for Google service. In the appendix number one of this document
we present a glossary of the most useful terms as defined in the agreement
(Section 15).
System Administration Responsibilities
15. The Agreement clearly states (section 2.3) that Google is merely a data-
processor. In consequence, Google‟s responsibilities do not extend to the internal
management of the email system. This responsibility to manage the system
and users corresponds to the College.
College Responsibility
16. With the signing of the agreement (section 2.3), we expressly accepted
responsibility for the Administration of the System:
9/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
ensuring that all Admin Activities comply with the Agreement
designating the employees who are authorized to access the Admin
Account, and
maintaining the confidentiality of the password and Admin Account
End User Administrators
17. The College thus should appoint one or more “Administrators” that through
the Admin Console will have the rights to access the Admin Account and to
administer the End User Accounts.
Admin Tool
18. Google provides the College with the Admin Tool only to manage the service,
any misuse of the Admin Tool is considered a material breach of the Agreement
(section 6.4 of the Agreement).
Technical Support
19. As stated above (6, 15 and 16) the administration of the system and of the
End Users corresponds to the College. This administration of the service also
encompasses technical support. With the subscription of this agreement (section
4.1), the College expressly acquired the responsibility to, at our own expense,
respond to questions and complaints from the End Users (or third parties relating
to the College End Users‟ use of the Service), ensuring reasonable efforts to
resolve the issues on our own without escalation to Google.
Technical Support Service Guidelines
10/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
20. If we could not resolve a technical support issue we may escalate the issue to
Google but in accordance with the technical support services provided by Google
to the Administrators “TSS” guidelines” 8
8
For the TSS, see the following URLs: http://www.google.com/a/help/intl/en/admins/tssg.html and
http://www.postini.com/supportinfo , or such other URLs as may be provided by Google.
11/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
Business Requirements
Objectives Scope
21. It is very important for the success of this project, to define in clear and
concise terms the institutional objectives sought with the provision of Google
Apps for the College.
Project Management Efficiency
22. With clear goals, the implementation of the system can be project-managed
much more efficiently. Clear business goals ensure correct prioritisation, and in
the event of an emergency are essential for contingency decisions.
Effectiveness of Policies and Business Processes
23. A clear definition of policies and business processes is also essential. Once the
system is up and running, the success in achieving the College business goals
depends on them.
Objectives for different Services
24. Google Apps Education comprises a set of different systems: “Gmail”,
“Calendar”, “Google Docs” (Word Processor, Spreadsheet and Presentation
Programs with collaboration capabilities), “Sites”, and “Talk”; all accessible
through a single “Start Page” and under the same term of references “TOS”.
Therefore, the best way to define the business objectives for this project is to go
one by one, making sure to understand what each one of them consists of, so
that finally we can formulate in an equal series of concise statements what it is
that the College wants by giving them to the users.
Objectives for different Users
25. The same service (for example calendar, or docs) could have different aims
according to the type of user to whom the service is provided. The objectives
thus, should also depend on whether the provision is for staff, students, or
eventually other groups (alumni, EIC incubetees, extended access, etc); or for all
users.
12/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
Compliance
26. The formulation of these College objectives for each service and type of user,
have to be in line with Google‟s “TOS” which the College accepted when the
contract was signed.
Objectives Definition
Objectives, Dependencies and Terms of Service Grid
27. To facilitate the completion of this requirement as well as the inclusion of the
College stakeholders, or the different offices that should participate in this
determination of the objectives, we suggest the following tool or table of
“objectives definition, determination of dependencies, and terms of service”. See
Objectives-Definition-Grid.xls – Appendix two (below the grid contains just one
example of such definitions).
Objectives, Dependencies and TOS Definition Process
28. Process proposed:
13/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
Step one: initial consultation with the Senior Managers to identify the stake
holders participating in the discussion of this requirement determination.
Step two: Preparation of a briefing to explain in clear and simple terms each of
the services and Google‟s “TOS”. The document will be distributed, previous to a
discussion meeting, to the stakeholders together with the tool described above
(27). The document to be prepared by IS or ICT).
Step three: stakeholders should prepare individually for the meeting (IS or ICT
will give support for any clarification).
Step four: stake holders meeting to:
a) Define the objectives
b) Agree on dependencies, policies and terms of service, and
c) Agree on actions for dependencies and on policies amendments if
required, including time lines.
Step five: A report should be submitted to Management Committee for ratification
or amendments of the recommendations agreed at the stakeholders meeting(s).
The final document would to be used for project management purposes.
Other Universities Experience
29. Parallel to the above process we can benefit from what other universities
have done. Their experience could be valuable for us to save time and make
better use of our limited resources. The following UK HE institutions have been
highlighted by the press as being particularly successful with Google projects: De
Montfort University, University of Portsmouth, University of Sheffield, and
Sheffield Hallam University. We have already established contact these
institutions for visits, telephone conferences or simple queries to go along with
the advancement of our project.
Anticipate likely critical issues
30. It is probable that a single meeting for business requirements is not enough.
Certain decisions may require further research, technical tests or even escalation
to Management Committee. These will need to be closely followed by project
management in order to deliver on time and at the same time without the risks of
multiplying a difficulty for unduly avoiding the efforts required to tackle it at
inception when it was more controllable.
Different Sub-domains for different users
31. For example keeping all the different types of users (staff, students, alumni,
EIC, etc.) under the same domain is a decision that main need more careful
consideration. Different sub-domains, at least for staff and students may be more
14/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
appropriate in terms of records management, systems administration,
compliance, and easiness of communications. A decision in either way should be
better informed to truly weight the consequences. The Google Apps Deployment
guide brings some types of domain names that are popular, for example
“@student.school.edu” (this in US); this will be equivalent to
“@student.rave.ac.uk” translated for our College in UK.
Change Management - Staff and Business Processes
32. When one is used to do things a certain way, the introduction of a change
could disrupt, albeit temporarily, personal productivity. These disruptions may
turn really frustrating if a real gain is not clearly perceived with the change.
Google tools may have an advantage here. There seems to be a general
consensus in that they are appealing to the individual users. However, the way
we are used to do things as an institution may change considerably and current
business processes no longer be adequate.
Pilot Group and the UAOD function
33. The Google Apps Deployment Pack recommends: “Get acquainted with
services (email, calendar, docs, sites, start page, talk): • on test domain, create a
pilot group of user accounts to test services”. This pilot group should be set up
parallel to the definition of objectives to build knowledge on reciprocal feedbacks.
It should aim at emulating the current environment (i.e. today‟s user
administration, policies and procedures) to decided on the feasibility of continuity,
or to probe the changes required. The User Administration and Operations
Developer (UAOD) role should be pivot to this group, because a)it will contribute
to the completeness of the test on the basis of current experience, and b) it will
gain training on the new administration environment (different admin console and
APIs) for the outsourced service.
Contributing to Staff Moral and to a Successful Transition to Greenwich
34. If uncertainty is avoided and the project team manages to develop a real
sense of inclusion for all stakeholders and the whole community, the Project
surely will be contributing through the well being of the users to a favourable
attitude towards the transition. Delivered on time and duly supported, the project
could be positively associated to the actions in preparation for the move.
However, the opposite will be equally true. An extraordinary effort and care are
required at this critical stage to conduct the project in the positive way.
15/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
Technical Requirements
35. Basically we are outsourcing our mail servers (including webmail servers) and
our calendar server. Our old servers will be decommissioned and the service will
run on Google‟s servers, at their premises, managed and maintain by them.
However in order to be able to synchronise our systems with Google we
introduced new pieces (hardware and software) to our technical infrastructure,
and are still completing the technical requirements with other pieces of software
or Application Programming interfaces (APIs).
Infrastructure
36. ICT has successfully installed, configured, tested and documented the Identity
Infrastructure server and synchronisation program:
a) Atlassian Crowd Identity Infrastructure
https://confluence.rave.ac.uk/confluence/display/ITIS/Atlassian+Crowd+Identity
+Infrastructure
b) Google Apps Directory Sync
https://confluence.rave.ac.uk/confluence/display/ITIS/Rave+Google+Applications
+Pilot This is a tool provided by Google to synchronise users and groups between
them and our directory server; it allows as shown in the figure below9,
synchronisation of username and passwords, email etc.
9
Source:
http://www.postini.com/webdocs/training/en/DirSync_GoogleApps/DirSync_GoogleApps.html)
16/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
Application Programming Interfaces (APIs)
37. Some of the APIs available from Google may be needed and will require
implementation but some (at present it seems at least one) would need to be
developed by the College or contracted to a third party.
Migrating Data (Email Migration)
38. We will need the current content of our Inboxes (especially for staff and
mostly for messages that constitute records) to be available in the new system.
Although Google provides an API for this function, it was not needed and ICT has
rather successfully implemented and used the Google IMAP Migration tool in the
accounts tested. The time for migrating all of the Inbox content varies
considerably for each user according to the files‟ size. Therefore a careful
estimation of the likely time required for migration of the different user groups
(staff departments, student courses) will be necessary to plan the duration and
opportunity for the migration.
Dynamic Grouping
17/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
39. Our mail groups are of two types: static (consisting of simple manual list of
members) and dynamic (members automatically grouped on the basis of certain
attributes in the Directory Server). It seems Google does not support dynamic
grouping and so IS will have to develop and implement a Sync Service using a
Google API for this. Besides this technical requirement it is important to quality
check the mail groups that we are going to transfer to the new mail system
(business requirement): currently we have more mail groups than full time
members of staff (111 groups by April 09 and 103 full time staff by 31 August
09).
Integration Testing
40. Although testing has been happening along with the implementation of the
technical requirements (as part of the implementation); from a project plan view
it is important to refer to the testing the whole solution of a phase on its own.
Once the technical requirements are all in place, it is important to proceed to a
quality checking with the project team, update the project with questions,
concerns, and changes, and set the new timeline for changes to happen if
required and notify all the staff involved). The Help Desk should also be involved
as a way of leveraging their training for „User Support‟.
18/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
Implementation
Action Plan and Timelines
41. As Google puts it, to make sure we‟re all speaking the same language, go
live means the date that our users can start using Google Apps. Because we have
different types of users we could have different “go live” dates, until completion
of the whole provision. Parallel to the Business Requirements determination, and
to the installation or development of the technical infrastructure, internal software
components, and correct settings tested Ok, it is important to put together a
plan, based in realistic estimations (i.e. informed at the level of detail) for the
different actions required to go live. Particularly we will need to focus on the
following aspects (involving different stake holders), each requiring a plan on its
own.
System Customisation
Marketing Issues
System Name and Logo
42. Google‟s Deployment Pack brings some helpful notes about marketing issues
for the project plan: “Branding brainstorm: choose a name for your email service
and collaboration suite. Giving your new email and collaboration tools a unique
name is an easy way to help people in your community to identify with the new
system. It also helps you build your school brand”… “Choosing a new name can
help you reinforce the change”. The pack also present some examples of what
other universities have done and give tips to choose logo (see the pack). “Once
you choose your name, you can build awareness in your community by using it
consistently in your online, resources, marketing materials, and press releases.”
College Re-branding and Google Apps Project
43. It is opportune to anticipate the impact of the current re-branding exercise.
Uploading logos and adjusting look and feel to changes in corporate images may
not be that difficult but is worthy to enquire for any issues now that could save
considerable time and money later (e.g. implications of domain name changes).
Implementing the Business Objectives
44. We will need to customize our account with information unique to
Ravensbourne (our policies, business processes, aim, etc.), and in line with the
rest of applications with which we are serving the users. This customisation will
ultimately be the product of the objectives defined for the business requirements,
19/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
and policies and strategy plan of the College, but could also be affected by
technical elements. It is difficult to list at this stage the whole set of business
decisions needing customisation (and this list could be extensive), but here is just
one example to illustrate the point: the strategies for Ravensbourne members
(staff, student, etc) to sign up to Google‟s terms and conditions that should be
based on Staff contracts, or Student Contract Handbook, College Policies, and our
responsibility for the Agreement and AUP, and that ultimately will determine the
customisation of the Start Page.
Business Processes
End User Administration
45. Current business processes for User Administration as we know them
(supported by our current email and calendar technologies) will change. Not just
because new the technologies bring a new way of doing things to achieve the
same business functions, but because they also bring new functions (docs, sites)
and, very important, because the business functions themselves, independent
from technology, are changing in line with the current transition of the College.
As with the business objectives customisation (44), it is difficult to list at this
stage the whole set of issues involved in these changes but they all will converge
in the user administration function of the IS department. We need to prepare the
change in process for many scenarios such as
How do we handle name changes? e.g. Marriage/Divorce
Forwarding of email from members of staff who have left
De-provisioning process according to a policy approved by MC
Configuration Google Docs ownership
Emergency away message for a third person
Calendar Senior Managers Restrictions and Designate powers.
Access request to other people emails
Extend access to someone that is no longer a member of staff or a student
College Wide Business Processes Supported by Google Apps
46. This is also a good time to start training your IT staff about the features of
Google Apps. Check out the Google Apps YouTube channel, which has dozens of
helpful how-to videos and features. Supported current email and calendar
technologies will change.
Populate Rooms in Google
47. The main data to migrate are the contents of personal mail inboxes as
described above (38), but we will have also to populate Google with the College
resources (mainly rooms) both form the current and the new building (depending
20/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
on the business decision). The rooms have already been migrated from the old
calendar to CELCAT and the latter will remain the authoritative source because
there is where the timetable planning and control takes place. However, there
also has to be in place a mechanism for controlling both copies in sync with a
clear business process to avoid conflicts.
Email Client
48. It may not always be convenient or advantageous for members of staff to
work through a browser when dealing with their emails. The selection and the
decision on the selection of an adequate email client compatible with Google
server to be supported by the College should also be part or the implementation
activities.
Dependencies
49. The progression of the project will cast more light on further dependencies;
hopefully the list to be fully completed at the definition of objectives. For example
the College decision on alumni relations: even if decided from inception that we
will not extend Google Apps to alumni, still we need to have in place a structure
such that could accommodate without excessive costs or difficulties an eventual
decision to include them, and that can cater for our current students to continue
with Google after graduation (issues of email address) if we haven‟t decide to
include the alumni.
HR System – Directory Server Synchronisation
50. It is well known the fact that current state of the staff IT accounts in the
Directory Server is in complete disarray. We simply cannot migrate all these
accounts (many of them not just of ex-staff but spurious accounts) to Google.
Trying to clean this manually would be unnecessarily expensive and not
maintainable. HR is currently doing an HR data audit Once this is completed the
HR System will become the authoritative source for the Directory Server through
the implementation of an automated synchronisation system, as the one that is
already running for the Student Records System (SRS). These actions are
expected to be completed soon. Once the first synchronisation is run successfully
the Directory staff data will be in shape to be synchronise with Google without
inconsistencies.
Accounts De-Provision
51. For better use of College resources and better Records Management practice,
it is an urgent a need of the College to adequately manage the termination of the
IT accounts. We are near to completing the implementation of the “IT Accounts
21/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
De-Provision Business Process”. We have advance up to quarantining ex-students
accounts and are about to set the correct mechanism to delete them, although
other priorities have come in the way of this line of action. De-provision of both,
staff and students, could be on time so that termination of Google accounts could
also be harmonised with the rest of College accesses in a single system.
Single Sign-On (SSO) Further Developments
52. Strictly speaking there was no need for the Atlassian Crowd Identity
Infrastructure (36) to provide a Google Apps Education service for the College.
We could have opted for Google‟s own authentication and login page, and thus
save the effort. The server was installed at this opportunity mainly as a strategic
move to keep the College at pace with technologies responsive to the current
demands of our environment, federated services, inter-organisations
collaboration, Software as a Service (SaaS) – Google Apps one of them, and
integration of the organisation‟s internal systems. Its real value then will be once
other systems are plugged-in to this identity infrastructure, above all the
College‟s own network login, as at this point we can truly benefit of portal
technology to harness the multiplicity of disparate and diverse services into a
unified business goal for the College. The experience of the user will also be
improved as he move seamless without having to login at every system.
CELCAT Timetables plug-in
53. We will need a synchronisation service from CELCAT to Google, to publish
timetables in calendar form. This will be a component that could be subscribed by
students or staff, for them to have timetable information up to date, in their own
personal calendars, and with out having to go the web published timetables
(timetable.rave.ac.uk). Indeed the managing of College Timetables and other
institutional calendars (e.g. Academic Calendar, College Calendar) is the
fundamental business reason for providing the students College calendar facility.
Awareness Campaign
54. Preparing users for change is key to a successful launch. The way the
information about the project is managed for the users greatly determines the
attitude with which the system will be received and in consequence can contribute
or hinder its success. Google‟s Deployment Pack emphasises this fact, with a
whole chapter in an awareness campaign. It brings suggestions and tips for this
notification to the users (staff and students); for example, Print marketing
collateral or Promotional materials, Host info session/demo session (i.e. consider
a table in your school‟s quad), Create a web landing page that outlines the
features and benefits of Google Apps at our institution – with relevant links at the
22/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
web and intranet most visited pages, Post an online internal FAQ about the
switch; and even provides help with templates for this (see the Deployment
Pack). The emails about the project sent to all staff and students also need
consideration from this viewpoint. As Google puts we also need to “build
excitement through trusted students and staff”. And finally, a Press release, that
can contribute to the corporate image of the College.
Check Lists
55. Implementation Check Lists are very handy tools for project management as
long as there is enough documentation to back their items up. In a loose context
they can turn to be equivocal or confusing. It will be useful to aim at generating a
check list for each major aspect of the project. See also the check list of Google,
provided with their Apps Deployment Pack.
Going Live
56. A final check list will need to be refined with the evolution of the project, but
a start using the system we will need first to:
A. Have migrated the data form the old servers to the Google Cloud so that
the continuity of the College businesses is kept (38 and 47).
B. Have the users completely aware of the starting of the system and in
agreement with the new policies or business rules; trained (at least in the
basics) and the help desk and other help resources ready.
C. Switch from the old accounts creation software to the new one. A pilot
implementation of the modified accounts creation software has already
been done It will need further test before switching.
D. Change live domain‟s MX records (mail delivery) to Google. These
switching may need to occur twice. One, once the migration of all the
inboxes is completed, and the other when decommissioning the old mail
server.
Live Manage - Life after Implementation
57. Day-to-day management of the newly implemented Google System will fall on
the User Administration and Operations Developer (UAOD) position. Among the
many routine requests regarding accounts management, many will be in
connection with Google as mentioned above (44), and all Google Admin actions
will have to be in harmony with the whole College function for User Identity and
User Access. It is expected that through a good planning the system will be well
prepared with the correct settings and ancillary procedures to support the User
Admin function of the College business processes; however it is through the
23/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
actual delivery of this function as well as through the users experience that the
completion of the assessment, feedback or adjustment of the implementation
could finally be done.
24/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
Appendixes
Appendix One – Glossary of Terms used in Google Contract
Useful clarification of terms for managing the Google project / service, as defined
in the agreement - (Section 15):
“Admin Account” means the administrative account provided to Customer by
Google for the purpose of administering the End User Accounts. The use of the
Admin Account requires a password, which Google will provide to Customer.
“Admin Console” means the online tool provided by Google to Customer for use
in reporting and certain other administration functions.
“Admin Tool” means online tools or APIs, or both, provided by Google to
Customer to be used by Customer in connection with Customer's administration
of the services to End Users, which may include, among other things, account
maintenance, enforcement of Customer usage policies, and Third Party Requests.
“Administrators” mean the Customer-designated technical personnel who
administer the Services to End Users on Customer‟s behalf.
“Alumni” means graduates or former Students of Customer.
“APIs” means the Google APIs listed here:
http://code.google.com/apis/apps/overview.html or other such URL as may be
provided by Google.
“API Terms of Use” means the terms of use here:
http://www.google.com/a/help/intl/en/admins/api_terms.html or other such URL
as may be provided by Google.
“Customer Data” means data, including email, provided, generated, transmitted
or displayed via the Services by Customer or End Users.
“End Users” means individuals associated with Customer to whom customer
chooses to give End User Accounts. This group may include, but is not limited to
Students, Former Students, Alumni, Staff, and Volunteers.
“End User Account” means Google-hosted accounts provided to End Users
through the Services for the purpose of enabling such End Users to use the
Service.
“Staff” means an individual who has been employed by Customer within the last
twelve months.
“Start Page” means the Google-hosted web page provided through the Start
Page Service.
“Start Page Service” means the service that provides a Google-hosted web
page for End Users, and which enables some customization by Customer and
some customization by End Users.
“Start Page Terms of Service” means the terms of service located at the
following URL:
http://www.google.com/a/help/intl/en/admins/startpage_terms.html, or other
such URL as may be provided by Google, and which terms govern Customer‟s use
of the Start Page Service.
25/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
“Students” means an individual who has been registered for classes offered by
Customer within the last twelve months.
“Volunteers” means an individual recognized by Customer as, while unpaid and
not an employee, is nonetheless a bona fide representative of Customer
performing services in furtherance of its education or non-profit objective, during
the time the individual is acting in this capacity.
26/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
Appendix Two – Stakeholders, Objectives, Policies,
Dependencies Definition table
27/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
28/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
29/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
Appendix Three –Google Apps Education Project Assessment -
18/11/09
The Head of IS Requested to meet with the Director of Quality and Academic, the
Director of Transition Operations and Delivery, the Director of Information
Services, the Head of ICT, the Technical Programme Manager, to discuss the
current situation, as per 18/11/2009, of the Google Project.
The Head of IS presented the following notes about the current situation
of the project as per 18/11/2009:
In the IT Strategy 2009 we had the proposal to “Outsource the provision of
collaboration tools for College wide calendar and email.” Google as quoted as an
example -one of the possibilities.
The College subscribed to Google Apps Education (which besides email and
calendar –the initial target of the plan, also includes Google docs). There is no
documentation as to why or how this decision was made (objectives, benefits,
costs, risks), covering both staff and students and why or how was it extended to
Google docs.
In the subsequent plan to the IT strategy, “IT-Plan-2009” presented to MC to
follow up the strategy the following project was listed (item 7):
Priority 1
Project Email, calendar replacement
Est. Effort (W) 2
Est. Start June 2009
Due When June 2009
Description and Notes Outsourcing of mail and calendar provision
IT Plan 1.5.
Complete Delivery? Y
There is not known further information about this project as to the concrete plan,
the stake holders, and agents responsible, time lines, deliverables, dependencies,
risks and impact on maintenance, less how the estimation of effort was made.
At present 17 November 2009 (five months overdue) the project has not been
delivered , and we don‟t have a clear indication as to how and when is going to be
delivered.
The project kicked off without an explicit project plan leaving way for confusing
assumptions.
30/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
Google Apps Education Project Plan Version: 1
Last Modified: 24/11/09
We don‟t know any further details of the project, time lines, etc. There however
are a series of actions that still need planning and delivery before going live with
Google. The biggest impact is mostly on IS for the User Administration and
Operations front. This not only for the subsequent actions required to complete
the implementation but as administrators once the service goes live. The UAOD
has just been recruited will start on 30 Nov.
It is not possible to succeed in the delivery of the Google project without a clear
action plan, responsibilities and mechanisms to control risks.
Given the critical state of the Google project, the lack of time, the congestion of
critical projects on the relocation team, the need to have clear definitions and
processes to go live, and the fact IS owns the administration of the End Users
(the rest being outsource) it is sensible to pass the project management
responsibility to the IS department.
The IS Department has a good track record of Information Systems Projects
successfully delivered.
It is essential to have in mind that once the project is implemented the action has
not finished. We would have outsourced the email and calendaring infrastructure
but not the user administration operations or the infrastructure for
synchronisation.
Participants Conclusion
There was consensus on the fact the project has not had proper project
management.. The Senior Managers present at the meeting required more
information about what is it that needed to be done before considering the
appointment of a project manager.
On 25/11/2009 the Head of IS submitted the document “Google Apps Education
Project Plan” (version 1) to provide for this information.
End of appendix three
31/31
0ff56120-94ba-4a8b-88fb-71c13eb28a3e.doc
