Texts should be created, shared, and edited in a Wiki, not in Word or within e-mails

This article was originally published in the Atlassian Summit 2011 community newspaper:

 

“Hi, I’m sending you a draft version of the text as an attachment, take a look.”

“Why don’t you just put the text in the wiki?

“Oh, no, I don’t want to do that. I like to complete everything first, and then you can always put in into the wiki if you think that’s a good idea.”

This was more or less how an exchange of e-mails between myself and a colleague proceeded, and I found this dialog – as well as the attached Word file – quite disturbing.

Within a company there can be many approaches for the development of texts as well as the sharing of texts for further revision. We could, for example, write a text in Word and then load the final version into the enterprise wiki. We could also send around texts by e-mail, asking colleagues to read them and, if necessary, to make changes. But we could also develop a text directly within a wiki. What should we think of this particular work process?

Reasons given by employees for the creation and sending of texts by e-mail

What are the reasons behind this phenomenon? What motivates employees in companies to still prefer sending texts by e-mail?

  • E-mail and Word are still the normal environment for the user. Many of them are not yet convinced users of the wiki and feel more at home in their own e-mail program or using Word.
  • They think they’re saving time. Of course, it’s often forgotten that the creating of a text directly within the wiki is by no means more time-consuming.
  • At a more basic level, many employees don’t really think too much about the sustainability and efficiency of their communication and, therefore, often don’t even pause to consider using a wiki. You could call this the “ignorance-advantage.”
  • Wiki contents are not perceived as “active” enough. Whoever creates a text usually wants timely feedback. It is often forgotten that it is possible to send an e-mail with a link to the corresponding wiki article (these kinds of informational e-mails are much faster for the recipient to process. If you also take advantage of the function that allows you to send – along with the link –the content of the wiki document by e-mail, a function that can save the answers sent by e-mail as comments in the wiki, the whole interaction becomes even simpler – and mobile).

Disadvantages of developing texts through e-mail

If you give it some serious thought, you’ll come to the conclusion that the points above don’t really correspond to particularly good arguments. In fact, with better information and explanations it would quickly become clear that these supposed advantages are actually not even advantageous. There are basic and powerful arguments that can be made against the creating and sending of texts using Word and e-mail, especially when there is an enterprise wiki available.

  • It doesn’t make sense to do truly important text work using e-mail, as this work cannot easily be documented by the company for recycling. If  someone looks for this text later on, he won’t be able to locate it using the wiki’s search engine or the search engine of any other centralized search system.
  • Information that is only saved in personal e-mails can lead to information asymmetry. This means that those employees who already know more than others will know even more, and other employees might experience even more difficulties in trying to stay up-to-date. Their lack of knowledge over happenings in the company will grow larger.
  • It is improbable (and actually arrogant to believe) that other employees, when they believe the time has come, will make a wiki document out of the text that has been circulated by e-mail. This is also difficult due to certain psychological pressures; employees know that if they put the document into the wiki that some might believe that the creator of the document was also responsible, or at least claiming responsibility, for the text. This is a further barrier.
  • The sending of information exclusively by e-mail leads to e-mail stress and the dreaded "e-mail flood" because a task with exclusive content that needs to be worked on is sent - instead of a message to be glanced at. The recipient needs much more time to process such messages.

Advantages of using a wiki

In contrast, there are arguments that clearly speak for the using of enterprise wikis for the creation and revising of texts:

  • Creating a wiki article using text sourced from Word or an e-mail can be quickly accomplished, taking less than five minutes. But if the text is created from the very beginning within the wiki, it goes even faster.
  • A wiki document is constantly centrally available. With an e-mail attachment, the best-case scenario has the recipient foraging through his mailboxes when he needs the text later on. The worse-case scenario is when an employee has since left the company, which means that IT has to painstakingly search through e-mail backups. Or the contents have somehow been completely forgotten, meaning that you might as well just create a new version.
  • Wikis have a revision history, which prevents redundancies from occurring and lessens the likelihood that changes from various editors have to be melded together.
  • In a wiki, everyone is always working on the current version, which is a great advantage. In the e-mail alternative, editors don’t automatically receive notice of the ideas and insertions of others, and therefore cannot take advantage of others’ work. This means that if you’re not using the wiki, you might be neutralizing possible good ideas, or even ideas that could complement each other.

A wiki? Always!

This should be a “no-brainer”; it's an incredibly easy decision to create, share, and edit information and texts directly in the wiki. There are no good arguments against this. Nevertheless, even professionals continue to work extensively with e-mail, which complicates company communication and renders it less efficient. In principle, it’s a little bit like the discipline required for athletics or good nutrition: The health requirements are widely known, but their implementation is by no means consistent.

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

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.
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

Leave a Reply