Problems with unsuccessful and weak wikis and collaboration solutions
If you already use a wiki (e.g. TWiki, Foswiki, DokuWiki, MoinMoin, JSPWiki, MindTouch, Sharepoint Wiki, Pbwiki, SamePage, TracWiki or TikiWiki), you often encounter problems inherent in these systems:
- Involuntary "one administrator syndrome" The systems are used, but they are used only by a small number of people. We often see cases where one or two employees maintain the content for dozens or even hundreds of other employees. And it is not like this was ever their intention. The other employees just aren’t able to deal with the system or have other reasons preventing them from collaborating on the wiki.
- Poor usability prevents acceptance and intensive use In many systems, operators quickly realize that the system generally fulfills the needs of some employees who use the system intensively. But the systems’ complexity and difficult operation prevent many other employees from using it.i
- Email is still faster and used frequently
In such cases, employees who have not used the system very much or for passive reading only often return to using email for communication or keep on doing so (like they always have).o - Parallel worlds and competing systems
There are parallel worlds with documentation, information and processes. After all, these are proprietary files like Word documents, Excel sheets, VISIO and PowerPoint documents as well as other systems with a similar purpose. These can also be wikis or specific process tools. In a real and well-accepted wiki, however, there are no other "live" systems. It is often the case that somebody tests out something new. This is OK. Strong systems, however, will ultimately draw such "experiments" back into the system. Weak systems are weakened by them while the complexity of the strong system is increased.
Do you even have a successful collaboration solution/wiki?
Generally, you should look at your existing system to check if you really have a substantial basic system. If this is not the case or if the system is still politically weak, consult the ROI calculation of a Wiki described in this document. It provides a few heuristics to help you determine whether your existing system is relevant.
- Your system contains more than 200 documents and information elements created within the system (excluding file attachments and images).
- Your system contains more than 5,000 modifications and versions.
- More than 25 people have used your system as editors with write access.
- More than 200 people have used your system with read access.
- There are more than 10 use cases in the company where the system is used as a reference or component of a live process.
If you are able to answer "yes" to all or most of the points above, you should seriously consider what you will do with the existing system if you convert to a new system, such as Confluence. If you answered “no” to many of the points, your current system might not be very relevant.
RIO-Calculation for an existing system (example with 100 employees)
Assumptions:
- One employee earns a salary of USD 45,000 per year.
- At 80% productivity with 25% absence due to vacation or illness and 100% calculated additional company cost surcharge, this amounts to approximately USD 33.75 or, rounded up, to USD 35.00 per hour (USD 45,000 / 200 working days / 8 hours * 0.8 productivity * 0.75 presence * 2 additional costs surcharge).
| Description | Detail/assumption | Calculation | Total savings per year |
|---|---|---|---|
| Increased productivity due to decreased searching time | per employee,15 minutes (0,25 hours) per week → | 100 employees * 0,25 hours * 35 USD * 52 weeks per year | = USD 45,500 |
| Avoid redundancies | per employee, once a month 30 minutes (0,5 hours) per week → | 100 employees * 0,5 hours * 35 USD * 52 weeks per year | = USD 91,000 |
| Increased satisfaction due to improved information | 1 sick day every two years → | 100 employees * 8 hours * 35 USD divided by 2 | = USD 14,000 |
| Improved meetings - less frequent, slightly shorter, agenda and minutes always available | per employee 15 minutes (0,25 hours) per week → | 100 employees *0,25 hours * 35 USD * 52 weeks per year | = USD 45,500 |
| Fewer emails | 15 minutes (0,25 hours) per employee per week → | 100 employees * 0,25 * 35 USD * 52 weeks per year | = USD 45,500 |
| Documenting company knowledge prevents loss of assets if an employee leaves the company (company change, retirement, death) | one annual salary in 10 years → | 4,500 USD * 10 years / 10 | = USD 4,500 |
| → Sum (if converting from open Source system) | USD 246,000 per year | ||
Saving costs (Confluence saves between USD 10 and 40,000 in software license costs compared with SharePoint. This does not apply if you convert form an open source system) | |||
Security prevents data disasters → cannot be quantified but is of invaluable importance | |||
Transparency prevents corruption → cannot be quantified but is also of invaluable importance (has nothing to do with trust) |
Weaknesses in the calculation and/or need for adaptations
- If this figure seems too high, you can make deductions for existing solutions depending on their success (e.g. existing wikis, other collaboration solutions).
- If the target group includes 100 people, only 80, 70 or even fewer may be active users.
- The savings for hours of work are rough estimates and cannot be verified. Other values may be more appropriate. This always depends on individual capabilities to find and exchange information.
Do you have other points that need to be considered? Talk with us about them.