…. about people, technology and processes

Archive for October, 2007

Whilst managers may have long known that ‘if you can’t measure it, you can’t manage it’, what does that maxim mean in the context of a wiki implementation? In other words, when evaluating a wiki implementation what can be measured and how should it be done? In an earlier post I indicated that:

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

During my discussion with Euan Semple regarding the issue of wiki evaluation, he highlighted how the emergent nature of wiki usage and the wiki itself requires “conversations and actions, not pre-planning and control”.Consequently, in his experience ‘evaluation’ has been a continuous process requiring managers to be (i) awake to how people are working/using the wiki by engaging with and being open to user feedback and (ii) prepared to amend original ideas about the implementation and allow/encourage users to take responsibility for ensuring the wiki meets their needs.

Contrasting that ‘emergent’ approach to evaluation, Ross Mayfield described a more directed/planned approach where initial goals, milestones and indicators/measurements are identified at the outset and later used to establish progress and/or reassess plans.However, he did highlight the difficulties of measuring benefits associated with fostering transparency, innovation and culture change, or establishing whether any improvement in a targeted work process is directly attributable to the wiki, which tends to rely on soft data.

To investigate what is actually happening in practice, I asked interviewees and survey respondents whether and how they evaluate their wikis. Whilst most interviewees indicated that no formal evaluation takes place, when asked whether their companies have learnt to better manage/use wikis, they identified a range of initiatives to improve wikis including change of the wiki-structure to reflect active communities of practice, improved training mechanisms, and seeking out of best practices (e.g. from WikiPatterns).

Likewise, the majority of survey responses (30% of responses) indicated that no feedback was sought/given regarding the wiki. However, where evaluation had been undertaken it focused largely on the wiki itself (e.g. content maintenance, the ability to locate information and ease of use) rather than the implementation process (e.g. identifying collaboration and training needs)

So despite the above maxim, and the key theme espoused throughout ‘learning organisation’ literature (i.e the need for continual and live attention to ensure processes, skills and structures encourage the best possible feedback from outside the organisation, and between all elements within the organisation), it appears that evaluations tend to be ad-hoc rather than formal assessments of the wiki and the implementation process, with many organisations not actively seek feedback, and instead relying on more subtle forms of evaluation that occur seamlessly as people use the wiki and adapt it to their needs accordingly. Furthermore, where feedback has been sought, it has focused on wikis’ utility rather than internal usage patterns, transition mechanisms and user commitment/drop-out levels (i.e. the implementation process and barriers thereto).

Such approaches overlook the value of evaluating the implementation process and fail to view evaluation as central to that process.In other words, evaluation must be a continuous process providing opportunities to engage in dialogue, discover barriers to wiki use/growth and possible solutions thereto, not an activity which is tacked on at the end.That approach reflects the importance of understanding the needs wiki use/management is endeavouring to satisfy, which can aid in setting flexible goals to guide development of capabilities at all organisational levels, changes to organisational systems, and subsequent assess thereof.

During my research I found that the majority of wiki implementations have resulted from grass-roots initiatives (67.65% of businesses surveyed), which relied heavily on high levels of grass-roots facilitation and self-learning and motivation to use the wiki. However, 17.82% of survey responses reported no significant wiki growth, with key barriers to use being content maintenance, wikis being too unstructured and appearing chaotic, and lack of integration with other tools. Interestingly, the survey responses also indicated that no content maintenance occured in 18% of cases – a direct reflection of the figure regarding no significant wiki growth.

Given that 47% of the wiki implementations survey were under a year-old, the responses may suggest that people are still discovering their uses, how to integrate them into work processes and existing systems, and how to cope with issues regarding content maintenance. More particularly, whilst the user community in the majority of cases indicated content maintenance was being undertaken, in light of the key barriers noted above, its skill/diligence in doing so may be inadequate, suggesting that even ‘technical users’ may not yet have effectively learnt how to adapt their behaviours and the wiki to best suit their needs. In other words, even people who are highly motivated to self-learn and adopt wikis struggle to maintain the wiki and overcome barriers to its use. Consequently, to overcome these issues and to encourage the spread of best practice in wiki usage throughout the different stages of wiki adoption by different adopter categories, grassroots activity should be balanced with directed usage/active managerial promotion and support.

During my discussion with Ross Mayfield, he considered that a key determinant of wiki’s success is the investment made in up-front ‘training’ of the wiki community, not just regarding technical wiki features but also in the generation of a shared understanding of the practices required to support the collaboration goal (including distributed responsibility for content maintenance) and imbuing those practices in the community. He went on to describe how wiki’s growth and maintenance is inextricably linked to its incremental roll-out to an initial core group, who through such ‘training’ establish how the wiki can be used to best suit their needs and build the community to support that use. That group should then be encouraged to ‘invite’ others to undertake the same process, and so continue the cycle, growing the wiki across the organisation with each group establishing their routines/norms to suit their needs.

Apparent in that process are:

elements of grass-roots determinism regarding the wiki’s use so that it best suits people’s everyday needs, and the community practices to be developed to support such needs, coupled with

managerial facilitation to assist people’s learning and the spread of such learning.

Euan Semple highlighted another factor to be aware of during that process, namely the importance of engaging a broad cross-section of people who will (voluntarily) fulfill different roles in the wiki “since some people are naturally drawn to create ideas, others to write and some to refactor/garden”.

In summary, managers should be more involved in the adoption and growth of wikis by giving people time to become accustomed to, experiment with, contribute to and maintain the wiki, being responsive/alert to how the wiki should be integrated with work processes and new areas for its use, and leading by example and reminding (e.g. placing information and tasks on the wiki).Consideration should also be given to the benefit of providing initial adaptable structures to guide users and the support/training necessary to encourage people to be responsible for the wiki. In that way, people will be encouraged to capture tacit knowledge (which could be otherwise lost in casual/social problem-solving encounters) that is valuable to them in their everyday tasks and which they care enough about to make it worthwhile maintaining.

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.

Since a wiki does not replace discrete pieces of software or processes whose use may be highly structured and/or obligatory, thought needs to be given to:

the wiki’s purpose;

its relationship with existing work processes;

how the wiki should be designed (e.g. should be unstructured or should some basic structure/templates be provided to guide users);

the level of openness, and whether permissions should be used to restrict access to certain pages/areas;

how users will be encouraged to use the wiki and move away from more familiar less efficient tools;

how people will learn how to use the wiki – not just the technical features but the practices required to support their collaboration goals; and

how and who will maintain the content,

all of which can help ensure the wiki provides a substantial positive impact on people’s ability to work efficiently/effectively, and thereby facilitate its uptake.

However, to what extent does such ‘thought’ equate to ‘planning’ and how much latitude should be given to allow the wiki’s use to emerge? In other words, can the wiki implementation be ‘managed’?

I discussed this issue with several consultants advising on the introduction of Web 2.0 technology. Euan Semple indicated that a different mindset is required for the implementation of wikis in organisations, where implementers encourage and repond to emergent uses and users with different expectations, rather than trying to preconceive/control how the wiki should be used. Ross Mayfield indicated that clearly defined goals/targets can help guide emergent behaviour and provide parameters for later evaluation. Jeff Weinberger indicated that in his experience during grassroots implementations people were making good use of the wiki from the outset, despite their being unplanned. However, he noted that the lack of planning may have stymied the wiki’s adoption in other parts of the company and the spreading of best practice in respect of its use.

In practice, I found that the majority of current wiki implementations have resulted from grass-roots initiatives (67.65% of businesses surveyed), so it was perhaps unsurprising that people also characterised the ‘management’ of the wiki as more emergent than planned (38.24%) or indicated that no wiki management activities were apparent (19.61%). These implementations relied heavily on high levels of grass-roots facilitation and self-learning and motivation to use the wiki.

However, such approaches have resulted in a myriad of barriers hindering wikis’ use and growth, including lack of clear purpose in using the wiki, reliance on email and chaotic/badly maintained content. Consequently, to sustain wikis’ use by these early adopters and grow it to other groups, emergence should be balanced with more up-front direction to ensure those barriers are circumvented from the outset.

Such ‘direction’ does not refer to ‘management’ in the traditional sense of ‘command-and-control’. Because wikis are different from other IT implementations, and represent a reaction to existing technology shortcomings, their management requires a different mindset, which actively engages and supports people in their use, structuring and maintenance so as to best suit people’s work needs.

Interestingly, Jim Highsmith has recently shared his thoughts on this type of ‘management’ style (which he coins ‘light-touch’ leadership) in the context of self-organising teams and the agile community. He indicates that:

“Light-Touch Leadership means that decision making is delegated to the lowest level possible and as many decisions as possible are delegated to the team. However, delegating decisions in an organization isn’t a simple task; it requires tremendous thought and some experimentation. To me, Light-Touch conveys the right mix of delegation of decision making to teams while retaining appropriate decision-making authority with the leader or in other parts of the organization.

While Light-Touch Leadership may be “light” in terms of decision making, it is heavy in articulating goals, facilitating interactions, improving team dynamics, supporting collaboration, and encouraging experimentation and innovation. These characteristics of a leader are more critical to success than delegation of decision-making authority, but decision making is still an important piece of the leader’s role. When a good Light-Touch Leader is working, she or he is nearly invisible. Things seem to happen smoothly and the teams operate seemingly without a leader.”

Whatever label is placed in the ‘management’ needed during a wiki implementation (or development of an agile community or self-organising teams), the themes are clear – the leadership style needs to embrace both planning and emergence to encourage and direct a deep broad set of people in their consideration of how they currently work, what their needs are, how things can be improved, setting goals and making decisions to those ends, and supporting them throughout the process.

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

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

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.

I was curious to discover whether wikis are acting as more than just a technology enabler for information dissemination within organisations, and if they could serve a deeper function of facilitating changes to culture and stimulating organisational learning practices.

Consequently, I asked survey repondents and interviewees (i) what factors facilitate collaboration in the company, and (ii) whether those factors were prerequisites for successful wiki implementations or if wikis could be used as a means to develop better collaborative work practices.Common threads throughout the responses to (i) highlighted the need for organization-wide communications, access to/sharing of information/knowledge and a willingness to contribute/collaborate.In respect of (ii) views diverged.Some interviewees considered that, whilst wikis can provide a solution to the problem of locating information, they simply support existing information sharing/communication practices, since politics and cultural issues often hinder wiki usage.However, others considered that wikis encourage transparency by “questioning how people are thinking” and “can be used to increase awareness of people’s contribution to the workplace”.

Ross Mayfield of SocialText concurred with the latter view stating that “the best thing a wiki can do is to make transparent an existing culture.It can change culture overtime but if you try to introduce it into a controlling environment too quickly the entire notion of it will get slapped down”.That emphasizes the importance of ‘managing’ wikis’ incremental implementation so as to build towards a supportive user-community.

I also asked survey respondents to characterize their companies before and after the wiki implementation based on factors derived from the literature review.The overall picture is one of change towards ‘learning organisation’ characteristics (even if only slight in some areas).The greatest shifts occurred in relation to the level of information flows and new ideas being sought/tried, and people’s willingness to help one another carry out work.These changes appear to have occurred in a relatively short timeframe, with 47% of wiki installations being under a year-old. Most respondents considered that the wiki implementation has a minor (27.72%) to moderate (30.69%) impact in shaping companies’ characteristics.

Furthermore, the apparent benefits to be gained from wiki implementations in relatively short periods seem to have rather modest barriers/disadvantages, where survey respondents considered time to contribute (11.67% of responses), and reliance on email (11.67%) to be more significant barriers to wiki usage than culture (9.05%) and lack of managerial support (7.14%).That maybe partly attributable to the climate of openness and trust, and other learning characteristics, which organisations were considered to possess prior to the wiki implementation.

Consequently, the evidence suggests that wikis have improved organisational information flow, enabled people to work/communicate more efficiently and effectively, learn from past experience and share knowledge/ideas, in organizational contexts which are not averse to collaboration and learning.Accordingly, wikis have provided platforms for collaborative and emergent behaviour, which could not satisfactorily proceed through existing technology.

Time will tell whether the reported changes in certain organizational learning characteristics continue to grow and become more pronounced as wikis mature.Certainly, the level of grassroots’ implementations, facilitation and organic growth, illustrate instances of people at operational levels challenging mindsets regarding work practices and the utility of existing systems, experimenting with new solutions and adopting individual/team practices (including peer-to-peer learning) conducive to double-loop learning.

To grow this behaviour across the company and tap people’s “massive undeveloped potential” (Moss-Jones (2005)), management must be more alert to those initiatives and address barriers which inhibit wiki use.To that end, undertaking activities proposed in the wiki management cycle offers managers opportunities to engage in organizational learning practices and develop corresponding capabilities.

So, whilst there is much more to organizational learning and much more than can be supported by wikis alone, I think their use/management maybe informed by practices associated with the ‘learning organisation’ which in turn may facilitate changes to culture and stimulate organisational learning practices, making wikis more than a mere technological enabler for wider information dissemination.

Having survey 102 companies, and interviewed 10 companies and 9 consultants, I compiled the following recommendations regarding the management of wikis in business:

1.For new implementations, consider the needs to be addressed/capabilities to be developed, how people currently work and changes that maybe necessary to routines/behaviours, as well as the nature of the culture, structure and other organisational subsystems, which initially will have to be worked within whilst gradual change is encouraged.For existing implementations, evaluate their impact (if any) on the foregoing factors, and who is (and is not) using wikis and why (including issues users have in respect of wikis and their work processes).

2.View the implementation as a change process and allow for planned emergence during adoption and growth/maintenance, and encourage evaluation throughout.

3.Involve a broad cross-section of people in the definition of flexible (collaboration) goals, and the consideration of how the wiki should be designed and people’s behaviour altered to (better) meet identified needs.Use those goals to guide and evaluate how well the needs are being met.

4.Consider the tasks being undertaken and the level of user competence when deciding whether some flexible structures/templates would help to avoid the wiki appearing chaotic and content being hard-to-find, as people learn how to create their own structure/maintain content.

5.Identify key ‘technical’ users (with needs corresponding to those identified) who can form pilot groups, or who can expand wiki usage to other areas/projects.Encourage experimentation to discover how the wiki can be used to best suit their needs and uncover issues with its design, integration with existing tools and/or impact on other subsystems.

6.Don’t rely solely on the self-motivation of the initial adopter groups.Develop and support good practices from the outset by supplementing self-learning with targeted training and best practice guidelines to help users understand the goals and wiki practices necessary to facilitate more effective/efficient work.

7.Recognise that later adopters may need greater support helping them understand how to use the wiki and work more collaboratively.Engage existing users in this process to grow the wiki organically.Focus on and demonstrate the uses/benefits of wikis’ use for everyday work (with knowledge collection being a by-product of wiki usage rather than an end in itself).

8.Allow people time to develop their skills with the wiki and gradually move them away from use of inefficient tools by constantly and subtly promoting its use (e.g. through moving tasks/information onto the wiki, sending people links/referring people to wiki pages and involving people in projects using wikis).However, support different communication styles and recognise that using a wiki may not be suitable in certain circumstances.

9.Encourage user delegation, and rotation of, a wiki gardening role to people within their respective communities of practice, whilst developing more dispersed habitual gardening practices amongst users.

10.Be alert to how people are using the wiki and seek feedback continuously to learn how people can best be supported in their work.Ensure that any measures used during the evaluation process are aligned with the needs which are driving the implementation.Assess/refine the implementation goals, process and wiki itself even if that means relying on soft data.