Whenever I explain why someone should use a wiki I usually come back to this graphic created by NASA:
Wikis, according to NASA, are designed (or at least deployed) to help mitigate the problems associated with document coordination via email. Whenever I show people this image, they immediately identify with the problems associated with document coordination and coauthoring via email.
Herein lies my question: if wikis are meant to help mitigate the email problem, why is it that when it comes to policy compliance we treat them like websites and not like email?
Because they’re web-based?
True, wikis are web based. But then again, so is email. In my opinion, what we are really talking about here is browser based versus client-based communication; think MediaWiki versus Outlook. This is most likely a nuance that is lost on many, taken for granted or considered unimportant. But the more I think about this, the more I think that these small differences are playing out in some major ways.
My Hunch on Policy
I have a hunch that many of the problems with deploying enterprise wikis are linked to the fact that we have trouble with them from both a policy and a cultural perspective because we try to treat them more like an intranet than like email. From a policy standpoint, we look at wikis and think about all of the interrelated policy frameworks (e.g. Official Languages Act; Access to Information Act; Privacy Act; Policy on Information Management; etc) and how they apply to government websites. I can see why we have gravitated in that direction, but have a feeling that it may be hindering adoption in a significant way. I would argue that public servants already understand their policy obligations when communicating via email. The only evidence I offer is the fact that email essentially runs the enterprise, and has for quite some time now.
Explaining wikis as websites that anyone can edit (standard practice, of which I am guilty) rather than a means of complementing email means that public servants are no longer familiar with their policy obligations. I’ve written on this matter before – about how push-button publication is changing the relationship between accountability and responsibility – but only connected the dots recently.
Why we might want to shift our thinking
Thinking about wikis as websites is creating confusion and complication, it disconnects us with what we are familiar with (email) and puts many outside of their comfort zone. We may overcome some of the barriers to adoption by refocusing on the fact that wikis can compliment email, and thus can be governed by a similar set of rules and norms. We look at email and understand how we craft it depends on the circumstances: intent, publisher, audience and the corporate (or non corporate) nature of the communication, etc. If we simply applied the same logic we might have higher levels of comfort around the use of wikis within the enterprise.
Wikis aren’t new, they are new to government
I know I sound like a broken record when I bring it back to Clay Shirky’s statement about the transformative nature of technology, but I think it is incredibly important:
“These tools don’t get socially interesting until they get technologically boring. It isn’t when the shiny new tools show up that their uses start permeating society. It’s when everybody is able to take them for granted. Because now that media is increasingly social, innovation can happen anywhere that people can take for granted the idea that we’re all in this together.” – Clay Shirky, TED Talk
Dulling the Luster
Perhaps giving everyone in the enterprise “control over their own website” is simply far too interesting, while extending their (boring) old email system is far less so. Moving forward I’m considering purposely dulling the shine of enterprise wikis by explaining them more like this:
“Think of wikis as just an extension of email. They make it easier to circulate those enormous attachments or collate people’s input on a document. All in all they aren’t so much shiny, new or interesting as they are ruthlessly utilitarian.”
Love this quote – These tools don’t get socially interesting until they get technologically boring. Reminds me of Facebook – it’s less about how new/wild it is now and just what people do.
I actually think the diagram is from my buddy Chris Rasmussen of Intellipedia fame. I’m pretty sure I saw him when he first launched the diagram in 2007
Steve – I’m gonna meet Chris at OGW in two days. =)
re: the quotation, I keep coming back to it time and time again.
Well shout-out to Jesse Wilson. That’s the sign of something good though – it spreads across the web. Love the diagram
Both of you are wrong. The graphic was made by someone from CENTCOM, Manny Wilson. I am saddend to see the credit has been dropped and now is going around incorrect. It was an image uploaded to Intellipedia and then cleared for the press and presentations, by Chris Rasmussen of NGA. I have also used this in some of my presentations and discussions.
Updated this to get the right Wilson brother credit, they are twins. There are also modified versions of this document, this looks to be the second version: Model developed by Manny Wilson, June 21, 2007… that’s the source information.
Steve, sorry I used the language “wrong” its better to say incorrect, and if you noticed, I mistakenly called out the wrong Wilson brother. Manny and Jesse are twins who are both Enterprise 2.0 evangelists at CENTCOM. After finding the sourcing material, I confirmed it was Manny Wilson’s original work. I’ll pass it on to him that the document is still being passed around.
When I present on wikis, I find it useful to compare the creation of a wiki page to creating a Word document. Word processing has been around for thirty years now and is a very familiar technology to all the generations.
I think a barrier to adopting wikis is that people feel that they will lose control of what they wrote. When I demonstrate the wiki’s ability to show who changed what and how to reverse those changes, I can see a more accepting attitude in most of the audience. Throw in a demonstration on how to lock pages and control who edits what and I find a lot of converts.
I think that people appreciate that they can collaborate using wikis but they also want to manage the collaboration. “Trust but verify” seems to apply to wikis as well.
@Andrea – thanks for the correction and please do pass along the fact that people are still using it. There was no mall intent on my part, just an assumption around origin.
@Bill – I also always point out that the technology actually allows them greater document control and flexibility; one of the core issues is lack of knowledge around the tool. This is one of the reasons that I’d rather liken it to email than the web as peep are more familiar with it.
I naively started my first wiki presentation with, “A wiki is a website that anyone can edit. Pretty cool, huh?” Instead, I spent the next hour fielding concerns about people changing their stuff. Showing how to view changes and how to reverse them just made it worse. I realized right away I made a big mistake.
Next time I plan to present it as a collaboration tool and not even talk about the web or changes. I really like the word processing mental model . . . great idea!
Is there a powerpoint or prezi on document development in wikis?
Thanks for the great post again Nick.
Craig/
@Craig – CommonCraft does a great video on wikis. And they have a good set of videos on many Gov 2.0 topics.
Correction: I meant “Web 2.0 topics” instead of “Gov 2.0 topics.” Starting to merge the two concepts. 🙂
@Jennifer you aren’t alone in that approach, many ppl do it, often w/ the same report
@Bill/Craig – I think that the common craft video on wikis explains them as a website any one can edit.
@Nicholas – Yes. But I’ve used the videos for several years and even tested students on the content. Students like the videos and more importantly, they grasp the concepts after only one viewing.