KM Component 18 – Collaboration Process

With KM in mind, collaboration is interacting with peers and colleagues to exchange ideas, share experiences, work together on projects, and solve problems. Work teams, project teams, and communities need a consistent way to share their knowledge, coordinate their activities, and communicate with one another. 

Providing a process for collaboration enables basic functions such as document and photo libraries, file sharing, membership rosters, lists, discussions, polls and surveys, calendars, meeting sites, and links. Making this process a standard ensures that there is a consistent way to collaborate so that once a user has learned how to do so, it will always be the same.

A standard collaboration process ensures a predictable, reliable, backed-up, and supported environment, which is preferable to ad hoc methods such as email, shared drives, personal hard drives, or unsupported tools. The process should allow a team to continue collaborating without losing information even if one or more of the members departs, a PC is lost or stolen, or a hard drive fails.

Without a standard, collaboration will be done in a variety of sub-optimal ways, or not at all. Thus, it is desirable to define a policy which requires the collaboration process to be followed by all teams. The policy should be supported by a standard tool for collaboration with a self-service creation process which is very easy to use. Until collaboration becomes ingrained, make it one of the three goals for knowledge management for all employees for whom it is relevant. For example, “For every customer project, a team space using the standard collaboration tool should be created for project team collaboration.” Then report each month on progress to achieving the goal.

The combination of a quick self-service creation process for team spaces, the ease of use of the chosen collaboration tool, and an employee goal should lead to rapid and widespread adoption. As a result, you should be able to declare success and replace the collaboration goal with a different goal for the subsequent year.

A collaboration process should include a policy, procedure, standard tool, standard templates for different types of teams, training, and support. It can be supplemented with a capture process which allows reusable content to be selected from team spaces and submitted to appropriate repositories for later reuse. It’s also helpful to provide guidelines for how to collaborate, including effective ways to ask others for help.

Providing a standard, supported way for teams to collaborate is a basic enabler of knowledge management. It allows knowledge to flow between people, creates an environment where documents and ideas can be shared, and provides supporting tools such as polls which make it easy to find out what team members are thinking.

Suggested Steps

1. Implement a collaboration process for project teams.
2. Define and enforce a collaboration policy for how teams are to collaborate.
3. Discourage team collaboration from taking place outside the team space. For example, project team members should not maintain any files on other sites or rely on email or non-standard collaboration tools.

Example

At HP, we wanted to establish that collaboration was expected to occur, and in a standard way. Before there was such a standard, people were collaborating informally, sending email to one other, or storing documents on someone’s hard drive. The problem was that if someone left the project team, someone else who wanted to find out what had been shared might not be able to get it. Without a standard way to collaborate, you won’t get the kind of collaboration you want – or it will happen in an inconsistent way.

Just requiring team collaboration is not enough. You have to make it easy for people to create a collaboration space. At HP, we used Microsoft SharePoint team sites. This allowed us to emphasize self-service—anyone could create and begin using their own team site in just a few minutes. We provided a template and allowed users to populate it with standard information and links that a project typically needed. This really helped things take off. One of HP’s three original KM goals was that every project should establish a project space. But we no longer needed that as an explicit goal, because everybody had started doing it routinely.

It is important to identify the business need that collaboration addresses. At HP, it was the need for project teams to work together, to communicate effectively, and to have common access to documents. We created a standard environment that didn’t require people to learn multiple tools or prevent them from reusing materials across projects. The self-service element was important – people didn’t have to wait for the IT department to create sites for them.

The collaboration process spanned four stages in the project life cycle:

1. In the initial phase, someone began pursuing an opportunity. They started up a collaborative team space for the team going after the deal.
2. They began including people from the sales force, people from services, or anyone within the company working on that deal who needed to collaborate.
3. As the project moved along, new project team members might be added, and the project manager might get assigned to work on another deal. Teams needed a way for things to be handed off from the sales part of the opportunity to the delivery part of it. The team space offered a good way for handoffs to happen—to prevent information from being lost, and to ensure key materials (e.g., proposals and project plans) were widely reusable.
4. Finally, these documents could be shared from the team space into the project document library, where others could access and reuse them. A standard workflow process moved documents from the team space into the project document library.

The following figures depict HP’s collaboration architecture and collaboration strategy.