I started discussing the organizational change implications of collaboration a couple of posts back, then introduced a specific case study in the last post. Now I want to pick up that case study and look at how it played out.

The team rapidly fell into two camps - the enthusiasts (4 people) and the resistors (4 people). The enthusiasts included the team member who had dug in at the very start, laying out the framework, style-sheets, setting up quick links to glossaries, help aids, and so on. Aside from being perhaps the most technology savvy in the team, this individual had been an information architect in a former life, and really saw the benefits of managing the content at an atomic level in ways that could not practicably be done with MS Word. He saw this content management approach yielding huge benefits down the road in terms of keeping the report as a “living document” and reusing elements in all sorts of different ways. Another enthusiast was one of the senior executives on team. This individual was not tech savvy, but had some experience with blogging. This member did display some resistance early on, but the ex-information architect hand-held him through the first couple of days, and he soon became self-sufficient. He also “got” the longer term vision of how the document as a Wiki would deliver important benefits in the future. Two otherteam members found no real difficulty going through the learning curve, and quickly began using the Wiki for both writing and editing.

The resistor camp had a very different experience. The main forms of resistance were in the learning curve. While it was probably not more than a few hours effortto understand enough of the basics of using the Wiki tool, most of the team members found this effort more than they were willing to try. Exacerbating this learning curve resistance was the fact that team members typically liked to use plane trips and waiting at airport gates and lounges to do their writing activities. Now, you might argue that airports almost always have WiFi hot spots, and that you can write plain text in MS Word and paste it into the Wiki at a later point. This logic did not seem to wash with the resistors - the fact to them was, writing and editing on the Wiki was not as convenient for busy, traveling people.

As the deadline for the first draft approached, something interesting happened.A glitch surfaced for some of the team members that made it impossible for them to sign into the correct area of the Wiki without administrator intervention. It was only on the day before or, in some cases, the day of the deadline, that many of the members hit this problem - revealing that they had not even attempted to write or read on the Wiki. Their resistance to the Wiki was so strong that they did not even try.

Given this mixed experience - half the team had got through the learning curve and saw the benefits of the new approach, while the other half never got through the learning curve, the experiment came to a crucial decision point as the draft report was to be released to a broader audience for review and comment. Should the Wiki be opened up to the broader audience, or should the content be converted to a more traditionalform (MS Word or Adobe .pdf)? Regrettably, against strong objections from the ex-information architect, the document was converted to MS Word, and passed onto a professional writer for a final clean-up prior to review. The argument was that this was a “snapshot in time” view of the report, and that the Wiki could continue to be used for its original purpose. The reality was that as soon as the Word version was created and edited, version control was jeopardized, and the momentum behind the Wiki (fragile at this stage in the experiment) was lost. The experiment was quietly declared a success, and people quickly went back to the more traditional way of working - trading MS Word documents by email or by posting to the collaboration hub.

In the next post, I will examine some of the lessons to be learned from this experiment.