News

Front Lines is a guest viewpoint section offering perspectives on current issues and events from people working on the front lines of Canada's technology industry. Dmitry Buterin is president of Bonasource Inc. in Toronto.

In the past year it seems every business publication has written articles about using "wikis" to share information within the enterprise. But as a business manager (of a tech services business!), I have found these articles exceptionally unhelpful.

• They are vague - are wikis a new way of doing business, a content-management system, or an on-line encyclopaedia? The subject is so new, most writers can't describe it clearly.
• They are impractical, because few writers (or anyone else) have enough hands-on experience with wikis to understand what separates good wikis from bad.
• They are not providing enough context from real-world users, since so few businesses are using wikis yet.

The unhappy result? The fickle media might cut their losses and abandon the wiki trend before it even has a chance to become a useful business tool.

And that's bad, because I think wikis have incredible potential — and not just within the enterprise. By enabling broader information-sharing and ongoing feedback, wikis can link companies with clients and suppliers in discreet project groups that speed up decision-making and reduce the costs of developing new projects and products.

But the media jumped on the topic too soon, when wikis weren't ready for prime time. Wiki software is still at a very early stage, most of it open-source software distributed for free. For the most part, the products are ugly, difficult to use and hard to learn (just like the early days of word processing).

The other problem is that most writers point to Wikipedia, the on-line encyclopaedia, as the best example of a wiki in action. Which confuses most readers, since Wikipedia — although it is a collaboration of multiple users — has almost nothing in common with the use of wikis to manage information flows in business.

I consider myself tech-savvy, but it has taken me a long time to understand how a wiki can be applied in our company. Lured by the media's excitement, I tried more than 30 wiki demos myself. Every time I grew frustrated by their poor design and lack of usability — or by inability to articulate which business problem it was solving for me or which other tools it could replace. There was too much information on the screen, poorly documented features, too many mouse clicks.

Inevitably I would throw my hands in the air and ask, "How can this cumbersome, ugly thing ever help a real business?"

I can only imagine how many early adopters abandoned the search. But our company depends on a flow of information between development staff on two continents and continuous client feedback, and e-mail just doesn't cut it. We had built a custom system, but it was a major distraction to maintain it. I knew we could replace it with a pre-built system.

Finally, we took the plunge with TikiWiki, which had a number of positive reviews. It took our team three months to figure out how to use the program effectively. Again, ascetic design(and downright ugly) and low usability did not help. But eventually we started using it to collaborate on software design and for project management.

But all our attempts to use it more widely — in sales, marketing and administration — proved fruitless. Our software team had to use the program to exchange information and update files. But our non-technical people couldn't get used to it. They would read the documents posted by others, but they wouldn't actively use the system to advance their projects.

So what's the problem with wikis?

They look ugly (too much information, no effort put into design), which immediately reduces adoption. Yes, you can tweak the design to make it look nicer, but how many organizations would make the effort?

They have low usability, in so many ways. For instance, users must usually learn special formatting. Access control is usually clumsy. Working with document and picture attachments is cumbersome.

There are way too many functions and options. Good design is about knowing what to leave out.

No auto-save function. After spending an hour typing up a Web page, click the wrong button and you'll lose it all.

Wikis CAN be good for many things, though - creating a knowledge database, project management, product design, and collaborating with geographically distributed teams. But learning to do these things is hard. For most users, it takes too much time and tweaking to get to the point where wikis will produce a return on investment.

But now the good news. Not all wikis suck.

Our experience with so many bad programs finally enabled us to find wiki software we like. Confluence, a commercial product from Australia, addressed 90 per cent of our wish list. And in the last few months wiki acceptance in our company has increased tenfold (and counting).

Better still, we are using it in every part of the company: to maintain HR procedures and forms; to create sales materials; to facilitate marketing initiatives; for management reporting; for all project management activities; and as our primary software-design system.

How does it make life easier? Here's one example.

Say I'm working on a sales proposal. Before the wiki, I might send out a Word document on a Monday morning to Jim and Maia. They save it on their hard drives and start working on changes. On Monday afternoon I think of an important change and resend my document.

The result: we now have three different versions of the original document. It will take a lot of discussion and detailed manual work to merge them into the final version.

But now things work much better. I put the document on our central wiki and send the link to Jim and Maia. Jim goes to the page and starts editing. At noon, I realize I need to make a change, and go to the wiki page. The system tells me Jim is working on it. I chat with him on-line, he puts his work on hold, and I make my edits. Then Jim continues his work.

In the meantime, the system has notified Maia of the changes. She can go straight to the latest version and start editing.

If I have questions about any of Maia's and Jim's changes, the system saves every version of every document. But if I like Maia's version, our work is done — with much less redundant communication and no "merging" hassles.

Now that I know how to use a wiki, I think it may prove the most useful new tool in business. It delivers ROI better than anything else — IF you overcome the learning curve.

Here are some tips for getting it right:

• Start with a hosted wiki (the one you do not have to install on your own server, but can go to a website and sign-up for as a monthly service plan). You can be up and running with your team in 10 minutes.
• Go for commercially developed and supported software, such as Confluence. Professional design and usability make the crucial difference. Proper tech support and a lively user community also help.
• Select a specific project involving a small team who have urgent need for collaboration.
• Find someone to lead the effort who has already used wikis. Experience is key.

Finally, learn and share! That's not just the key to an effective wiki. Today it's essential for business success.