<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Close team spaces when projects end</title>
	<atom:link href="http://www.steptwo.com.au/papers/cmb_projectspaces/index.html/feed" rel="self" type="application/rss+xml" />
	<link>http://www.steptwo.com.au/papers/cmb_projectspaces/index.html</link>
	<description>Beyond The Idea</description>
	<lastBuildDate>Thu, 09 Feb 2012 09:46:05 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Graham Tritt</title>
		<link>http://www.steptwo.com.au/papers/cmb_projectspaces/index.html/comment-page-1#comment-211</link>
		<dc:creator>Graham Tritt</dc:creator>
		<pubDate>Fri, 19 Sep 2008 09:01:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.steptwo.com.au/?p=1324#comment-211</guid>
		<description>I disagree with a lot of this.

Agreed, a collaborative team space should be closed, made read-only. But it should be archived, not deleted. 

The distilling includes ensuring that its  organisational (e.g. folder) structure is clear, and that metadata is complete (such as author, creation and modification dates). This can be automatically added, using the context of the project and its phases and deliverables.

We have good enough search engines now to find things by full text and structured searches. It should all be in a document management system or business management system anyway. The amount to be stored and searched is no more a problem, it has never been insoluble.

&gt;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.

The aim is to codify knowledge which will last longer than the availability of the original team members. That&#039;s why knowledge systems have been invented. 

Methods, documents, procedures etc can be mined for information! We have heard enough about business intelligence, so that we should not make the same old mistakes when considering team spaces. There is a continual overhead of say 10% in ensuring that every item is in context, but that is what a DMS does.

As we have seen with email trails, retaining old project documentation is mandatory. No choice. Even old meeting invitation lists.

Graham</description>
		<content:encoded><![CDATA[<p>I disagree with a lot of this.</p>
<p>Agreed, a collaborative team space should be closed, made read-only. But it should be archived, not deleted. </p>
<p>The distilling includes ensuring that its  organisational (e.g. folder) structure is clear, and that metadata is complete (such as author, creation and modification dates). This can be automatically added, using the context of the project and its phases and deliverables.</p>
<p>We have good enough search engines now to find things by full text and structured searches. It should all be in a document management system or business management system anyway. The amount to be stored and searched is no more a problem, it has never been insoluble.</p>
<p>&gt;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.</p>
<p>The aim is to codify knowledge which will last longer than the availability of the original team members. That&#8217;s why knowledge systems have been invented. </p>
<p>Methods, documents, procedures etc can be mined for information! We have heard enough about business intelligence, so that we should not make the same old mistakes when considering team spaces. There is a continual overhead of say 10% in ensuring that every item is in context, but that is what a DMS does.</p>
<p>As we have seen with email trails, retaining old project documentation is mandatory. No choice. Even old meeting invitation lists.</p>
<p>Graham</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nay</title>
		<link>http://www.steptwo.com.au/papers/cmb_projectspaces/index.html/comment-page-1#comment-36</link>
		<dc:creator>Nay</dc:creator>
		<pubDate>Thu, 28 Aug 2008 12:58:57 +0000</pubDate>
		<guid isPermaLink="false">http://www.steptwo.com.au/?p=1324#comment-36</guid>
		<description>Great article and congratulation for the new look of this site. As Iam studying KM I am looking for articles regarding KM projects.. any suggestions?

Thanks</description>
		<content:encoded><![CDATA[<p>Great article and congratulation for the new look of this site. As Iam studying KM I am looking for articles regarding KM projects.. any suggestions?</p>
<p>Thanks</p>
]]></content:encoded>
	</item>
</channel>
</rss>

