There’s quite a convincing case for internal wikis – even for the smallest of organizations.
One of the heaviest hidden operational costs of businesses, large or small, is the loss of productivity from inefficient knowledge sharing.
In fact, a cutting edge study canvassing a cohort of 1,000 U.S. knowledge workers (entitled the Workplace Knowledge and Productivity Report produced by Panopto) revealed that:
“…42 percent of institutional knowledge is unique to the individual.”(Source)
In other words, almost half of the knowledge that an employee discovers, finds, researches, produces, augments etc. will be irrecoverably lost if (and when) that employee leaves.
Not only does this figure pose a tangible loss in strategically valuable institutional knowledge, but coupled with the following estimation that:
“…U.S. knowledge workers waste 5.3 hours every week either waiting for vital information from their colleagues or working to recreate existing institutional knowledge.”(Source)
The potential ROI recovery on every worker’s time saved in waiting on a fellow co-worker’s response or ‘reinventing the wheel’ on existing knowledge is huge.
For a team of say 50, this would amount to over 250 hours of productivity per week, for example. In real monetary terms, this saving alone would be worth the equivalent of one week’s salary for 6 full-time employees.
Suffice to say, as mentioned up top, there is a substantial business case for building an internal wiki for staff use.
When weighed up, the relatively moderate investment of designing and implementing an internal wiki versus the potential losses in productivity is
What is an internal wiki?
An internal wiki is a site designed to be used as a tool for staff members of an organisation or business only.
The purpose of an internal wiki is to act as a convenient digital storehouse of information intended strictly ‘for staff use only’, and delivered as a network of shared posts or articles interlinked together according to topic.
WIkis are both collaborative and living. In other words, the content is produced collaboratively and continuously re-edited and improved according to purpose.
Think Wikipedia, but for internal company information only.
Advantages of using an internal wiki for your project
Wikis facilitate collaborative learning. This is where the shared input of from the most informed to the least informed make a contributive effort to scripting the institutional knowledge base.
In the context of your business or organisation, a wiki will act as an internal driver for continued professional development.
Your people learn. Grow in stature and then teach. And wiki catches it all.
A stimulant for internal knowledge acquisition and sharing.
The wiki grows from a seed eventually into a forest resulting from the steady labour of contributors, underpinned by their like-minded inquisition and pursuit of understanding.
The varied source of authorship leads to a diversity of voices and styles. But if well governed, the result (much like Wikipedia) is a knowledge repository of great value and shaped with real integrity.
Asynchronous in nature, a wiki does away with the distraction of shoulder tapping in the office by building a prescribed body of knowledge as the first port of call.
Wikis tend to have high adoption/use rates, largely because they breed a sense of ownership within the user base. The people who utilize the information also produce it. A kind of “for us, by us” mentality. Therefore there is a natural inclination and self-investment that isn’t present with a non-contributing readership.
Wiki’s are an effective organizational learning tool with tangible ROI if used correctly.
Best practice features of an internal wiki
What’s the standard for a Wiki?
The first of its kind, WikiWikiWeb was developed by Ward Cunningham on 16, March 1995.
Nicknamed after a Hawaiian airport shuttle bus called the Wiki Wiki Shuttle (‘wiki’ meaning quick in the native Hawaiian tongue), the original tagline of this first ever wiki software was “the simplest online database that could possibly work”.
In essence, it was a content management system by which teams of people could rapidly deploy and scale web-based informational databases.
Today, there are many, many wiki softwares (called wiki ‘engines’) for getting the job done. But most notable is MediaWiki, the engine which powers Wikipedia itself (along with tens of thousands of other sites from around the world).
Typical uses for wikis are encyclopedias or company knowledge bases. But either way, wikis are becoming essential reference material in a growing number of social or commercial learning contexts.
Here is a shortlist of distinguishing features that are common among wikis:
Hypertext – in simplest language, this is a web-based text document (perhaps also including graphics, audio or video) which contains hyperlinks to other texts.
It is widely accepted that hypertext was first conceptualized by Ted Nelson in 1965 as a form of non-sequential writing. A type of computerized memory extension formatted according to the pattern “As we may think”.
Collaborative – collaborative writing capability for multi-authorship projects. The ability to host large cohorts of writers who share drafting and editing responsibilities for the project.
Markup – whether HTML or CSS, for example, wikis allow editors to program the text pages with markup changes. This helps to develop custom web pages that include features like <a href> tags for hyperlinking between texts or <strong> tags for emboldening text, making for a far more enriching user learning experience.
Rich text editor – this function helps add dimension to an otherwise flat text document. Also known as a ‘what you see is what you get (wysiwyg)’ editor, plain texts are enriched by images, audio and video media with text decoration like italics etc.
These above points are the staple features possessed by wiki engines.
Another way to look at it is that software programs which have the above functions also can be used for the purpose of building a wiki.
As long as the raw ingredients are there, then it’s possible to both build and grow your very own wiki.
Ongoing requirements for maintaining a well organised internal wiki
A wiki is a living document. Its contents keep multiplying organically. The more it gets used, the more it grows.
In fact, the scope of your wiki should be a direct fruit of your team’s daily hunger and thirst to know more.
The day your wiki stops growing, is the day your team loses appetite. (Perish the thought).
Much like any project, maintaining a wiki needs governance. For quality of content, for uniformity of format and topical relevance in particular. This all calls for keen supervision.
But what are the key items to look out for when drafting a wiki maintenance plan?
Here are a few pointers from those in the know:
Joseph Boone, “Former US Army IT communications specialist” with over 10 years experience as an IT analyst and communications expert contributed the following to helpdeskgeek.com:
- Usability and readability testing: your internal wiki is supposed to actively serve the purpose of being an informative destination of choice for your team. Like any resource, the more useful it is and in the case of a text document ‘readable’ it is – the better it will serve. Your return on investment relies on it being easy to get value from as a user.
- Established policy guide: there’s a reason why general housekeeping rules are given upfront. For the members of the house to remain functional, they need an orderly environment. And to keep an orderly environment you need to set some boundaries, routines and an agenda. Running a useful wiki is the same.
- Critical curation: perhaps contrary to the contemporary educational theory supporting collaborative learning, a successfully run wiki actually needs governance. Cutting away the fruitless branches and purging the underperforming ones will only give rise to better all-round yield.
- Promoting and acknowledging power users: the lifeblood of a wiki is the user contribution. You have a vested interest in encouraging those who are inclined to give. The more they contribute, the more your wiki grows. The more it grows, the better it satisfies users. The better the user satisfaction, the greater the value. The more it is valued, the more persuaded non-contributors are to get involved. Reward your contributors.
An internal Wiki example
There’s no better example wiki than the gold standard itself, Wikipedia.
Sure, it’s anything BUT an internal wiki – but that said it does serve as a solid gold standard of how a wiki should be done.
Here are some stats:
- Wikipedia is the largest and most-read reference work in history.
- one of the 15 most popular websites ranked by Alexa;
- more than 58 million articles
- attracting around 2 billion unique device visits per month
- more than 17 million edits per month (1.9 edits per second) as of November 2020
For the sake of having a working example benchmark of success, Wikipedia fits the bill.
Much to examine and learn from for building your own internal wiki.
As far as highlights are concerned, here is a list of our favourite operational snippets from the Wikipedia site:
The above image is from the homepage of Wikipedia.
There are 2 main features to note here:
- Main content
- Sidebar content
The main content is a compendium of the current or latest news, changes and topics. A fitting entry-point for a wiki project.
Essentially, it’s a splash page that informs the community of the latest buzz and absorbs the focus of the target audience with hyperlinks out.
For those unconverted readers, this is a simple introduction of how contributing works and helps them decide if it is for them.
A page essentially inviting readers to begin their journey as a contributor to your wiki.
This page is the social communications hub for the wiki. It’s really a messaging platform that allows users to share ideas, ask questions and stay connected with one another.
An anchor page for all main category links. This serves as an index which is only one click away from the home/main page providing access to any page resource via its corresponding head category.
Category archive page
This category archive template has a category pages index appearing just before the page content. This index of links is followed by an introductory paragraph describing the contents of the category.
The classic wiki article page template. A simple H1 heading, followed by a category link and then the main article content, including a featured image and table of collapsible contents.
Editing content in Wikipedia is made simple by this proprietary editing tool. Its capabilities straddle both visual editing and markup language. Only logged in members can fulfill editing duties in this case.
Article revision history
Each article has a revision history which is disclosed to all members detailing exactly how much work has been put into producing the ‘as-is’/current version.
This suffices as an audit trail of activity for each post.
Owner’s welcome and request
Every community project needs the support of its users. Without such contributions the project would simply run out of steam. A wiki by definition is tethered by the same constraints. Therefore a key role of every wiki project lead is to stir up continued and increasing support for the project to maintain its momentum.
This is a knowledge base style self help portal within the wiki which serves the purpose of ironing out the administrative creases encountered by contributors.
The onboarding landing page. If newcomers have any questions about how to get started and use the platform – this is the resource which answers all of those early stage questions.
This is a forum which backs the wiki users with a discussion board for airing out their opinions, performing Q&A, resolving disputes and solving technical problems.
Wikipedia offers every visitor the opportunity of downloading each article as a PDF document. A simple ‘download’ button will land a pristine PDF version of the article they are reading on the desktop of their device.
A convenient dashboard with all of the headline performance statistics of the wiki informing you of which articles do well and which ones don’t. Great for identifying the content gaps and areas of improvement.
Building an internal Wiki using WordPress
As mentioned earlier, every wiki needs a wiki engine.
Whilst Mediawiki has earned all the early attention by launching its flagship, WIkipedia, there have since entered other solutions into the wiki engine marketplace that are worthy of consideration.
Some are direct competitors in the wiki engine niche and others are substitutes with cross over competencies.
One such able competitor with oodles of transferable wiki appeal is WordPress CMS.
WordPress lines up as a multi-talented Swiss Army Knife solution within the CMS field.
Traditionally recognised as a personal blogging platform, WordPress actually possesses a very apt and stable core CMS functionality and beyond this is even perhaps THE MOST versatile web builder out there.
In the realm of CMS software, there just isn’t anything even close to the dominance of WordPress right now.
Blogs, online courses, knowledge bases – WordPress has so many faces. And its $500+Billion ecosystem is flooded with custom add ons and plugins that extend its already expansive reach into specialist areas of operation…including, of course, as a world standard wiki engine.
But the question is, what is the ideal array of WordPress ingredients to produce the ideal wiki engine recipe?
Here’s our recommended blend for building an internal wiki using WordPress:
Wiki engine: the functional foundation of your WordPress wiki engine. This is the framework for pulling all of the content together and aligning articles according to categories automatically hyperlinked together in silos, ready-made for your convenience.
Use Heroic Knowledge Base plugin to convert your WordPress into a fully fledged wiki engine.
FAQs: easily accessible answers to frequently asked questions will extend the informational value of articles lending enrichment to context and application of main page content.
Use Heroic FAQs plugin to build modular blocks of FAQ related knowledge into wiki pages, quickly and easily.
Social messaging: enable internal team messaging via your wiki app to encourage collaboration and influence member contributions.
Use the BuddyPress plugin to allocate restricted access to certain collaborative functions in your WordPress self-service portal.
Password protected content: make certain functions and areas within the wiki accessible to only a select few with password protection.
Use Restrict Content Pro to gain granular control over archives, articles and page content assigning access to members by ID or subscription level.
Revision edit tracking: stay transparent with editing activity on your wiki site by displaying a revision edit audit trail – complete with named staff resources responsible for each tweak to content.
Use this snippet to include revision tracking on every article in your WordPress internal wiki.
Wiki user forum: a virtual bulletin board for wiki users and contributors alike. This forum will join together various threads of query and conversation for the purpose of keeping all members on the same page.
Use BBPress to instantly add a multi-featured web forum to your WordPress wiki.
Advanced search configuration: a LIVE search surfaces search results speedily and presents them immediately at the users fingertips before committing them to follow a hyperlink.
Use Heroic Knowledge Base plugin to equip your WordPress wiki with LIVE search function.
Citations: references add stacks of educational value to wikis. Footnote citations are a neat method of including reference links within the body of your articles.
Use CM Footnotes to insert citations easily within articles and posts.
Voting and feedback: field feedback from your wiki users in situ and use their submissions to prioritize your content improvement drive.
Use Heroic Knowledge Base plugin to enable up voting and down voting on each article. Also, with a feedback form users can add free text comments to further add value with detailed constructive criticism.
Monitoring, analysis and improvement: keep track of user experience metrics to guage overall performance and usability of your wiki. This will ensure you maintain a ‘fit for purpose’ resource that is genuinely worth its keep.
Use Heroic Knowledge Base plugin to analyze your user journey and stay abreast of where to score your quick wins.
Print My Blog: give users the convenience of being able to instantly download a PDF version of any article.
Use the Print My Blog plugin to install a robust solution for instant PDF conversion of your wiki pages.
And that’s how a wiki WordPress style is done.
The best part is none of those 3rd-party plugins require code or advanced level tweaking. At most, with the code snippet for revision history it’s a cut and paste job. Nothing more.
A very convenient solution for WordPress beginners and old hats alike.
And now, over to you…
Are you ready to give setting up your own WordPress internal wiki a try?
Have you already tried building an internal WordPress wiki?
Either way we’d be interested to hear from you.
Leave a comment below.