Everyone loves his (wiki)space..yet..

This world is full of writers, some of them are pros and the rest are wannabe pros and soon to be pros. But all of them love to scribble..and there are just too many tools available for word editing. Yet none matches the popularity of Wikis and similar spaces where users can create their own space, define navigation and contribute what they can- be it news, articles, work place insights, technical tips and workarounds for some problems.

In our corporate day jobs we keep on learning a lot of things and we end up creating such Wiki spaces or similar intranet sites where we write a lot and upload a lot of files. The reasons can be multi-fold and multi-dimensional such as creating a page for each working team in a group, then a page for each software release by a group, then a page for writing about specific release updates by teams, then a page for uploading all the documentation available for release, then a page for all patches available for a specific release of a product in a particular year, then a page for all releases that were no more supported, then a page for all the compatible software for all the releases..the list is endless and at times even a page for all the release parties in a quarter along with photos and all the team outings and fun times and CSR activities and so many other reasons for creating yet another wiki page.

We love our Wiki pages don't we? But do we care enough about their relevance, structuring and navigation? In reality do we need all those pages that we create all the time? Do we need to create all of those pages at all? To sum up, should we define and enact policies for such online content creation and maintenance to make it resource efficient? Is there a way to do it? Shouldn't such intra-org sites be administered more often for relevance?

Well folks, the idea over here is not to discourage people from sharing knowledge and opinions with coworkers, but to see that such sites do not become the 'company sponsored closets' for all the irrelevant information. The idea is that information existing on knowledge bases is always relevant and easily findable as well as retrievable   How do we go about it without curbing the freedom of the company employees from putting their thoughts on paper er webpage? There can be simple strategies for achieving these goals.

SharePoint/Wiki Analytics

Nowadays many of the SharePoint versions and Wiki pages have their own Analytics Apps available (some of them free, some premium versions do come with a price tag). You can implement such Analytics apps based on your information security policies or build homegrown software just to monitor the page usage, updates and relevance. If you are using Wiki, you can check 'Pageview statistics' tool: See Wiki Pageview stats tool. You can use this tool to see how many times a page was seen by audience and rank all the pages under a section accordingly. You can review some of the pages with low rank and decide whether you want to do away with them.

Sunset policies for pages

You can also decide the Sunset policies based on the type of pages that you are creating and the content thereof. For example, if you are storing event photographs for quarterly events, you can keep the latest photos and the one's from the last quarter. Adding such photos for every quarter over the years may just add unnecessary burden to your storage. Just a thought! Or if it is press release, you can keep 4 quarterly releases over the year. If it is product/minor release/ hot fix/ patch version update and executable files, you can keep it active as long as the artifact is relevant.

Sunset policies for sections/sub-sites

Alternatively you can create sections with a relevance date in mind. For example if it is a sub-site for documentation, you can keep only the documentation for latest release and do away with the documentation for releases that are no more supported. You can create subsections for training materials and developer notes specific to a software version/patch that is being supported. Once it is not longer supported or you change development platform, you can take down the material that is of no use to developers. If you create a section for all the corporate videos, you can do away with the videos that are associated with now-deprecated releases. Videos being resource guzzlers need special attention!! Or if you are very possessive about your information artifacts (just like anyone else!) and want to think twice before taking them off, you can create a separate 'soon-to-be-archived' section and dump such information there. Once all stakeholders agree, you can take down such archives and free up the storage.

Auto-archival policies and page settings

I do agree that it takes significant time of developers or whoever is going to archive pages to read the content and decide whether to throw them off or not. Therefore you can decide an auto archival policy for all the pages based on their categories and use-by dates. Once you implement such policies and add use-by dates to all the pages, you can breath easy as the system will take its course.

Friends, I could have suggested assigning a page Admin per development team/scrum team for managing the wikis. But in today's world of multiple job-hops and high attrition the existing team members may not always have a good idea of the relevance of a particular content that exists prior to his joining. In such cases, the administration is best left to the Development/QA Managers and Leads to manage the team knowledge bases.

All said and done, it is in the best interest of teams that only the right and relevant knowledge stays in the knowledge repositories. If they are not managed properly they soon become the information dump yards where none bothers to visit as everyone knows that they are the long-forgotten closets of irrelevant information!!!