Wiki Washy or Flavor-Of-The Wiki, Take your....ah...Picky?

(November 4, 2011) The need to document business processes has gone viral. Sure, companies started the process craze years ago with the need to achieve quality certifications like ISO9000, but what's happening today is different. It's much bigger. Now it's about survival. How do you run a business after you've fired all the high-priced folks who actually knew how to run things?

The popular answer seems to be, hire a tech writer and let them create a wiki! What's a wiki? It's a magical place where everyone joins hands in a circle and does something forbidden and dirty. They collaborate. That's the ticket. A wiki is a magical, writhing cluster of consensual collaboration. It's like Pandora...and we're all going to join tails (or tales in the case of process documentation) and be one. 

Well, I certainly would love to teach the world to sing in wiki harmony, but I can't. Wiki isn't an answer, it's a tool and like all tools, it has its place. So don't get caught up in the hype. 

Rather than go into a long discussion on the pros and cons, the whens and wheres, the hows and whys, I decided to share my answers to some qualifying questions I received from a recruiter recently regarding a wiki creation job for a well known Dallas company that sells (as Steve Jobs once put it) "sugar water."

Qualifying Questions:

Can you provide examples of file-based content you have migrated and restructured into Wiki content (e.g. web page orientation, extensive linking, embedded images/video/audio/charts, web page table of contents with links within web page, tagging for search, clear authorship and version)?

No for several reasons. Wiki is inside stuff. It is proprietary so I can’t share what I have done. Also, depending on what Wiki they are going to use, most are extremely inefficient documentation tools that are the worst of all worlds because they do not support a full set of HTML commands. So in other words, a nicely formatted web page does not work as a Wiki. And all of the features of a well done document do not translate to a Wiki. Now my experience with this is VERY current. Wiki is the business buzz term of the month, but it is a tool that ONLY has distinct advantages in a VERY collaborative environment, where folks are going to be participating in providing their two cents across the company. If it is not intended to be used this way, then real web pages or real documentation is far superior.

Now, can I do what they ask? Yes, in several flavors of Wiki (SharePoint and Confluence). But would it be right? Need to see. Anyone who does not agree with what I have just said does not know what they are talking about.

* Can you provide examples of Wiki layouts and topic structures you have developed and/or utilized in the past?

See above.

* What types of corporate documentation legal policies have you dealt with in the past and how did this modify your documentation work?

This question was written by a chimpanzee. For instance I could say I dealt with EOC requirements that preclude me from calling women “bitches.”

* Have you created an internal-use corporate Wiki previously? If so, what watch-outs can you provide from the experience?

So now they want me to give them what took me many hours to determine. Fine. I’ll give them a dealer’s taste. First, I have not seen a single Wiki that supports a full set of HTML commands. Why? It’s an immature technology. Second, some of the Wiki tools such as SharePoint cannot support simple cutting and pasting of graphics. Graphics have to be stored in special folders and linked to the Wiki pages. Now if you have ever dealt with linked files, they are constantly getting broken and the maintenance is horrendous, read expensive.

* Can you provide an example of the most complex Wiki you have developed to-date (e.g. addressed content hierarchy & compliance needs, consistent tagging, content structure and layout, integration of internally public and internally private Wikis)?

Wiki pages are organic and work best when used as a collaboration tool. In this case, you set up a structure for folks to use, let them draw on the board, and then come in after the fact to clean up the mess. Wiki pages are proprietary so I cannot provide an example.

* What would you consider "Wiki best practices" and how have you threaded these best practices into your Wiki content development in the past?

Wiki best practices are where folks want to use the Wiki to communicate information that might be needed by many groups. Most Wiki sites start out okay, but content does not get reviewed, and content is typically not dated. So once folks find out that they can’t get current information, they stop using it. I have not seen it work well for very long. It becomes like a garage that needs to be cleaned out. A fish tank without a filter. Eventually, the fish dies.

However, even with all the negative stuff I have said, it is possible to do it correctly. It takes CONSTANT maintenance to make the information usable. And most importantly, it takes a commitment to collaboration between all of the employees who use it. Wiki is not free. Companies need to understand that. It’s not the tool, it’s the process and the commitment to using the process that makes it work.

By the unbelievable naivety of these questions, it is obvious that your client is simply buying a flavor-of-the week. As a consultant, I would first sit down with them to try to define the problem that they are trying to solve, and only then would I propose a solution which may or may not be Wiki.

Frankly a far superior solution that I have seen used effectively (without the need for consultants) is Dropbox. Having a collaborative space where folks can place and share files is AWESOME. That’s why Dropbox, the company, is growing by leaps and bounds.

Tell your client that solving communications problems is MY business, not theirs. I will be happy to fix their problem for them once we figure out what it really is…for the right price.

*****

Funny, they haven't called me back ;-)

Art