A Teams and Tools Guide


Introduction to Effective Use of Collaborative Tools

Collaborative tools are more capable versions of the age-old tools: paper, binders, file drawers, ...and memory.

Properly used, they enable team members to create, modify, extend, and find reports, lists, and formatted information pertinent to the team. But they're much more than this. They also provide some capabilities of meeting rooms, phones, email, and admins, in that they enable team members to discuss the information in real time or asysnchronously, help with coordination of both people and information, and serve as a sort of institutional memory for each team, all the individual on the teams, and all others who need to know what's going on.

Many companies have lots of collaborative tools (file repositories, task databases, message boards, wikis) but don't know how to use them effectively. Skills and practices for working together that are augmented by online tools are not well known. Unlike the best practices of running physical meetings, they haven't yet "culturally crystallized," permeating the modern knowledge-worker culture.

This guide overviews some basic approaches to creating practices in the use of collaborative tools for your organization or team.

Some starting vocabulary

link ref Eugene on these + +

A Good Approach

Consider the What and Who of your current work, talk about them in terms of paper versus network tools. Then proceed with the How norms that are know to be productive in collaborating teams who use networked tools to augment that work.

The What, Who and How questions are the place to begin planning tools use for a new group on a new project:

Part I: The What

What are we doing on this project, in this group? Answer this overview question by answering these questions:

Part II: The Who

Who will we be working with to create the deliverables? Answer this overview question by answering these questions:

Review all the materials identified in the prior section and think thru:

Use your answers to the questions above to develop 2 tables:

Table 1. Mapping people into groups where each group has common needs relative to the material on the servers.

Table 2. Mapping material to group access rights. A simple model of access rights is Read, Create. That is, for the members of each group, consider whether they should be able to only Read that material, or to Read and Create new material (e.g., add a task to task db or a file to a file repository).

Step III: The How

What will be our processes for working together - collaborating - to do the work of the project? Answer this overview question by answering questions like these:

Step IV: The Roles

Another aspect of having new tools is there are new roles that will be needed on the project team--on any team using tools to support their collaboration. When all materials were paper-based there were admins who knew how to bind stacks of paper into reports, knew who should see what documents, etc. The new roles have a very different focus.

The roles known to be needed, and set up as part of the social structure in advance or at outset of project don't have a 1-to-1 relationship to team members. The roles can and in some cases should be shared across multiple people to disseminate the best practices and provide several means of support to other team members.

Step V. The Norms

Finally, there are 'norms.' These norms are pre-requisite goals to achieve productive team use of networked tools for their collaborative work:

>Posting task

> Posting progress on tasks

> Encouraging useful info to be posted e.g., a discussion by the water cooler about something that effects the team/project

> Reinforce good stuff, e.g., “Joe, that message from Jane-customer is useful for us to know, please post to announcements in the project site”

Post responsibly to the named categories e.g., don’t post z related deliverable info in milestone 1 folder
Sharing as naming conventions evolve – all need to know what terms mean e.g., that the “milestone3” now includes Z-2 deliverable.

• Everyone on the team has to own a sense of “responsibility for maintaining health of the team’s collaboration within the tools”

• Social Structure –
>Leadership has to ‘buy-in’ – not just talk the talk, has to walk the walk i.e., work within established norms
(Be careful if the leader is violating a practice e.g., discussion in email vs. in wiki.)