The spiral of wiki adoption

In an earlier post I indicated that wiki ‘adoption’ refers to the stages through which users typically progress before committing to a new technology, with different adopter ‘types’ (e.g. innovators, early and late adopters) progressing through the stages at different times and speeds. Perhaps an even simpler (although less scientific) way of categorising users lies in the distinction between those who are technical (e.g. technologically familiar or curious) or non-technical, with ‘technical-users’ more readily adopting wikis and associated concepts of teamwork, knowledge capture and sharing, and learning therefrom. ‘Technical users’ tend to be ‘innovators’ and ‘early adopters’ often comprising people from technical companies and engineers. In fact, my survey of 102 companies corroborates this generalisation, with the greatest proportion (37.26%) of participants coming from the IT sector followed by the professional services sector, and 22.55% being IT engineers and 15.69 being consultants.

The survey results indicated that high levels of self-learning (69.93% of responses) have been supported by peer-to-peer learning (18.18%) with very little targeted/tailored training (1.40%) or issue of best practice/usage guidelines (10.49%). Popular mechanisms used to supplement self-motivated usage and ‘unlearning’ of older inefficient yet familiar habits include information being placed on to the wiki, people being involved in projects using a wiki and emailing links to the wiki. Those mechanisms moved users rapidly through the first adoption stages of becoming aware of the wiki, to understanding through trial/experimentation with the wiki.

The Wiki Adoption Spiral depicts how ‘technical-users’ move through adoption stages and spread wiki usage virally to later adopters. It reflects that:

  • adoption stages for ‘technical users’ (constituting the first adopter categories) are shorter and converge as they proceed quickly through initial (awareness, understanding and trial) stages, creating their own ‘transition mechanisms’ involving self-learning and experimentation with wiki use.
  • adoption categories and processes are fluid, as different users can be drawn into the process without early categories having completed the ‘typical’ cycle. For example, due to organic growth other categories maybe made aware of the wiki prior to its ‘adoption’ (e.g. through involvement in projects wikis), and commence their adoption process.
  • progress through stages can be halted (i.e. no growth through abandonment or rejection) if there is no perceived ‘need’ to use the wiki and/or barriers are not overcome.

Whilst early adopters more readily enter the adoption process because they are more technically competent/inquisitive, the implication from the above points is that top-down support /facilitation is equally important for developing good ‘wiki’ practices within the initial adopter group as for later adopters. Such facilitation involves generation of a shared understanding about collaboration goals, wiki purpose, responsibilities and ‘gardening’ practices. The experience/knowledge of those adopters can then be coupled with other transition mechanisms (e.g. more ‘technical training’, involvement in projects using a wiki and information being made available on the wiki) to accelerate the diffusion process to other adopter categories.

The high level of ‘learning by doing’ and peer-to-peer support illustrates an opportunity for users to participate in a collaborative learning experience, which provides an ideal platform for encouraging communication and collaborative behaviours in general (e.g. helping transfer knowledge/ideas throughout the company, working across organizational boundaries and learning from past experience/best practices of others).

Although reliance on email and familiarity of other tools may illustrate a reluctance to ‘unlearn’ habitual less effective work practices, there needs to be a balance between directive wiki usage and support for different communication styles as people become accustomed to using wikis and the different capabilities they can provide. That also requires responsiveness to feedback and anlyses of ways in which existing tools can be integrated with wikis to best support people in their work.

What collaboration technology do you (think you) need?

There are a number of ways in which new collaboration technology may be introduced into an organisation, including:

  1. An ‘inside-out’ approach which focuses first on the business needs and capabilities to be developed, then on identifying the technologies which can support those needs/capabilities (McAfee approach - “Mastering the Three Worlds of Information Technology” Harvard Business Review (2006)).
  2. Continuous scanning for innovations/new technology and matching promising innovations with relevant problems (Rogers’ approach - Diffusion of Innovations (1995) Free Press, New York).
  3. Operating a ‘me-too’ approach as a result of ambiguous goals and a volatile/uncertain environment, whereby the implementation of new technology is influenced by/modelled on what other organisations are implementing or the current technology adoption trends in the market (Mimetic Isomorphic approach - DiMaggio and Powell The Iron Cage Revisited American Sociological Review (1983)).

In an effort to determine which approach businesses favour and the consequence of the approach in terms of wiki adoption, I asked survey respondents to identify the drivers behind their wiki implementations and how they are actually using their wikis, to gauge if there was a correlation between the two. The key business ‘needs’ identified spanned three broad areas of supporting collaborative work practices (27.88% of responses), increasing the effectiveness/efficiency of existing tools (22.68%), and improing the ability to locate or retain information/knowledge (23.05%). Few responses indicated (or admitted?) that the wiki had been implemented simply because it represents something of a new trend in collaboration technology.

In terms of what the wiki is actually being used for in the workplace, responses indicated their primary use as knowledge bases (22.53%), for ideas generation (16.21%) and project collaboration (16.21%). With the primary need being to support collaborative work practices, higher actual uses for ideas sharing and project collaboration might have been expected instead of the wiki’s predominant use as a knowledge base. Of course, it could be inferred that the primary need is being satisfied through a variety of wiki uses, of which the knowledge base currently predominates, with actual uses for ideas sharing and project collaboration increasing as people discover other uses the for the wiki.

What’s intersting about this however, is that wikis are being employed mainly for internal purposes, and not for marketing and collaboration with clients (a mere 3.85% of responses indicating use for this purpose). On the one hand, given the relative newness of many wikis (remember that 47% of the 102 wiki implementations survey were under a year old) the responses may suggest that wikis and capabilities regarding their use/management are still being developed internally before being extended outside the organisation. Alternatively, given the importance of collaborations with customers, it may suggest that businesses are not in fact applying the wiki to key needs, which requires the development of capabilities so as to be better able to deliver what it is the customer wants. Integral to that is the ability communicate quickly and effectively with customers.

During the interviews I conducted, I asked Suw Charman what ‘needs’ were driving the implementations (e.g. inefficiency/ineffectiveness of existing tools, inability to locate/retain information and/or knowledge, better support for collaborative work practices, etc). She noted that “there is a difference between what businesses need and what they think they need”. She went on to indicate that due to their popular public uses (e.g. Wikipedia) businesses implement wikis to help employees find and access past/current information, instead of thinking about issues surrounding efficient work, and better collaborative, practices. Consequently, “they tend to look at the problem the wrong way around … since it is not about sharing knowledge and the introduction of a new technology per se, but about getting work done quickly and easily”. Her comments reflect the practicalities of the Rogers’ approach and the imitative selection processes that create a form of ‘pressure’ as a result of the Mimetic Isomorphic approach, which approaches may not in fact focus on the collaborative behaviours/capabilities which need to be developed and engender requisite/appropriate managerial support to do so.

In light of the reported barriers to wikis’ use (e.g. time to contribute/maintain content, reliance on email, lack of managerial support, culture, lack of clear purpose for the wiki and wiki not being integrated with other tools) it seems that reliance on the Rogers’ approach or the Mimetic Isomorphism approach is resulting in a lack of commitment to the change process integral to the adoption of this style of collaborative technology, undue reliance on voluntary adoption and insufficient support during the adoption process, and loss of opportunity to recognise why such tools like wikis are being introduced to the business and their potential to help resolve issues with existing knowledge management/work practices and develop collaborative capabilities both internally and externally. In other words, a more holistic ‘inside-out’ approach.

Wiki Management Cycle

In my previous post I introduced the idea of using a process framework for managing the wiki implementation. Here’s some more detail about the concepts behind each of the framework’s processes:

Wiki Management Cycle

  • Identify ‘needs’: This requires focusing first on the business needs, collaborative behaviours and capabilities to be developed, then on identifying the technologies which can support those needs/capabilities.
  • Plan: Having identified a wiki as a suitable technology, its implementation and management must be considered. This should balance planned and emergent approaches to foster learning and allow patterns of use and self-sustaining behaviour to evolve over time, whilst providing direction/purpose to co-ordinate and guide efforts towards a shared vision of what is to be achieved. Consideration should also be given to the practical applications and purpose(s) of the wiki, how it will fit with existing technology systems and work processes, and the nature of facilitation (e.g. initial structuring and seeding of the wiki) to support and sustain use.
  • Adopt: Wiki ‘adoption’ refers to the stages through which users typically progress before committing to a new technology, with different adopter ‘types’ progressing through the stages at different times and speeds. Rogers’ Model of Technology Adoption Categories below illustrates the characteristic responses of adopters to technology innovation:

Rogers’ Technology Adopter Categories

Typically, those users become aware of a technology’s potential and then develop an understanding of it, which can lead to testing through trial use, and if successful, to its application in everyday work, before full adoption across the organisation as a key element in work processes. Whilst that path may not be linear, recognising the different stages may help to identify support/transition mechanisms to ensure each user-category is more likely to adopt the wiki, and help avoid its rejection, which may occur during any stage of the adoption process. In particular, the issue here is how to strike the balance between voluntary grass-roots adoption and directive use to encourage participation, raising considerations about the nature of training, teamwork, use of facilitators, support for different communication styles and unlearning of old habits regarding overuse of inefficient/ineffective technologies.

  • Maintain: Closely related to adoption is wiki growth and propagation of good practice throughout the organisation. Issues here relate to managerial support, content management and wikis’ integration with other systems and work processes. Of interest here is whether managers have in fact absorbed the advice from industry and academic literature indicating they should be directly involved in the implementation by leading by example, mandate and reminding, reducing barriers to use, encouraging experimentation with the wiki and monitoring its use for ideas and best practices then propagating them throughout the organisation. Content management is also a key issue. Since wiki content should become more useful, structured and navigable over time if people are updating, linking and tagging, consideration needs to be given to the mechanisms which best encourage that type of behaviour.
  • Evaluate: Of interest here is whether, and if so how, businesses are evaluating their wiki implementations. Such evaluation can be a mechanisms for encouraging feedback and learning from the implementation process, and allowing for revisions to implemenation plans, and wikis’ design, usage and maintenance. Measuring users’ progress through adoption stages and how often people are using wikis will provide some elementary figures on wiki diffusion and infusion in the organisation, and may provide grounds for investigating any barriers to the implementation process. However, more difficult issues relate to evaluation of wikis’ impact on bottom-line performance and development of organisational learning practices. Measurements focusing solely on bottom-line performance improvement in terms of accelerated project cycle times, reduced email overload and search costs may provide some hard data to support ROI, but they do not consider more important effects of wiki management/usage on organisational learning and collaborative capability development. Not only is it more difficult to establish direct causal connections between wiki management/use and improvements here, any evidence would be in the form of people’s opinions/perceptions.

Wiki implementations - a change process

The original wiki design principles (Wiki Design Principles) encourage emergent work and do not impose structure, process or rules, contrasting applications characterised by a top-down command-and-control mentality. That can allow people to work together in self-directed ways, encouraging levels of openness, autonomy and knowledge sharing which other systems (i.e. all systems in the organisation including cultural, managerial, structural and operational systems) could not well support. Consequently, a wiki implementation should be viewed as a change process rather than the introduction of a new technology per se.

Since cyclical process frameworks have been suggested for technology management in general - i.e. as means to aid consideration of technology’s role, effects on the organisation and nature of managerial activities/involvement, from existing literature I derived a wiki management framework to help assess how in practice businesses are managing wiki implementations and the utility of such a framework for managing the change process.

That framework includes the following processes: ‘Need’ Identification, Planning, Adoption, Maintenance and Evaluation. During my research I posed a range of questions to interviewees and survey respondents regarding their practices in respect of each of the processes. I’ll be discussing the responses in a later post.

Wiki Management Cycle

Wiki Management Cycle

Wikis and organisational change

Numerous blogs, industry and academic literature reflect the considerable correlation between the concepts related to the adoption of innovations, development of a ‘learning organisation’ and successful management of wikis in business, including:

  • development of a receptive culture and managerial support;
  • role of leaders in promoting interaction, dialogue and feedback;
  • top-down and bottom-up approaches to learning and management;
  • widely shared vision for what is required, and the teamwork, adaptiveness and creativity necessary to advance that vision.

A little while back there was an interesting debate which sparked considerable comment about the ability of social software/Web 2.0 to effect organisational change. In other words, whether Web 2.0 technologies can act as more than a mere technology enabler for wider information dissemination/communication in organisations and their use/management stimulate organisational learning practices and culture change.

One school thought maintains that Web 2.0 (including wikis, blogs, bookmark managers and network/micro-blogging services) will not address or substantially change the barriers that prevent organisational learning e.g. free flow of knowledge, lack of trust, missing incentives, power differentials, unsupportive cultures and the general busyness of employees (Davenport) . The other school (including McAfee, Suarez and Hinchcliffe) recognises that technology by itself won’t resolve the dilemma, but view the increasing use of Web 2.0 as a catalyst for change.

Proponents of the latter view consider Web 2.0 to be a radical departure from previous generations of collaboration/knowledge management tools, since they are easy to learn, deploy and use, giving people the ability to self-organise and collaborate in ways which best suit their needs. They consider that well-executed wiki adoption and management, couples with a growing need for businesses to focus on supporting innovation/collaboration, will encourage organisational learning.

That debate fed a second string to my research, i.e. the extent to which use/management of wikis may contribute to improved organisational communication and collaboration making them potentially useful tools for encouraging practices associated with the ‘learning organisation’. It also highlights the twin-edged nature of the problem, since using a wiki effectively in the workplace may itself depend on the extent to which the organisation is able to cope with complexity/change, learn and continuously improve.

Consequently, since the clear message is that implementing wikis (and any Web 2.0 technology) is as much about understanding organisational culture, learning, collaboration practices and human behaviour as it is about the technology itself, I also investigated:

  1. how themes of the ‘learning organisation’ can aid and be reflected in the management of wikis in business; and
  2. the extent to which such management can in turn encourage organisational learning and foster collaborative behaviour.

New technology - Old Problems?

Increasingly, wikis are being implemented in businesses to address concerns with knowledge management, collaboration practices and limitations of existing systems, and to:

  • Reduce email traffic;
  • Provide a common platform (rather than a private channel) for collecting, organising and sharing knowledge and experience of all stakeholders;
  • Provide a flexible tool adaptable to a range of uses including knowledge repository, project/action tracking and intranet;
  • Facilitate swifter more widespread and effective communication.

However, their use in the workplace maybe inhibited for a variety of reasons including:

  • Potential lack of clear purpose since wikis may not replace existing systems or processes;
  • Lack of content or too much unmanageable content if not refactored (i.e. editing/organising pages);
  • Bureaucratic command-and-control organizational (sub-) culture(s) and structure which stifle knowledge sharing, openness and trust;
  • Risk of abandonment if users do not perceive a clear need for, or benefit from using, wikis or other barriers to their use are not overcome.

Those difficulties raise specific issues about wikis’ management and use, the effect of organisational context (i.e. structure and culture) on wiki uptake, and more generic issues about adoption of innovations. Similarly, a business’s ability to collaborate effectively reflects issues at the heart of technology management, namely improving the effectiveness of an organisation and its people through the application of concepts and techniques for operating, improving and integrating an organisation’s systems, and introducing innovatory systems.