Work and the Wonky Wiki
Thanks to my experience and the readings this week, I now understand how wikis came into being (Leuf & Cunningham, 2001(?), p 14-15), I have examples of good uses of the wiki format and examples of inappropriate projects for wikis (Barton, “Embrace the Wiki Way!”), and I have grandiose ideals for how I can implement and use wiki and web 2.0 applications in my workplace - if I could get around IT. And, I have a reference for how to organize tasks and manage conflict on collaborative teams (Brown et al, 2007, p 126-135) although this last reading seemed out of place given the other strictly wiki related readings. Still, I copied the list from page 135 to use as a cubicle decoration (a.k.a. subtle hint).
I love my job. I work for a medical device company that thrives thanks to network security. On top of that, approximately 90% of communication at this company happens via email. That statistic alone says we need to look into better ways of communicating. I wonder what percentage of emails sent contain fewer than 140 characters if you exclude the corporate signatures…
As I was reading about the origins of the Geek Squad in “Wikinomics”, I imagined what it would be like to have access to games at work, or access to Facebook for that matter (Tapscott and Williams, 2006(?), p 241-245). But if the company cannot monitor how you use something, they just block access to it in the name of corporate integrity. Interestingly enough, we do have some collaborative tools to use that are company sanctioned. We have a document management system where you can check documents out, make changes, and then resubmit them for approval. This works great for electronic approvals and revision control. What is most interesting is that this system has a feature where you can “submit” items for collaboration, which allows a selected group of coworkers to go into the system, view, check out, and modify a single document. This is a great feature and it is actually very wiki-like in design if not a bit one-dimensional for a web application.
There are a few issues with the system that would be solved by using a wiki. First, documents are often checked out from the system and collaborators forget to check them back in, so the project can be delayed as the document sits buried in someone’s temporary files. Second, a fair number of people don’t know how this option works so they don’t use it. Third, you are limited to the editing and commenting capabilities of the software you use to author the file. For example, MS Word’s track changes will show who added or deleted what, but if you author an entire document that way it gets really messy. The system has a change history that can be completed each time the document is checked in, but it is optional and it relies on the author to detail every change made in that revision.
That said, I can see so many areas where wikis could be used to foster collaboration on documents and projects, particularly in the medical device industry. I think the stigma that Kaitlin S. cited from Leuf and Cunningham regarding how wikis are unstructured and too open and makes implementation in a highly regulated industry difficult, but not impossible (p 33). I think eventually the right people will see how beneficial this technology can be to the industry and the rest will be history. I just hope I am still around to say, “I told you so”.