Child pages
  • Intranet Book: Driving Major Projects Forward with a Company Wiki
Skip to end of metadata
Go to start of metadata


Without a meaningful analysis of the procedure, the process, the pros and cons, and a broad discussion in the company, I don’t even need to think about starting a discussion with the others. And neither a chat nor a microblog is the right tool here.

I create a wiki page on the intranet. No, not a Word document or a Google Doc, but a wiki page, because it gives you all the tools you need for this application.

I put the following information about ISO certification in the new document first: 

  1. Goals and benefits of the ISO project in our company 
  2. Pros of its implementation 
  3. Cons and possible risks resulting from the implementation 
  4. Project team
  5. Internal and external implementation costs 


This is not yet comprehensive enough for a decision, of course, but it’s good first step. Take a look at my screen; the result could look like this:

Example of a wiki page right at the beginning. 

Source file: https://seibert.biz/beispielwikiseite1


Example of a wiki page after a couple of iterations. Source file: https://seibert.biz/beispielwikiseite2 

What we imagine by a digital workplace is made quite clear here. We and our customers share intermediate results early on.

When we started using a wiki for our work several years ago, discussions like this frequently cropped up: “Why are you commenting on and changing my document? It’s only a draft! It’s not finished yet! Somehow I feel like you are criticizing my work by messing around with it even though I’m still working on the draft.” 

Of course, a wiki also contains an option for restricting user rights to ensure that only you (or only the intranet project team or just my ISO certification project team here) can view and edit a page. I also admit that a process of habituation is needed here to really get the usage of the wiki right internally and make sure everyone is used to this way of working.

Meanwhile, years of experience in dealing with wikis have led us to making this kind of draft available in the system early on. It goes without saying that I don’t go around promoting the interim status of the draft in a chat or micropost at this point, as I’m still working on it. That said, however, other users in the system can still see the new page on the change list or from their subscriptions to various sections. 

That means, for example, that my coworker Carl may have subscribed to the “ISO Certification” wiki section that I created for this purpose. Let’s pretend that the section has only been activated for the fifteen or so people who will actually be working on the project. You may find this comes closer to your own reality if you think about your company.

Carl views my new page because Confluence (or your wiki system of choice) has told him there is new content. We spoke about relevance earlier – and this is important here: since Carl is interested in my ISO story, receiving this extra email about it doesn’t bother him in the slightest. If he did, he would simply disable the “Observe” function (see “Personalized Messages”).

Since he can already see all the content I have created in the email, he thinks, “Great. That Seibert guy is beginning to document things properly at last. That will give the project a boost. But he forgot to put me on the list of participants again.”

So Carl opens the page, presses “Edit” and inserts his name in the list. The same applies to Lisa and Ben, who I both forgot when I first set up the page. Ben has even called a company he knows well to find out about the experiences they had with ISO certification there. He has stored the call log for this in our customer relationship management system (CRM), and inserts a link to this in the concept document and adds a brief comment about his contact partner’s experience with costs. 

As the actual author of the document, Confluence automatically makes me an observer, which is why I also receive notifications about the changes made. When I look through my incoming emails, it feels like the scales have fallen from my eyes: “Of course! I’d never have thought of that.” For one thing, Ben had already told me about his phone call. And I actually knew that he, Carl, and Lisa wanted to be on the project team. But I’m only human as well. It’s great that the additions to our wiki are presented simply and clearly. Newly added content is highlighted in green:

Source file: https://seibert.biz/wikiaenderungsmail 

What I like best about the whole thing is that I can quickly jump through these emails on my smartphone while I’m on the go and learn something new in a few seconds: I can easily make additions to my protocol and concept. Ben, Lisa, and Carl are all interested in the matter and have made an active contribution to driving it forward. 

That not only feels good, it also acts as a boost to the project. And it also gives me the chance to chat with them briefly the next time I see them in the hallway and thank them. Personal interactions of this kind close a very productive and meaningful cycle of digital collaboration and personal coordination. That is because personal conversations always bring up new ideas that one of the project’s stakeholders can then record in the wiki. 

In workshops we hold, question marks light up on the faces of half of the participants when we say how many people are involved in our projects on our wiki. Can really everyone make changes? Isn’t it totally unproductive if you have to constantly iron out the nonsense and misplaced ignorance posted by trainees and newcomers? Won’t I have to monitor all of the wiki documents by email? That’s pure madness because of the enormous volume of emails! In the end, nobody will be able to see whose work it is: so, everyone’s stirring the soup, or what? 

I don’t want to go too far. But it is a fact that this form of collaboration is unusual for most people. And sure, it makes attributing results and success more difficult or maybe even impossible. And no, vandalism or errors caused by ignorance or nonsense never occur. On the contrary, in fact, employees are more scared of contributing something that is wrong and prefer to change nothing if they are unsure. After all, a mistake would be seen by lots of people. 

To me, this doesn’t mean a crazy number of emails or contributing to the flood of emails, but productive work that I really enjoy. For example, if I’m going to drive this ISO thing forward, it doesn’t bother me if I receive an update email. In fact, I’m really interested! I enjoy looking through my Confluence and Jira messages and often use it as a way of relaxing during my work day. In 80 percent of cases, they are quick and easy to read. I don’t have to do anything and can see how everything is going. That feels good and I have the feeling I’ve done something useful if I can archive the email after a few seconds. 

Our wiki document on ISO certification isn’t really buzzing over the next few days: just a change or a message here and there from those observing the page. 

The following principle applies here: he who writes stays. It’s exactly the same with a Google Doc or Word document in Microsoft Office 365: as a rule, only a few make a decisive contribution and make significant advances. Maybe because they have lots of energy. Or because they are affected. Sometimes, just because they think they have enough power to make a decision.

We don’t control who does or doesn’t advance an issue in our company. For us, discussing priorities together at the company level is enough. 

In our case, Benjamin is putting a lot of energy into the ISO 27001 certification project and working a lot on the document. What’s special about a wiki is that content-related messages always involve those who are really interested in the topic or in a particular page. Each change is therefore a reminder to the others that the topic still exists and that something is happening. 

Each activity leads to more activity and attention from the other participants. Activity induces activity. This creates a self-supporting cycle. 

When using Google Docs and MS Word in O365, however, this feeling of collaborating on a common cause fails to arise in most cases. 

I should probably say that a bit differently. These tools are fantastic for real-time collaboration. They can also be very well presented. We all log in to the same document over the web interface and work on it at the same time. Combined with a video conference call, this creates a really productive collaboration scenario for people at different locations. 


Link to this page: https://seibert.biz/intranetbookcompanywiki


  • No labels