Wikis are an established part of knowledge management within IT companies. There are many reasons for this. At IBM it was - according to Gunter Dueck - the need for navigation, for a registry within the enormous IBM-Intranet. Thus Project Bluepedia was started, first with about 30 volunteers and then it virtually 'exploded'. This utilization as a 'registry' makes sense, but there is another reason. If you take a look at the laptops of numerous consultants, you more and more often see wikis. Why is that? Consultants often have to quickly familiarize themselves with new topics, often they consult various clients at the same time or one client on various topics. Wikis are electronic, networked post-it notes which are fast and efficient to work with.
That exactly is the reason why Wikis are so popular with IT departments: You can quickly secure knowledge, do research and update the texts. When several people work together, there will be synergy effects. Why are they so important especially when it comes to IT?
What's the difference between a bus driver and a software developer?
Let us compare a software developer to a bus driver. A bus driver needs basic training (driver's license) and in Germany they often receive a 4 week basic training course in which they learn geographic knowledge, he is a front-seat passenger, drives under supervision, learns official instructions etc. When he has finished this very intense basic training he just has to follow duty rosters and maybe get some further training for about 2 days a year to learn about new regulations.
A software developer's daily routine is vastly different: 4 weeks of intense basic training is totally unusual. Instead they fight on an almost daily basis with new challenges: Suddenly deployment takes twice as long - what's going wrong? A customer reports that there are performance problems with the new database - why? And then a new software release or enhancement package arrives - and suddenly large amounts of knowledge are outdated - the half-life period of knowledge is always a challenge in the IT sector.
And here the difference between a bus driver and a software developer is showing: A bus driver always has received basic training whereas in the IT sector there are many career changers coming for example from mathematics or natural sciences. That's not bad, for in the IT sector you always have to deal with unforeseen problems, you have to try and learn - you move almost constantly outside any routine. Know-how is the best means for success.
The reason behind a wiki is a purely economic one: In a small company knowledge exchange often takes place in the coffee kitchen, but in bigger companies many people often solve the very same problems over and over again. This is not bad, but it's uneconomic if there is no exchange, if knowledge is lost and you always have to learn from scratch. Often after solving a problem you send an e-mail to your colleagues with the solution. Only: the distribution list is almost always too small or too big and you can't update the result and you can't connect or link it to other know-how articles - and that exactly is where wikis succeed.
It's odd, but many decision makers in IT are skeptical when it comes to wikis. What are their arguments?
"There is a competitive situation aiming at specialized concepts and other concepts or documentation."
These supposedly competitive situations between wiki entries and concepts do not exist. Concepts are comparable to the bus drivers' official instructions. Into the wiki go knowledge entries for all the knowledge that isn't included elsewhere: How do I analyze why deployment is taking so long? Why is the runtime behavior under DB2 different from under Oracle and what can I do about that? A wiki doesn't double documentation, but it provides links to existing documents, for example to http://help.sap.com/.
"The acquisition effort is too high."
This argument always makes me smirk. It is general knowledge that developers hate doing documentation - it's no secret: You have to deliver working software and you work under serious time pressure - and in case of doubt either quality or documentation are sacrificed. I have hardly every seen developers who take pleasure from writing concepts - and therefore they will only add the most essential information to wikis. But if there is only one page per developer per year added, and that can happen in quite a short amount of time - there will be valuable information found in this knowledge repository.
I think that the misapprehension is based on comparing company wikis to Wikipedia. The difference lies in Wikipedia being the leisure entertainment of perfectionists while a company wiki is nothing but a tool for fast and efficient work.
However, the wording "too high´" begs to ask which standard of comparison is being used - in other words, to ask about the effectiveness of a wiki. In view of the fact that software developers are - in contrast to bus drivers - knowledge workers, the benefits can't be overestimated.
"There are no institutionalized and periodic controls to confirm the correctness of the entries."
If you take this argument seriously, any information exchange or knowledge transfer that is not quality assured should banned. I wouldn't be allowed to answer the questions or give advice to colleagues, neither in the coffee kitchen nor in e-mails. A person in charge would be needed for every single topic to assess each and every statement.
Of course this is neither desirable nor possible. In my experience, the people who contribute content to a wiki belong to the circle of knowledge-bearers within the company. In most cases the quality of their contributions is outstanding.
And even if the quality were questionable, then such a bad article would provide pointers for further research.
"There is the danger of faulty action based on substantially incorrect entries."
In a company there are defined processes and instructions - for example in form of guidelines or specifications. Employees thus should receive training and those things should be assured within the framework of the overall quality management.
But is this an argument against a wiki? Maybe at a bus transport company, because there are job instructions that the employees have to follow. In an IT-company we also follow procedure, but most of the day guidelines don't help. We are fighting problems on a daily basis: How does an API work, what does a new release offer, why is the database access so slow?
We are highly specialized and well-paid knowledge-workers, entrusted with the IT-mapping of the core processes of a company. We have to analyze errors in the code, in part errors we have made. We are trained to work with missing facts. Our knowledge is becoming obsolete at dramatic speed and we have to constantly update our knowledge. While we're developing things we are making mistakes or at least we make questionable decisions and we do have methods to find errors and secure quality.
We know the difference between reliable, robust information like the SAP library and the OSS and conversations in the coffee kitchen. We even reevaluate information from SAP consultants in relation to our unique situation and the ones of our clients. We even find errors in the SAP Library and in the OSS. We have quality assurance systems, we work with reviews and previews. Our software is designed by highly qualified application architects - and yet an ambiguous or erroneous wiki entry is supposed to be a problem?
