Why Wiki Isn't New to Government

In government, where change is recurring and often stressful to the employees affected, Web 2.0 can be a tough sell. One of the biggest hurdles in implementing technology in the workplace is not resistance to technology per se, but the cultural shift that the new software represents.  But when a technology is introduced which replicates an existing work process in a more efficient way, is it really "new"? 

When I joined the public service I often heard it said, "In Government, everyone is an editor."  For recent graduates — or others just accustomed to the experience of creating polished work and having it accepted verbatim and with full attribution — this is a warning about the process of government.

You write a document.  Several peers or senior colleagues will review it and add suggestions and changes.  After this initial round of  development, your manager will likely wish to take out their own red pen for additional quality control.  Once you've folded these in, your document (or rather, "the" document) will be ready to make its way up the chain to your director, who will likely make other edit requests for you to include before returning it for final approval.  Depending on who or what the document is for, the document may continue to morph for some time even after its left your workgroup.

For people who are either protective of their product or simply used to creating something "final" by themselves, the whole experience can be a bit unnerving.  Some edits will feel legitimately useful: significant additions of important information, corrections of errors, or re-ordering of content to make the ideas flow more effectively.  Other changes may sit less well: wholesale deletion of entire paragraphs, wordsmithing, or comma moving.

But this is the way we work in government.  What you create is a draft, which may ultimately be returned to you several times covered with sticky notes and red ink, or, in the case of electronic documents, with multicoloured strikeouts and comment bubbles detailing the tracked changes.  It can be initially painful and occasionally still frustrating, but more often than not the resulting product is superior to what any one person could have created alone.

If this is any different to what a wiki accomplishes, the distinction is lost on me.

You create a wiki document.  Several peers or senior colleagues review it and add suggestions and changes.  After this initial round of development, you advise your manager that you've got a draft posted.  The manager logs in and makes their own contributions to quality control.  Now there's something online for your director to have a look at when they have some time.

The process is completely transparent.  Everyone's edits, major and minor, are captured in the wiki's history tab.  There are no multiple copies of the document floating around through email, nor any misplaced hard copies with edits yet to be added.  Everyone is editing the master copy of the document in real time.  None of the deleted text is ever really lost: it exists in a previous version.  Any content deleted from a previous version of a document can be copied forward into the current version, if someone decides it was worth including after all (as-is, or as draft text to be re-worked).

A wiki isn't useful for every document — sensitive information requires sensitive handling, and you probably don't want employees making wish-list alterations to official policies — but for fast and efficient building of unclassified documents, why not wiki?

3 comments:

  1. Good post Todd. I hope you're helping to sell wikis in your department ;)

    This sheds light on a key issue - we focus on the tool, not the utility or behaviour. Where do we fall down? In my opinion and experience, it's sales.

    When you buy a car - the person who put the engine in isn't selling it to you. Rather, it's someone trained in knowing customer needs, fears and behaviours as well as the product who makes the deal.

    In the case of my department, the IT shop that implemented the wiki has been 'selling' it. For the most part they're gaining traction but I think you can see where that's going.

    What's the implication of this? Those of us who need to rely on people using the wiki and 'playing nice' end up taking more and more time to show people it's true value before we get any value from it.

    Before the Government as a whole or departments start to implement or expand on new technology, the investment in communication, outreach and engagement needs to be made. We've been at the mercy of the Ronco "set it and forget" it approach for too long.

    My hats off to any department who has a division dedicated to internal engagement and outreach. I'd love to know if one exists!!

    Onward
    @mjmclean

    ReplyDelete
  2. Just like you can hammer in a nail with your shoe, the distinction as to how it is different to what a hammer accomplishes, may be lost lost on you.

    Same with a document on the Shared Drive and the added "Track Changes" function on MS Word. Though you may not see the distinction between this and wikis, I'm not jumping to a Word-version of Wikipedia anytime soon. But I see your point, and I think you're alluding to "Collaboration".

    Title and main theme, perhaps, should be "Why collaboration isn't new to Government".

    Then go into why without government wikis, it's painstakingly slow, lacking transparency.

    Just a suggestion.
    PS Thanks for fixing commenting.

    ReplyDelete
  3. Hey Doug, thanks for your comment. Actually, I meant what I wrote, just as I wrote it. As a BBS sysop since 1990 and a MediaWiki sysop since 2005, I think I have a better than average grasp of communication and collaboration, and I feel like I can speak with some authority about wiki as process as opposed to wiki as software. I could be more directly critical of the government and its current practices, rather than trying to address issues of discomfort with a process that isn't as foreign as feared, but I think that would be another example of improper use of a hammer.

    As for the comment fixing, we both owe thanks to Martha McLean for pointing out the symptoms that were making replying difficult (though not impossible). Thanks Martha, and thanks for your comment as well.

    ReplyDelete

Powered by Blogger.