Tag Archives: Groupware

What You Probably Don’t Know About Wikis


Several of my posts talk about uses of semantic wikis.  In fact, my company is largely based upon a semantic wiki platform, called Symcordia™.  But the more people I talk to, the more I realize that:

  1. While just about everyone has used Wikipedia as a reference source, few people have ever really thought about what a wiki is – what are its strengths and limitations?
  2. When people visit a Wikipedia article, they almost never look at the Talk page associated with that article, and have no idea of the value that may be hidden within the Talk pages, or why they exist.
  3. When people visit a Wikipedia article, they rarely look at the Page Ratings, or rate a page (you can rate Wikipedia pages based on the degree to which it is Trustworthy, Objective, Complete, Well-written.)
  4. Occasionally, I come across someone who says, “I don’t use Wikipedia – the content cannot be trusted!”  (These same people trust network television news!)

What is a Wiki?

Here’s a nice little video that describes the basics of a wiki:

Wikis – More Than Just Knowledge Capture!

If you look beyond the basic encyclopedia article in Wikipedia and examine a typical Talk Page, you will find it provides a place for people knowledgeable and passionate about a topic to debate that topic and how best to present it to readers.  Similarly, it provides a place for those with knowledge of Wikipedia’s standards and editorial policies to ensure an article meets quality and integrity standards.

If you look at the Page Ratings (not all pages have these – this is a fairly recent feature and is being expanded in functionality) you will find a place to rate a page based upon its trustworthiness, objectivity, completeness and clarity.  Perhaps, even more importantly, you can see how others have rated it.

Why Semantic Wikis?

Wikipedia is an encyclopedia – a compendium of articles.  As such, it deals with a single class of knowledge – the encyclopedia article.  For most organizations (for example, a business or an IT group) there will be dozens of different classes of knowledge to organize and represent.  For example, the diagram below is a simplified entity-relationship model for the knowledge inherent in a typical IT organization.  It comprises entities such as processes, services, metrics, roles, competencies, and so on, and shows the relationships among them.  So you know, for example, that if you are going to define a new process, you will need to define roles needed by that process, and if you are going to define roles, you need to define the competencies needed to fill a given role.

A semantic wiki lets you assign semantic properties to a page to reflect these different knowledge classes.  It also enables you to have page templates for each class of knowledge content.  This simplifies and encourages knowledge capture and use and ensures consistency within knowledge types.  This helps you to organize the content, and even to differentiate between two types of content:

  1. Content that must be of extremely high integrity (an operational process, say) and therefore the entire organization needs to understand its current state of development and its governance process. This type of content can and should be designed and made consistent in appearance to increase organizational clarity. The ER Model above represents this type content which tends to be at the ‘core’ of IT in most companies and encourages convergent thinking.
  2. Content that is more exploratory in nature (pages for a Community of Practice, say). This type of content doesn’t necessarily have a lot of pre-defined structure or governance in its development. It emerges over time as people brainstorm and collaborate. This type of content is typically at the ‘edge’ of an organization’s processes and encourages divergent thinking.

The graphic above (from Symcordia™, our semantic wiki platform) shows a typical example of the semantic properties of an IT Capability page.  The Property ‘Status’ can be changed, say, from Operational to Proposed to Under Discussion to reflect its current status.  This change can even be automatically controlled by workflow – the act of changing an Operational page, will change the semantic status of that page to Proposed, alert the appropriate page Owner and Governance Entity and move the page through its governance workflow until it reaches Production status.

We use the same screen real estate – the Property Box – to capture and show page ratings.  Again, the fact that each page can be of a different semantic class allows you to easily adjust the ratings questions based upon the page type.  (My post on how my rock band is using a semantic wiki to enable our learning and development illustrates this nicely.)

Is Microsoft’s SharePoint Really a Wiki?

SharePoint is often referred to by those in the know as a WINO – Wiki In Name Only.  For a rich discussion on this point, I’ll point you to an informative post by my business partner, Roy Youngman.  The other aspect of SharePoint in practice is that its strengths as a document management system tend to reinforce document-centric behaviors.  A common result, given that “old habits die hard” is that people tend to create and attach Word, PowerPoint and other document types, so the collaborative and “single version of the truth” characteristics of wikis are never realized.

Wikis Versus Document Management

To appreciate the limitations of documents as ways to share and grow knowledge, think about all the servers and disc drives filled with documents that never get shared – that quickly become out-of-date. To quote from another of Roy Youngman’s posts on Why Are Wiki’s in Corporate IT Rare:

The very notion of updating a document is perceived as painful and avoided at all costs by anyone with the expertise to actually make the changes… Every document was originally written to stand alone and few of them rely on one another to create clarity, so they contain many redundant passages; in fact, most of them contradict each other in one way or another and confuse the few people who do read them.”

Wikis mitigate the short-comings of document-orientation. Again, to quote Roy:

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. “

That means that Wikis enhance knowledge discovery and improvement, while documents tend to bury knowledge.

Have you experienced the power of a wiki?  Please take a moment to share your thoughts and experiences.

Graphic courtesy of The American

Related articles
Enhanced by Zemanta
About these ads

More Hurdles in the Shift from Documents to Wikis


Last week, I posted about The Painful But Rewarding Shift from Documents to Wikis.  In the post I shared some of the lessons my partner and I have learned from our experiences helping IT organizations shift to a Wiki approach for creating organizational clarity and getting people in the organization to engage in continuous improvement.  I will continue with this theme in this post.

When to Edit, When to Comment?

I guess this issue exists equally with Word documents – MS Word has its powerful Reviewing mode with its ability to add comments or to actually edit a document.  The same is true on a Wiki – you can comment on a page, or you can go in and edit the page.  The difference is, we have all been commenting on and editing Word documents for years!  But when you get to a Wiki, you typically don’t have the years of experience, nor do we have the shared but tacit understanding of when commenting makes sense compared with editing.  To the Wiki novice, not feeling sure about when to edit versus comment can freeze you into inaction!  You feel much more ‘exposed’ about making either comments or edits – but edits feel somehow more ‘in your face.’

We have found that a few supporting pages (themselves, a natural fit for a Wiki approach) can be very helpful in covering questions such as “edit or comment”.  Examples include:

  • Wiki Collaboration Guidelines and Procedures
  • Wiki Manual of Conduct
  • Wiki Manual of Style

Additionally, we have found that the gentle guiding hand of a Collaboration Manager and/or a Wiki Gardener can both demonstrate by example and, where appropriate, make adjustments to shift comments to in-line text edits or vice versa.  And, for those who can’t wait to find out the answer by trial and error, we’ve found the general principle is – if you are certain about the change you want to make, go ahead and make it!  The Wiki will let others with an interest in the page see the changes you have made, and they can always be backed out – nothing is ever lost!  If you are less certain, post a comment, quoting the text you want to change (most Wiki tools make that easy to do) and raising the points of discussion that lead you to be tentative about making the change.

Blank Pages Are Intimidating!

I’ve run experiments, creating a new page with an important page title (such as Potential Wiki Governance Principles) and asking folk to “weigh in.”  Perhaps not surprisingly, nobody does.  Add a few threads of text, or a contentious issue (that might be addressed by a principle or two) and people start to weigh in.  As I said, this is not surprising.  People are intimidated by blank pages.  Having said that, as a consultant who has facilitated hundreds of workshops, I know that starting with a “clean sheet” is rarely a good idea.  However, there are situations (and team dynamics) where a clean sheet is exactly the best place to start.  Which is why I ran the ‘blank page’ experiment.  At least one lesson learned would be: you can make things happen in a facilitated workshop that you can’t achieve on a Wiki!

Free, Open (and Risky?) Versus Controlled, Closed (and Safe?)

For whatever reason, my partner and I tend to find ourselves working on social media and collaboration initiatives with companies that have traditionally been somewhat “locked down” and conservative – often in highly regulated industries.  They have an inevitable (and understandable) bias towards controls and regulations – more concerned with “stopping bad things happening” than with “making good things happen!”  Unfortunately, this is not an ideal culture for open collaboration and knowledge exchange!  As much as they want to move to a more open and sharing culture, their natural instinct is to “govern and control.”

Given this, one of the issues we find ourselves coming back to as we navigate the changes inherent in becoming more open and collaborative is, ‘Do we manage the change from the current culture or from the culture we hope to change to?’  The temptation is to draw up a list of rules and create governance bodies and processes to manage the environment.  This is what people expect – but the question is, do such approaches serve to reinforce the current culture as opposed to fostering the desired culture?  Do rules and regulations send a message to people, that, “This is business as usual – be careful, think twice before you write or comment!”  And do such messages, unintended as they may be, tend to shut down otherwise valuable dialog and knowledge exchange?  Do they perpetuate the status quo?

We argue (and have demonstrated) that less rules and regulations are more effective in engaging stakeholders and fostering healthy dialog – without bringing the organization to its knees or being overrun with lawyers!  Of course, someone (the role is often called Wiki Gardener) has to monitor the site and take corrective action when needed.  They have to coach accidental transgressors.  Deliberate or malicious transgression is a performance management issue and must be handled as such – with firm and immediate action.

What have your experience been with Wikis in IT?  How have you handled “rules and regulations”?

 

Photo courtesy of Bionic Band: Home of Bionic Band Sports

Enhanced by Zemanta

The Painful But Rewarding Shift from Documents to Wikis


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

Enhanced by Zemanta

‘Social’ IT Management – Part 2


In Part 1 of this series on ‘Social’ IT Management, my esteemed colleague, Roy Youngman and I discussed the inherent complexity of the IT management function, and how a more ‘social’ and emergent approach can represent a better way to manage IT.  In Part 2, we will briefly discuss the types of things that could be in a ‘Social’ IT Management Platform and the advantages of a Wiki platform for enabling this social approach.  Please watch for the 3rd and final post in the series, where we will discuss some Principles we have found helpful in moving to a Social approach to IT management.

So, What Have We Learned from the Experiments?

We’ve learned that we can use tools like SharePoint, Confluence, and MediaWiki to organize the institutional knowledge of an IT environment, which not only improves organizational clarity, but also empowers IT resources to become greater masters of their fates.  Figure 1 below illustrates an example around process knowledge using an extension of the basic SIPOC technique.

Figure 1

The tool can capture information about IT processes, the roles people play in the performance of a process, the competencies these people need to be successful in those roles, a description of the deliverables a process produces, and much more.  The approach handles best-practices across the IT industry so any one IT department doesn’t have to reinvent-the-wheel.  And the whole thing serves as a collaboration hub that encourages community ownership and continuous improvement of practices, processes and so on.

A Wiki Core

At the core of the collaboration hub is Wiki technology.  We’ve also learned from our recent work that Wikis are rare in IT organizations, in large part because corporate organizations are heavily invested in “documents” as the means for developing, codifying, and sharing knowledge.  Paradoxically, we’ve discovered that this “document-centric” approach is both the main reason why Wikis are rare in the corporate IT world and why Wikis are great for the corporate IT world, so it is worth examining the differences.

From Document-Centric…

Figure 2

Figure 2 above shows how the document-centric approach works. Using MS Office products like Word, a team of people work on a subject (like documenting a process).  Everyone tends to work independently both in the authoring of their assignments or the review of material others have written.  Many versions of the document are created, stored in many places, and passed around in the process.  It is usually a difficult task to consolidate everyone’s input and more often than not, one person has to step forward and take on the bulk of the writing and editing.  When complete, there is little desire or motivation to change it for the better because creating it in the first place was so painful.  So it stagnates.  Eventually, other documents are written that contradict portions of the old document, confusing the few people who do know how to find them and take the time to read them.

…To Wiki-Centric

 

Figure 3

The Wiki approach shown in Figure 3 above is distinctively different.  Unlike a document, which is designed to be self-contained and read from beginning to end, a Wiki is nonlinear.  Using a design such as that described in Figure 1, the content can be well-factored, thereby minimizing redundancies and preventing contradictions that confuse people.  The nonlinear approach also allows people to focus and contribute to whatever area of expertise each person happens to have.  When multiple people have similar subject knowledge or interests, they find each other naturally in the process and synergy happens.

As a hub, the Wiki enhances the discovery of knowledge and exposes the subject matter in the greatest need of improvement.  The Wiki approach supports “divergent-thinking” (which is essential to allow anything to improve) through focused conversations and social measurement techniques. It also supports “convergent-thinking” (which is essential to ever arrive at clear conclusions) through the version control and workflow features inherent in Wiki technology.  The clear advantage of the Wiki is its ability to depict the best portrayal of knowledge currently available at any time while constantly encouraging a community to expand and improve it.

The contrast between Figures 2 and 3 is dramatic.  Corporate IT has a lot of investment in the document-centric approach.  But the return on that investment has been dismal and most IT people will testify to that.

So why then are Wiki’s still so rare in the Corporate IT world?  As is often the case when dealing with unfamiliar territory, “better the devil you know” is the typical rationale.  Ah, but this excuse is starting to fail in corporate IT departments.  Why? Because other departments throughout the business are discovering the benefits of Wikis and getting ahead of IT – the cat is out of the bag!  Many progressive CIOs have seen this trend and want to create an IT organization that enables Social Business rather than just reacts to it.  They want to better manage and leverage the knowledge trapped in their organizations and in tens of thousands of documents lost in personal and shared drives.

In spite of the inherent difficulties, we applaud such vision and have developed a set of principles we have found helpful in moving to a Social approach to IT management.  We will present next in the third and final post of this series.

Related articles
Enhanced by Zemanta