Stewart Mader blogs atWikiConsulting.com

Back in July, I encouraged readers to contribute to a survey on wiki use in business being conducted by Penny Edwards for her MBA dissertation at The Open University Business School. The results of that research are out now in Managing Wikis in Business, on Penny’s blog. The wiki where she has documented the research is worth a look as well. It even has a page on Wiki Patterns, and cites a book called Patterns for Effective Use Cases that calls patterns a sign of quality: “a pattern expresses what is present in a well-formed example” and a sign of strategy: “a pattern names a way to deal with conflicting pressures.” These are excellent terms to describe patterns, and good reasons to use them to help start or grow your wiki. After all, who wouldn’t want to use tools that signify quality and strategy?

This quote especially stood out for me in the report: “Given the relative newness of many wikis, the responses suggest that wikis and capabilities regarding their use/management are still being developed internally before being extended outside the organization, where important collaborations lie with customers.”

That’s the next great step. Once you get comfortable with a wiki inside your organization, there’s immense potential waiting to be tapped when you use it to interact with customers and give them a place to share knowledge and strengthen the community around your products.

• Comments Off

Mike Cannon-Brookes, Atlassian’s co-Founder, recently presented on Organisational Wiki Adoption at WebDirections South 2007 in Sydney, Australia. The presentation is excellent on both content and design - in fact, Mike set a goal of no bullet points: “FYI I set myself the challenge of doing an entire 1 hour presentation with no bullet points - and succeeded! I was even running quite a bit over time so had to run through the last few slides very fast.” That last sentence says it all - when you don’t tie yourself to bullet points and rigid structure, you can more easily adjust your pace to fill - or finish in - the time allotted. Less structure = more flexibility = very wiki-like. All in all, an excellent piece, and well worth a few minutes of your time:

• Comments Off

I got asked this question during a presentation earlier this week. It’s a simple question with a complicated answer - here’s why: Historically, whenever any new enterprise tool has appeared on the landscape, its proponents have told everyone that it was the next big thing (think KM systems) and would obsolete everything else so they should get on board as quickly as possible. Every time, without fail, this has not been the case. KM has largely not lived up to the extremely high bar set in its heady early days.

So when I answered the question, here’s what I said: in some cases it will replace and obsolete other enterprise tools, but in other cases it will coexist and work alongside - even in complement with - those other tools. Think that was a politician’s answer? In some ways it was, because it I said the same thing that’s been said countless times before - that it would unilaterally obsolete other tools - I would have immediately discredited myself because people know that’s not true and get scared when there hear things about a wholesale switch from one way of doing things to another.

In another way, it wasn’t a politician’s answer, because multiple tools can coexist and letting people choose can help them be more productive and enjoy what they do. Furthermore, when you introduce the wiki to your organization, there’s no need to immediately shut down and remove all other tools - that just sends a jarring and bad signal when the real benefit of the wiki is it helps return other tools, like email, to their optimal uses. Here are two examples where the wiki can coexist with other tools for the better:

Wiki + Email:
If you’ve been emailing meeting agendas, put them on the wiki instead and you’ll reduce the volume of emails asking you to do time consuming things like fix or add to agenda items. Instead, put the agenda on the wiki so others on your team can directly make changes themselves, then send out an email with a link to the agenda-containing wiki page. You’ve just reduced the email associated with that meeting to just one outgoing message, and the reduced volume means less work for you and people will likely pay closer attention to it since their inboxes will be less crowded.

Wiki + Website content management system:
Many firms use a content management system to power their websites, and the system is usually managed by one person, or a small team of people. The rub: they’re constantly overloaded with requests to edit the content of pages and have a difficult time keeping up with them in a timely fashion. A great way to solve this is to put the website content in a wiki space, with a wiki page corresponding to each page on the website. Now, people can edit the content on the wiki as needed, and just let the web publishing people know when it’s ready to go on the website. This reduces the web publishers’ workload from making lots of changes (which often requires emails back and forth to get content, ask for clarifications, etc.) to just copying the updated content over to the content management system.

• Comments Off

Nathan Wallace of Janssen-Cilag has written an excellent case study on their wiki adoption, which Bill Ives picked up on the FastForward Blog. Janssen-Cilag is a pharmaceutical research company with employees in Australia and New Zealand, and is one of 250 operating companies of Johnson & Johnson, the New Jersey-based maker of pharmaceutical, medical, and personal hygiene products. The case study is very comprehensive - one of the best written and most information-rich case studies I’ve seen yet, and Bill’s post is well worth a read as well as he pulls out some of the salient points.

Here’s what I commented to Bill on his post: “They needed a system where editing is immediate and very simple. It was more important to let people add content rather than worrying about what they shouldn’t do.”

So true - it’s good to hear that an organization is concentrating on the positive and taking an optimistic approach instead of wringing its hands over thoughts of bad things happening.

“…”Knowledge management, previously a big concern, has moved off the agenda for the time being.” That is because knowledge management became a byproduct of using the wiki and not a separate activity.”

Great point - true knowledge management happens when people are able to do it without fighting with the technology and seeing it as a separate activity. It scares me to think of how many organizations have ended up treating it as an after-the-fact burden b/c the tools haven’t made it easy.

This is a great case study - Nathan deserves a lot of credit both for what he’s doing with wikis at Janssen-Cilag, and for sharing this really comprehensive, detailed case study with us all. Bill, thanks for your added input as well!

• Comments Off

In Wiki is the new FAQ Dennis Howlett looks at the Wall Street Journal’s coverage of wiki use at SAP and Intuit. At SAP, the Developer Network and Business Process Expert communities group found that online forums were inefficient because the same questions were being asked over and over, sometimes with people waiting a long time for answers. “It got to be a little much,” says Mark Yolton, vice president of the SAP Developer Network and Business Process Expert communities at SAP. So the group introduced a wiki and encouraged the community to contribute.

This is a smart idea because with forums, people might not think to search and see if their question has been answered before, or they might search with slightly different terms and not find the existing answers. With a wiki, all the answers to a question can be organized on a page, and people can easily edit, add to, or correct an answer.

At Intuit, the technology innovation group introduced a wiki for employees outside the group to contribute information on technologies the company might want to use in products. The problem is, contributions to the wiki haven’t taken off, so the director of the group is trying to stimulate activity by inviting product managers and designers to temporarily join the group and contribute to the wiki. Howlett argues this isn’t a good wiki use because Intuit isn’t giving people a reason to actively participate in the wiki community.

My take on it is that the Intuit group’s effort should be focused on the people inside the company first. If the people in the technology innovation group aren’t contributing to their own wiki, it’s not likely that those outside will contribute either, because there’s no core community. Having people temporarily join the group to contribute to the wiki might get content into the wiki for a brief period of time, but what happens when those people leave the group? They might continue to contribute, but then again thy might go back to their usual work and just not have time for the wiki anymore.

Furthermore, having temporary contributors build the wiki is risky because they don’t fully belong to the community like those in the technology innovation group, and it’s the full time “residents” who should set the tone and guidelines of the community so that it has a clear purpose. Intuit’s wiki might work, but I think SAP’s has the strong foundation that I’ve seen in other successful wikis.

• Comments Off

Dennis Howlett recently wrote about how NYK Shipping & Megacarrier is using Confluence and Lotus Domino together to power their intranet. NYK is a global shipping company (one of the world’s largest, in fact), and Alek Lotoczko, who runs the company’s intranet, was looking for a way to increase collaboration after seeing that only about 50 people regularly contributed to the Domino-based intranet. He first used the open source DominoWiki in January 2007, and by June, with just word-of-mouth, contributors had more than doubled to 117.

By that time he started talking with the corporate communication department, which was also looking for a wiki for its own use, and the two decided to switch from DominoWiki to Confluence. Alek was able to secure funding from this, and he points out that using a free, open source tool allowed him to get things started and demonstrate the value of a wiki before spending any money. Bear in mind that this isn’t to say all organizations should start with one wiki that’s free, and then switch to another, because that can create its own set of issues. In fact, with the low cost of wikis in general, and the fact that you can often get a 30 day free trial, it’s fairly easy to start directly with the tool of your choice.

So where does NYK’s wiki/intranet stand now? “The Domino system isn’t going away because that’s NYK’s corporate comms standard. Instead, it is being used to prime the wiki project which Alek hopes will eventually reach about 2,500 employees.” This is a great example of two enterprise software tools coexisting, and the wiki is being used for its strengths in attracting and building a consistent level of collaboration. This is an excellent example for organizations to learn from as they think about how a wiki can become a succesful part of their computing landscape.

• Comments Off

The InfoWorld blog points to a recent survey showing that corporate email is becoming more expensive than ever. The survey, conducted by Osterman Research, looked at just over 100 enterprises with an average of 6,636 email users and found that a majority are concerned about the expense associated with migrating to Microsoft Exchange 2007. The survey showed that organizations face steep costs to migrate to the new email server, and, “messaging storage growth is a serious or very serious problem.” Regarding messaging storage growth, the problem people think they’re facing is having enough available storage space for archives of message, but I think the bigger problem is that all those stored messages aren’t doing much good because people can’t do much with them. Email is not an archival tool for information, which makes accessing and reusing that information difficult.

The survey was commissioned by a Linux-based competitor to Exchange, so it might be construed as biased, but the bigger issue here is that organizations have to look at how email is being used, and what activities would be better served by other tools, like wikis and blogs. Email has become a crutch in business communications because it’s being stretched far beyond its intended use as a communications tool. Organizations are trying to use it to collaborate and it was never designed for this, so it makes a very poor collaboration tool.

If you and I were working together on a document, there are a lot of steps in between when I work on the document itself, and when you work on it. To send it to you, I’d have to create an email, attach the document, and send it to you. Once you receive it, you’d have to download the attachment (insert worry about viruses here), open it (let’s hope you have the right software to do so!), and finally you can edit it. That may not seem like much, but imagine doing that every time we pass the document back and forth.

And, what if I send you the document, then get a great idea for something to add. Should I wait until you’ve had a chance to edit it and send it back, or do I add my new content and send it again? If I do the latter, it open up the possibility that you might edit the wrong copy of the document, and my content either gets lost in the process, or has to be added back later. This is why email isn’t a good collaboration tool, and using a wiki can return email to it’s proper use, such as when I send you a message to tell you the wiki page with our document is ready for your input. Then, if I have a great idea I can add it to the wiki page, which ensures you’ll see it when you look at that same wiki page.

• Comments Off

This is the second in a series on wiki adoption, based on my visits with organizations in the midst of wiki adoption. Part 1 is here. Once your group starts using the wiki, be firm about making sure people don’t drift back to earlier means of collaboration. For example, if you used to send out meeting agendas by email, and now you put them on the wiki and email a link to the appropriate page, you may get someone who protests and asks for the agenda by email. They may argue that it’s more work to get an email and have to link to a wiki page, instead of just having the agenda right in the email.

If this happens, I’d suggest responding that although it seems like an inconvenience now, it’s really only a temporary inconvenience that paves the way for several improvements. First is a reduction in email when people are using to going to the wiki and an email with a link to the meeting agenda wiki page is no longer necessary. The second is a further reduction in email when people need to edit the agenda and can do so directly on the wiki instead of emailing the person who sent the agenda.

The third improvement is that now information is stored in a more archival, accessible, and secure format than email: if you were to lose your laptop or it’s stolen, email is lost along with it and this can compromise the security of sensitive information. However, if you’re using a wiki, that information is stored on a secure server and won’t be lost or compromised as easily.

The fourth improvement is that once you start using the wiki for meeting agendas, it lays the foundation for further wiki use, like managing the tasks and projects that arise from the agenda. It’s this organic use that makes the wiki quickly become an indispensable tool for information and collaboration.

• Comments Off