Get hands-on training for JIRA Software, Confluence, and more at Atlassian Summit Europe. Register now ›

mseibert.pngThis is the first of three  posts by Martin Seibert. He is the CEO of a German internet agency called //SEIBERT/MEDIA, a specialist for enterprise wikis and corporate communication. //SEIBERT/MEDIA is one of Atlassian’s official partners in Germany. This blog post is also available in German at http://seibert.biz/wikisuccess1.
A company Wiki is not only a new technology for many employees (at least within the company environment); it also requires a change in the normal communication- and collaboration patterns throughout the entire company. Through our experiences with dozens of company Wiki projects, we know that the successful introduction of a Wiki usually depends upon three factors: technology; organization; and culture. This article – the first of three articles on this topic – is dedicated to the challenges of technology.

Technological aspects are often overestimated

Generally speaking, many companies overestimate the influence of the technology during the introduction phase of the Wiki. This overestimation is primarily due to the fact that many companies wrestle intensively and almost exclusively with the question of technology. In our experience, however, these technology factors are only about one-third of the equation for a successful Wiki introduction. Nevertheless, in regards to technology, companies must still implement a few very important prerequisites.

1. Choosing the correct Wiki software

The choosing and implementing of the software is a cornerstone of any Wiki project. Companies need to correctly implement the technological components before cultural or organizational aspects can be fully considered. The evaluation process requires the answering of a number of central questions: Which fully mature Wiki systems for enterprise use are available and which one is the best one for the depicting of your company’s business processes? Should your company rely on open source technologies such as Foswiki or should you choose a fully developed commercial solution like Confluence? Which weaknesses and strengths are implicit in these solutions regarding their adaptability (i.e. plugins)? Which interfaces are available for connecting to other systems? Is an LDAP connection – and thus a single sign-on solution – possible?
The focus of the evaluation is on the company’s requirements as well as on the question of which tasks the employees should be able to perform using the Wiki. The features of a particular technology should in some way be needed if a technology is to be successful within a company. Admittedly, our project experience has shown that some companies choose software even without just such a concrete need for that particular software; in such a situation, much energy must be invested after the fact to adapt standard solutions to the actual requirements of the company – often unsuccessfully. One study by Jakob Nielsen confirms that the prerequisite for the successful introduction of a software tool is the actual existing need for that tool:
A uniform finding across all of our case studies is that organizations are successful with social media and collaboration technologies only when the tools are designed to solve an identified business need. Different companies have different priorities and use different forms of internal communication; not every company needs every tool. Although picking the tool to support the need sounds obvious, it runs contrary to the technology fetishism that characterizes much talk about the latest Internet fads.
An intensive evaluation, for example in the form of strategy workshops with an experienced Wiki service provider, is the best way to evaluate Wiki software regarding the above factors.

2. System operation

Operating on a computer
There are three options for the operation of Wiki software. The simplest solution is having the system run locally on a PC at the company. This is sometimes a very sensible option, especially for a test phase with very few users during an initial evaluation. If, however, the classic functions such as collaboration are required, then this alternative is naturally not going to lead to the desired results, as the Wiki is only in operation when the corresponding computer is up and running; in addition, it is unlikely to be accessible from PCs outside of the work environment.
Third-party hosting
One established course of action is to enlist a third-party hosting service. These are typically service providers that support your company during the Wiki project and also provide hosting services. The disadvantage of this choice is that the Wiki is being managed outside of your internal systems; in other words, it is externally accessible, which is especially problematic from a political perspective: Many customers prefer to operate systems within their company, the primary purpose of this being to keep their data within the company. Still, many companies are reconsidering this concern in light of the current trend towards cloud computing, and over the next few years more and more companies will try to outsource their hosting activities.
Internal operation
Nonetheless, for most companies it goes without saying that they will operate a Wiki within their own company infrastructure. This third possibility is, however, the most difficult as well as the most expensive, since the company needs the corresponding know-how (i.e. a systems administrator and security plan) as well as the proper infrastructure (i.e. hardware or a virtual system on which the Wiki can run). Still, this alternative remains in many ways the most popular.

3. Technology infrastructure in the company

The technological component also touches on a company’s overall technology infrastructure. Some companies already have a problem when it comes to the choice of browser, as Internet Explorer 6 is still used in many companies. However, Internet Explorer 6 does not allow many of the functionalities offered by a Wiki software package.
In most smaller companies, the users are, admittedly, often already using more modern browsers such as Internet Explorer 7 or 8 or Firefox, but at many companies where employees do not have the chance to influence what software they use, thousands of users still work with outdated browsers. This is indeed a dilemma, because in this case the incomplete infrastructure can often be correlated with not only a lack of flexibility but also the missing willpower necessary to change the situation.
For the medium-term this problem will surely prove irrelevant, but at present this component is still extremely relevant, and many companies are being confronted with the fact that their state-of-the-art Wiki system cannot be completely utilized due to technical bottlenecks.

4. Integration and single sign-on

Also important for the acceptance of the Wiki is its integration within an existing sign-on server; the best-case scenario for this would be a single sign-on solution without any additional sign-on requirement. Employees find it very distracting when a system requires separate access procedures, which can greatly complicate the introduction of the Wiki. The Wiki should be imbedded into the existing infrastructure in order to raise the chances of its being accepted, especially in those cases when there are multiple existing systems for which a unified login or even a single sign-on solution has already been established

5. The position of the Wiki software in relationship to other systems

There are two interesting aspects to consider regarding the position of the Wiki software in relation to other systems:
a) Should there be gateways for the exchanging of data between the Wiki and already existing systems? For example, should it be possible to transfer data from a business intelligence system into the Wiki? To depict it in the Wiki? Should it be possible to transfer data from the Wiki into other systems?
b) Is there an existing portal solution into which the Wiki should be integrated, or will the Wiki be available separately using a URL? If the first is the case, then other questions must be raised; for example, does this influence in any way the layout, since the Wiki might then have to be adjusted to fit the existing portal solution due to the layout template.
These questions need to be answered, and technical solutions need to be found.

6. Evaluation of Plugins

There are a multitude of plugins and expansions for the performing of specific tasks within modern Wiki systems. During the Wiki introduction phase companies need to evaluate these plugins as well as consider the extensions needed to run the Wiki software correctly and utilize it to the fullest extent.
More than anything else, expansions such as a WebDAV plugin are powerful solutions. Such plugins make it possible to use a Wiki server like a local computer system in the company network or to use the Wiki just like other distributed networked drives – in other words, to create a framework that allows employees to save their work directly to the Wiki instead of on one of those distributed networked drives; the Wiki is then – just like any other drive – available, for example, when using Windows Explorer. The difference is that it is also available using browsing software.
Functionality like this has extremely high potential, but it also requires a high level of client-side configuration. The necessary know-how as well as the corresponding capabilities must be organized. Such functions are unusable without a systems administrator and corresponding configuration rights.

Fresh ideas, announcements, and inspiration for your team, delivered weekly.

Subscribe now

Fresh ideas, announcements, and inspiration for your team, delivered weekly.

Subscribe now