Wiki Adoption: A Pilot Project As An Obligatory Routine

You never get a second chance to make a first impression.

When introducing a new and in its type different software, this aphorism, that once Oscar Wilde and also Mark Twain adjudicated, fits very well, because: a wiki adoption can not be repeated very often. This is why we recommend to prepare a wiki project in the timeframe of a pilot phase, for later application.

Love at second sight does not exist between wiki and employees

When the wiki adoption fails, it leaves ‘burnt soil’ behind - and burnt soil is generally known not to be very reproductive. This is why it is recommended, to start a pilot project with a larger group of people, in which a reasonable number of people review, if the wiki can fulfill expectations. This pilot team finds problems, fixes mistakes and prepares the system to be applicable in the firm. The wiki should only be rolled out, if it passes the practice test.

To answer the question, of how dramatic a failed wiki adoption is, is given to us in the third step of an innovation process discussed in another article according to Everett M. Rogers, Decision. During this decision phase preference is manifested towards innovation. If this innovation is poorly set up, the user develops a negative disposition, which has a certain stability by principle. Furthermore the jeopardy exists, that a negative ‘public opinion’ is generated. It could happen, that the innovation of the entire department, in the overall sector, of the entire company is perceived negatively. Even employees, that have not been in contact with the new tool, take on a reserved position.

Media scientists speak of a negative frame in this context, the novelty does not retain a fair chance. This is why a pilot project is so important: the larger the social circle that decline the wiki in event of a poorly prepared adoption, the more burnt soil is produced.

Wiki pilot project: “A good idea, but...”

Many wiki champions, that would like to establish a wiki in their company, are signaling compliance and understanding for the concept of the wiki pilot. Surprisingly, those people want to however forego the pilot project: They theoretically find the idea of a pilot project proficient, but in practice they would rather kick off immediately. Three reasons lead to this time and again: Pilot projects are expensive, take time and are unnecessary in specific affairs.

Counter-argument #1: Expenses
Most wiki adoption projects have a reasonable over all budget. A pilot project, so the apprehension, increases this budget and is an expensive driver. This argument is both shortsighted and incorrect. The external costs increase slightly by enabling a pilot project. For the most part, merely additional workshops have to be implemented, since different groups of people have to be trained, first the pilot team, then the roll out team. However, even this reasonable additional cost through a train-the-trainer-seminar can be reduced by enabling intern employees to hold training independently.

It is an insight, that is as old as software development itself: He who makes mistakes, because of saving in the planning stages, has to spend multiple amounts to fix the mistakes after implementation.

Counter argument #2: Time
There are often dead lines that a third party has given. Sometimes a wiki is supposed to be ready for a specific application, that is soon starting. Sometimes the board of directors has terms of reference, that the project team is to maintain. Sometimes expectations of the so called Lead Time (this is the time from inquiry of the client up to the delivery of the product from the person providing service) are utopian.

In these situations we advise to scrutinize the reason for the tight time schedule. Frequently the hectic atmosphere is home made, and can be disarmed through reconciliation of an appropriate person. It is incidentally a general phenomenon of software projects, that these are partially implemented with enormous time pressure. Too seldom the question is asked where this pressure is actually coming from and if the project result and the business goals are conductive. An objective and sober consideration often leads to an easing in regard to times components.

Counter argument #3: Overestimation
Many people underestimate the complexity of a wiki adoption - and they overestimate themselves and the adaption capability of their employees. The reasoning example is always the same: the deal of a wiki is a software with excellent usability. And the colleagues that work with the system are by and large clever people. Why waste time and money on a preliminary study? Lets assume that a business decides to take on a really well engineered wiki software like Confluence and that the employees are really trim with the handling of computer and web. The adoption of a wiki however deals with an innovation, that leads to a change of the previous cycle. It requires relearning and reorganizing, not only of the operation of the new software, but also the concerns of emotional attachment. The employees need time and assistance, to get used to the new system.

Priming first, then rollout

Out of these reasons we advise companies, that want to adopt a wiki: Only roll out the wiki, if you are certain, that it fulfills the requirements of your employees and take time for a pilot project. Normally, the roll out is postponed for no more than one month and the costs will rise to a maximum of 5.000 Euros. A successful wiki adoption should be worth this much.

Are you considering introducing a wiki? Are you evaluating promising software? Do you need support with an up-and-running wiki project? We are experts in business communication and would be happy to consult with you, so please contact us. Further information on this topic can be found on our special page on enterprise wikis.

Further information

Architecture of a Wiki-Project: Elements, Process, Approach, Rules
Architecture of a Wiki-Project: Customers’ Frequently Asked Questions
Factors for the Success of Wikis 1: Technology is important, but not King
Factors for the Success of Wikis 2: Organization is the Key
Factors for the Success of Wikis 3: Overcoming Resistance from the Company Culture

Forget Less and Ensure Quality with didit Checklists for Atlassian Cloud Forget Less and Ensure Quality with didit Checklists for Atlassian Cloud Forget Less and Ensure Quality with didit Checklists for Atlassian Cloud
ATTENTION!
Our blog articles reflect the situation at the time of writing and are not updated. It is therefore possible that the contents are outdated and no longer correspond to the latest developments. We do not accept any liability for this.

Leave a Reply