A fundamental root cause of information clutter is "no ownership".

People are assigned to projects. The projects end (or are cancelled), the people move on and the documents remain behind to gather "dust" and become information clutter.

This is hard to prevent. The wiki vs. sharepoint doesn t address the clutter, it just shifts the technology base that s used to accumulate clutter.

Let s look at the clutter

1. Technical design info / architecture docs. Old ones don t matter. There s current and there s irrelevant. Wiki.

   Last year s obsolete design information is -- well -- obsolete.

2. Meeting minutes, action items, etc. Action items become part of someone s backlog in a development sprint, or, they re probably never going to get done. Backlogs are wiki items. Everything else is history that might be interesting but usually isn t. If it didn t create a sprint backlog items, update an architecture, or solve a development problem, the meeting was probably a waste of time.

3. Project plans and roadmaps. The sprint backlog matters -- this is what a "plan and roadmap" aspires to be. If you have to supplement your plans with roadmaps, you probably ought to give up on the planning and just use Scrum and just keep the backlog current.

   The original plan is someone s guess at project inception time, and not really very interesting to the current project team.

4. Organization business mgmt info - travel, budget info, headcount info, etc. This is a weird mixture of highly structured stuff (budget, organization) and unstructured stuff ("travel"?)

   How much history do you need? None? Wiki at best. Financial or HR System is where it belongs. But, in big organizations, the accounting systems can be difficult and cumbersome to use, so we create secondary sources of information like a SharePoint page with out-of-date budget numbers because the real budget numbers are buried inside Oracle Financials.

5. Project pages with business analysis, requirements, etc. This is your backlog. Your project roadmap and your requirements and your analysis ought to be a single document. In the wiki.

   History rarely matters. Someone s concept at project inception time of what the requirements are doesn t matter very much any more. What the requirements evolved to in their final form matters far more than any history. This is wiki material.

How old is too old ? I ve worked with customers that have 30-year old software. The software -- obviously -- is relevant because it s in production.

The documentation, however, is all junk. The software has been maintained. It s full of change control records. The "original" specifications would have to be meticulously rewritten with each change control folded in. Since the change control documents can be remarkably pervasive, the only way to see where the changes were applied is to read the source and -- from that -- reverse engineer the current-state specification.

If we can only understand a 30-year old app by reverse engineering the source, then, chuck the 30-year old pile of paper. It s useless.

As soon as maintenance is done, the "original" specification has been devalued.

How to clean it up? If you create the wiki page or sharepoint site, you own it forever. When you leave, your replacement owns it forever.

Each manager is 100% responsible for every piece of information their staff creates. They have to delete things. The weak solution is to "archive" stuff. Which is just a polite way of saying "delete" without the "D-word".

Cleanup must be every manager s ongoing responsibility. If they can t remember what it is, or why they own it, they should be required (or "encouraged") to delete it. Everything unaccessed in the last two years should be archived without question. Everything 10 years old is just irrelevant history.

It s painful, and it doesn t appear to be value-creating work. After all, we work in IT. Our job is to "write" software, not delete it. No one will do it unless compelled on threat of firing.

The cost of storage is relatively low. The cost of cleanup appears higher.

How to stop the email chain?
Refuse to participate. Create a "Break the Chain" campaign focused on replacing email chains with wiki updates (or sharepoint updates).

Be sure your wiki provides links and is faster to edit than an email.

You can t force people to give up a really, really convenient solution (Email). You have to make the wiki more valuable and almost as convenient as email.

Ramp up the value on the wiki. Deprecate email chains. Refuse to respond to email chains. Refuse to accept "to do" action items through email.

You can use Confluence Wiki for storing documents as attachements and have the Wiki s paths work as the file paths in Sharepoint.

Re: stale data: have ownership of the data (both person and team) and ensure that deliverables for the owners include maintenance of ALL the data.

As far as "Off email", this is hard to do as you can t force people to do this short of actively monitoring all email... but you can try some deliverables with metrics regarding content added to the Wiki. That way people would be more likely to want to re-use the work already done on the email to paste into Wiki to meet the "quota" instead of composing fresh stuff.

Our company and/or team used all 3 of these approaches with some degree of success in the past

Is there a reason not to have the wiki hold the files?

Also, perhaps limiting the mail server to not allowing attachments on internal emails is too draconian, but asking folks to put everything in the wiki that needs to be emailed more than once is pretty darn useful.

Efficient information management is indeed a very hard problem. We found that "the simpler the better" principle can make miracles to solve it.

Where should data go - we are big believers of the wiki approach. In fact, we use Confluence for sharing possibly every type of information, except really large binary files. For those, we use Dropbox. Its simplicity is an absolutely killer feature. (Tip: you can integrate them with the Dropbox in Confluence plugin.)

Finding stale data - in our definition, stale data is something that is not updated or viewed for a specific period of time. The Archiving Plugin of Confluence can quickly and automatically find these, then report them to the authors and administrators, who may potentially update them (or remove them, see next item). There is, of course, information that never expires, but the plugin is able to skip them after you mark the corresponding pages.

Removing stale data - we are fairly aggressive on this. If the data is not (highly) relevant anymore, clean it up now! We can safely follow this practice, because we never actually delete data. We just move outdated data to hidden archive spaces using, again, the Archiving Plugin. If we changed our mind later, it is very easy to find it in the the archive, view it or even to recover it.

More active usage - our rule: if the information is required to be persistent, don t email it. Put it to a wiki page instead. The hard thing for some people is to find the best location for the information (which space? where in the page hierarchy?). Badly organized spaces with vague scope are another big efficiency divider, unfortunately. Large companies may consider introducing a wiki gardener to cure this.