A Personal Viewpoint by Rainer Volz
Last month I talked about the role of traditional web-based versus instant messaging and Peer to Peer applications and pointed out some of the their features. This month I turn to Instant Messaging and Peer to Peer functionality and my experience with such tools in a team context.
One application I use for virtual teams is Groove Workspace, by Groove Networks. This product combines aspects of traditional project rooms with direct collaboration and instant communication. Creating a team room is relatively simple: you download and install the product, Groove Workspace, create a shared space, and then invite the members of your team. Since Groove Workspace is a Peer to Peer (P2P) application, we don't need a central server to store the team room, each team member has a personal computer copy. The team members, who also must have installed the Groove Workspace, receive a copy of the room, and all changes made to the individual copies are automatically synchronised, so that everybody can see what is going on.
That sounds too simple? It is simple, in principle. A good way to introduce such an application is to arrange a meeting with the whole group, connect them to a local network, install the application and then let them play around with it. That serves two purposes, a) the team can start communicating and getting to know each other, and b) make sure that everybody can use this future team environment. The latter is especially useful when working across organisational boundaries, where the hardware/software-environment of team members may be different.
Groove Workspace is only available for MS Windows and is a bit resource-hungry. In my experience the hardware resources were the main problem, because some team members - especially the ones with a non-technical background - tended to have laptops with <=128 MB RAM. They were used to run office applications, mail and web-browsers, and so their machines had to be upgraded. If you only have one day to get started, you should make the technical requirements clear in advance.
Introducing the application itself to team members was easy. If they used web-based team environments previously there is not much to explain. Groove provides different sets of tools that can be used to create a space, or you can create your own mixture. If you use the project toolsets provided by Groove Networks, you get a Welcom page, a task planning tool, a meeting planner, calendar, discussion forum, a web browser with link management and a file storage tool. The functionality is simple and the tools are straightforward to use.
The main difference between a Groove space and a web-based team room that is probably new for most people is the synchronisation. In centralised, web-based environments team members are working on the same data, changes are committed instantly to the database. In our decentralised P2P environment everybody has its own copy of the data. Whenever somebody changes something this change is transmitted to all other participants of the team room, when they are online. That is one of the nicer aspects of P2P applications: project members don't have to be constantly online to be able to work. As long as you work offline with your copy of the team room, all changes are queued locally and sent whenever you get online again. This feature allows mobile users to participate actively in the work. No more excuses about lack of access to calendars, meeting minutes and documents.. But what should be agreed on is that users synchronise at least once a day. This requirement is not a technical one, but I found if users worked offline for extended periods of time they tended to miss important changes and caused too much rework for others.
The features mentioned until now provided the same asynchronous behaviour as web-based team rooms do. Groove also provides Instand Messaging (IM) functionality that helps to solve problems directly, synchronously, by using text-chat or even voice-chat, and presence indication, so you can see immediately who is online or not. The text-chat is quite flexible and can be used inside a team room, but you can also create ad-hoc chat rooms and so invite also external people to these online meetings. The content of these external chat rooms can later be saved and transferred to the main team room. In my teams the voice chat was rarely used because most members used 56K lines to connect and with these it didn't work.
In the next part ( PM World Today June 2003 ) we will look at some other aspects about using a P2P application like Groove in a project. In the meantime, if you want to try it out yourself, more about the application can be found at http://www.groove.net/. Of course, there isn't just Groove available. You can compare it to Magi Enterprise http://www.endeavors.com/, by Endeavors Technology, and Tenix http://www.tenix.net/, by The Data Corporation. These two provide similar functionality.
Part 1 provided an overview of the functionality a P2P tool like Groove Workspace offers. In this part I would like to go a bit more into detail. I'll cover some frequently asked questions about the product, security, bandwidth, and will then describe three use cases for projects.
Let's start with a definition of what we are dealing with: when you bought the Groove Workspace licenses you thought you were buying a product. No, the Groove application is not only a product - as many of the new net-based communication solutions it is a mix of product and service. By buying the product you buy also a service level agreement (SLA) with Groove Networks. Why? In principle Groove is a P2P solution, communicating directly from one peer workstation to the other, but as other P2P solutions too, it uses central servers for certain functions. These servers, this infrastructure is the reason for the SLA. In this case the infrastructure is provided directly by Groove Networks. One more SLA to track.
What services you are paying for? The basic SLA comprises contents buffering for people being offline, presence indication services and contact directories. Of course, you can get better SLAs with management functionality and other hosted services.
The next topic often mentioned is security. If there is a project there is always the question of security, especially if the communication uses other people's networks. The Groove product provides relatively good security, 192 bit encryption, on disk and during transfer on the net. How strong is that? For comparison: the standard for secure online banking or shopping (SSL), which you are using every day in your web browser, provides 128 bit. The encryption is transparent to the user and always on, so no team member can forget to encrypt vital information on his laptop - as long as it is in a Groove space.
While this is sufficient for most projects, some have higher requirements. When the encryption is not strong enough or some policy tells you to mix products/services to minimise the risk of flaws or dependency on one provider - in this case both, encryption and network services, are delivered by the same company - the usual solutions apply: build a Groove tool with custom security (not trivial) or use separately encrypted files to transfer the really sensitive information.
Bandwidth is still a problem, especially across organisational boundaries. The project environment itself might provide good connectivity, but the external connections are often limited to mail and browser traffic. While the Groove application can deal with this and work across firewalls, it is often difficult to get a permission to do that. Sometimes you are even forced to use separate phone lines for external contact. And there are always mobile users, whose bandwidth changes with the location. So, while there is no problem in using Groove with with phone lines - I often use it with normal 56K phone connections - it is essential to keep that in mind when designing the team rooms and processes. Team rooms designed for LAN users might not be ideal for mobile users, because of the amount of traffic involved. Groove provides now some mechanisms to deal with that (files can be synchronised/downloaded when required), but they are not implemented in all tools. If there is no policy in place someone might still attach a 10MB presentation to a discussion entry.
Having said all this we can come now to the really interesting question: How can you actually use this product in a project? Until now I used it in three ways: as a short-term meeting space, a conversation space, a team room.
The meeting space is essentially a chat room for an online meeting, comparable to a multi-user text chat with conventional IM products. A meeting or chat space can be created ad-hoc, no preparation necessary, besides inviting the participants. After the meeting is closed the space is destroyed, but since this is text-chat, the meeting transcript can be saved, as a source for the meeting minutes, if required. I use this type of space as a way to hold a regular online meeting for a defined period of time or to provide a space for an ongoing discussion with one or two people during the day. The latter is similar to e-mail discussions in projects, but provides more context and easier access. You don't have to go through lots of single mails, there is one continous flow of text, that you scroll through if you should have been away from your desk for a while.
The conversation space is a regular Groove space with multiple tools, mainly for documentation and communication. The idea here is to have a common space for long-term discussions with individuals. Such a space provides a kind of private atmosphere, the material in there is secured and shared. I found it is a good way to keep communication up with key people, because you can use it synchronously or asynchronously, whatever is more convenient. The problem here is more to convince the participants that there is more than phone and e-mail.
Depending on the size of your projects/teams you might want to use one or
more Groove spaces as team rooms. Most team rooms are not stand-alone. They
are complemented by external servers. I use the Groove spaces mainly for coordination,
administration and communication, but that depends on the nature of your project.
My spaces typically contain tools for project scheduling, time sheets, discussions,
announcements, and links to critical project documents and external systems.
One reason for this is to keep the amount of data transfer low, especially
when working with external people, which might not always have sufficient
bandwidth for the transfer of large documents. Another reason is that there
are often already other applications or systems, which provide the necessary
funtionality, for document management, software development etc. It makes
no sense to duplicate that functionality.
This way you can use the Groove team room as an information hub for your team, which connects and coordinates all relevant people, documents, and systems. The hub normally exists as long as the team does. As soon as the team's mission is fulfilled, the contents is exported and archived in the document management system, the space is deleted.
I hope this introduction to P2P tools in projects provided enough overview for you. I used the Groove Workspace product as an example because I have the most experience with it, but as already mentioned in the first part, there are alternative products. Of course, every product has it's on palette of features, but I think most of the basic aspects mentioned can be applied to them, too.
If you want to try it out yourself, more about the application can be found at http://www.groove.net/. Of course, there isn't just Groove available. You can compare it to Magi Enterprise http://www.endeavors.com/, by Endeavors Technology, and Tenix http://www.tenix.net/, by The Data Corporation. These two provide similar functionality.
A feeling for the presence of others is an important factor in teamwork. Presence here not only means physical presence, but also mental presence, in the work, in the effort to reach the goal of your endeavour. My definition of presence in a project context would follow the characterisation Jim and Michele McCarthy gave in their excellent book http://www.mccarthy-tech.com/sfyh_interviews.htm Software for your head: "Presence - A person's impact over a given time period; the experience of another's impact. The quality, value, and cost of your presence over time is determined primarily by
(1) the differences it made to those who interacted with you during and after the time in question,
(2) the differences it made on the objects and processes involved,
(3) the differences you forge in your own life by your perceptions and the interactions with others. Your degree of presence over a time and at a particular place with a particular group determines the extent of your results.
The McCarthys defined protocols and patterns to make sure that the team's presence is established, but most of the descriptions mentioned there are meant for co-located teams. What presence mechanisms are provided if you have to deal with a virtual team?
The groupware industry currently follows the simple "being in the place in question" definition of presence, an indication of online status. In the simplest case you might only see how many people are online at a given time, more advanced products keep the member list with online/offline indicators in front of you to instil a kind of group feeling. Instant messaging (IM) applications make the presence indication even more explicit, typically they show not only the online status, but offer also "busy" indicators: busy, don't disturb; available and active; away; etc. Products with support for multiple rooms may also show if the person in question is currently active in a certain team room, or elsewhere.
All these indicators are used for one purpose, to show who is there and can be contacted for immediate communication. What would be required here in terms of the definition given at the beginning of this column? The optimum would be the information that you are
Part 1 of the requirements shows the other members of your team that you are now available, actively working on this project, not on something else.
Part 2 regulates your availability to optimise communication. In simple scenarios it might be OK that everybody is available for communication all the time to everybody else, but most of the time it is useful to be able to restrict your presence indication to a certain subgroup. On one side this helps to avoid frustration for people unsuccessfully trying to contact you, on the other side it saves you time, because you don't have to deal with unwanted communication. Most IM applications currently provide only one "busy" indicator to everyone, in the future user-definable privacy rules will help to customise the busy-status for different audiences.
Part 3 defines your availability further in terms of communication channels. Due to restrictions - on the road with PDA and mobile phone - you might not be able to accept the same number of channels (phone, fax, e-mail, video, VOIP, whatever) as normally - in the office, so you show which are available for whom.
Part 4 shows your availability in terms of geographic location. Team members might want to call you as along as you are in the office to join them, customers as long as you're near their site, etc.
This kind of customised information could help to create a meaningful presence for you in an electronic team environment, something that helps to cover at least parts of the definition given at the beginning: "the differences it made to those who interacted with you during and after the time in question". An important part of interaction is starting it, and guiding your distant collaborators with indicators to the right time and means helps to avoid a lot of frustration and confusion. Not all of the features mentioned must integrated in one product, some can be replaced by availability agreements and other means, but I think it is worth looking for built-in presence support to make life easier.