To stimulate adoption, just say no.

This post originally appeared on the Senior Fellows and Friends blog in June, 2010.

Word No, underlined by red pencil

©iStockPhoto/Kanstantsin Shcharbinski

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 Revenue Agency , (CRA) 6 years before, coming from the Nortel Networks meltdown. He had a background in large-scale learning, development and management and he knew this web 2. stuff was probably a good thing, he just did not know exactly how. 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.

Lessons:
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?

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

Leave a Reply

Your email address will not be published. Required fields are marked *