Online collaboration is a fact of life in International Development programmes. Teams and individuals are scattered across organizations, across countries and regions, as well as time zones. Sadly, we hear more grumbling about platforms and processes than success stories. So working with organisations to improve how they work together online takes up a lot of our time.
The problems vary with the size of organisation, to some extent. Large organizations normally have Intranets or private networks, but these aren’t always open to project partners from other organisations. But their rich features often make them difficult to access from international locations, especially where Internet access is still expensive and/or unreliable. However, there is also a downside to the use of free tools, which we at Euforic Services have often promoted. That option normally means using several different platforms, like wikis, blogs, project management systems, etc., that need to be brought together somehow and may require multiple sign in and entry points for users.
So sometimes it’s worth investing a little in developing an integrated platform. But money is always an issue, so how easy is it to customise a collaboration platform on a tight budget?
We had the chance to learn and experiment last year. With our friends Antonella Pastore and Tania Jordan, we were contracted by IDRC to configure and deploy an online platform that would support knowledge management and communication in a new collaborative research programme.
The platform was to be based on the Google Apps infrastructure, previously selected by IDRC during an earlier phase of the project.
In Euforic Services we’ve been using Google Apps for several years now in our own work and for external projects and consultancies, in relatively small teams. But this was a new challenge, how to deliver a fully fledged collaboration platform and get over 200 people on board? So what does it take to configure and deploy a platform that is functional and it is actually used by teams and individual users? And what did we learn in the process?
Our project plan and implementation followed a rather standard approach and sequence - from configuration and set up to pilot phase and iteration, to soft launch and go live. But for each of these phases there are some specific elements that is important to consider for a successful deployment of the Google Apps - as well as for any other online collaboration solution.
The problems vary with the size of organisation, to some extent. Large organizations normally have Intranets or private networks, but these aren’t always open to project partners from other organisations. But their rich features often make them difficult to access from international locations, especially where Internet access is still expensive and/or unreliable. However, there is also a downside to the use of free tools, which we at Euforic Services have often promoted. That option normally means using several different platforms, like wikis, blogs, project management systems, etc., that need to be brought together somehow and may require multiple sign in and entry points for users.
So sometimes it’s worth investing a little in developing an integrated platform. But money is always an issue, so how easy is it to customise a collaboration platform on a tight budget?
We had the chance to learn and experiment last year. With our friends Antonella Pastore and Tania Jordan, we were contracted by IDRC to configure and deploy an online platform that would support knowledge management and communication in a new collaborative research programme.
 |
| Homepage of the KM platform |
The platform was to be based on the Google Apps infrastructure, previously selected by IDRC during an earlier phase of the project.
In Euforic Services we’ve been using Google Apps for several years now in our own work and for external projects and consultancies, in relatively small teams. But this was a new challenge, how to deliver a fully fledged collaboration platform and get over 200 people on board? So what does it take to configure and deploy a platform that is functional and it is actually used by teams and individual users? And what did we learn in the process?
Our project plan and implementation followed a rather standard approach and sequence - from configuration and set up to pilot phase and iteration, to soft launch and go live. But for each of these phases there are some specific elements that is important to consider for a successful deployment of the Google Apps - as well as for any other online collaboration solution.
Decide what is in and what is out - and think 'around' the box
From the initial scope of the work and during the inception phase, we agreed with the IDRC team on which Google Apps would form the core of the collaboration platform. These included: Sites, Drive, Calendar, Google+ and Hangout, Picasa Web Albums.
If you are familiar with Google Apps, you may have noticed that Gmail was not included in the configuration of the platform. Indeed, each of the potential end users already had an institutional mailbox and the idea of having to manage a secondary email address was not negotiable.
So how to get around it, when Gmail is central for the Google Apps? The solution we found was to set up the new user account with an automatic forward so that all emails sent to their new Gmail address would be automatically sent to their primary email box. As a consequence, we also created a Site as central entry point for the whole platform (see image above) and worked with Google Groups to define and manage the sharing and access rights to documents on Google Drive.
From the very start of the project, during the inception phase, we used the exact set of tools that had to be deployed in the new platform. While this was business as usual for us (the combination of Google Docs, Calendar, Hangout etc is our standard modus operandi), this also allowed the project team at IDRC to improve their own skills and knowledge of the tools in a learning by doing approach. As a result, not only they learned the ins and out of the Apps but could later act as super-users and platform champions.
When defining the pilot, we wanted users to go through a set of test cases. These were documented in a step by step pilot guide, developed using a combination of Google Sites and Docs. As the pilot users were all from the same working group, we defined the pilot using real content and for a real purpose: finalizing the organization of a working group meeting. Working with this real live case and with real content was instrumental in getting pilot users on board, as they saw the results of their participation in the pilot coming together and being used in the actual face-to-face meeting.
As we opted for a managed rolled-out in the deployment of the platform, we were able to consolidate the training and support documentation, as well as the platform navigation, with the feedback received by the first pilot users. At the opening of the platform to a larger number of users (around 100), we run two online demos sessions (using Hangouts - again, learning by doing) which were also recorded for later playback. Additional webinar sessions were planned after the third round of accounts creation. A helpdesk was (and still is) also in place for troubleshooting and additional users’ support, with guaranteed response time within 24 hours.
With a lot of focus on the tools and technical solutions that are available out there, we should not forget that what is actually needed by users are effective (and possible simple) solutions that can enable their work. For example, working in geographically dispersed teams, one primary need of platform users was to held online meetings - so Hangouts is the solution. Adopting a functional perspective (instead of a tool focused perspective) helps users to understand how to work more efficiently and effectively - and to buy in into a new online platform.
With a new batch of users accounts created recently, the platform has now over 200 active users. While it’s still too soon to evaluate users’ engagement and activity, the usage statistics look promising so far. However it’s clear that the success of the platform will now depend on getting most of the users to work along - or at least get a large enough critical mass of users doing it.
If you are familiar with Google Apps, you may have noticed that Gmail was not included in the configuration of the platform. Indeed, each of the potential end users already had an institutional mailbox and the idea of having to manage a secondary email address was not negotiable.
So how to get around it, when Gmail is central for the Google Apps? The solution we found was to set up the new user account with an automatic forward so that all emails sent to their new Gmail address would be automatically sent to their primary email box. As a consequence, we also created a Site as central entry point for the whole platform (see image above) and worked with Google Groups to define and manage the sharing and access rights to documents on Google Drive.
Walk the talk - use the tools to support project management
From the very start of the project, during the inception phase, we used the exact set of tools that had to be deployed in the new platform. While this was business as usual for us (the combination of Google Docs, Calendar, Hangout etc is our standard modus operandi), this also allowed the project team at IDRC to improve their own skills and knowledge of the tools in a learning by doing approach. As a result, not only they learned the ins and out of the Apps but could later act as super-users and platform champions.
Make it real - pilot and soft launching
When defining the pilot, we wanted users to go through a set of test cases. These were documented in a step by step pilot guide, developed using a combination of Google Sites and Docs. As the pilot users were all from the same working group, we defined the pilot using real content and for a real purpose: finalizing the organization of a working group meeting. Working with this real live case and with real content was instrumental in getting pilot users on board, as they saw the results of their participation in the pilot coming together and being used in the actual face-to-face meeting. |
| KM Platform training guide |
Get your users on board - training, demos, helpdesk
As we opted for a managed rolled-out in the deployment of the platform, we were able to consolidate the training and support documentation, as well as the platform navigation, with the feedback received by the first pilot users. At the opening of the platform to a larger number of users (around 100), we run two online demos sessions (using Hangouts - again, learning by doing) which were also recorded for later playback. Additional webinar sessions were planned after the third round of accounts creation. A helpdesk was (and still is) also in place for troubleshooting and additional users’ support, with guaranteed response time within 24 hours.
Give users solutions - not tools
With a lot of focus on the tools and technical solutions that are available out there, we should not forget that what is actually needed by users are effective (and possible simple) solutions that can enable their work. For example, working in geographically dispersed teams, one primary need of platform users was to held online meetings - so Hangouts is the solution. Adopting a functional perspective (instead of a tool focused perspective) helps users to understand how to work more efficiently and effectively - and to buy in into a new online platform.With a new batch of users accounts created recently, the platform has now over 200 active users. While it’s still too soon to evaluate users’ engagement and activity, the usage statistics look promising so far. However it’s clear that the success of the platform will now depend on getting most of the users to work along - or at least get a large enough critical mass of users doing it.