Tag Archives: Wiki

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

Accelerating Individual and Organizational Learning – Case Study from a Rock Band: Part 2 of 2


This is Part 2 in a 2-Part post – please see Part 1.

Quick Recap

This post explores how a semantic wiki can support self-organizing teams, using a rock and roll band as a case study.  We developed a semantic wiki using the Symcordia™ platform to enable the band’s development and learning – both collectively (organizational learning) and for band members (individual learning).

Necessity is the Mother of Invention.

The band began as a vehicle to cover classic rock songs.  Over the first week or so, we found ourselves drowning in endless email chains, with lists of songs to cover, suggestions for band names, and so on.  I’ve always found emails to be both inefficient and frustrating as an approach to coordinating and sharing knowledge across a work group.  We were finding it tough to keep track of all the suggestions and maintain a “single source of the truth” to guide our practice and development.  We believed there was a better way, so we quickly (initially about 3 hours work) built a band wiki using my company’s Symcordia™ platform.

A band has several characteristics that make a wiki a great enabler:

  1. Playing in a band is a highly collaborative endeavor.  Wikis are inherently collaboration tools.
  2. Playing in a band demands shared knowledge:  What are we going to play?  Which key should we play it in?  Who will take which parts (e.g., lead vocal, harmony vocal)?  Wikis are a fabulous way of capturing and sharing knowledge.
  3. A band must develop and grow – or it dies on the vine.  Wikis are wonderful enablers of individual and collective growth and learning – they can put at your fingertips all that you need in terms of knowledge and tools to develop and grow – things like musical scores, YouTube tutorials, song lyrics.
  4. For a developing band, history and shared experience is crucial to learning: What did we try and why?  What worked well – and not so well?  A wiki is an ideal vehicle for capturing history and creating shared learning.
  5. A band depends on all sorts of creative decisions:  What’s the best sequence of songs for a given context?  Which settings worked best for amplifiers, mixing boards and effects pedals?  A wiki is a great way of enabling and capturing those decisions and the logic and collective wisdom behind them – one place to keep a ‘single version of the truth.’

Initial Design and Features

Given these characteristics, we came up with our initial design.  Here’s a screen shot of the wiki sidebar – a primary navigation mechanism.  Note, we’ve not yet tried to make the site “pretty” – we will eventually create a public face into selected portions of the band wiki, and use a more fancy style sheet for that:

There’s an inevitable section about the band – each member has a page where they can post personal details, photos, videos, etc.  We’ve also worked up some “principles” or “simple rules” about how we want the band to work (e.g., We encourage band members to move from instrument to instrument.)  Having these on the wiki allows us all to collaborate on developing the principles and bringing them to life.  We struggled with naming the band, so we created a space for us to develop naming ideas, comment, vote and converge on a final name.

The most important space, in terms of developing as a band, is the Band Repertoire.  As you’ll see above, there are sections for:

  • Performance Ready Songs – songs we feel are ready for performance to an audience.
  • Songs In Development – songs that we are working on with a view to readying them for performance, at which time they get promoted to Performance Ready pages.
  • Prospective Songs – songs that we’d like to perform and within our talent and limitations, e.g., if it needs a flute, we probably can’t do it (sorry, Jethro Tull!)
  • Song Ideas – suggestions about songs we’d like to try at some time.

Typical Song Page

Here’s a partial screen shot of a typical song page:

Key here is:

  • The version of the song (some songs have multiple versions by different performers – for example the Guns ‘N Roses version of Knockin’ on Heaven’s Door is quite different from the Bob Dylan original).
  • A YouTube of the song by the performer we are trying to emulate, so we’re all aiming for a common performance outcome, or at least, a starting point to develop from.
  • Links to the tablature (music) for guitar, bass, drums, keyboards and any other learning aids.
  • The key we will play it in.  (Four band members playing a song in different keys does not sound so good!)
  • Performance Notes – clues about how to perform a song, and observations on how we are doing so far.
  • Song lyrics – lead vocals and harmony vocals singing different versions of the lyrics can really spoil a performance!

Semantic Properties

Each song page has a Semantic Properties box:

In order to protect my band mates privacy, I’ve ‘faked’ the assignment of parts to be all me!  But each part (vocal and instrument) can be assigned to different band members, and we can try different assignments at our practice sessions to see what works best (and capture this in our Performance Notes).

We can also vote on different aspects of the song.  The things on which to vote change depending upon context – e.g., whether it’s Performance Ready, Song In Development, Prospective or Song Idea.  For Performance Ready songs, a question is, “How well do we perform this song?”  For a Song In Development, it is, “Are we getting better with this song?  Are we ready to perform this song?”  And for a Prospective Song it’s, “Do we want to work on this song?”

Because these are Semantic Properties, we have pages that dynamically generate reports, such as:

  • Which parts I am playing what roles on?
  • Which songs do we most want to work on?
  • Which songs are improving the most quickly – or slowly?

Capturing Performances

We capture MP3 recordings and video clips of our performances and embed these in the song pages, track and rate how our performances are evolving over time – creating an historical record of growth and learning.

How Is It Working Out?

I’m going to save my richer response to this till we have a little more experience under our belts, but there are some early insights that I’ve seen many times before with my business consulting clients as they try to leverage collaborative tools like this:

  1. Email habits die hard!  For all the frustration with email overload, and the inefficiencies and inadequacies of email for collaboration, band members’ first instincts are to send an email, which begets a natural reply response.  Good thoughts are lost to the ether and invisible to the wiki!
  2. It’s tough making time to learn – even though the learning curve for a wiki is trivial.  The late Dr. Stephen Covey talked about the man struggling in the woods to saw down a tree.  An old farmer came by and observed, “That saw looks pretty dull.  Why don’t you sharpen it?”  The man replied, “I don’t have time to sharpen the saw – I’m too busy sawing!”
  3. I know from my business client experience with wikis that they gain the most traction when their use is ‘in the natural flow’ of daily work habits.  For our band members, they tend not to sit at desks with a computer screen and a browser.  They are busy executives moving from meeting to meeting and town to town.  Their dominant means of communicating beyond their meeting context is via Blackberries – phone calls and emails – so the band wiki is not ‘in the flow.’  This will change when we release a version of Symcordia optimized for smart phones and tablets.

Lessons Learned from a Reader

I’ll close this post by pulling a comment from the Part 1 post.  The comment came from Glenn Remoreras, one of my favorite bloggers (See Simple Processes.)

Based on my experience of championing the use of wiki with my team, it was a bit of a crawl, walk run process– and we are still crawling after a month. Here are our lessons learned:

  • Adoption champion is critical to success of the process. (I took this challenge myself as the manager of my area). As champion I generated initial contents and encourages to channel collaboration through the tool by suggested practices.
  • Different team members will have a different level and pace of adoption. That’s normal and acceptable. I did not force my team to use the tool, I slowly introduce it in our meetings and reporting.
  • Leader’s example is important. The leader spearheads the different ways to use the tool by doing it himself/herself. Later on the team will realize the benefits by experiencing how it changes the way they work.
  • Crawl walk run approach is necessary to not force the team adoption. Team members will adopt when they realize that it actually facilitates better flow of information and better team collaboration. Don’t rush it!
  • Subsequent and consistent use of the information in the community (wikis, blog, forum, file sharing) for information purpose to outside entities strengthens importance and drives team members to adopt.

My team is getting there collectively. Now we are managing some of our project status reporting, meetings, team locator, activity-task assignment, forum, and file sharing through the team community we have established.

Disclosure

My company is centered around a semantic wiki platform – currently optimized for IT groups (see Symcordia.com for more) so I do have a few axes to grind.  But I’m also a true believer in wikis as an enabler of collaboration and performance improvement. This is based upon my experience as a consultant and our client’s experiences using Symcordia™, our semantic wiki platform.  The platform is built on the underlying Confluence wiki engine, with a variety of plug-ins that add semantic properties, sortable tables, page ratings and so on.

Image “Classic Rock” by C.F. Payne courtesy of Reader’s Digest

Related articles
Enhanced by Zemanta

Accelerating Individual and Organizational Learning – Case Study from a Rock Band: Part 1 of 2


My regular readers know that I post from time to time about how wikis can enable organization performance and increase organizational clarity.  (For example see here, here and here.)

In the interests of full disclosure, my company is centered around a semantic wiki platform (currently optimized for IT groups – see Symcordia.com for more) so I do have a few axes to grind.  But I’m also a true believer in wikis as an enabler of collaboration and performance improvement. This is based upon my experience as a consultant and our client’s experiences using  semantic wikis.  Symcordia™ is built on an underlying Confluence wiki engine, with a variety of plug-ins that add semantic properties, sortable tables, page ratings and so on.

From IT Leadership to a Rock and Roll Band!

I’ve also posted before on lessons from the performing arts – see here.  Now, I’m adding to my business and consulting experience through my ‘non-day job’ as a member of a rock and roll band.  We are using Symcordia to enable our development and learning – both for the band (organizational learning) and its members (individual learning).

The Importance of Passion as an Ingredient for Collaboration

I was excited to get into this as it combined two of my greatest passions – wiki-enablement of growth and learning, and playing rock and roll!  In the words of the band Cheap Trick – this feels like Heaven Tonight!  (My business partner, Roy Youngman, created an excellent post on the importance of passion to collaboration.)

As you read this, think about interest groups you might be part of at work – a special project team, a six sigma team or whatever.  How could you use a wiki to enable development and learning to increase their effectiveness and ignite some passion for their work?

Here’s the Back Story

Necessity, as they say, is the mother of invention.  We started the band – a conglomeration of 4 very passionate musicians – as a vehicle to cover classic rock songs.  Over the first week or so, we found ourselves trading emails, mostly with lists of songs to cover, styles and genres to try, suggestions for band names, and potential dates to meet for practice sessions.

Having spent several years of my career successfully using wikis as a way to escape from endless email streams and knowledge lost in Windows folders, I found this both inefficient and frustrating.  I tried to keep track of all the suggestions, consolidate them and publish them as “the list” of stuff we’d work on, but it was all but impossible to do.  The list kept changing – both in content and purpose (some of the song ideas were aspirational, some were deadly serious, some were deliberately frivolous).

I had this nightmare vision of us turning up for our first practice, with no collective idea of what we were working on – we’d each prepared a different set of parts for a different set of songs!  Each band member is more or less multi-instrumental, but when 4 band members have each prepared the same lead guitar part, and nobody has worked up the bass part, keyboard part, etc., there’s a train wreck in the making!

I believed there was a better way, so I quickly (initially about 3 hours work) built a band wiki using my company’s Symcordia™ platform and got the band members onto it.

Why a Wiki for a Band?

A band has several characteristics that make a wiki a great enabler:

  1. Playing in a band is a highly collaborative endeavor.  Wikis are inherently collaboration tools.
  2. Playing in a band demands shared knowledge:  What are we going to play?  Which key should we play it in?  Who will take which parts (e.g., lead vocal, harmony vocal)?  Wikis are a fabulous way of capturing and sharing knowledge.
  3. A band must develop and grow – or it dies on the vine.  Wikis are wonderful enablers of individual and collective growth and learning – they can put at your fingertips all that you need in terms of knowledge and tools to develop and grow – things like musical scores, YouTube tutorials, song lyrics.
  4. For a developing band, history and shared experience is crucial to learning: What did we try and why?  What worked well – and not so well?  A wiki is an ideal vehicle for capturing history and creating shared learning.
  5. A band depends on all sorts of creative decisions:  What’s the best sequence of songs for a given context?  Which settings worked best for amplifiers, mixing boards and effects pedals?  A wiki is a great way of enabling and capturing those decisions and the logic behind them – one place to keep a ‘single version of the truth.’

Please join me for Part 2 of this post in the next week or so – I’ll cover the basic design for the wiki, screen shots of how we are using it – especially, how we are leveraging the semantic properties, and our early experiences.

Graphic courtesy of Cox Mpoperi Wilson Education Consultants

Related articles
Enhanced by Zemanta

The Semantic Wiki – Driving IT Organizational Clarity and Performance: Part 3


Example of Semantic Structure for an IT Operating Model

This is the 3rd and final part of a 3-part post.  (See Part 1 here and Part 2 here.)  This short series represents the culmination of 5+ years of work for my business partner, Roy Youngman, and me.

A Quick Recap

In Part 1, I discussed the frustration Roy and I felt with the state of management consulting, where the artifacts we’d leave behind (PowerPoint slides, Word documents, etc.) rarely became part of our client’s organizational fabric.  Also, the middle managers and the ‘troops’ who had to bring to life the strategies and operating models we were developing often did not get exposure to the work until relatively late in the day.  Because they had not been part of the work, they were slow to understand and embrace it.

I explained that we quickly recognized that the technologies and sensibilities of Web 2.0 and social media promised a better way to help our clients – a way that would engage broader and deeper participation by client staff at all levels, and would leave behind a ‘living, breathing’ IT strategy and/or IT operating model, captured as a set of wiki pages.  These pages were developed collaboratively with our clients, so the act of development and deployment essentially became concurrent – defining the IT operating model was part of deploying it, and vice versa.  We determined that a Semantic Wiki would be an ideal technology to support our consulting work – and more importantly, to provide a platform we could leave behind with our clients to empower their organizational collaboration and ongoing refinement and use of the IT strategy and operating model.

In Part 2, I went on to provide historical context for the wikis first introduction in 1995, and enumerated its strengths and weakness that were limiting IT organizations ability to collaborate effectively using traditional wikis. I went on to explain the concepts behind the Semantic Wiki and how these provided an ideal platform for enabling complex organizations such as IT, where multiple, different value propositions have to be supported.

Balancing Order and Chaos

IT organizations are surprisingly complex, supporting two fundamentally different value propositions:

  • Core capabilities comprising the critical processes, assets and structures that help run the day-to-day business
  • Edge capabilities where innovation, growth and change are cultivated

These distinct value propositions have Operating Model implications, requiring distinct forms of semantic wiki-enablement, as highlighted in Table 1 below.

Value Proposition

Example Capabilities

Needed Wiki Characteristics

Wiki Governance Model
Core
  • Operations
  • Service Management
  • Enterprise Solutions
  • Coherent integrated structure
  • Stable space
  • High integrity
  • Globally governed
  • Workflow controlled
  • Process Owner as key control point
Edge
  • Enterprise Architecture
  • Product Management
  • Departmental Solutions
  • Project & Team Spaces
  • Business Relationship Management
  • Idea Generation
  • Consistent modular structure
  • Agile
  • Support divergent discussion & brainstorming
  • Content can migrate to Globally governed
  • Domain governed
  • Workflow optional
  • Domain Owner as key control point

Table 1 – Types of Wiki Space

Globally Governed Space for ‘Core’ Capabilities

Core capabilities such as data center operations, service management and enterprise solutions (e.g., ERP systems) depend upon processes that are standardized, tightly controlled and centrally planned.  Management systems for these types of capability must focus on integrated, reliable, efficient processes and compliance to norms.

A wiki that supports core capabilities must be highly ordered and globally governed.  For example, each process should have a ‘Process Owner,’ with clearly defined accountabilities for maintaining and continuously improving their processes.  They need defined workflow mechanisms, for example, to control the promotion of a material change to a process page from ‘draft’ to ‘pending approval’ to ‘approved’ to ‘operational.’

Domain Governed Space for ‘Edge’ Capabilities

Edge capabilities, on the other hand, depend upon structures that are loosely knit, with agile processes that can rapidly adjust to entrepreneurial initiatives and fast-shifting technologies.   Management systems and organizational culture must foster new product success and the experimentation needed to get there.  Whereas core capabilities epitomize highly ordered environments, the edge represents the place where chaos and order meet and creativity blossoms.

A wiki that facilitates edge capabilities works best with limited structure and control, where, to paraphrase China’s Chairman Mao Zedong, “one thousand flowers bloom”.  Here the underlying semantic model will be centered on problem areas and the process of ideation, with Business Relationship Managers, Product Managers and Architects as the natural choice for the wiki’s points of control.

Today’s wiki platforms are helpful here, but we expect them to evolve to better support techniques such as brainstorming, innovation jams, mind mapping, and provide integration with tools for simulation and modeling, prediction markets, sentiment analysis and ‘light weight’ collaborative project management.

One Space – Two Wiki Models

IT organizational needs can be comfortably addressed in a single Semantic Wiki, with each value proposition having its own underlying semantic model and associated governance structure.   Having both ‘core’ and ‘edge’ capabilities supported in the same wiki space affords important benefits.  For example, everything is discoverable and linkable across the models.  These characteristics are all but impossible to achieve in a traditional document-centric collaboration approach.

If the primary goal of the core is to ‘prevent bad change’, a tightly structured semantic wiki with a robust governance model is a powerful way to support this goal and the organizations that must deliver against it.  If the primary goal of the edge is to ‘create good change’, a loosely governed semantic wiki with ‘sandboxes’ to generate and test ideas is a great way to support this goal.  Today’s leading wiki platforms, with their semantic extensions offer a single, integrated solution that can help drive IT organizational clarity and improve performance.

An Empowered, Continuously Improving IT Organization

Roy and I have found that encapsulating IT strategies and operating models in a semantic wiki has tremendous benefits that are simply not available in the more traditional approach some call, “death by PowerPoint!”  For example:

  • A far broader group (and ultimately, the entire IT organization and their clients and partners) can be engaged in the process of strategy and IT operating model development and deployment.
  • All the artifacts of strategy and IT operating models (strategy on a a page, key themes, business outcomes, major programs, metrics, processes, and so on) are immediately available to the organization and its stakeholders – this enables continuous improvement and evolution.
  • Significant productivity increases result from having these artifacts available as shared wiki pages.  While the term “knowledge management” (KM) has fallen out of favor, the goals of KM continue to be highly relevant, and the end result of building a semantic wiki for the IT organization creates a very robust and powerful KM platform.
  • A semantic wiki dramatically decreases email traffic and, more importantly, decreases the time taken to find information and increases the confidence that the information found is the ‘single source of truth’
  • Adoption and organizational change management issues can be largely addressed by ensuring that use of the wiki is “in the natural flow of work.”  I will did further into this important concept in a future post!
Related articles
Enhanced by Zemanta

The Semantic Wiki – Driving IT Organizational Clarity and Performance: Part 2


This is the 2nd in a 3-part post representing the culmination of 5+ years of work for my business partner, Roy Youngman and me.

A Quick Recap

Roy and I had become frustrated with the state of management consulting and the lack of “stickiness” with our consulting work.  In helping clients develop business-IT strategies and realign their IT operating models, the deliverables we would leave behind as the artifacts of the work (usually PowerPoint slides, Word documents, etc.) rarely became part of the client’s organizational fabric.  Another source of frustration was that we’d typically arrive at those deliverables through a series of workshops – usually with the CIO and IT leadership team.  Middle managers and the ‘troops’ who had to bring those strategies and operating models to life often did not get exposure to the work until relatively late in the day.  Because they had not been part of the work, they were slow to understand and embrace it.

As Web 2.0 and social media began to take hold, we started to see and experiment with better ways to help our clients – engaging broader and deeper participation by client staff, and leaving behind a ‘living, breathing’ IT strategy and/or IT operating model, captured as a set of wiki pages developed collaboratively with our clients.  As such, the act of development and deployment became more concurrent.  Defining the IT operating model was part of deploying it, and vice versa.

However, we’d found that IT organizational attempts to improve collaboration and support knowledge management typically met with limited success, and that collaboration tools and platforms deployed by IT were falling short.  While the power and simplicity of wikis were appealing, their ‘one size fits all’ approach was not well suited to supporting an IT operating model.  We closed Part 1 by summarizing the strengths of a wiki, and suggesting that these strengths also create vulnerabilities.

The Proverbial Double-Edged Sword!

A wikis strengths also create vulnerabilities.  For example, the ease with which users can create and edit pages can quickly lead to a chaotic free-for-all, as content becomes subject to the whims of authors and editors, and absent a meaningful underlying structure, pages proliferate.  The lack of review before modifications are accepted can limit the credibility of a given wiki page as a ‘source of truth.’  A process definition, for example, may have been last edited by someone that introduced a serious error – and that error can proliferate as people refer to and use the process with the assumption that the content on the page is valid.

Sites such as Wikipedia mitigate these vulnerabilities through a robust system of editorial administration, oversight and management – enhanced by the ‘law of large numbers.’  In this case, with a sufficiently large universe of editors, the content of any page quickly converges towards a mean, reflecting “the wisdom of the crowd”.  But with an internal wiki – say one used by an IT organization or other shared services function, the law of large numbers does not apply, so without other mechanisms to manage structure and content, the wiki degrades in quality and value over time.

SharePoint as a Common Culprit!

This degradation is commonplace in organizations using Microsoft SharePoint as their collaboration platform.  While typically deployed to support collaboration, the reality quickly scales back to “a place to store documents”, which, in the words of one of my clients, soon degenerates to, “a place to lose documents!”

The other problem with SharePoint is that its strength is also its weakness.  While it is a good document management system, documents in of themselves are rarely the proper end goal of collaboration.  Collaboration is largely about having multiple authors create, evolve and use content, and documents are a poor medium for developing, codifying, and sharing knowledge.  Wikis provide a far more valuable alternative approach.  As my colleague Roy Youngman noted in his blog:

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

Semantic Wikis to the Rescue!

But all is not lost, as the world of Web 2.0 gives way to Web 3.0, tapping into the special properties of the Semantic Web, a term first coined by Tim Berners-Lee.  Tim was the inventor of the World Wide Web and is director of the World Wide Web Consortium (W3C), which oversees the development of proposed Semantic Web standards.

Berners-Lee defines the Semantic Web as, “a web of data that can be processed directly and indirectly by machines.”  A Semantic Web goes beyond the traditional web concept of hyperlinked, human-readable web pages by inserting machine-readable metadata about pages and how they are related to each other.  This enables automated agents to access the Web more intelligently and perform tasks on behalf of users.  As the W3C describes it:

In addition to the classic ‘Web of documents,’ W3C is helping to build a technology stack to support a ‘Web of data,’ the sort of data you find in databases. The ultimate goal of the Web of data is to enable computers to do more useful work and to develop systems that can support trusted interactions over the network.”

In some respects, the Semantic Web is designed to overcome the all too familiar limitations of today’s Web – a proliferation of untrustworthy content that can be hard to navigate and make sense of.  Building on the Semantic Web concept and standards, a Semantic Wiki has an underlying model of the knowledge described in its pages, thereby capturing the meaning of the data within the wiki.

While traditional wikis have structured text and hyperlinks, a Semantic Wiki captures and identifies information about the data within its pages, and the relationships between pages, in ways that can be queried or exported like a database.  While conventional wikis provide users a simple means of expressing data and metadata, typically through tagging, Semantic Wikis include additional ways to express semantic declarations.  They are therefore able to understand and display the relationships between pages or other data.   For example, you can declare the underlying semantic properties of an IT Operating Model, such as:

  • Processes require people taking on specific roles
  • Roles point to specific competencies people must have to fill them
  • Competencies comprise specific Knowledge, Skills and Behaviors
  • Metrics define process performance

Having these semantic properties explicitly defined enables wiki governance rules and workflows – for example, someone defining a new process will be prompted to define the associated competencies needed for that process, and an appropriate template can be automatically loaded for defining those competencies, thereby encouraging consistency and quality.  A simple query can highlight roles that are missing, or identify associates who are qualified to fill a given role.

The graphic below shows a partial example of the underlying semantic structure for an IT Operating Model.

Example Semantic Structure for an IT Operating Model

Several wiki platforms offer semantic extensions, including Semantic MediaWiki (which extends MediaWiki, the underlying open source platform that powers Wikipedia) and zAgile’s Wikidsmart extension to Atlassian’s popular and powerful Confluence platform.

In combination with other plug-ins and extensions, such as Page Rating, Social Reputation, Workflow and Task Management, a Semantic Wiki can enable real and meaningful collaboration for IT organizations (or any other environment where collaboration can improve service quality, speed of delivery and organizational clarity.)

I will pick up in the 3rd and final part of this series by discussing the two primary value propositions for an IT organization and how a semantic wiki can provide a single integrated space for enabling these differentiated needs.

Enhanced by Zemanta

The Semantic Wiki – Driving IT Organizational Clarity and Performance


This will be Part 1 of a 3-part post.  This short series represents the culmination of 5+ years of work (on top of a 40 year career in IT!) for me and my business partner, Roy Youngman.  The series of posts also marks the formal announcement of The Merlyn Group, LLC, a business venture we actually started one year ago, but have been ‘flying below the radar’ while we worked with our initial clients and technology.

A Little Historical Context

Roy and I started working together at Ernst & Young back in the early 1990′s.  About 5 years ago, we both became very frustrated with the state of management consulting.  The main problem we saw was a lack of “stickiness” with our consulting work.

Most of our consulting work was either helping clients develop business-IT strategies, or helping them realign their IT operating models (processes, services, governance, organization, metrics, and so on), often in support of new Business-IT strategies.  Our deliverables typically comprised PowerPoint slides, Word documents and Excel spreadsheets.  While these all played an important part of informing and aligning our client teams, the artifacts we’d leave behind rarely became part of their organizational fabric.

This was exacerbated by the fact that we’d typically arrive at those deliverables through a series of workshops – usually with the CIO and IT leadership team.  Middle managers and the ‘troops’ who had to bring those strategies and operating models to life often did not get exposure to the work until relatively late in the day.  Because they had not been part of the work, they were slow to understand and embrace it.

A smaller, but no less important concern was the travel involved in all of this.  Post 9-11, travel costs typically added 20% to the cost of an engagement – good for the airlines and hotels, perhaps, but not good for the client and certainly not good for us.  Time lost commuting and the wear and tear on mind and body took their toll.

Enter “Consulting 2.0″…

As the technologies and sensibilities of Web 2.0 and social media began to take hold, Roy and I started to see a better way to help our clients – a way that would engage broader and deeper participation by client staff at all levels, and that would leave behind a ‘living, breathing’ IT strategy and/or IT operating model, captured as a set of wiki pages.  These pages were developed collaboratively with our clients, so the act of development and deployment essentially became concurrent.  Defining the IT operating model was part of deploying it, and vice versa.

This 3-part series of posts will explain how we did this, and highlight some of our key learnings along the way.

The Unmet Promise of Collaboration

We had observed that IT organizational attempts to improve collaboration, enable knowledge management and drive organizational clarity typically met with limited success.  In our research and consulting work, we’d found that limitations with collaboration tools and platforms deployed by IT were a key factor in these disappointing results and that a ‘one size fits all’ approach was all but doomed to failure.  Some aspects of IT require a highly structured and tightly governed approach to enabling collaboration – process management and continuous process improvement, for example.  Other aspects, such as enterprise architecture and business-IT relationship management work best with a looser and more emergent approach.

The Art and Science of Collaboration

The great news was that a new type of tool was emerging – the Semantic Wiki.  We recognized that a semantic wiki would easily accommodate the complexities inherent in IT Operating Models.  But first, let’s review how wikis came about – and how their strengths can create serious limitations for use in an IT organization.

1995 – The Wiki Is Born!

Wikis have been at the heart of collaboration since Ward Cunningham created the first Wiki, known as WikiWikiWeb in 1995.  Ward and co-author Bo Leuf, in their book The Wiki Way: Quick Collaboration on the Web, described the essence of the wiki concept as follows:

  • A wiki invites all users to edit any page or to create new pages within the wiki Web site, using only a plain-vanilla Web browser without any extra add-ons.
  • A wiki promotes meaningful topic associations between different pages by making page link creation almost intuitively easy and showing whether an intended target page exists or not.
  • A wiki is not a carefully crafted site for casual visitors. Instead, it seeks to involve the visitor in an ongoing process of creation and collaboration that constantly changes the Web site landscape.

According to Wikipedia, the world’s best-known and largest wiki:

A wiki enables communities to write documents collaboratively, using a simple markup language and a web browser.  A wiki is essentially a database for creating, browsing, and searching through information. A wiki allows for non-linear, evolving, complex and networked text, argument and interaction.  A defining characteristic of wiki technology is the ease with which pages can be created and updated. Generally, there is no review before modifications are accepted.”

The Wikis Strengths

The keys to a wiki are:

  1. The ease with which people can collaboratively create, access and edit documents.
  2. The fact that those documents can be hyperlinked to create complex and networked text that allows the reader to navigate both linearly (as with traditional text) and non-linearly (jumping from idea to idea).
  3. The ease with which documents can be searched – with the knowledge that you are always looking at the current and only version of the page.
  4. As an inherently web-based concept, wikis benefit from evolving Web standards and technologies such as browsers, mark-up languages and even the magical world of open source – enabling Wiki users and developers to participate easily in a rapidly growing ecosystem of plug-ins.

The Proverbial Double-Edged Sword!

But these strengths also create vulnerabilities. Join me for Part 2 of this series, where will will look at the weaknesses of a wiki as an enabler of IT collaboration, and how a semantic wiki overcomes those limitations.

Graphic courtesy of Semantic Wikipedia

Related articles
Enhanced by Zemanta

Changing the Culture of an IT Organization – One Wiki Page at a Time!


I’ve been a student of IT organizational culture since I began my management consulting career some 30+ years ago.  It’s wrong, of course, to generalize too broadly, but I’ve worked with literally hundreds of large enterprise IT organizations (i.e., IT organizations of 250+ members) and have seen more commonalities than differences.  Of course, within any IT organization, there are sub-cultures – architects are not the same as operations people or as solution developers – but again, there are more common threads than sharp differences.

Prevent Bad Change…

For all the change that IT organizations bring about for their customers and clients, IT people are generally resistant to change.  I think this resistance is deeply rooted in a couple of factors:

  1. IT environments are full of technical complexity – layers upon layers of technology containing multitudes of interfaces and dependencies.  Change something over here and something over their is impacted – sometimes in subtle ways that may not be evident for some time, or until some other seemingly unrelated change is made.
  2. IT professionals thrive by taking complex situations and reducing them down – ultimately, to zeroes and ones.  There’s no room for ambiguity in a digital system – as such IT specialists are conditioned to abhor ambiguity.  And yet change is full of ambiguity – what ‘has been’ is no longer, and what ‘will be’ is not yet stabilized.  The natural inclination, then, is to drive out the ambiguity, and typically, the fastest, safest path to achieve that is to revert to the status quo – ending the change before damage is done (or the changed state it reached!)

Meet the Culture Where it is – Or Where You Want it to Go?

This inherent tendency to ‘prevent bad change’ creates some tough dilemma’s when introducing social networking and collaboration capabilities such as Wikis.  Wikis thrive best where a culture is open and emergent – “enabling good change,” if you will.  As you design the governance mechanisms for a Wiki, you have some interesting choices.  For example:

  • Do you allow people to create their own pages?  Or do you put controls on who creates and who edits pages?
  • Do you allow all spaces to be open to anyone in the organization?  Or do you allow for “private” spaces, where a select few (such as an IT leadership team) collaborate?
  • Do you allow people to display avatars that are humorous or ironic?  Or do you insist on “corporate photographs” from people’s security badges?
  • Do you allow people to write in their unique voices – even if a little rough around the edges?  Or do you have a Wiki Gardener monitor pages and clean up the rough edges?

To be clear, I’m not talking about allowing people to violate corporate codes of integrity – potentially offensive or inflammatory graphics or text is clearly out of bounds and violations of such codes of conduct should swiftly be managed as performance management issues.  I’m talking about an open and emergent Wiki environment – complete with the bumps and hiccups it may contain, versus a more closed and structured Wiki, protected from potential ‘voices of dissent’ or the raising of challenging or tough issues.

Governance Designed to Meet the Culture Where it is

You can take the position that Wiki governance should be designed for the current state:  “We are locked down, deeply concerned about security and privacy.  We have to have special ‘standards of conduct’ and controls to keep things structured and secure.”

Governance Designed to Help Shift the Culture

Or, do you take the position that the governance should be designed with an eye to the desired future state: “We encourage open dialog and a thriving ‘community of adults’ – keep within our corporate code of integrity and help make the Wiki a safe, valuable and fun place to grow and share our enterprise knowledge about IT.”

Given the people responsible for approving Wiki governance will probably not have significant experience with the more open model, their inclination will be to ‘play it safe’ and design for the current state.  Unfortunately, that is likely to perpetuate the current culture and probably prevent the Wiki from becoming what they want it to become.  It make take one or two strong, visionary leaders to take the leap of faith, and allow a governance model that reflects their aspirations for the culture.

Graphic courtesy of Positive Change

Enhanced by Zemanta

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