Taping box from Shutterstock
Filed under: Articles, Collaboration and social
Establishing team spaces for projects can be one of the most productive uses of collaboration tools. Projects have a lot of information to share between team members (and beyond), and collaboration can provide new ways of meeting this need.
Projects are also nicely ‘bounded’, with a defined membership (the project team), a clear goal (the project objectives) and a finite lifetime (the length of the project).
With organisations running hundreds of projects, however, these team spaces can still become a problem, particularly if they are left lying around past the end of projects.
A simple rule should therefore be established and enforced: team spaces must be closed when projects end.
Delete team spaces
A team space builds up a huge amount of information over the lifetime of the project, mostly relating to the day-to-day work of the project.
If these spaces are not removed at the end of projects, however, it can rapidly get to the point where the ‘dead outnumber the living’. This clutters up servers, impacts on search, and makes it hard for people to find the information they need.
At the conclusion of each project, or shortly after, team spaces should be deleted as a matter of policy.
An argument can be made that these collaboration spaces contain valuable information and documents that might be needed for future projects.
In reality, most of this information is inconsequential: invites to meetings, daily back-and-forth messages, draft copies of documents, superseded content. This information doesn’t need to be kept beyond the end of the project.
While there are important details that should be preserved, the team spaces aren’t the best place to do this. Stripped of the context of the original project, information can be very difficult to interpret.
Which are the draft and final versions? Which version of the project plan does this document relate to? These types of questions are very difficult to answer without being able to ask the original project team members.
Team spaces should therefore not be seen as viable long-term storage places for key project information.
Distil and archive
This is not to say that all information should be deleted. Before the team space is closed, the key information should be distilled, cleaned up, and metadata added.
The information should be moved to a suitable long-term storage space, such as the corporate records management system or the intranet.
The project team members should do this, as they are best placed to determine what will be useful. Supporting guidelines should be provided to assist them with this task.
Setting it up from the start
When initially establishing team spaces, an owner (or local point of contact) must be identified. This person then becomes responsible for decisions about the space (including deleting the space and archiving the content).
A defined end date must be specified, with the collaboration tools sending an automated reminder when that date is reached. The project team has the choice between closing the space, or extending the end date.
By defining these key details at the outset, the team spaces can be made much more manageable with little extra effort.
Unilaterally deleting spaces
When projects end, team members are often quickly moved to new projects. This makes it hard for them to find the time (or motivation) to do the necessary cleanup and archiving of project content.
The central collaboration team should therefore be prepared to unilaterally close spaces a few months after the project has concluded. The content should then be moved to long-term (offline) storage, in case it does prove to be needed in the future.