I posted recently on the question, Can Social Media Significantly Improve the Ways IT Work Is Performed? The post began to share some of the lessons learned as I continue to work with IT organizations that are pushing into the “social media” age and using tools such as Wikis and Social Networking to drive IT performance improvement.
Document Orientation – The Wikis Greatest Enemy!
My colleague and business partner Roy Youngman posted a while back on the question, “Why are Wikis in Corporate IT Rare?” In the post he posited that most corporations, especially IT departments, are entrenched in a document-oriented approach as the means for developing, codifying, and sharing knowledge. Roy made an important point that:
Paradoxically, ‘document-orientation’ is both the main reason why Wikis are rare in the corporate world and the main reason why Wikis are great for the corporate world.”
Wiki Benefits – A Solution to the Shackles of Document-Centricity!
Roy went on to explain that:
The Wiki approach addresses almost all the short-comings of ‘document-orientation’. The nonlinear nature of a Wiki enables well-factored content, thereby minimizing redundancies and preventing contradictions that confuse people. It also allows people to contribute to whatever area of expertise each person happens to have so everyone is drawn in, not just the elite few. A Wiki approach enhances the discovery of knowledge and exposes the subject matter in the greatest need of improvement. And the improvement is a constant theme – the very heart and soul of a Wiki.”
From Document to Wiki – Changing Mindsets One Page at a Time!
I’ve been using document-centric tools such as Word and PowerPoint since they first became available in the late 1970’s. Beyond the simple accessing of Wikipedia, I’ve been actively using Wikis such a MediaWiki and Confluence since 2005. So I have significant experience both in the traditional world of documents, and the more contemporary world of Wikis. And I can tell you, the shift from document-centricity to Wikis is non-trivial! I can also tell, it is HUGELY BENEFICIAL!
Here’s a sampling of the mental hurdles I’ve had to navigate in order to realize the full benefits of a Wiki approach.
When to “Polish” Versus When to “Collaboratively Evolve”?
Historically, when I’ve been creating some kind of deliverable (a Word document Project Charter, or a client project briefing PowerPoint deck for example) I’ve always felt that it has to be polished to a high degree. Many years ago, a wise and seasoned consultant and mentor advised me to always produce quality documents – both in terms of content and look and feel. He said, “If it looks shabby and full of typos, how can you expect the client to take it seriously?” The latter point is not necessarily obvious based on the deliverables I see from many consultants. As an example, I saw a key deliverable produced by a large consulting firm that was full of typos, grammatical and formatting errors. The final insult was that a PowerPoint slide misspelled the CIO’s name – in a key presentation that was given to the CIO!
By contrast, when I start to create a Wiki page, I feel almost obliged (and grateful!) to start with a much rougher “draft” and look forward to the ensuing “collaborative polishing” that will emerge. Sounds obvious, but getting comfortable with a “rough draft” as a starting point did not come easily to me until I began to notice that people were less inclined to collaborate on a document if it looked highly polished and “print ready”. Learning when to “polish” and when to release “draft” material is not always obvious and is very situationally dependent – demanding a keen sensitivity to the specific context for the document.
Structure, Linking, Tagging and Factoring in a Wiki World
I’ve always paid attention to document structure. I believe I understand the basic principles of good structure, and learned a lot about logical structure from the powerful Minto Pyramid Principle back in the late 1980’s. But when you get to a Wiki, things change! The ability to hot-link across “documents” and to external sources in ways that just don’t work in a document-based world (who knows where any given document will be located?) changes the way you think about structure.
Tagging and Folksonomies create another layer of possibilities (and another layer to think about!) that is rarely used effectively in a traditional document environment. The concept of factoring, well understood (if not always followed!) by programmers, involves structuring content for maximum reusability, minimum redundancy, and ease of search. These are typically not considerations in a traditional document approach.
One of the many benefits of a Wiki is that it enables an entire collection of ideas and information to be placed into a single, hyper-linked space. But if that space is a messy structure, the benefits may quickly erode. If you aren’t a programmer (or, at least, not a good programmer!) you may need access to a Wiki expert for help in thinking through the structuring of a given space – especially if you are using a Wiki that allows for a hierarchical structure among pages.
Does eMail Traffic Really Reduce?
A client I was working with recently was (appropriately!) paranoid about anything that drove up eMail traffic. When they learned that the Wiki could send eMail notifications about changes, they were immediately hesitant to utilize this feature. While it’s natural to want to find ways to reduce eMail traffic, we’ve found that there’s an important distinction between “normal” eMails, that come from people and automatic notifications. The former typically demands time and activity – responding to the email. The latter is purely and helpfully informational. Also, if you aren’t finding the information helpful, then turn off the automatic alerts!
The great news for this client, in addition to discovering that automatic informational eMails in the form of Wiki alerts were far less intrusive and demanding than real eMails from people, was that the transition to a Wiki approach dramatically reduced the person-to-person eMail traffic, as the endless cycle of passing documents around was replaced by collaborative editing of a Wiki.
I’ll look at more of these “mindset changes” associated with the shift to Wikis in upcoming posts.
Image courtesy of Westwood K-8 Technology