Saturday, June 19, 2010

To stimulate adoption, just say no.

About mid way into the pilot phase of the open collaborative workplace project, we added Karl to the team.  This is the story of his adoption of a wiki approach to preparing a large document. Karl had joined the Canadian Public Service 6 years earlier, after surviving most of the Nortel Networks meltdown. He had a background in large-scale learning, IT development and management and he knew this web 2.0 stuff was probably a good thing, he just did not know exactly how it should be used. This is the story of his initiation to a wiki, specifically the MediWiki install known as GCPEDIA. It is a story you may be able to repeat.

One of Karl's first tasks was to prepare a formal project charter that would begin the process of taking us from pilot to enterprise solution. As you can imagine preparing a project charter in a government central agency is a significant task. There was a prescribed outline to follow, four primary authors and an executive  level steering committee of 20 or so to be consulted. In addition to the immediate circle there were perhaps 100 or so interested parties.

After obtaining the requisite word processing template from the project management office, Karl came to me to discuss the approach for developing the charter. We had a tight deadline and I told Karl that we should use the wiki to create the document.

Two days later Karl showed up with a draft. As a word processing document. He was in a hurry he said and did not have time to learn how to use a new tool. He would put it on the wiki later he said.  I was keen to see the document, but refused to look at it, telling him to "do it on the wiki".  Apparently he did not believe me because a day later he was back with another word processed document, this time printed!  I rejected it outright. He left in a bit of a huff, probably thinking I was being unreasonable.

After a few minutes of instruction he was working away in the new tool. Some copy and paste and a little formatting and he had a rough wiki version. Commenting that maybe that was not so bad he sent a link to the small group of original authors.

Over the next few days we all contributed to the document and Karl began to smile as the benefits of writing on the wiki became obvious. No  emails with attachments.  No confusion over what version was the most recent.  A consolidated revision history and immediate notification of changes. We worked on it when we could, in the early morning or late at night, from the office or from home, I even made an edit from my BlackBerry.

In a few days we had created a version that we were happy with as a first draft and invited the larger group of executives to take part. A couple of them did, and we also had comments from interested bystanders.  By the time we got to the committee meeting everyone had had their opportunity to contribute and the document was quickly approved.


Most people will naturally resist change, even when they know it good for them. If there is a familiar alternative they will use it, particularly when they are under pressure. By removing the familiar, users have no choice but to try the new way.

If it is possible to make your collaboration space the only way to do something important, make it so. It will force that critical first step.

What do you think, is this something you can use?

Do you have any adoption stories you would like to share?

Thom Kearney is a partner in Rowanwood Consulting and can be found online at This post refers to a time when Thom was a Senior Director with the Canadian Federal Government leading the introduction of the Government of Canada internal collaboration space known as GCPEDIA.


  1. I like this approach. I'm not sure it would work in every agency or organization, but it's definitely worth a try.

    Some years ago, I faced a similar issue in a private company, where one of our greatest collaboration tools became an actual hindrance to the larger (and worthier) goal of knowledge management. We were using email distribution lists to source deep technical answers from our development team (the architects, engineers, and developers) and from higher level support (sysadmins) to aid in customer support for an n-tier HR web application with replicated instances for each customer. We were looking for one of two responses: 1) it's a defect, send it up or 2) try this fix and report back.

    The great thing about the email distribution list is that it tied into processes our developers, sysadmins, and support people were already doing: namely email. The downside is that email threads tend to get cluttered and eventually create pockets of temporal expertise that disappear when enough of the original players move on to other jobs (even in the same company). This necessitates duplicative effort when, inevitably, a question needs to be answered again. The answer was a forum, since this is the most intuitive way currently available to keep track of this kind of knowledge.

    So, with executive support, we sourced and evaluated forum software and eventually implemented one that could do what we wanted it to do, more or less. It worked well, but was only half a solution. What it didn't do, and what few forums do, is allow responses by email. The initiative was not a failure, per se, but its adoption could have been strengthened by not forcing the users to completely abandon the familiar in favor of a new and unfamiliar process.

    I think this lesson will continue to hold true as we transition the way we do business. If we can make these brave new worlds more familiar, we can get people to do so many things.

  2. Thanks for your comment Aaron,
    I totally agree that this is not something you can always do. It is important to make sure that the tool can fully support the task, and I am not promoting a draconian approach to creating adoption.

    Rather, its more like first time I parachuted. I really wanted to jump out of the plane, but the instructor had to push me to get me out on the wing because I was not ready for the wind resistance. I think many of us have a kind of built in resistance to change,and sometimes we need that friendly push.

  3. Aaron,

    Basecamp has a messaging function which allows reply by email... worth checking out. I am trying to get people to use a forum as well, but making people sign up, request access, etc is making adoption much harder.


    Great post. I have been trying to do this with mixed results - part of the problem is in a public safety context I really need collaborative software that can handle sensitive information. The most collaborative of government documents - briefing notes and MCs - are often secret so using collaborative software is still out of the question.