Close team spaces when projects end
Categorised under: Collaboration, James' articles
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.
[CM Briefing 2008-11, read the full article]
Tags: Collaboration, projects, team spaces
James Robertson is the Managing Director of 
2 Comments:
I think it depends if its the same team working on multiple projects or if teams change from project to project.
If you were going to simplify this: without a team attached to it, a workspace needs to be put down.
I certainly think that team spaces needs to be actively managed rather left to populate the corporate info landscape like zombies.
As you state in the full article, archiving is really crucial here – as is some kind of history or register of past projects (which should include the location of the mortal remains of that project).
I’m not sure whether this is more of a problem in organisations that are project-based (e.g. consulting firms) or operations-focused. I suspect the latter – because while there may be fewer projects, project management disciplines are generally weaker in those organisations and screwing this stuff up will simply cause a lot of diffuse pain rather than directly impacting your business.
Yes, I think your distinction between process- and operations-focused organisations is important. It all comes down to good project management at the end of the day, technology or not…