Developmental approaches to B2B virtual communities

Technovation 31 (2011) 296–308 Contents lists available at ScienceDirect Technovation journal homepage: www.elsevier.com/locate/technovation Developmental approaches to B2B virtual communities Matthew Tickle n, Dotun Adebanjo 1, Zenon Michaelides 2 Management School, University of Liverpool, Chatham Street, Liverpool L69 7ZH, United Kingdom a r t i c l e i n f o Keywords: Virtual communities Communities of practice Open innovation Web 2.0 Case studies Cross case analysis a b s t r a c t This paper analyses the development approaches of four business-to-business (B2B) virtual communities (VCs) and compares them through use of a cross-case analysis. The study indicated that there is no ‘‘one size fits all’’ method for developing VCs and that a structured, rigorous development methodology based on academic research is required in order to successfully create and manage VCs. It also found that the main challenge in creating successful VCs is not that of developing them, but that of developing an engagement and contribution culture. & 2011 Elsevier Ltd. All rights reserved. 1. Introduction This paper analyses a number of developmental approaches to business-to-business (B2B) virtual community (VC) development. Consequently, it identifies and evaluates different methods of development by studying four such VCs and comparing them through use of a cross case analysis. A VC is a community of people with a common interest but not necessarily a common geographic location (Sands, 2003). In their most basic form, VCs are websites that allow their users to interact with each other using tools such as discussion forums, weblogs (or ‘blogs’), real-time chat and trading areas. VCs effectively allow the exchange of vast amounts of information between users scattered globally. Case et al. (2001) make the distinction between a VC and a traditional community (i.e. a location where people with similar interests can share experiences, ask questions and collaborate)—members of a given profession can join a ‘physical’ community bringing with them a large amount of critical information, knowledge and experience, which they share only occasionally at events such as conferences. VCs, on the other hand, overcome this minimal interaction by connecting geographically disparate groups in real time, through an online environment. This allows them to share knowledge and information with speed, but with little expense. According to Wu and Fang (2010), such interaction has been credited with the ability to create value by activities such as idea generation resulting from consumer interaction within VCs. Like traditional communities, VCs also act as a repository of information for their n Corresponding author. Tel.: þ44 0151 795 3717; fax: þ 44 0151 795 3640. E-mail addresses: M.Tickle@liverpool.ac.uk (M. Tickle), D.Adebanjo@liverpool.ac.uk (D. Adebanjo), Z.M.Michaelides@liverpool.ac.uk (Z. Michaelides). 1 Tel.: þ0151 795 3606. 2 Tel.: þ0151 795 3602. 0166-4972/$ - see front matter & 2011 Elsevier Ltd. All rights reserved. doi:10.1016/j.technovation.2011.04.002 members, but they can store a much larger amount of important data (Case et al., 2001). The data stored within the VC is also far more accessible, with members using sophisticated search engines to identify their exact topic of interest. Another advantage for VC members is access to opinion leaders and industry experts with a mouse click with whom they would otherwise never have contact. Ardichvili et al. (2003) suggest that VCs are fast becoming the tool of choice for knowledge management professionals in multinational corporations such as Hewlett Packard, British Petroleum, Chevron, Ford, Xerox, Raytheon, IBM and Shell. Their study of VCs within Caterpillar found that the company had more than 600 such VCs with more than 15,000 members worldwide. Despite the proliferation of VCs in international business organisations, there is still little known about factors that lead to their success or failure. Little is also known about the vast number of different methods of development available to community managers. A historical analysis of VCs was produced by Kubicek and Wagner (2002) who provide an insight as to how these networks evolved over time with varying technology infrastructures. Their analysis concluded that a standard design or development methodology for VCs does not exist. Because of this, Harrison and Zappen (2005) believe that each VC can be seen as ‘‘an experiment in accommodating the tensions between access to hardware/software infrastructure, design of the particular application or system, user needs, and the initiating and ongoing resources that support these efforts’’. Wenger et al. (2005) state that there is no ‘‘perfect’’ technology configuration for VCs, believing that the choice of technology changes from community to community over time, further complicating the situation. This paper presents the findings of four case studies of VC development and compares them through use of a cross case analysis. The paper first introduces a literature review of VCs, before detailing the study’s research questions and aim. The methodology of the study, including summaries of the four case studies, will then be introduced. Finally, results from the analysis M. Tickle et al. / Technovation 31 (2011) 296–308 of the four case studies will be presented in the discussion and analysis section, before the study conclusions are detailed. 2. Literature review VCs are developed from the more established concept of communities of practice (CoP). A CoP is a group of people that share a passion for something they specialise in and who interact on a regular basis in order to learn how to do it better (Wenger, 2004). CoPs improve the performance of their members, by allowing them to share the experience or advice of other members (Wenger, 2004). The main driver behind CoPs is that people learn more when they engage and share knowledge with others than they do when attempting to learn alone (Campbell and Uys, 2007). With the proliferation of advances in technology, practitioners began examining the ability of ICT to enhance these offline CoPs through use of VCs, and the number of VCs created to support offline CoPs grew progressively. Most VCs are self-organising, as they are made up of individuals who voluntarily choose to participate, with participation being open to all members interested in the shared practice the VC supports (Wasko and Faraj, 2005). Many VCs occur outside organisations, although companies such as Proctor and Gamble, Hewlett Packard, Sun, Ford, IBM and Shell have embraced the idea on an organisational level (Williams and Cothrel, 2000; Michaelides and Kehoe, 2007). Chiu et al. (2006) highlight the importance of VCs in terms of knowledge management, stating that knowledge is a valuable resource for competitive advantage due to it representing intangible assets that are difficult to imitate. It is widely accepted that most organisations do not have access to all the knowledge they require and, as such, must rely on links to outside organisations (and individuals) to acquire this knowledge. VCs offer one such way to create these external links, as they support knowledge exchange between geographically dispersed co-workers. VCs can therefore be seen as a tool to support open innovation principles within an organisation. 2.1. Open innovation Open innovation is a relatively new concept that challenges the way firms view their internal research and development (R&D). According to Huizingh (2011) open innovation is not a clear cut concept, as it manifests in different forms. In the early twentieth century, internal R&D was seen as a strategic asset and a barrier to entry in many industries, with research based companies such as IBM, GE and AT&T conducting the mass of the R&D, and earning the majority of the profits in the process (Chesbrough, 2003a). Rivals needed to invest in their own R&D labs and employ the most talented researchers and engineers in order to outperform their competitors (van de Vrandea et al., 2009). Once a stream of new, innovative ideas was created, these firms had to defend their intellectual property (IP) against its use by competitors (Dahlander and Gann, 2007), resulting in many useful innovations being ‘left on the shelf’ if they could not be used by the company to stop competitors gaining any sort of advantage. This model has been coined the ‘closed innovation’ paradigm of the early 20th century. Although this method of innovation had originally proved successful, Chesbrough (2003b) notes that several factors occurring in the latter years of the century began to undermine the closed innovation paradigm. Firstly, highly skilled people who left a company after many years of loyal service took a large amount of their hard-earned knowledge with them to their new employer, with the previous employer not receiving any sort of compensation for the training. Secondly, private venture capital investments 297 became more popular, creating new, valuable firms that could commercialise external research. As a result of these two factors, people started to realise that there was a second, outside path to market for many of the ideas that were currently left on the shelf at these large R&D companies. The very ideas that the market leaders discovered through their R&D processes were now being used against them as these new firms competed for industry leadership. Chesbrough (2003a) coins this paradigm shift as ‘open innovation’ and argues that ‘‘open innovation is a paradigm that assumes that firms can and should use external ideas as well as internal ideas, and internal and external paths to market, as firms look to advance their technology’’. Within the open innovation process, ideas can still originate from inside the firm; however some of these ideas can seep out of the firm at either the research stage or the development stage. When these ideas leave the firm, a start-up company is formed, often staffed with some of the company’s own personnel (Chesbrough, 2003b). Other leakage mechanisms include external licensing as well as departing employees setting up their own start-up company. The open innovation paradigm also allows for ideas to be generated from outside the firm and then researched and developed within the firm. The firm’s boundaries are therefore more porous as opposed to the solid boundaries of closed innovation firms. Innovation is becoming more global in nature, with an increased global dispersion and firms can therefore not innovate in isolation (Dahlander and Gann, 2007). It is well known that technology assists in integrating internal and external inputs to innovation (Dodgson et al., 2006). The proliferation of the Internet in particular has allowed companies access to a vast amount of scientific and commercial knowledge that was less available (both in terms of cost and time) as recently as the early 1990s (Kafouros, 2006). Bjork and Magnusson (2009) highlight the use of social networks and communities of practice in generating and acquiring new knowledge as well as increasing learning within the organisation. Furthermore, Kohler et al. (2009) found that virtual interactions add value in different stages of the ‘real-life’ innovation process and Mention (2011) believes that this form of co-operation between parties increases the likelihood that innovations will occur. All of these profess the importance of VCs to empower the open innovation approach. 2.2. Participation in VCs VCs are rather dissimilar to their social network counterparts (such as MySpace, Facebook and Bebo) in that member participation in social networks is due to the increased social nature of interactions, and as such members of these networks require little motivation to participate (Adebanjo and Michaelides, 2010). In contrast, members of VCs generally require a substantial increase in stimulation in order to collaborate. This is generally due to a number of barriers potential members need to overcome before contributing to the community. A major barrier for members is fear that their contribution is not relevant or a feeling that they do not have the correct level of expertise in order to post a relevant contribution (Williams and Cothrel, 2000). Similar to reasons of non-contribution in face-to-face communities, large egos within a VC can disrupt conversations, with personal attacks on members’ contributions destroying participation all together (Wasko and Faraj, 2000). This is supported by Ardichvili et al. (2003) who found that many Caterpillar employees feared possible criticism or ridicule should their contributions be viewed as unimportant to the discussion. It was also discovered that new employees felt intimidated about posting as they believed they have not yet ‘‘earned the right’’ to post to a company-wide system. The size of the VC can also become a barrier—a large number of members leads to a large number of contributions, making it a difficult and time consuming process to find information that is 298 M. Tickle et al. / Technovation 31 (2011) 296–308 truly useful (Yeow et al., 2006). This ‘information overload’ effect can actually deter members from using the VC as a problem solving tool due to the perceived danger of receiving large numbers of inappropriate replies to their questions. VCs will also not be eligible for every business application. It is unlikely, for example, that many people will want to regularly visit a financial services VC. As is found in social networks, people are generally interested in each other (in areas such as gossip, news and sports), and not in the latest financial offerings or payment plans (Barnatt, 1998). Many Caterpillar employees mentioned that some process-oriented problems are very difficult to duplicate, therefore a solution to such a problem being located within a VC is highly unlikely (Ardichvili et al., 2003). For members to contribute to a VC, they must feel that their contribution is worth the effort and that some value from their contribution will be received by themselves. Members may also be more inclined to contribute if they feel that their participation will enhance their personal reputation both within the VC and also in their professional setting (Wasko and Faraj, 2005). These findings indicate that personal benefit and reputation building can be strong motivators for active participation. Osterloh and Frey (2000) agree, suggesting that intrinsic motives are much more powerful enablers of knowledge and information sharing as compared to extrinsic stimuli (such as monetary or administrative). Muller-Seitz and Reger’s (2009) findings suggest that some members contribute simply because it ‘feels good’ to help others that have challenging problems, as solving problems is challenging and fun. They also suggest that giving back to the community in return for help with specific problems as a motive for participation. A later study by Muller-Seitz and Reger (2010) found that both intrinsic and extrinsic stimuli can be successful in encouraging members to participate and that a lack of formal structures within a VC can be detrimental to members’ motivation levels. Trust is also an important factor in encouraging participation within a VC—trust develops when a history of favourable past interactions leads to expectations about positive future interactions. Increased trust in other members’ ability, benevolence and integrity increases the level of participation within the community, thus supporting a strong sense of reciprocity and encouraging future contribution (Wasko and Faraj, 2000, 2005). Ardichvili et al.’s (2003) study confirms this, with Caterpillar employees stating that they are more likely to contribute to VCs once they trust that the other members will not misuse the information they posted. Employees also stated that they were more likely to use the VCs as a source of new knowledge once they trust it to be a reliable and objective source of information. 2.3. The role of technology The potential for different levels of user participation is highly dependent on the technological base of the VC. A community implies an experience of togetherness that extends through time and space, therefore recreating this behaviour of personal interaction through technology is vital for a VC to operate successfully (Wenger et al., 2005; Muller-Seitz and Reger, 2009). Campbell and Uys (2007) support this, believing that community members will only accept the technology once it allows them to communicate in a timely and efficient manner. Every VC faces challenges in terms of its technology—inadequate technologies increase the communication costs for members thereby limiting community activities, and the plethora of technology options and the diversity of user skills in IT further complicates this matter (Koh et al., 2007). Campbell and Uys (2007) found that unfamiliarity of the technology was a major barrier for participation within the VC. Technical impediments that frustrate members are likely to lead to a reduction in return visits. However, they noted that once members had overcome this technology barrier they started to find it useful to their contributions (rather than an inhibitor to communication). The authors continue by stating that the more members use a given technology, the less concerned they become with its limitations, and are prepared to ‘‘forgive and forget’’ after a period of successful use. The authors also believe that VC technology is more readily accepted by community members once it becomes a transparent means of communication (that is, once it becomes an accepted form of communication that allows the members to communicate in a timely and efficient manner). Wenger et al. (2005) state that there is no ‘‘perfect’’ technology configuration—it changes from community to community over time. Although the technology is an important aspect of the community, it is merely the enabler that facilitates the delivery of value to end users (Hagel and Armstrong, 1997; Stuckey and Smith, 2004; Orlikowski, 1996) and it therefore needs to be selected for the communities’ needs rather than for the features it offers. It is important that technology is seen as an enabler of VCs rather than the driver—many VC owners still believe that selecting a suitable technology is all that is required to create a successful VC, when this is, in fact, a sure-fire route failure (Preece, 2000). According to Wenger et al. (2005), there are five technologies that are most relevant to VCs. These are detailed in Table 1. 2.4. Summary This literature review shows that VCs are an emerging and popular research topic and that significant benefits can be achieved from VC adoption, particularly in support of open innovation principles. It can be seen, however, that there are a number of different factors that affect the success of any VC, and that there are as yet no definitive developmental approaches. From the literature review, a number of research questions were identified. These are as follows:  How has the rapid growth of VCs manifested in developmental approaches?  What are the key factors that influence VCs and how do these factors interplay to influence the development and success of VCs? Table 1 Technologies for VCs (adapted from Wenger et al., 2005). Technology type Usage Synchronous Allow members of a virtual community to communicate and collaborate in ‘real-time’. Examples include Instant messaging, video conferencing and whiteboard applications. Asynchronous Allow members to communicate when there is a time difference involved. Examples include discussion boards and e-mail. Publishing Allow members to collaborate through information exchange. Examples include Blogs, RSS feeds, newsletters, document repositories (including version control) and calendars. Transaction Allow members to securely purchase goods and services through the virtual community as well as identifying the parties involved in the transaction. Paypal is a good example. Data collection and interpretation software Allow community organisers to analyse member profiles and participation statistics, in order for them to continually re-engineer the community in order to meet the users’ needs. M. Tickle et al. / Technovation 31 (2011) 296–308 3. Research aim and objectives The overall aim of this study is to identify and analyse the current developmental approaches to the implementation of VCs in order to identify facilitators and obstacles to successful VC development. 4. Methodology The research methodology employed is case study based. Case study research has been used previously in VC research (Adamides and Karacapilidis, 2006; Adebanjo and Michaelides, 2010). Yin (2009) states that a case study attempts to ‘‘illuminate a decision or set of decisions: why they were taken, how they were implemented, and with what result’’. The case study approach allows collaboration between the researcher and the case study organisations, allowing identification of the current developmental approaches in their real-life context. Due to this, relevant theory can be generated from the in-depth understanding following observation (Benbasat et al., 1987). The case study research approach is applicable to this study as it facilitates: (a) the study of process-related issues associated with a specific phenomenon over time; (b) the understanding of a specific phenomenon over time and (c) the use of a new perspective that allows the achievement of a better understanding of a specific phenomenon (Lorenzo and Kawaleck, 2004). A multiple case study design has been preferred to a single-case design as multiple case studies can prove valuable in order to illuminate contrasts and similarities between the cases (Hartley, 2004). Yin (2009) believes that the analytic benefits of having two or more case studies can be substantial and, when given the choice, multiple-case designs should be preferred over single-case designs. Four case studies were identified, each one selected due to their relevance to the research topic and the availability of the individuals involved. Data collection took the form of participant observation and qualitative research interviews. The permutation of two case studies analysed using the complete participant strategy and two using the interview technique offered a balance to minimise bias following Hartley’s (2004) suggestion that the combination of closeness and distance is essential to good research. 299 (2008) believe that this approach is sometimes the only way to gain the kind of insights sought. Whilst working as a participant-as-observer, documentation such as project plans, requirements and design documents and testing plans was collected in order to record the main areas of interest. Structured and semi-structured interviews with other employees involved in the case study VCs were also used to obtain a more objective view. Details of the interviews are summarised in Table 2. The methodology used for these interviews was the same as that used for the ‘interview’ case studies explained below. The results of the interviews were triangulated with both the observations and documentation to increase the validity of the findings. 4.2. Interview case studies The data obtained from the first two case studies aided to clarify both the data requirements and the specific interview questions for the two interview case studies. The selection process for these two case studies was based on their relevance as well as the availability of the participants involved. The interview participants included six managers that were directly involved in the development and management processes of their VCs. Kvale (2007) defines the qualitative research interview as: ‘‘an interview, whose purpose is to gather descriptions of the lifeworld of the interviewee with respect to interpretation of the meaning of the described phenomena’’. The use of interviews in the research process is supported by Voss et al. (2002) who believe that structured and semi-structured interviews are the typical major data source for case study research. King (2004) and Burgess (1984) both agree, believing that interviews provide an opportunity for the researcher to uncover new dimensions of a problem and thus obtain accurate accounts based on their personal experience. A number of in-depth face-to-face interviews were conducted with the six managers, which were followed up with five telephone interviews where additional information was required. The data obtained was triangulated with documentation (such as project proposals, project plans and various project reports) obtained from the interviewees. Details of the interviews are summarised in Table 3. 5. Case studies 4.1. Participant observation case studies Taylor and Bogdan (1984: 15) describe participant observation as involving ‘social interaction between the researcher and the informants in the milieu of the latter’. The complete participation method used for these case studies enables ‘private’ information to be obtained that would normally not be available through use of interviews or other research techniques. Easterby-Smith et al. The four case studies involved in this study are summarised in this section. 5.1. Case study 1 CS1 was funded by the European Commission. The overall purpose of the CS1 community was to provide critical collaboration Table 2 Interview summaries for participant observation case studies. Case study No. of interviews held Interviewee role Topics of discussion 1 1 Community Owner 1 1 Project Manager Database Administrator General background information, overall strategy and goal, business model, alternative business models, benefits to users Development process, functionality offered, user types, lessons learned Technology chosen, reasons for choice, alternatives researched, most used areas of community 2 1 1 Community Owner Project Manager Database Administrator 2 General background information, overall strategy and goal, business model, benefits to users, lessons learned Development process, functionality offered, user types, lessons learned Technology chosen, reasons for choice, alternatives researched, most used areas of community 300 M. Tickle et al. / Technovation 31 (2011) 296–308 Table 3 Interview summaries for interview case studies. Case study No. of interviews held Interviewee role Topics of discussion 3 2 Community Manager 2 1 Project Manager (community development) Database Administrator General background information, overall strategy and goal, business model, alternative business models, benefits to users Development process, key decisions in development process, functionality offered, user types and privileges, governance strategy, lessons learned Chosen technology, reasons for choice, alternatives researched, development process, functionality offered, Web 2.0 principles, administrative duties, most used areas of community 3 Community Owner 1 2 Community Owner 2 (technical lead) 1 Developer 4 General background information, overall strategy and goal, business model, alternate business models, Development process, key decisions in development process, benefits to users, lessons learned Functionality offered, user types and privileges, governance strategy, lessons learned, chosen technology, reasons for choice, alternatives researched, development process, functionality offered, Web 2.0 principles, administrative duties, most used areas of community Development method (in-house) tools to bring together Public Research Organisations (PROs), Small to Medium Enterprises (SMEs) and Investors (corporate and financial) across 11 European regions. This was achieved by bringing members together via physical events across all 11 regions, creating new business ventures between the parties involved. The VC was developed ‘‘from scratch’’ using a .NET front end and an Oracle 10g database. Although highly scalable and reliable, this technology was not chosen to suit the community; rather it was chosen because the developers were familiar with this technology. The Project Manager highlighted: interaction at events also helped to create trust among members, which was beneficial as members were not sufficiently encouraged to participate within the VC, so most of their collaborations occurred at the events. The VC consisted of a large quantity of ‘Community’ functionality (i.e. tools that allowed members to collaborate online), including a number of Web 2.0 tools such as blogs, discussion forums, document and image libraries, comments and shared bookmarks. Some of the functionality was, however, seen as authoritarian and overly complex, as was explained by the Database Administrator: ‘‘the .NET and Oracle combination is actually more suited for enterprise business systems than online communities’’. ‘‘when you wanted to apply for an event, you had to be approved by two separate people, one after the other. So you might be approved one Administrator, and then rejected by the other. It was very controlling and it just put people off applying’’. The development of the VC was outsourced to a Chinese software development team and strong relationships were formed between customer and supplier, which were very beneficial during the development process. Development was conducted in four ‘phases’, each phase building on the previous in terms of further functionality and improvements. The VC had a large number of highly complex requirements, and cultural, language and time differences between customer and supplier were intensified by the use of online tools rather than face-to-face communication: ‘‘requirements were ‘lost in translation’ and it wasn’t until you received a delivery of the latest phase that you realised that it was wrong’’ (Community Owner). The design of the VC was completed without consultation of the end users, resulting in their opinions and ideas never being catered for and a large amount of the functionality offered was unused by members: ‘‘there were sections of the site that users told us were simply useless – there were sections that benefited us more than they benefited members’’ (Community Owner). The web design of Chinese websites is different from that of European websites, and this confused a number of the European members, as the Project Manager explains: The Project Manager added that these processes also increased the amount of effort required for those managing the events: ‘‘these events were quite popular, so you can imagine how many applications these Administrators were having to process – it just added unnecessary workload’’. The process was similar when users wanted to be upgraded to a ‘Member User’ of the community, thus gaining access to additional functionality and privileges. This issue was further highlighted in the amount of data each user was asked to complete about themselves, with the Project Manager explaining: ‘‘Some forms took far too long to fill in – we’re talking about 5 to 10 minutes per form, and there were at least 3 forms each user had to complete if they wanted to attend an event. We got a lot of complaints about that’’. The level of community management required was also underestimated, with members’ problems and queries not being addressed in sufficient time, further frustrating members: ‘‘We just didn’t have enough people managing the community – we were more interested in getting the next phase of development up and running’’ (Project Manager). ‘‘the interface just felt ‘strange’ to some members – for example, clicking a link on some pages would open the desired page a new window, but with others, the new page opened in the same window. Users became confused. Obviously, this is the usual way of working for Chinese websites, but we just weren’t used to it’’. There was also a distinct lack of a business model, with several ideas being identified but none making it through to fruition. As a result of this and the previously identified factors, the VC was closed down soon after its funding period expired: CS1 had an existing user base, enabling a critical mass of members to be attained instantly. The regular face-to-face ‘‘As soon as the funding ran out, the community effectively ceased to exist’’ (Community Owner). M. Tickle et al. / Technovation 31 (2011) 296–308 301 5.2. Case study 2 5.3. Case study 3 The VC in CS2 was designed for food and drink companies within the North West of England. CS2 aimed to bring together food industry employees and allow them to discuss topics, exchange ideas and attend events together. It also provided members with information such as market intelligence, food research and analysis and food legislation. The VC was similar to that of CS1 in that it was developed from scratch using a .NET front end and an Oracle 10g database. The VC was also developed by the same Chinese development team and used the same phased development approach. Due to this, the strong customer–supplier relationship continued and proved very beneficial for CS2 and the majority of the cultural issues identified in CS1 were eradicated: CS3’s VC was created to develop more leaders and entrepreneurs in the North of England. The community was funded by a number of funding bodies, and was billed as a ‘‘one stop shop’’ for all leadership needs, collating and disseminating leadership best practices and acting as a support tool for individuals and employers wishing to become better leaders. The VC was developed using the proven community platform BEA Aqualogic (now Oracle WebCentre Interaction) which utilises a combination of Java and .NET with an SQL database. This community platform was chosen from a large list of alternatives as the significant amount of ‘out of the box’ Community Functionality available was seen to suit the community’s needs. This out of the box functionality also made the VC look and feel like other communities available at the time, helping to decrease the learning curve for members and speed up user acceptance. The selection of the technology was, however, limited by other means, mainly the short development time given by the funding body, as described by the Project Manager: ‘‘We made sure that we’d learned our lessons with this one – we did the design of the system ourselves’’ (Project Manager). However, due to the similarities in the development method, CS2 did suffer similar problems to those of CS1. Again, the technology was not chosen to suit the community and the phased approach added to the slow and laborious turnaround of new functionality, and although the design had been completed in-house, end users were again omitted from the requirements and design processes: ‘‘Looking back on it, the functionality offered to members was what we thought they wanted – we never actually asked them what they wanted. If we were doing this over again, that’s the first thing I’d do’’ (Community Owner). A large amount of Community Functionality was available, allowing members to interact using a number of tools, and faceto-face interaction between members at events was successful in encouraging business relationships between members. The major problem was an unwillingness to share information between members (mainly because the majority of members had limited experience of using VCs) and as such these members were distrustful of this new technology: ‘‘Looking back, I think the food industry just weren’t ready for this new innovative technology’’ (Community Owner). Due to the nature of the food industry, a large number of members already knew one another before the introduction of the VC and they much preferred collaborating face-to-face rather than through an online community: ‘‘most of the users we spoke to mentioned that they did not need the community to bring them together as they already had their own ‘offline’ community for that. They basically told us that they didn’t need the VC’’ (Community Owner). This highlights Barnatt’s (1998) point that VCs will not be eligible for every business application. The business model for the VC also failed to attract sufficient resources to make the community self-sustainable. Numerous options were identified, and the Community Owners decided to charge members to access the market intelligence. Around 100 licences for this information were purchased, however the takeup from members was very low: ‘‘I think we sold two licences in total’’ (Project Manager). As a result, the Community Owner admitted: ‘‘applying for additional funding to keep the community running was the only real option, but we knew this would be virtually impossible given the amount of money we’d been given originally’’. ‘‘because the project was funded, if we wanted to buy something over a certain amount it had to go through a three month tendering process. We obviously didn’t have three months, so to get around this we had to go with a supplier that was on an approved government list of providers. That dictated to a large extent which piece of software we had to buy. We wouldn’t have bought this software had that restriction not been there’’. The configuration of the platform was outsourced to a UK software development team. The software development team worked onsite and the face-to-face interaction was extremely beneficial—reducing confusion and removing the problem of cultural issues. ‘‘If you have the time, I would recommend in-house over outsourcing development. Our problem was we simply didn’t have the time. But we did have a large sum of money available for development, so outsourcing was a viable option in that sense’’ (Project Manager). Development took the form of an agile methodology whereby changes to the VC were made as and when they were required. This turned out to be very advantageous, as many of the requirements for the VC were constructed as the project progressed: ‘‘I think the agile methodology is very advantageous – you can react in real time and it really helped us over the length of the project’’ (Database Administrator). The combination of utilising a proven platform and an agile development approach together with good relationships with the outsourcing supplier vastly reduced the development times and functionality turnaround. In terms of requirements gathering, the community managers used market research to identify potential end users’ needs, increasing the VC’s relevance to these end users. The content on the community was updated regularly and the VC offered Premium Content (Harvard Manage Mentor, 50 Lessons and Get Abstract) at a fraction of the price available elsewhere. The VC also employed a number of Moderators who actively searched out leadership information in various sectors before sending it to the community managers to post on the site. The community managers continually analysed the community’s offerings through a regular review of functionality, thus enabling the VC to evolve over time to suit its members’ ever changing needs. The registration process was quick and easy, with users only needing to enter their e-mail addresses, so encouraging many to 302 M. Tickle et al. / Technovation 31 (2011) 296–308 register. However it also had a significant shortcoming—each member had limited profile information stored about them, so members could not validate other members’ identities, resulting in a reduced level of trust within the VC. A member contributing to the community is more likely to be accepted if they have an identity—the more clearly that identity is defined, the more readily their contributions will be valued. The opposite is also true, with no identity reducing the level of trust—members therefore very rarely contributed to the VC due to them not trusting other members within the community. This limited participation seriously threatened the success and sustainability of the VC. Although the business model involved charging a membership fee to access various Premium Content at a far reduced rate than it was available elsewhere, the take up was insufficient to keep the community sustainable: ‘‘I think we sold about six memberships for the Premium Content, and eventually we ditched this idea and started to give this content away for free’’ (Project Manager). 5.4. Case study 4 CS4 was the most successful VC out of the four case studies. This VC was designed as a ‘one stop shop’ for knowledge transfer (KT) information and advice for KT professionals across the UK and was self-funded by a social media company specialising in VC development. It is an online resource dedicated to facilitating KT between universities, businesses, entrepreneurs, investors, scientists and KT professionals by bringing them together, allowing them to share best practices and experiences. CS4 also promotes upcoming KT events to its members, allowing them to meet regularly face-to-face. ‘‘There wasn’t an existing community for KT professionals out there are the time, and there was always a need for bringing a KT community together’’ (Community Owner 1). Two large institutions specialising in KT were targeted, and these two institutions now use it as their preferred VC, promoting its use to their members. This enabled the VC to benefit from an existing userbase as well as free marketing to potential members. The VC was developed from a community platform that allowed it to be created in less than one day via a ‘‘software as a service’’ (SAS) model. ‘‘It’s a switch-on process – they set up a new version for us after asking us what we wanted in terms of registration fields, keywords etc. and they then made it available to us over the Internet. All we had to do was configure it by adding our colours and logos. It’s that simple’’ (Community Owner 2). The platform is built from a .NET front end with an SQL database. After a short period of time, the community managers decided to purchase the code for the platform, allowing amendments to be made to the VC using their own in-house development team: ‘‘We wanted to own the code ourselves so we could take the platform forward’’ (Community Owner 1). All future amendments are made in-house using an agile methodology: ‘‘Now, changes are made when we think they need to be made’’ (Developer). The Community Owner also sets the timescales of the development rather than a funding body (as this VC is self-funded) and this allows the Community Owners to do what they think is best for the VC and its members rather than worrying about deliverables. A number of other solutions were analysed before this particular platform was chosen, but the major advantage of this platform was that it allowed a significant amount of functionality to be available ‘instantly’, reducing development time: ‘‘The platform offered the core functionality that we wanted, in super fast time’’ (Community Owner 2). Using this platform also allowed the VC to benefit from a ‘proven’ best practice design, decreasing users’ learning curve and increasing uptake: ‘‘You know that it works before you even get involved – these platforms have been used extensively by hundreds of other customers before us’’ (Community Owner 1). Community spirit is an important factor of this VC, and members are actively encouraged to get involved in all aspects of its development: ‘‘The users come back quite regularly and ask for new functionality or bits and pieces changing. We’re trying to adopt the ‘open’ approach by involving as many people as possible in the community’s activities’’. In consequence, the community is continuously evolving to suite members’ changing needs. Another example of fostering community spirit is the fact that the most pro-active members of the community are rewarded for their efforts by being upgraded to Moderators, who encourage other members to contribute to the VC, ensuring that the content posted is updated on a regular basis and is relevant to the end users. This also lowers the Community Owners’ workload, and even encourages contributions from members: ‘‘this upgrading of members to Moderators has actually acted as a motivation to participate in the VC – everyone wants to be a Moderator now!’’ (Community Owner 2). Although the VC itself does not produce revenues, it has created an interesting business model—the Community Owners now own the code for the community platform, they have begun creating new VC’s ‘on the fly’ for future customers. Using the CS4 VC as a flagship, the business model therefore involves charging new customers for their own communities: ‘‘The VC is hosted in the same place as 40 other communities, most of which are paying us fees for hosting and change requests’’ (Community Owner 1). 6. Results Analysis of the four case studies identified four distinct dimensions that are crucial to the success of a VC—these are culture, technology, resources and Community Functionality. The four dimensions are analysed and discussed in this section. 6.1. Culture The main aspects of the culture dimension are shown in Table 4. The findings indicate that success depends on the willingness of members to share information. CS2 and CS3 show that low willingness to share information results in very limited contribution rates from members. However, having a high willingness to share information does not necessarily increase members’ contributions—although this was the case in CS4, CS1 had members that were initially very willing to interact, but due to various other factors (such as convoluted functionality) their willingness diminished over time. 303 M. Tickle et al. / Technovation 31 (2011) 296–308 Table 4 Aspects of culture dimension. Area CS1 CS2 Target audience size Willingness of target audience to share information with others VC suitable for business application? Existing user base? Successful marketing strategy? Buy-in from Community Owners? Development strategy Outsourced/in-house development Large (worldwide) High Small (North West England) Small (North England) Large (worldwide) Low Low High Yes Yes Yes No Build from scratch Outsourced (China) No No No No Build from scratch Outsourced (China) Development approach Regular review of functionality? Members involved in functionality review? Members’ return rate Majority of content published by Content publishing regularity Members encouraged to participate in community? Recognition for contributing to community? Level of control community managers have over members Detailed member profiles available to other members? Face-to-face interaction between members? Phased No No Low Community managers Low No No Large Yes Yes Phased No No Low Community managers Low No No Small Yes Yes As Barnatt (1998) highlighted, not all business applications are suitable for VCs and CS2 is a perfect example of this. However, just because a VC supports the business application does not necessarily guarantee that the VC will be successful—CS1 had a legitimate reason for using a VC, however it still had low return and contribution rates and ultimately failed once its funding period elapsed. An existing userbase is also important—out of the four case studies CS2 and CS3 had the smallest number of members, due to the lack of an existing userbase. In comparison, CS4 had an existing userbase which allowed it to quickly reach a critical mass of members which were retained by giving them a voice. The results show, however, that having an existing userbase is one thing, but retaining these members is a different matter—CS1 had an existing userbase, but over time the numbers dwindled for a number of reasons. It appears that an existing userbase is important, but will not prove successful if members cannot be retained. A successful marketing strategy is an important factor in attracting new members to the community. CS2 and CS3 had unsuccessful marketing strategies and this added to their failure in attracting new members to the community. CS4 successfully used two large KT institutions to market their community for them, providing a constant stream of new members that continues today. However, CS1 had a successful marketing strategy that regularly brought in new members, but over time its convoluted functionality earned it a bad reputation, reducing the number of new members registering. Having a good marketing strategy is therefore good for enticing new members to register, but without significant benefits, the VC will struggle to retain these members. The findings indicate that buy-in from Community Owners is successful for success. CS1, CS2 and CS3 did not have buy-in and the subsequent insufficient community management led to unsustainable business models. CS4 did have buy-in from its Community Owners and this has been a major part of its success and one of the main reasons it is still in operation today. The study has shown that building a community from scratch is more difficult than using a community platform. Members saw the design of CS1 and CS2 as convoluted and unfamiliar and this resulted in low contribution and poor return rates. Members of CS3 and CS4 on the other hand appreciated the familiar design CS3 CS4 Yes No No No Use existing platform Outsourced (England) Yes Yes Yes Yes Use existing platform Platform purchased, then developed In-house Agile Agile Yes Yes No Yes High High Community managers Members Low High No Yes No Yes Small Small No Yes No Yes and functionality provided by the community platforms. Development time and functionality turnaround were also dramatically reduced by using these community platforms. The findings indicate that using an in-house development team is more successful than outsourcing. CS4’s development (since purchasing the code and developing in-house) is by far the quickest and easiest of the four case studies, with minimal issues during development. By contrast, the two case studies that were outsourced to China (CS1 and CS2) suffered from a lack of control and misinterpretation of requirements—functionality offered by these communities was seen as convoluted and counter intuitive. However, CS3 indicates that outsourcing can still be a viable option—the community managers increased their control of the development process by ensuring that the developers were onsite during development. The results suggest that an agile development approach is more beneficial than a phased approach, as the agile approach supports the ‘‘community evolution’’ principle, with regular changes supporting the ever evolving needs of its members. Members complained about issues in CS1’s design and functionality—the owners attempted to fix these issues, however because of its phased approach, by the time these issues had been rectified, members had already stopped using the VC. In contrast CS4 is still constantly adapting its offerings via functionality reviews with its members and the speed at which members’ ideas can be realised has guaranteed its success. Regular reviews of the VC’s functionality are vital—CS1 and CS2 failed to do this, and members did not see any use for the original functionality. CS3 and CS4 regularly reviewed their functionalities, allowing it to evolve over time to suit their members’ needs. Although CS3’s managers regularly reviewed their functionality internally, they decided not to ask for input from members. In contrast, CS4 did involve members’ opinions in their reviews. This has allowed the community to acquire a large number of loyal, pro-active members who return and contribute on a regular basis, as the functionality on offer is both relevant and useful to them. The findings indicate that member-generated content results in a more vibrant and successful community. Member-generated content is more relevant to other members and increases interaction. CS1, CS2 and CS3 had minimal member-generated content which lead to a stagnant community. CS4, however, had regular 304 M. Tickle et al. / Technovation 31 (2011) 296–308 content published by members, leading to high return rates and attracting new members. Encouragement to contribute and recognition of participation are critical in facilitating member-generated content—CS1, CS2 and CS3 did not encourage their members to participate, nor did they recognise pro-active members’ contributions. In contrast, CS4 encourages its members and recognises contributions by upgrading pro-active members to Moderators. The findings indicate that attempts to control members’ activity results in negativity—CS1’s members were frustrated by the double approval process and because of this many failed to return. The study indicates that member profiles are instrumental in encouraging interaction and trust-building between members. The more clearly a member’s identity is defined, the more regularly their contributions are valued and trusted, encouraging future interaction. CS4 illustrates this with detailed member profiles resulting in high interaction between members. In addition the community managers of CS4 link these profiles with the minimal amount of abuse being found within the community, with members wanting to maintain their professional reputations within the VC. Finally, the findings suggest that face-to-face meetings are important in the development of trust within VCs and should be encouraged. Members are more likely to help each other if there is a chance they will meet each other in the future. CS3 did not promote any such meetings, resulting in members developing ‘lurker’ behaviour, taking the information available and not reciprocating. The lack of face-to-face meetings also resulted in low trust levels, further compounding this lack of contribution. CS4 on the other hand supported regular face-to-face meetings between members and as such trust levels within the community are high, resulting in members frequently replying to each others’ requests for help. 6.2. Technology The main aspects of the technology dimension are shown in Table 5. The results suggest that using build from scratch technologies is more difficult than using a platform technology, highlighted by CS1 and CS2—although these enterprise business system (EBS) technologies allowed for any functionality to be available, as well as excelling in terms of security and reliability, the design of this functionality was convoluted and unfamiliar. The majority of the functionality available was also not relevant to members due to end users not being consulted in the design process. The platform technologies used in CS3 and CS4, however, were more successful, due to the familiar ‘‘out of the box’’ functionality they offered. These platforms also enabled a quicker, more cost-effective development process. The findings indicate that VCs that utilise technologies based on the community’s needs are more successful in fulfilling users’ requirements. Members of CS3 and CS4 found the functionality familiar, relevant and useful to them and they saw a benefit to contributing. The case studies that did not select the technologies based on the community’s needs (CS1 and CS2) were less successful—their functionality was unfamiliar, and irrelevant to members’ needs contributing to members’ increased reluctance to participate in the VC. It is obviously very important, therefore, to search for the most suited technology for the community. A thorough analysis of the various options available enabled the community managers of CS3 and CS4 to find the most suitable and cost effective technology. On the opposing end, CS1 and CS2 missed out on these opportunities, instead using a technology and functionality that they were familiar with, a technology which was not beneficial to the VC. The findings suggest that a re-usable solution does not have any effect on the community itself. However, the re-usability of the CS4 VC created the only sustainable business model out of all four case studies, whereby new VCs could be created that on the fly for new customers with minimum effort. The CS4 business model is successfully being used to date, with 40 other communities utilising this community platform. The complexity of requirements also affects the success of the VC, with highly complex requirements severely reduced the user retention and contribution rates. CS1’s members in particular were frustrated by the amount of time required to learn and use the convoluted functionalities effectively. The complexity also increased development times, further frustrating members with slow functionality turnaround. CS3 benefitted from a much lower requirements complexity, with members being able to access the information they required quickly and easily. In particular, members who have limited experience of using VCs will find it difficult to participate in the community should it feel unfamiliar to them—this is highlighted in CS2, where even though the complexity of the requirements was low, members were still unwilling to contribute. However, it is still possible to encourage these less experienced members to contribute—CS4’s combination of low requirements complexity and the utilisation of familiar functionality proves this. In all three case studies where requirements complexity was low, development times were also severely reduced. The findings indicate that having more Web 2.0 functionality does not necessarily increase member participation—CS4 utilised Table 5 Aspects of the technology dimension. Area/case study CS1 Dot Net with Oracle 10g (build from scratch) Main application of chosen technology Enterprise business systems CS3 CS4 Dot Net with Oracle 10g (build from scratch) Enterprise business systems Dot Net with SQL (community platform) Virtual communities Yes No No Dot Net and Java with SQL (community platform) Enterprise portals/virtual communities Yes No Any No Any Yes Community Functionality Yes Community Functionality No High Large Infrequent No Low Medium Infrequent No Low Small Infrequent Yes Low Large Frequent Chosen technology Technology chosen to suit needs of community? Other technology options considered? Main functionality provided by chosen technology Can the solution be re-used? Requirements complexity Amount of Web 2.0 functionality Frequency of which Web 2.0 functionality used by members CS2 305 M. Tickle et al. / Technovation 31 (2011) 296–308 a large amount of Web 2.0 tools that were used by members on a regular basis, despite the relatively low IT-saviness of its members. This could be due to collaboration being a vital aspect of knowledge transfer, therefore increasing members’ likelihood to exchange information with each other. On the other hand, CS1 also utilised a large number of Web 2.0 tools, but these were used infrequently at best, mainly due to its counter-intuitive design. The design of these Web 2.0 functionalities is therefore an important factor, with the results showing an increased difficulty in designing and building relevant Web 2.0 functionality from scratch as opposed to using a community platform. 6.3. Resources The main aspects of the resources dimension are shown in Table 6. The findings indicate that unnecessary expenditure was made in all three of these case studies financed by grant funding. Communities financed by grant funding also find it more difficult to become self-sustainable after the funding period, with all three grant funded communities failing once the grant funding ran out. CS4, on the other hand, remains in operation to date. The findings also indicate that the community manager’s commitment to the community is higher should the community be financed using their own capital—CS4 was financed this way, and benefitted from increased levels of commitment as well as limited unnecessary expenditure. The findings indicate that it is more beneficial to work to realistic deadlines rather than to deadlines set by funding bodies. CS1, CS2 and CS3 all suffered from rushed development times where sacrifices were made in order to meet deadlines set by the funding body. In some cases, functionality was added that simply helped with the production of the deliverables. The Community Owners of CS4 on the other hand worked to their own, more realistic deadlines, resulting in less mistakes being made during development. The functionality offered was also more relevant to members. For the community to remain self-sufficient, its business model must be successful. As VCs are a relatively new area, very few successful business models have been identified for them. CS4 confirms this—it is the only VC that had a successful business model and as a result is the lone VC still in operation today. The findings suggest that large development teams are required when the community is to be built from scratch. The findings also suggest that larger development teams are required for grant funded communities. Similar to this, the findings suggest that the size of the community management team should be in proportion to the amount of community management required from them. CS1 and CS2 did not have sufficient support for their members, and these VCs suffered as a result. CS3 and CS4 on the other hand had larger community management teams that handled members’ queries and requests and listened to their opinions, allowing these VCs to benefit from increased member loyalty. The findings suggest that Moderators are essential in encouraging participation between members. CS1 and CS2 did not utilise Moderators which further exacerbated the small community management team size issue. CS3 and CS4 utilised Moderators and benefited from frequent content publishing as well as regular member return rates. An interesting question is whether Moderators should be paid for their work. CS4’s Moderators are not paid, but they continue to moderate due to their interest and commitment to the community, which is increased due to the additional responsibility and respect they receive from the community managers. This is obviously the perfect situation, but sometimes Moderators require extrinsic motivation in order to contribute. CS3 highlights this, with Moderators being paid for their contributions. 6.4. Community Functionality The main aspects of the Community Functionality dimension are shown in Table 7. The findings suggest that successful VCs utilise functionality that is both relevant and useful to members. CS1 and CS2 included functionality that members saw as convoluted and unnecessary, resulting in them using the functionality infrequently. CS3 and CS4 made sure that their functionality offerings Table 6 Aspects of the resources dimension. Area/case study CS1 CS2 CS3 CS4 Original funding method Set deliverables and deadlines? Development time determined by Grant funding Yes Deadlines in contract None No Large/large Small/large Grant funding Yes Deadlines in contract Premium Content fee No Large/large Small/large Grant funding Yes Deadlines in contract Premium Content fee No Medium/medium Medium/medium Own capital No Community managers Software as a service Yes Small/small Medium/small No N/A No N/A Yes Yes Yes No Business model Successful business model? Development team size/amount of development required Community management team size/amount of community engagement required by them Moderators used? Moderators paid? Table 7 Aspects of the Community Functionality dimension. Area CS1 CS2 CS3 CS4 Functionality useful/relevant to members? Amount of collaborative functionality Frequency of members using collaborative functionality ‘Killer App’ relevant to and utilised by members? Functionality ‘familiar’ to members? Can community managers edit areas of the community ‘on the fly’? No Large Infrequent Yes (events) No No No Large Infrequent No (market intelligence) No No Yes Small Infrequent Yes (Premium Content) Yes Yes Yes Large Very frequent Yes (groups) Yes Yes 306 M. Tickle et al. / Technovation 31 (2011) 296–308 were relevant and reviewed this functionality on a regular basis. CS4’s community managers even used member input in this process, further increasing the functionality’s relevance. The findings indicate that the level of collaborative functionality affects the frequency with which members interact. CS4 had a large amount of collaborative functionality and benefitted from high contribution and return rates, whilst CS3 had a limited amount of collaborative functionality available, resulting in infrequent interactions between members. The findings indicate, however, that having a large amount of collaborative functionality alone is not sufficient in encouraging participation between members. CS1 and CS2 utilised a large amount of collaborative functionality; however this functionality was convoluted and their members were not encouraged to use it, resulting in minimal interaction between members. The findings suggest that a relevant killer app is essential in enticing potential members to register with the community. CS1, CS3 and CS4 had large numbers of members registering simply to use the killer app. CS2 on the other hand struggled to entice potential members to register as they did not see the benefit or relevance of the killer app on offer. The findings also indicate, however, that a relevant killer app is not sufficient by itself to create a successful community. CS1’s members, for example, used the VC to apply for the events but did not use any of the additional functionality, resulting in minimal interaction between members. CS3’s members acted in a similar fashion, and could be described as lurkers who exclusively accessed the Premium Content but gave nothing back to the community in terms of member-generated content. The findings suggest that functionality familiarity is very important, with familiar functionality being likely to increase the member acceptance rate by decreasing members’ learning curves. The functionality offered by CS1 and CS2 was seen to be unfamiliar and convoluted, leaving members frustrated and reluctant to return. CS3 and CS4’s functionality was much more familiar (due to the use of prove platforms) and this allowed members to perform their tasks quickly and effectively. In fact, the familiarity of CS4 ensures that the majority of the content published on CS4 is published by its members, rather than the community managers or Moderators. The findings suggest that allowing community managers to edit areas of the community ‘‘on the fly’’ is very beneficial to the success of the VC. CS1 and CS2 did not have this feature and as such required each change (no matter how small) to be completed by the development team, frustrating members with unnecessary delays. The community managers of CS3 and CS4 however were able to make minor amendments to their VCs as and when they were required, allowing them to quickly and easily tailor the community to suit the needs of their members. 7. Discussion and conclusions The study has identified a number of findings that contradict existing literature. These findings are shown in Table 8. In addition, the study has identified four dimensions that are central to the successful development of B2B VCs. These include culture, technology, resources and Community Functionality and are illustrated in Fig. 1. In conclusion, the study’s findings indicate a number of interesting factors that play significant roles in the development of VCs. Firstly, the results highlight that culture is the most important of the four dimensions identified. The correct culture encourages Fig. 1. Development cloud for a B2B VC. Table 8 Comparison of the findings of previous studies against the findings of this study. Findings of previous studies Findings of this study Wasko and Faraj (2000) and Ardichvili et al. (2003) suggest that VCs increase the ‘information overload’ effect, whereby members are put off contributing to the community for fear of receiving too many replies to their queries, as well as the amount of time they will have to take in order to validate each of the replies. The findings of this study contradict this belief, with CS4 showing a self-feeding cycle of contributions which are followed by further contributions. In fact, CS4’s members aim to obtain as much information as possible from other members, as this is the whole concept of knowledge transfer. This suggests that the more information posted on the VC the better. Most of CS4’s members do not have prior experience of using VCs; therefore the information overload effect is a prevalent factor in this VC, however the powerful search tools available to members allow them to find the exact information they are looking for with relative ease. If community managers were to attempt to limit the information overload effect, it is likely that the VC would resemble something similar to that of CS1, where limited information is posted on the VC and benefits for all members are lost. Ardichvili et al. (2003) indicated that members of a VC are likely to be put off contributing to a VC for fear of criticism from other members. Although this fear may be present among members, CS4 has shown that such criticism is actually rather rare in these professional VCs, as Community Owner 1 explains: ‘‘I’m actually surprised at how little abuse there is. I think it’s down to fact that it is a professional site rather than a social siteymaybe people feel a bit more responsible for things they post here as opposed to what they would post in Facebook or MySpace’’. Campbell and Uys (2007) believe that any relationships that are established prior to The findings of this research suggest otherwise—CS4’s members use the VC to identify other members that have similar interests and then add them to their the VC emerging can ‘‘hinder the free flowing sharing of ideas and knowledge ‘‘contacts list’’. necessary in a flourishing community’’. They believe this hindrance can lead to a difficulty in new members joining and contributing to the community, and that members will only participate in groups which include members they already know. M. Tickle et al. / Technovation 31 (2011) 296–308 member contributions and return visits which are required to achieve a critical mass of members and therefore creating a flourishing community that is of use to its members. The correct culture also decreases development times and functionality turnarounds. The findings also suggest that the choice of technology is also an important factor, whereby successful VCs utilise community platforms rather than building from scratch. With regard to resources, we have seen that grant funded communities are susceptible to waste and that a sufficiently sized development and management teams are required. Business models are another interesting aspect, with very few being available at the present time due to the innovative nature of VCs. Finally, we have seen that functionality that is both useful and familiar to members is imperative to the success of the VC. As mentioned previously, a structured, rigorous development methodology based on academic research is required in order to successfully create and manage VCs. It is apparent that there is no ‘‘one size fits all’’ method for developing VCs and therefore the possibility of a roadmap of decisions would be an interesting place to start. Future research into this area would be of interest. Industry practitioners wishing to create and manage their own VCs should take heed that this task is not an easy responsibility. In fact, one of the study findings is that the main challenge in creating successful VCs is not that of developing them, but that of increasing member participation and return visits. It is therefore essential that industry practitioners remove the many obstacles and barriers associated with member contribution. They must also avoid ‘micro-managing’ the community, as VCs do not respond well to being managed in this way, with excessive rules and regulations turning members away (Muller-Seitz and Reger, 2009). This study also has implications for future research. The study has shown that culture is the most important dimension of the development of a B2B VC, and it is therefore important to carry out research to investigate the way in which culture is created. In addition, future research can investigate the relationship between the four dimensions of B2B VC development identified in this study. Finally, it is important to highlight the limitations of the study. Of the four case studies selected, only a selection of participants were interviewed. Future analysis into a larger number of successful VCs would lead to a more beneficial insight into success strategies and methods of overcoming the obstacles highlighted in this analysis. Although this study identifies that a structured, rigorous development method based on academic research is required in order to create and maintain successful VCs, such a development method is not presented here. This will be the subject of future research by the authors. References Adamides, E.D., Karacapilidis, N., 2006. A knowledge centred framework for collaborative business process modelling. Business Process Management Journal 12 (5), 557–575. Adebanjo, D., Michaelides, R., 2010. Analysis of Web 2.0 enabled e-clusters: a case study. Technovation 30 (4), 238–248. Ardichvili, A., Page, V., Wentling, T., 2003. Motivation and barriers to participation in virtual knowledge-sharing communities of practice. Journal of Knowledge Management 7 (1), 64–77. Barnatt, C., 1998. Virtual communities and financial services—on-line business potentials and strategic choice. International Journal of Bank Marketing 16 (4), 161–169. Benbasat, I., Goldstein, D.K., Mead, M., 1987. The case research strategy in studies of information systems. MIS Quarterly 11 (3), 369–386. Bjork, J., Magnusson, M., 2009. Where do good innovation ideas come from? Exploring the influence of network connectivity on innovation idea quality. Journal of Product Innovation Management 26, 662–670. Burgess, R., 1984. In the Field: An Introduction to Field Research. George Allen and Unwin, London. 307 Campbell, M., Uys, P., 2007. Identifying success factors of ICT in developing a learning community—case study Charles Sturt University. Campus-Wide Information Systems 24 (1), 17–26. Case, S., Azarmi, N., Thint, M., Ohtani, T., 2001. Enhancing E-communities with agent-based systems. Computer 34 (7), 64–69. Chiu, C., Hsu, M., Wang, E., 2006. Understanding knowledge sharing in virtual communities—an integration of social capital and social cognitive theories. Decision Support Systems 42, 1872–1888. Chesbrough, H., 2003a. Open Innovation: The New Imperative for Creating and Profiting from Technology. Harvard Business School Press, Boston. Chesbrough, H., 2003b. The era of open innovation. MIT Sloane Management Review 44 (3), 35–41. Dahlander, L., Gann, D., 2007. How open is innovation? In: Proceedings of Druid Summer Conference. Copenhagen, Denmark. pp. 18–20. Dodgson, M., Gann, D., Salter, A., 2006. The role of technology in the shift toward open innovation: the case of Proctor and Gamble. R&D Management 36 (3), 333–346. Easterby-Smith, M., Thorpe, R., Jackson, P., 2008. Management Research third ed. Sage, London. Hagel, J., Armstrong, A., 1997. Net Gain: Expanding Markets Through Virtual Communities. Massachusetts, Harvard Business School Press. Harrison, T., Zappen, J.P., 2005. Building sustainable community information systems: lessons from a digital government project. ACM International Conference Proceedings 89, 145–150. Hartley, J., 2004. Case study research. In: Cassell, C., Symon, G. (Eds.), Essential Guide to Qualitative Methods in Organizational Research. Sage, London. Huizingh, E., 2011. Open innovation: state of the art and future perspectives. Technovation 31 (1), 2–9. Kafouros, M.I., 2006. The impact of the internet on R&D efficiency: theory and evidence. Technovation 26, 827–835. King, N., 2004. Using interviews in qualitative research. In: Cassell, C., Symon, G. (Eds.), Essential Guide to Qualitative Methods in Organizational Research. London, Sage. Koh, J., Kim, Y., Butler, B., Bock, G., 2007. Encouraging participation in virtual communities. Communications of the ACM 50 (2). Kohler, T., Matzler, K., Füller, J., 2009. Avatar-based innovation: using virtual worlds for real-world innovation. Technovation 29 (6–7), 395–407. Kubicek, H., Wagner, R.M., 2002. Community networks in a generational perspective: the change of an electronic medium within three decades. Information, Communication and Society 5, 291–319. Kvale, S., 2007. Doing Interviews. Sage, London. Lorenzo, O., Kawaleck, P., 2004. A model enterprise system infusion. In: Proceedings of the EUROMA 2004: Operations Management as a Change Agent, INSTEAD. Mention, A., 2011. Co-operation and co-opetition as open innovation practices in the service sector: which influence on innovation novelty? Technovation 31 (1), 44–53. Michaelides, R., Kehoe, D., 2007. Internet communities and open innovation: an information system design methodology. In: Proceedings of Sixth IEEE International Conference on Computer and Information Science (ICIS). Melbourne, Australia. 11–13 July 2007. Muller-Seitz, G., Reger, G., 2009. Is open source software living up to its promise? Insights for open innovation management from two open source softwareinspired projects. R&D Management 39 (4), 372–381. Muller-Seitz, G., Reger, G., 2010. Networking beyond the software code? An explorative examination of the development of an open source car project. Technovation 30 (11–12), 627–634. Orlikowski, W.J., 1996. Learning from notes: organisational issues in groupware implementation. In: Kling, R. (Ed.), Computerization and Controversy. Academic Press, New York, pp. 173–189. Osterloh, M., Frey, B.S., 2000. Motivation, knowledge transfer and organisational forms. Organisational Science 11 (5), 538–550. Preece, J., 2000. Online Communities: Designing Usability, Supporting Sociability. John Wiley and Sons, Chichester, England. Sands, M., 2003. Integrating the Web and e-mail into a push–pull strategy. Qualitative Market Research: An International Journal 6 (1), 27–37. Stuckey, B., Smith, J.D., 2004. Building sustainable communities of practice. In: Hidreth, P., Kimble, C. (Eds.), Knowledge Networks: Innovation through Communities of Practice. Idea Group, Hershey, PA. Taylor, S.J., Bogdan, R., 1984. Introduction to Qualitative Research Methods: The Search for Meanings second ed. Wiley, New York. van de Vrandea, V., de Jong, J.P.J., Vanhaverbeke, W., de Rochemont, M., 2009. Open innovation in SMEs: trends, motives and management challenges. Technovation 29, 423–437. Voss, C., Tsakriktsis, N., Frohlich, M., 2002. Case research in operations management. International Journal of Operations and Production Management 22 (2), 195–219. Wasko, M., Faraj, S., 2000. ‘It is what it does’: why people participate and help others in electronic communities of practice. The Journal of Strategic Information Systems 9 (2–3), 55–173. Wasko, M., Faraj, S., 2005. Why should I share - examining social capital and knowledge contribution in electronic networks of practice. MIS Quarterly 29, 35–57. Wenger, E., 2004. Knowledge management as a doughnut: shaping your knowledge strategy through communities of practice. Ivey Business Journal /http:// www.iveybusinessjournal.com/article.asp?intArticle_ID=465S. Wenger, E., White, N., Smith, J., Rowe, K., 2005. Technology for Communities, http://www.ewenger.com/pub/index.htm. 308 M. Tickle et al. / Technovation 31 (2011) 296–308 Williams, R., Cothrel, J., 2000. Four smart ways to run online communities. Sloan Management Review 41, 81. Wu, S.-C., Fang, W., 2010. The effect of consumer-to-consumer interactions on idea generation in virtual brand community relationships. Technovation 30 (11– 12), 570–581. Yin, R., 2009. Case Study research: Design and Methods fourth ed. Sage, Thousand Oaks, CA. Yeow, A., Johnson, S., Faraj, S., 2006. Lurking: legitimate or illegitimate peripheral participation? In: Proceedings of International Conference on Information Systems. Milwaukee, WI. pp. 967–982.