Intranet obesity: content diet or content stomach stapling?

Intranet content review, cull and control requires drastic solutions. When intranets are piggy eaters, their health problems can only get worse. The eternal problem of intranet obesity is now under discussion on the contentstrategy Google Group. Here's the question, from Richard English in Toronto:

What if the CMS didn't have a content expiry process, what if there
was some other method / process that got content reviewed. What would
that look like? I'm looking for off the wall crazy ideas.

Good call, Richard, because the good old faithful solutions (like eat less and exercise) fail again and again. Two off-the-wall crazy ideas follow, as requested.

Dave Couston says:

Semi-off-the-wall: what about setting up some kind of mechanical turk-like process where anyone or a specific subset of people within the organization can use a simple interface to pick up a piece of content from the stack of items that need periodic reviewing, and review it for freshness according to some simple instructions? In return maybe they'd receive some sort of fractional credit that would be worthwhile to them within the org - credit towards an extra day off, something like that? I guess it would only work if there's little expertise required to determine whether the content needs sunsetting or not, or if the pool of people acting as reviewers had that expertise.

Matt Moore of Innotecture offered a stomach-stapling solution with the following, though he was 'not necessarily recommending' any of the ideas:

  • Every 12 months delete everything. Unless someone actively nominates an item to be kept. And some else seconds that nomination.
  • Charge people a $ fee for each published item that they own. You can have as many items as you like, provided you pay for them.
  • Each month, the CEO will visit a page at random on the intranet. If the content is up-to-date, the content owner gets a small reward. If the content is lousy, the content owner has to perform some kind of community service.
  • If a page gets no views over a 12 month period then automatically cull it.
  • Add a "delete this page if junk" button to every page that any employee can use.

 

Adrian Howard described how a radical cull of wiki content was more acceptable when the process was at least partly automatic. Another upside:

There was also a nice side effect: Because we left the system running people felt able to experiment a bit more - knowing that unused stuff would be automatically culled. A sort of pave-the-cowpaths for content.

When Richard said he was stuck with a CMS that was a piece of junk, one member suggested getting a second CMS to manage the first one! Every intranet team faces some rough realities:

  • Every piece of content, in principle, is owned by a staff member (but the owner may not know it).
  • Staff move, resign, change jobs, forget, and have human weaknesses.
  • Some combination of technology and human control is required.
  • Culling content by humans alone is a time-consuming and sensitive task.

Hilary Marsh requested the following simple system from IT—but would it work for a 300,000 page intranet?

  • A "content expiration" field in the CMS (which didn't have any functionality associated with it). We filled in the field manually for each piece of content based on the rules we set for various content types.
  • A monthly report of content set to "expire" in the coming month
  • A way to archive content so it would remain live on the site but not be returned in general searches

 

As all intranets tend towards obesity by default, imagine the impact when social media is/are added to every intranet's menu.

Join contentstrategy at googlegroups.com and follow the whole discussion.
Image of Mr Creosote (c) MontyPython?

 

 

 

 

 

Leave a comment: