Lionbridge Innovation

Using Time Zones to Your Operational Advantage: Part II

Director of Technical Services Excellence, Jim Compton continues the dialogue on efficiently using time zones in global business operations…

Director of Technical Services Excellence, Jim Compton continues the dialogue on efficiently using time zones in global business operations…

---

If Part I of my article seemed like it should have been titled “Time Zones: the Phantom Menace,” then think of Part II as “a New Hope.”

 Last time, we looked at how time zones can impact a project’s duration, and so far, the example scenarios we’ve introduced all seem to suggest that multiple time zones work to the disadvantage of the project’s duration and process cycle efficiency.

This time, we’ll introduce a new, multiple-time zone scenario to our set of examples that represents an improvement over what has been possible in a single time zone, and we’ll take a look at the global workflow design principle that makes this so.

Scenario Four – Multiple Time Zones, the Re-Mix

To remind you about our pretend project, we’re producing a training presentation by way of a very simple workflow:

Activity	Duration
Write Training Spec	1 hour
Create Template	2 hours
Author Content	8 hours
Assemble Module	2 hours
Total Project Value Add Time	13 hours

In the globally-distributed arrangement that we introduced in Part I, the training spec was written in Boulder (CO, USA), the template was created in New York, the content was authored in London, and the module was assembled in Mumbai.

Let’s tweak things a bit and see what happens when we swap the activities that are performed in Mumbai with those that are performed in London. That is, we’ll have the content authored in Mumbai and the module assembled in London.

Figure 2 - Globally Distributed Process (Re-Arranged)

Let’s compare the results of this new scenario against our existing scenarios.

Metric	Multiple Time Zones (re-arranged)	One Time Zone	Multiple Time Zones (original configuration)	Multiple Time Zones (delay event)
Total Value-add Time	13	13	13	13
Total Elapsed Time (in hours)	24	30	37	61
Turnaround Time  (in days)	1	~1.5	2	3
Process Cycle Efficiency	54%	43%	35%	21%

Here’s the same data displayed graphically:

This new time zone arrangement has the shortest duration and highest process cycle efficiency of any scenario we’ve seen so far – beating-out our single time zone example. The turnaround time is one day, compared to the previous best of one-and-one-half days.

While it may seem that 54% process cycle efficiency is still pretty inefficient, from a practical standpoint, this scenario is close to the theoretical best case. In the theoretical best case (in which there is no wait time), the work would be ready for the customer to pick up by 9pm Monday evening Boulder time. But assuming the customer can’t receive the deliverable until the next morning, the customer-perceived elapsed time would be exactly the same – 24 hours.

It may be helpful to visualize all of these scenarios by taking a look at the spreadsheet that I used to map them out in the first place.

Principle #1: Go West, Young Man

 This brings us to our first principle of using time zones to your operational advantage.

Scenario Four is so effective in terms of duration because it utilizes the main concept behind the “Follow-the-sun” workflow model – making sure that wherever there is daylight, there is work going on. On our planet, this is achieved by moving the work westward.

A round-the-clock, multiple time zone operation would need at least three times zones spaced more-or-less evenly apart (assuming the constraints of a 24-hour day and 8-hour workdays).

Here’s a visual example that may be helpful:

Figure 3 - Following the Sun versus Moving Against the Sun

In this example, we have twelve work units (displayed as little bricks) representing approximately a quarter of the workday each. In the “follow the sun” arrangement (the green bricks), the work moves from East to West as soon as it becomes closing time in any one time zone. You can see that in this arrangement there is little to no down time due to waiting for an office to open.

Contrast this with an arrangement whereby the same work moves from West to East. Where the red arrows appear to be crossing “into the night” to get to the sun represents lost time waiting for an office to open.

The Cliffhanger

At Lionbridge, we have solution centers in 26 countries. This contributes to our broad geographical reach and grants us a great deal of flexibility in being able to architect global workflows that best serve our customers’ needs (including, but not limited to, quick turn-around times).

Employing follow-the-sun workflow models requires some scale and flexibility. It will not always be an option for everyone to flow work westward, but don’t fret. I have yet to share with you some additional global workflow design principles and practices that can benefit operations of all sizes.    

In the third and final installment of this series, we’ll ditch the theory and get practical, discussing some techniques that can help you more effectively manage time zones on your real-life globally distributed projects.

Until we meet again, your feedback is encouraged and appreciated!

Using Time Zones to Your Operational Advantage: Part I

ww_distribution.png

Jim Compton, Director of Technical Services Excellence, discusses how time zones can play a favorable role in your global business operations…

Jim Compton, Director of Technical Services Excellence, discusses how time zones can play a favorable role in your global business operations…

---

The trend toward globalization has naturally resulted in an increased use of geographically de-centralized teams, which means work for certain parts of a process might be executed anywhere in the world.

My experience at Lionbridge is that this relatively new way of working has been greatly beneficial, and I'm guessing this may be similar to your experience. Widening the playing field has created more options for designing the best operational solution, and by "thinking outside the border," we have access to a wider and more diverse pool of talent and resources.

In this model of worldwide-executed work, I've found that, of all the contributing factors, one in particular can act as a project's greatest ally or worst enemy: time zones.

The Time Zone Factor

In the trinity of "better, cheaper, faster," the issue of time zones most prominently affects duration: the time it takes for a project to be executed from beginning to end.

With respect to Thomas L. Friedman, while the world may be flat, the pictures I've seen suggest it is at least somewhat sphere-shaped. And because our sun (lousy at multitasking) can only create daytime in so many places at once, all worldwide endeavors must operate within the constraint that it's always the middle of the night somewhere, and at any given time someone on your global team may be asleep.

The extent to which teams decide to exploit this constraint or let the constraint exploit them can have a profound impact on a project's overall duration.

Let's take a look at how time zones can impact a project's duration by using some made-up, but quite possible scenarios.

Example Scenarios

Let's pretend we have a project to create a training presentation that uses a very simple workflow: Write Training Specs-> Create Template-> Author Content-> Assemble Module, after which the product can be delivered to the customer (who in our example is based in Boulder, Colorado, USA).

ACTIVITY	DURATION
Write Training Spec	1 hour
Create Template	2 hours
Author Content	8 hours
Assemble Module	2 hours
Total Project Value Add Time	13 hours

Let's agree that (a) a workday is defined as eight hours split in half by an hour lunch, starting roughly at 8am and ending roughly at 5pm, and that (b) no-one works outside of the workday, and that (c) daylight savings time is not a factor.

Let's consider the following different operational scenarios:

Scenario One - One Time Zone

In Scenario One, all activities are executed in one time zone, out of Boulder. Starting Monday morning, the spec, the template, and a little bit of the content authoring work are executed before lunch. By end of the work day, a little more than half of the authoring work is complete. The work picks up again on Tuesday morning, and by 2:00pm Tuesday afternoon, the product is delivered to the customer.

Scenario Two - Multiple Time Zones

In Scenario Two, every activity is distributed to different members of the team, who are based in different time zones, and the process goes smoothly. Any latency between the end of one activity and the start of the next is classified as "wait time." As you can see from the graphic below, wait time due to non-working hours adds a significant amount of time to the total duration of the project. (This is true for single-time zone projects as well.)

Figure 1 - Globally Distributed Process

Scenario Three - Multiple Time Zones (with a delay event)

Scenario Three is architecturally identical to Scenario Two, but in actuality, things didn't go as smoothly. Let's pretend the handoff from New York to London was missing some crucial but overlooked component that the content authors needed to get started (for example, a password to access the files).

In this scenario, instead of work beginning on Tuesday morning in London (8:00 GMT), corrections have to be implemented five hours later when New York opens (13:00 GMT). Because of its delay getting started, London can no longer complete its work by end of day Tuesday, and instead completes the work early afternoon Wednesday, the following day.

For Mumbai, this means that instead of starting the work on Wednesday morning, it can't start until Thursday morning. This glitch actually created a full day delay!

Comparing the Durations

Let's compare the results of these scenarios. Note that our Total Elapsed Time intentionally excludes any customer out-of-office time prior to pickup. That is, if a project is technically complete but the customer cannot pick it up until later (for example because they have not yet woken up), that time is not counted.

Process Cycle Efficiency is the Total Value-add Time divided by the Total Elapsed time. A bigger number here means more efficient.

Metric	One Time Zone	Multiple Time Zones (one configuration)	Multiple Time Zones (with delay event)
Total Value-add Time	13	13	13
Total Elapsed Time (in hours)	30	37	61
Turnaround Time (in days)	~1.5	2	3
Process Cycle Efficiency	43%	35%	21%

And a graphical representation...

I hope you can see how the way the project's execution plays out through time zones can have a major impact on a project's duration; but admittedly, I haven't yet told you how you can actually use time zones to your operational advantage. In fact, if you weren't paying attention, you might think the moral to the story is "never work outside of one time zone." Au contraire!

Here's a teaser for Part II:

While it's true that at any given time it's always midnight somewhere, it's also true that at any given time it's the beginning of the workday somewhere else. By exploiting this fact, and by following some best practices that I will share with you next time, I hope to demonstrate how you can not only minimize the impact of time zones, but you can actually harness their power to drive up the Process Cycle Efficiency.

Until we meet again...

Are the World's File Formats Becoming XML?

After asking, "Are the world's file-formats becoming XML?", I found myself in the middle of a mini-existential crisis, realizing that I had just asked something challenging and important for which I didn't actually have an answer.

Today Jim Compton is thinking about the present and future of XML. Take it away, Jim...

---

Last week I gave a presentation to some of our Lionbridge sales group as part of an internal training series. My presentation was called "XML Tools, Standards, and Technology." One of my objectives was to reinforce the importance that XML currently has to Lionbridge's business, but I also wanted to convey that XML is only going to become increasingly more important.

After a series of "show-and-tell" slides where I discussed dozens of different real-world XML applications in use today, I asked the following question:

"Are the world's file-formats becoming XML?" 

My motives for this question were purely rhetorical, and fortunately I wasn't taking questions until later, because the second this question left my lips I realized that this wasn't a rhetorical question at all; it was a real question capable and deserving of a real answer. I found myself in the middle of a mini-existential crisis, realizing that I had just asked something challenging and important for which I didn't actually have an answer.

Now that a couple of days have passed since my presentation and I've had the opportunity to do some thinking and research around my question, please allow me to share my thoughts and findings.

The Reason for My Question

Of course, I asked this question because I already suspect that the answer is "yes." From my desk chair it certainly seems as if I'm seeing XML in more places than, say five years ago. Many of the things that I used to do from my desktop I'm now doing purely online in "the cloud," but even the documents that still live on my hard drive now seem to have an "x" somewhere in the extension.

Professionally, I'm hearing more from existing customers that they are interested in migrating their existing content (and therefore their structured translation endeavors) into an XML-based model. It also seems as if more new customers are bringing XML to the table as the default.

The matter is important for Lionbridge. The extent to which the world's content will or will not be organized as XML has a profound significance to a company whose role includes producing and managing content in different human languages. By focusing our innovation efforts in the right place, we will be better able to support the future language demands of the content producing world.

My Research

So I did some web-searching to see if anyone else had already answered this question for me. While I was able to find lots of commentary in the vein of "an increasing number of technologies are using XML," there was little that I found in the form of hard data.

To give myself a sense of the scope of this "increasing use," I performed a couple of non-scientific measurements that I'll share with you.

Measurement One

I was interested in knowing which file-producing/editing desktop applications on my computer used XML-based "native" file formats, and which supported XML-based "exchange" formats. (Note that I didn't count any XML editors in the survey.) For most formats I just popped them open in a text editor and checked for the telltale XML structure.

Application	Native XML?	XML Exchange?
Adobe Creative Suite 3* (Photoshop, Illustrator, InDesign)	somewhat, .psd structured as XMP	yes (.svg, .inx)
Audacity 1.2.6	yes (.aup)	n/a
Microsoft Office 2007 (PowerPoint, Excel, Word)	yes (.pptx, .xlsx, .docx)	yes (various)
FreeMind	yes (.mm)	n/a
GIMP 2.4.4.	no (.xcf)	no
Google Sketchup 7	no (.skp)	yes (.kmz, .dae)
Microsoft Visio 2003*	no (.vsd)	yes (.vdx)

*not the most recent version. 

Lesson learned? Well, most of the apps on my machine either created XML-based files directly or supported the export of an XML-based format. I was also reminded of the fact that not all XML is created equal. There was a huge difference between the hierarchical granularity and the data structure between, say an .mm file (where every node gets its own element) and a .psd (where all of the picture's guts are crammed into a single element).

Measurement Two

I went to the Wikipedia page "List of XML markup languages" and tried to assess how much this page has grown. Today, there are 194 XML-based languages listed which represents a 23% increase from the 158 languages listed since November 2006 (when the article was created).

Lesson learned here? Well, I suppose this generally suggests that the number of public XML-based markup languages has grown, but this didn't necessarily give me what I was looking for. Of course we would expect time to produce more XML-based languages (could it do otherwise?), but it says nothing as to how these XML-based languages are faring in the real world or how they compare to their non-XML based equivalents.

Conclusion?

Well... inconclusive. For the time being, my question remains deserving of (and waiting for) a real answer.

I now realize that the question doesn't live in a vacuum, and is probably co-dependent on the answer to the question, "to what extent is the world's data becoming web-based?" I also realize that what I probably really want to know is, "how will I recognize if and when XML has become the lingua franca for electronic file formats?"

So maybe this is where I hear from you. Do you have any research, data, insight, ideas, or plain 'ol opinions that you'd be willing to share on this subject? If so, I'd love to hear from you!

Structured Translation: The Case for XLIFF

Today Jim Compton's thinking about XLIFF and its use in structured translation. 

---

In the early nineties, as CAT (computer-assisted translation) tools started to really take off, so was born the translation pivot file: an intermediary format that bridges translatable material from its native environment into the world of structured translation. The development of the pivot format facilitated the use of practices that we take for granted today, including translation memory, electronic glossaries, rule-based QA, etc.

At that time, the de-facto translation pivot format was RTF - a clever application of the RTF standard that used character styles and hidden text to perform a variety of functions, including segregation of translatable from non-translatable material, and storage of the bilingual content within the file itself.

In 2002, the translation pivot format enjoyed an evolutionary jump with the advent of XLIFF, an XML-based format that performs its entire magic using xml markup - you know, "tags."

If you're not using XLIFF with your own structured translation endeavors, here are a few reasons why you might want to consider doing so:

Solid Character Encoding
XLIFF uses Unicode to define encoding, which is straightforward, unambiguous, and relatively safe from transcoding errors and other forms of encoding corruption.

This may seem like an obvious "must", but the translation pivot format has not always been based on Unicode, and has historically been prone to transcoding and encoding issues that can be expensive and time-consuming to correct.

While the risk of encoding trouble isn't absent with an XLIFF-based translation process, it is certainly greatly minimized when compared to non-Unicode-based alternatives.

Strong, Normalized Metadata Support
The flexible support for standard and custom metadata at various levels (at the file level and at the translation unit level) opens up a world of possibilities for improving the localization process, including, but not limited to:

• Improving TM leveraging through the inclusion of context
• Pairing of content to specific glossaries or reference material
• Including length-limits and other "handling instructions" for translators
• Including information as to the content's state of completion or likely reliability
• etc.

Rules-based Pre-Processing
While technically not inextricably bound, XLIFF is closely affiliated with rules-based pre-processing, mostly because there are very few non-rule-based mechanisms for converting source files into XLIFF files.

The issue here is consistency. Rules-based pre-processing encourages pre-processing consistency, which in turn encourages segmentation consistency, which in turn encourages effective TM leveraging and therefore a lower overall translation costs.

Extensibility
As a type of XML - the format itself is extensible, meaning that it is free to evolve into whatever it needs to become. Today, as OASIS, the organization that developed XLIFF works on version 2.0 of the specification, the format continues to evolve and improve.

Openness and Standardization
That XLIFF is an open standard encourages participation from the world of developers and would-be tool developers, and ensures that their solutions are likely to be interoperable - creating operational freedom and flexibility.

And in fact, CAT tools built around the XLIFF standard continue to get better and better.

At Lionbridge, our own collection of XLIFF-based tools (which I would argue has become one of the best in existence) is helping us to automate more-and-more previously manual activities and to bring the localization process entirely online - moving us further toward the "El Dorado" of Localization 2.0.

Some Online Resources

Have I inspired you to research further? Here are some links that you may find helpful:

• XLIFF "Cover Page" (contains lots of links and resources about XLIFF)
• 1.2 XLIFF specification (current version when I wrote this)
• XLIFF 2.0 Feature Tracker (what the future may look like)
• Wikipedia stub on XLIFF (sparse right now but will inevitably grow)

Of course, Lionbridge is willing and able to help you to establish an XLIFF-based structured localization process.

As always, your feedback is encouraged and appreciated. Thanks!

Free Hacking Tip: Use a Web Browser as an Encoding Tool

Another great post by Jim Compton. Today he shares a free hacking tip...

---

With the gradual proliferation of Unicode, the issue of different character encodings is fortunately becoming less-and-less of a headache, but we're not quite there yet. Pre-Unicode encodings are occasionally still a factor for projects, and it can be challenging and sometimes confusing to identify what encoding you're looking at, or to perform transcoding without causing character corruption.

It may come as a surprise to you that right now you're probably looking at a capable and free encoding-diagnostics and transcoding tool - your web browser.

The Transcoding Challenge

Let's take a typical situation where we want to convert a file from some flavor of ANSI encoding into Unicode. To do this, both you and the application that will do the actual conversion of the bytes need to know the language-class of the file that you are converting.

Unlike Unicode, ANSI does not have a built-in mechanism (such as a byte-order mark) to identify its language-class to applications. Some applications, such as the Windows Notepad will try to guess using clues such as the language of the operating system.

As is always the case when it comes to guessing, such applications can get it wrong.

Here's what it looks like when a Russian ANSI file is misinterpreted as being Western European.

Figure 1 - Russian ANSI misinterpreted as Western European ANSI

The file is not corrupted per se, but is being improperly displayed by the well-intentioned but ill-informed application. Any conversion at this point would cause corruption, however, as the resultant Unicode would essentially be exactly what we're seeing here, but with every character re-encoded using multiple bytes.

This means that it is important to perform character-encoding conversion from within applications for which you can explicitly tell the application the language-class of the ANSI.

Enter the Web Browser!

Web browsers, because they have to deal with the possibility of encountering any variety of encodings while surfing the worldwide web tend to have rich multi-lingual read/write abilities.

To make use of this functionality, open up your text file in your favorite browser using either the File->Open method or by simply dragging the text file into the browser window.

(Note: If your file has an extension that your browser doesn't recognize, such as .properties, .rc, etc. the browser may assume that the file is a binary and try to "download" it for you. Since we're talking about all text-based resource formats, you can temporarily trick the browser by first adding a .txt suffix to the file name. A more permanent solution would be to configure the browser to recognize these MIME-types as ANSI text.)

Once open in the web browser, the file may or may not be automatically recognized with the correct type of encoding. Just like Notepad, the browser takes a guess, and it would be safest to assume that its guess was wrong.

Here is what the same Russian file looks like when opened by Microsoft Internet Explorer, which incorrectly guessed that the file is a UTF-8 file sans byte-order mark.

 
Figure 2 - Russian ANSI misinterpreted as UTF-8

Fortunately, browsers include a method by which we can explicitly tell the browser what kind of encoding it should be interpreting the file as. In Internet Explorer, for example, there is an encoding selector under the View menu.

Figure 3 - Encoding selector in Microsoft Internet Explorer

Note: there are many more encodings to choose from under View->Encoding->More.

Since the file is in actuality encoded as Russian ANSI (or "Cyrillic (Windows)"), we need to tell the browser this fact by choosing this encoding from View->Encoding. Here is what our Russian ANSI file looks like when we've explicitly told the browser.

Figure 4 - Russian ANSI correctly interpreted

It is important to understand that even though the display has changed, we haven't made any actual changes to the underlying file at this point. The file is byte-for-byte identical as when it looked like a bunch of box-characters, but now the browser is interpreting the bytes correctly.

Once the browser is properly interpreting the actual encoding of the file, we can use the browser to change the encoding to Unicode. In Microsoft Internet Explorer, this can be done through the Save As dialog by choosing Unicode from the Encoding drop-down.

Figure 5 - Using "Save As" to change encoding

The resultant file should be properly encoded as Unicode (little endian byte-order) with a byte-order mark. Since the file is now explicitly Unicode, Notepad should be able to open it up without issue.

Figure 6 - Russian file encoded as Unicode

Ta-da!

Subversion 1.6 Introduces Welcome Improvement for Localization Projects

Today Jim's talking about Subversion 1.6...

---

Howdy!

Are you a fan and/or user of the open-source version-control system Subversion^®? If you're like me, you may have missed that back in March of this year the tool underwent a fairly substantial update - version 1.6.

 
Someone at CollabNet must have been reading my mind, because the 1.6 update includes a significant change that addresses one long-standing pain point for me - file-level granularity in the svn:externals property. Before 1.6, you could specify folders but not files, but now the externals property supports individual file definitions too. :-)

Why do I care about being able to include individual files within an externals definition, you ask? To explain, I should briefly explain one of the common ways that Subversion is used in Lionbridge on localization projects.

Subversion in a Localization Project

Like other code development projects for which Subversion was actually designed, a localization project can be looked at as a set of files which undergo a series of changes based on the contributions of the project participants. In the localization world those contributions tend to be more focused on language activities (i.e. translation), however.

Subversion is great for managing localization projects. In addition to providing version control, an SVN Repository can act as the hub of an on-demand, pull-based file distribution system - allowing dozens of translators and other participants to be working simultaneously without the need of a file dispatcher (read: bottleneck). Combined with Logoport-based online TMs, such a mechanism supports round-the-clock progress and parallel processing on even very complex, high-volume projects.

When designed properly, files will remain in their natural directory structure throughout the process, avoiding the need to shuffle-around files into different packages at different stages - at best an inefficient process and at worst a potential source of error.

The Pain Point

One challenge with having contributors interact directly with a Repository, however, has been in trying to prevent those folks from having to check-out files which aren't relevant to them. German translators, for example, probably have little interest in the localized resources for French, Spanish, Japanese, Czech, Russian, etc - so it makes sense to try to spare them the burden of having to download these files on check-out.

This is easier said than done, unfortunately. Of course if resources are segregated by language-specific sub-directories, you could always provide the German translators the path to the subdirectory containing the German resources, but if we have many language subdirectories (one per component, for example), we're hardly making their lives easier by doing so.

Enter "Custom Modules"

One technique that we've employed is the concept of modules (borrowed from the CVS world) - essentially an empty directory that is unique to a particular role and is "loaded" with externals pointing to all relevant subdirectories for that role.

For example, the German translators would be directed to check-out ProjectName/CustomModules/GermanResourcesModule

...an empty directory that includes an externals property which "links" to the following subdirectories within the "natural directory structure":

ProjectName/NaturalDirectoryStructure/SomeComponent/GermanResources
ProjectName/NaturalDirectoryStructure/AnotherComponent/GermanResources
ProjectName/NaturalDirectoryStructure/YAComponent/GermanResources

In essence the German translators get a custom package that includes only those directories which are relevant to them, but the files themselves remain linked to their natural home within the natural directory structure - the best of both worlds!

Unfortunately, since the externals property only supported directories prior to version 1.6, this technique would only work if your languages were segregated by subdirectory. If all your language resources live together in one directory (identified by a prefix or suffix in the file name, for example) this technique would simply not work.

But now since you can specify individual files in the externals property (hopefully supporting a regular expressions syntax), hopefully this limitation is a thing of the past.

I haven't actually installed version 1.6 yet, but this upgrade would seem to be worth the effort.

What do you think?

Lionbridge Builds Collective Intelligence Using Wiki

Please welcome Jim Compton, today's Lionbridge blogger, who's sharing his thoughts about collective intelligence in a corporate setting...

---

For my inaugural contribution to this blog I thought that I would share some of the experiences we've had at Lionbridge using wiki for the purpose of collecting and capturing institutional knowledge and expertise.

First, a little internal background: Lionbridge (as I would expect is true for many companies) has historically found it challenging to:

1. ensure that expertise and knowledge is documented (as opposed to locked-up in people's brains), and
2. keep said documentation up-to date and accurate

Traditional approaches to documentation - asking the experts to author documents or having folks author content to be hosted through a web server (i.e. static html pages) - have always had inconvenience working to their disadvantage. Getting an expert to author a complete, holistic document on a subject was often a huge, time-consuming chore that took a back seat to actual project work (if it would ever happen at all). Adding the need to coordinate with a web-master to the mix created the situation whereby the cost of participation was just too high for many - so they opted not to.

And getting people to contribute is only part of the battle. Once you have documentation in hand, you also have the issues of needing to pair the information with those who need the information, and of making sure that the information evolves as the facts themselves evolve.

When we started experimenting with wiki several years ago, we quickly noticed a profound effect on our state of documented institutional knowledge. With the wiki-characteristics of low-cost participation (people can contribute just a single fact if they know one) and instant web-based distribution, we started to see profound levels of contribution from people who hadn't previously contributed at all.

The number of collectively-authored articles on our system started to grow rapidly, and when we hit a sort of critical mass, we started to notice an interesting phenomenon: the collected articles started to create a form of intelligence that was greater than that of the individual articles themselves.

Folks who are familiar with the phenomenon of Wikipedia will know what I'm talking about. The unique behavior of wiki-linking enables an author to create a link to information that may not even exist yet. As more authors write on various subjects, eventually the information for missing subjects will get authored. Instead of pointing to nothing, those articles which contain wiki links become more valuable by acting as referral articles. By following these links, a user can often glean more information than if they were to have actually consulted the experts themselves.

I liken this phenomenon of articles organically linking themselves together to my layman's understanding about the way synapses work in a brain to create intelligence. Intelligence isn't just about collecting facts (or experiences); it is about growing meaningful connections between them.

Anyhow, I feel that we've just scratched the surface utilizing the benefits of these technologies. We live in exciting times, don't you think?!

If you've had similar (or contradictory) experiences with wiki in your organization, I'd love to hear your story.