Abstract
The execution of globally distributed information technology service projects (GDITP) by globally distributed teams, while inherently complex, offers the advantages of swift implementation and seamless service delivery to global clients. The numerous challenges including the intangibility of customer specifications, the iterative nature of information technology (IT) activities and coordination difficulties arising from diverse teams contribute to complexity in managing these projects. Moreover, the organizational complexity is compounded by competing power centres, turning project delivery into a politically contested process.
In traditional projects such as construction or customized manufacturing, overcoming aforementioned challenges through strong top-down leadership is typical in many time-bound projects. However, in the realm of IT projects, which are inherently people-centric, enforcing a command-and-control environment is challenging. Communities-of-practice (CoP) offer an alternative structure that engages highly skilled employees in a collaborative community, navigating the challenges posed by IT projects. Our study explores this innovative approach, focusing on a product firm effectively leveraging CoPs to successfully execute global service projects.
Delving into the functioning of CoPs, our research illustrates how they scale up using both formal and informal networks to meet diverse global customer requirements. Despite operating globally, CoPs exhibit emergent collective mindfulness, adapting tools, processes and products to the demands of the projects. The study also details how the organization manages complexity while adhering to product architecture and a uniform project framework.
Keywords
Our research provides insights into the interactions within CoPs and how they operate in a projectized environment with globally dispersed members of varying cultural backgrounds and competencies. The paper emphasizes the critical role of community-driven gradual formalization, utilizing tools for governance and compliance with public identification of achievements/failures, fostering individual accountability. The study highlights the value of the coexistence of formal and informal CoPs, showcasing them as a potential buffer against attrition-induced knowledge loss and discontinuity.
In conclusion, our case study illustrates the significance of CoPs in providing organizational resilience and ensuring continuity inthe face of attrition, making them a valuable asset inmanaging the complexities of GTIDP.
Project delivery via globally dispersed teams is de rigueur in information technology (IT) service projects, promising faster implementation and uninterrupted service. Globally dispersed information technology projects (GDITP) represent multiple challenges due to the intangibility of customers’ specifications, the iterative nature of IT activities and coordination challenges due to multiple teams with different backgrounds (Stray & Moe, 2020). Unresolved, these differences often lead to low trust and a breakdown in communication, ending in project disruptions (Daim et al., 2012).
Product-based project companies represent an important subset of IT firms. Relying on proprietary products, they cater to a project portfolio comprising global projects with heterogeneous expectations. Glitches due to variations in scope require rapid solutions. While formal team-based structures, with modularized project deliverables with tidy boundaries amongst project teams, customers and suppliers (e.g., Albrecht & Spang, 2014), supported by extensive project management and knowledge management tools, have promised successful project delivery along with rapid solution-development, the key to managing interactions successfully to achieve project-success has long eluded project managers (Dasí et al., 2020; Sosa et al., 2004).
In contrast to formal teams, working within module boundaries and coordinating via both formal and informal channels, CoP represents an alternate organizational structure. Exemplifying a different paradigm of ‘groups of people informally bound together by shared expertise and passion for a joint enterprise’ (Wenger & Snyder, 2000), CoPs deliver by harnessing the collective tacit knowledge existing therein (Amin & Roberts, 2008). However, cases of failure in implementing CoPs, for example, as researched by Venters and Wood (2007), point out the need for further research to understand the challenges of successful implementation of CoPs.
Dispersed interdependent teams in GDIT, coordinating and collaborating towards the resolution of complex problems in delivering a complex artefact, makes them an ideal setting to research CoP. Making it even more attractive as a research problem is the iterative nature of IT projects accompanied by relatively greater intangibility, as compared to civil or manufacturing projects, predisposing it to multiple conflicts arising out of differing worldviews of the stakeholders. While knowledge sharing in project organizations has been studied (e.g., Dingsøyr et al., 2018), the manifestations of knowledge sharing in a CoP have rarely been explored within the context of a GDITP in a product-based service organization.
In this paper, we present our case study of a software product-based project company delivering services to global customers via a combination of on-site project teams and off-site teams dispersed across three continents working as a CoP. Our research details how the organization has been able to manage this complexity while retaining fidelity to the product architecture and compliance to a uniform project architecture. Our study also provides valuable details of the interactions within the CoP and how the CoP operated in this projectized environment despite having globally located members, with different cultural backgrounds and levels of competencies. Our paper highlights the critical role of community-driven gradual formalization using tools for governance and compliance to community norms with public identification of achievements/failures, driving individual accountability, and highlighting the value of coexistence of formal and informal CoPs.
LITERATURE REVIEW
Limiting our literature review to the context of globally dispersed projects, we present it in the following three parts: (a) challenges in IT projects, (b) globally dispersed working and (c) CoP.
Challenges in Information Technology Projects
The numerous factors contributing to the failure of IT projects are scope changes, scope-creep, challenges in the rapid development of new features due to the emergence of competitors’ new products, customer’s inability to define or clarify existing workflows along with the inability to articulate precise requirements (e.g., Lyytinen & Hirschheim, 1987; Yeo, 2002). Customer’s opportunistic behaviour (Chaudhry, 2020), along with ambiguously stated expectations of the customer (Yeo, 2002), also increases the iterations before convergence between the customer’s expectations and project deliverables is achieved. Implementation of less-than-robust algorithms, hasty patches and bug-fixes commonly resorted to during the project implementation phase by the implementation team come to the fore during project-support (Aanestad & Jensen, 2016).
Product-Based Project Organizations
A product-based project company witnesses dynamic tensions between project managers willing to tailor the product to achieve project closure and the product architect striving to preserve the product from morphing into an unmanageable entity due to multiple additions/alterations. While software configuration management emerged as a subject since the work by Bersoff (1984), the dynamics of maintaining fidelity to product architecture in global IT project-based service firms operating with multiple power centres has witnessed less research.
Incorporate Local Art or Retain Fidelity to Product Strategy
Utilizing a proprietary product’s architecture to deliver dissimilar project charters, each bringing its idiosyncratic uncertainties, requires sophisticated organizational capabilities and organizational learning (Whyte et al., 2016). This challenge can be resolved either by creating customer-specific solutions and creating an interface with the core product without disturbing the product architecture, or, by assimilating modifications within the product and living with ever-expanding product architecture, a frequent occurrence of which can stretch organizational technical and managerial capabilities (Kidd & Burgess, 2010)
The system architect’s perspective differs radically from that of the project manager. Responsible for retaining the competitiveness of the product by incorporating new features, the system architect is also responsible for ensuring the reliability of an ever-increasing complex product. Arguably, incorporating project-driven customizations should make the job of the system architect easy, as different project teams offer new ideas.
However, the features and suggestions from project teams add to the dilemma of maintaining the product on the planned product trajectory and avoiding ad hoc additions creating undetermined vulnerabilities.
Globally Dispersed Working
Within the context of GDITP, iterative collaborations among various stakeholders play a crucial role in successful outcomes (Daim et al., 2012; Henderson et al., 2016). The absence of a shared worldview renders fruitless or brings in inefficiencies in the interactions amongst software architects, technology specialists, customers and domain experts, at an organizational level and a project level. Convergence to a common worldview regarding the project, or a problem, the approach to be adopted for developing a solution and its implementation, is a difficult proposition, with geographically and temporally separated teams of experts with different nationalities and experiences since trust on their global counterparts is often in a nascent stage (Xu et al., 2020).
For any project company, a common project architecture can end up as a contested space. For global support teams, creating uniformity in project implementation and supporting knowledge-recycling (Walsh & Ungson, 1991) a common project architecture forces the project teams to conform to its requirements to meet diverse customers’ requirements. Faced with strict deadlines, many project managers would like to allow their teams to develop rapid and often idiosyncratic solutions. The project charter, the contract, its unequivocal penalties and possible negative performance appraisals create a projectized environment for all involved. While such solutions allow the project managers to successfully deliver the project charter, the idiosyncratic nature of the solutions presents challenges for other teams, particularly the maintenance teams. To add to the challenge of meeting deadlines, system architects act as the final gatekeepers, with the power to veto a specific solution to protect the product from insecure customizations. The challenges arising out of such contested space and the craft nature of solution development lead to a search for veterans as sources of knowledge, conversant about solution-archetypes implemented in earlier projects and the successes and failures thereof. Boundaries and official communication protocols between different teams tend to break down as people seek out experts embedded within departments possessing such knowledge (Tsoukas, 2002).
These interactions form the nucleus around which networks flourish. When supported by favourable conditions, these networks evolve into communities with hierarchies, norms, conventions, embodied understandings and shared world views (Dietrich et al., 2013). Multiple interactions and socializing between teams and individuals (Ariño et al., 2001; Smith & Blanck, 2002) foster trust and rapport upholding the community. Actors, despite being driven by their objectives, remain embedded in multiple networks (Stjerne et al., 2019) within these communities identifying with the community so long the benefits of belonging to and identifying with the community accrue.
Communities of Practice
A product-based project organization typically tends to have multiple projects worldwide, with project teams and support teams operating virtually, trying to meet customer’s requirements while ensuring quality standards. A successful product-centric project company could be driven by a structure that would fall somewhere between strong formal teams or a community of practice (Wenger & Snyder, 2000), both with strong integrating mechanisms (Lawrence & Lorsch, 1967). Outcomes at the GDITP level can be understood in terms of underlying actions, interactions and characteristics of either (a) formal teams, complying strictly with protocols, or (b) organizational members engaging and interacting as CoP.
Initially conceptualized as informal collectives and differentiated from formal teams with members willing to ‘share their experiences and knowledge in free-flowing, creative ways’, CoPs possess an ‘organic, spontaneous and informal nature’ (Wenger & Snyder, 2000). As observed by Rennstam and Kärreman (2020), members typically converged around technological objects transcending formal work groups, often substituting peer review for formal leadership.
CoPs seem to emerge and operate in two distinct manners. Emerging organically with organizations acknowledging their existence and utilizing their capabilities seem to be significantly different from the alternate approach wherein CoPs are created due to top-down directive of the leadership (e.g., as researched by Venters & Wood, 2007). Creating structures like ‘governance committees’ and ‘sponsors’ (Probst & Borzillo, 2008) without an explicit need or organizational challenge shared by the collective mind of a core group seems to lead to failures. This also emerges as a gap in the current understanding of CoPs. A potential area of research could be identifying the differences in impact between CoPs evolving organically due to interactions between experts in a domain/technology versus those which are established due to top-down organizational directives.
The existence of problems requiring time-bound resolutions, sine qua non in knowledge-based projectized industries, provides the necessary impetus towards networking and seeking out knowledge. This proactive ‘participation in networks’ (Mischen, 2015) by employees leads to the creation of informal structures, languages and artefacts, forming the nucleus for an emerging community. The multitudes of informal and formal networks within CoPs, bridging problems with experts (Amin & Roberts, 2008), overcome organizational complexity (Lesser & Storck, 2001) in a manner that formal organizations with formal communication protocols would find hard to replicate.
What is the nature of interactions in a globally dispersed team that leads to successful project completion is an area with limited research. Aside from the case of failure of CoP in the British Council, as researched by Venters and Wood (2007), we did not find much evidence of CoP in product-based IT services organizations. It is only when a critical mass of repeated social interactions has been reached that organizations witness the emergence of a common language for the involved actors (Sablis et al., 2021). There is a concomitant increase in gainful collaborations and perceptions of interpersonal justice and trust (Lee & Choi, 2003) that nascent social networks coalescence into CoP, where members trade knowledge and expertise (Su, 2021). The implementation of structures like governance councils or technological platforms like digital forums or dashboards, etc., by organizations provide the formal links to organizational hierarchy and processes, thus collectively contributing towards necessary social ecology (Gupta & Govindarajan, 2000). These mutually reinforce to create effective and efficient channels of collective memory in an organization.
For a product-based organization catering to globally distributed customers via globally dispersed project teams, we explore two research questions. In contrast to organizations working with multiple project architectures (e.g., Klessova et al., 2020), to leverage on previous learning curves, a product-based project organization aims to replicate a uniform project architecture for rapid and quality delivery of respective project charters. Allowing diverse project architectures would render a global back-end inoperable. This brings us to the following research questions:
What factors encourage the emergence of CoP in a GDITP organization? What role does projectized CoP have on the performance of projects?
Employees in different teams bring their worldviews, as reflected in their understanding of problems, the conceptualizations of solutions and implementation. In geographically dispersed teams, the absence of direct communication either prevents a common worldview from emerging, or more effort and iterations for the common worldview to form. Agreement on goals, however, does not eliminate process-based conflicts, which requires high emotional intelligence among virtually located team members to negotiate and achieve consensus. Interactions ensuring rapid handover between multiple virtual teams to deliver time-bound solutions would require adherence to community-accepted artefacts (Latour, 2004), or top-driven formal governance structures. This raises the following research questions:
How does a projectized CoP resolve conflicts to deliver solutions to complex problems despite multiple constraints arising out of multiple stakeholders? What role do the tools play in conflict resolution within GDITP organization?
RESEARCH METHOD
Case Study Method
To understand the phenomenon in depth, we studied a product-based project organization, enforcing uniform project architecture while delivering multiple project charters through globally dispersed teams. We adopted the abductive method of the case research study (Dubois & Gadde, 2002), allowing us to engage pre-existing theories to guide our exploration of this complex phenomenon.
Research Setting
Orion is a leading provider of industrial hardware, software and global services. Orion’s projects typically involve developing customized solutions for Fortune 500 companies, with many projects in build-own-operate mode. Over time, as customer companies moved to outsource management of IT infrastructure, the percentage of build-own-operate projects have increased, thus making Orion responsible for managing and maintaining IT facilities, including projects post-implementation. Orion delivers its solutions using Stern OS, its proprietary operating system.
Orion India, a fully owned subsidiary of an American IT firm, was established in 1995. Orion’s India Engineering Centre (IEC) commenced operations near the end of 1998 and was formally launched in May 1999. Figure 1 presents the organizational structure.
Stern Sustenance Group
Stern OS is a high-end proprietary operating system developed by Orion, often installed on servers and high-end workstations as part of a complete solution. The sustenance activities, that is, involving work specific to the operating system, are carried out at different geographical locations to provide year-round 24×7 support.
Sustenance Centre in India
The Stern Sustenance Group started in California to support Stern. With global operations, there was a need to expand thegroup globally to provide services to customers in different timezones. The initial expansion included setting up in the U.K., then France and Germany, and subsequently India. During theinitial days of the Indian centre, teams of engineers spenttime in the U.S. and U.K. centres toget to know the organizational processes and get a feelof different cultures.
DATA COLLECTION PROTOCOL
Interviews with respondents, observations of project work, including virtual project conferences and documents shared by respondents formed the primary sources of data. Respondents selected by snowballing provided the fundamental data for this study. Data from observations as non-participative observers and documents were primarily used for validation. Respondents for this study were limited to employees operating from Bangalore. Members of top management, project managers and team members belonging to different software development and sustenance teams formed the respondent pool. All interviewees were engineering graduates, and some were postgraduates in computer science. Most of the project managers were senior engineers promoted to the role with more than 10 years of work experience in developing code and managing teams. Table 1 shows the respondent profile in brief.
Brief Description of Respondents.
The sample has been selected via snowballing to have a representation from each category of teams. Years of experience do not directly correlate to organizational hierarchy due to the influence of other factors like educational background, career movement across organizations by employees, performance appraisal, idiosyncratic negotiations by employees based on their skillsets and experience at time of joining, nature of experience, etc. Some employees preferred to stay in the technical domain while others moved to project management roles, due to their personal preferences. As is common in most knowledge-based industries, expertise in a domain or technology does not necessarily translate to years of experience in a proportional manner. Many subject matter experts, limiting themselves to technical work, have significantly less experience than project managers with broad-based managerial experience. Interviews were guided by the following questions:
How are different project activities managed? How were different activities coordinated? What kinds of coordination mechanisms have been put in place? How effective were project management tools and techniques? All interviews were conducted at the project sites and each lasted for more than an hour on average. Going to the sites also helped the researcher understand the work environment. Some interviewees substantiated their points by relating them to electronic documents discussed with the researcher, which would not have been possible otherwise. Data were collected until data saturation (Strauss & Corbin, 1997) was reached.
DATA ANALYSIS
Data were analysed using thematic analysis with constant comparisons across respondents (Strauss & Corbin, 1997). Each line, phrase, sentence and paragraph from the transcribed interviews and field notes were reviewed to decide the concepts the data reflected. The in vivo codes allowed us to identify lines of the transcript that required further analysis. Codes were compared with each other for similarities, differences and to determine general patterns. Using the constant comparative method, Level 1 codes were condensed into categories or Level 2 codes. Annexure 1 provides the preliminary theory developed in parallel with data coding. Causal diagramming to represent theories is a widely accepted practice (e.g., Perlow et al., 2002) facilitating concise representation of complex situations, including behaviours of different stakeholders. Developing the article after forming the initial theory allowed us to develop a theoretically sensitized document (Engwall, 2003).
RESULTS
To capture the dynamics within multiple networks in product-based project organizations, we extensively adapt the framework proposed by Klessova et al. (2020), bringing together the formal and informal mechanisms of project management in GDITP (refer Figure 3).
Project management tools and process bible represent artefacts that have evolved and are accepted by the community, bridging multiple actors in the organization. Without the necessary directive for streamlining the activities, which commenced as ad hoc, informal and individual-specific, these bridging mechanisms would have been rendered defunct. This streamlining of activities was guided by who we term a process sponsor (contrasted to the project sponsor of Breese et al., 2020). The role of the sponsor, enacted by the director, is mandated to ensure that the bridging processes are not circumvented. How different actors interacted to deliver multiple projects is depicted in Figure 3. We present the case in the following sections organized thematically. Critical events that led to the successful delivery of projects and internal developments that led to the establishment of a CoP are presented in this case study.
PROJECT DELIVERY
Issues faced during project implementation and problems arising from existing implementations are handed over from one centre to another in a relay-race format, establishing the daily rhythm. Teams engage with the problem on a real-time basis, trying to understand the nature and magnitude of the problem, and providing solutions within the daytime. As the clock moves ahead, the problem and the solution developed is handed over to the next service team, that is in the daytime.
Solution Development as a Political Process
Working on the initial solution towards proof-of-concept and fine-tuning the solution till satisfactory resolution via geographically dispersed actors is easier said than done. Differences in understanding the problem, its impact on the overall installation and the initial solution-framework received from the previous centres make the ground ripe for conflicts to emerge.
The inherent social hierarchy within the community, that is, within the system architect network and solution network, colours each member’s approach towards the problem the solution, and each other. A position in the network of system-architect, in charge of product development is an aspiration for many IT professionals vis-a-vis being a member of solution developers team. Often referred to unflatteringly as maintenance teams, solution developers have a tough time convincing their contemporaries in system architect teams about the validity and value of their solutions. Solution developers’ position as subordinate to the system architect is indicated and reinforced by mandatory scrutiny and an obligatory sign-off by the system architect before their solutions are accepted.
The establishment of the process bible and project management tools, with their strong emphasis on documentation, levelled the playing field in a way. A problem highlighted by the solution developer and labelled inconsequential by system architects is now documented with reasons provided by the involved actors. A re-emergence of the problem from a different customer would display the inability of the system architect to understand the value of suggestions offered by the solution developer. As one solution developer informed,
Earlier, the solution developer would develop a patch and forward it to the project team to incorporate it. So, when the projects were handed over to the maintenance teams, it was observed that a single problem has multiple solutions, each with its own logic. Some of these patches were unstable and were creating problems for other modules when interfaced with the other modules of the software. Many people in project team as well in solution team would get into this mode due to pressures from project managers. We had massive problems in maintenance of such implementations, as often, modifying the code of these patches had spillover issues. It would be a nightmare as it could put to risk the entire installation as implemented for a client. And the funniest part, no one knew who had done what, and why. What was the logic used was documented in an elementary, almost in a sketchy manner as an afterthought. …today everything is archived, the issues, the questions raised, and replies given, the acceptance or rejection of the reply, with supporting reasons. Earlier my suggestions could be brushed aside, without adequate reason.
Logging issues in the project management tools brought in an unprecedented level of visibility and accountability. Historically, issues raised were accompanied by sketchy evidence of software failure, often in the form of screenshots or forwarded emails of customer reporting glitches, without sufficient contextual data. Solution developers were often caught between two conflicting stakeholders—the project heads and the system architects. They were often the scapegoats when projects got delayed or when solutions failed. Directed by the sponsor, solution developers, the lowest in the social hierarchy, were empowered to resist dictates from people up the organizational hierarchy, like project managers, to circumvent the required detailed documentation. Transparency and traceability fostered by the tools changed the mindset of different actors. As reported by one respondent,
…if a project failed, the tool showed the trail identifying all who were involved. So, one cannot play safe within the system. I must either resolve the problem, or, log in the reasons which prevented the solution, and better, come up with alternatives so that the customer issue is settled. Saying that it cannot be done and sitting tight would identify me as someone who cannot innovate.
An idea proposed and incorporated into the product signified the competence of the solution developer in the internal and external network. A corpus of such ideas, proposed and successfully implemented, not only boosted the confidence of the solution developers but also enabled them to break the glass ceiling and become a system architect. Formalized, such a practice also benefited the company in recruiting solution developers, touting the possibility of career shifts into the socially desirable role of system architect. For many, it was a way to get into higher positions in competing IT firms.
On the flip side, a project team’s interest in pushing a patch to the programme to passing on local issues as central issues to the system architect, made managing future versions of the product more difficult. The challenge between a genuine add-on, which will give a strategic edge over competing programmes, versus incorporating a patch which might create spillover problems is an uncertain zone for system architects. Each product update makes the product more complex. There are possibilities of unknown problems, which might, in a worst-case scenario, bring a global customer’s operations to a grinding halt.
The dilemma faced by the system architect comes to the fore when a project-specific patch, developed by the project team gets implemented locally after being disallowed to be incorporated into the product by the system architect demonstrates superior functionality than the existing product. The transparency regarding such episodes ensures, especially when repeated, doubts about competence are noted. Such community-driven scrutinizing has ensured a high level of professionalism, a kind of, in the words of one respondent, ‘doing one’s homework thoroughly'.
System Architect—A Villain or Guardian of the Code
System architect nomenclature collectively represents the multiple teams responsible for maintaining the product. Different modules of the operating system have teams, for example, printer drivers would have a dedicated team, etc., responsible for that piece of software. A glitch-free software creates loyalty to existing code, particularly in large, complex operating systems. To avoid catastrophic failures, updates follow the product architecture strategy, implemented typically with progressively updated software code with rigorous quality control.
System architects function as gatekeepers, guiding locally developed patches to undergo integrity checks for identifying potential conflicts with existing modules. This process not only safeguards system integrity but also ensures that product updates align with the overarching product architecture strategy. With an increase in the number of customers leading to increased suggestions/local solutions/patches, the processes had to be updated. The update included transparent purposive questioning to prevent large-scale stonewalling of the requests by system architects, and an unqualified acceptance of all requests. Since the system architects were involved in approving the patches, it enforced a hesitant and cautious ownership on the part of system architects for locally developed solutions.
Purposive Questioning
The engagement of the system architect with the requests and the manner of questioning was documented on forums supported by project tools. This allowed the entire collective of organizational members to understand the line of questioning adopted, and critiques raised along with supporting technical analysis, attracting ideas/ suggestions from other members. Ideas ranged from what competitors included in their products, how certain technical challenges could be overcome, and what had been implemented in earlier projects. As reminisced by Sanjeev, a senior engineer,
The debates on the forums engaged in attracted lot of attention. You had to be careful about what to write and how to articulate it, so that it was project-oriented/technology-oriented discussion. Criticism targeting individuals, and not the work/technology attracted censure, while creating a legacy that was not good for future interactions. A good input to the discussion furthered your reputation.
The changes in the process and a greater involvement of the community network, ensured a collegial resolution of problems, preventing conflicts among actors. Project managers also used this data to understand the status of different requests/issues and understand the effectiveness of the team members in resolving a messy bug.
Problem Analysis, Prototyping and Development
A project team attempts to resolve a newly identified problem using an existing knowledge base. If the problem is beyond the local knowledge-base or capability pool, the problem is referred to the Enterprise Service Group, which would oversee the root-cause analysis to determine the source of the bug (e.g., application, specific hardware driver, Stern OS). The project management tools included a community scoreboard, highlighting problem-solvers and their successes and failures.
Good problem-solvers sought out inputs/feedback from the community. Other actors chipped in by engaging in stress-testing, testing for compatibility, pointing out vulnerabilities, etc., providing evidence of collective mindfulness. Figure 4 elaborates on the exchanges during the development of a solution, which can either be a local patch or a modification of the product architecture.
Negotiated Interactions Between Two Organizational Sub-Networks.
Emergence of Community of Practice
Our paper, by providing a window to ‘the unique, interactional, and collective effects that are not only additive but also emergent’ (Barney & Felin, 2013, 4), deepens our understanding of CoPs. CoPs have traditionally been conceptualized as an informal collection of professionals or experts in a guild-like fashion within an organization, with its language and subculture not visible in the formal organizational structures and processes. Our paper, for the first time, illustrates how leaders can guide the development of tools and processes that can engage the CoPs, allowing the organization to leverage the collective capabilities of CoPs. Earlier interactions implied personal emails and telephonic discussions akin to localized and personalized networks. Knowledge about successful contributions was limited to a handful of the organizational members, as was the presence and identity of subject matter experts and solution developers. Projectized problem solving utilizing IT platforms reorients traditional CoP that ‘may or may not have an explicit agenda’ (Wenger & Snyder, 2000) to employees as engaged actors taking on challenges, working collaboratively with other actors towards rapid problem analysis and solution development. The erstwhile inconspicuousness was radically replaced by extensive visibility, noticeable to all organizational members.
From Network to Community and Emergence of Cultural Artefacts
Guiding the multiple teams down a path to form a cohesive community was the biggest achievement of the sponsor. The three locations provided support using different sub-teams, each composed of 3–4 engineers. For example, one team works on kernels, another works only on network-related problems, another takes care of interface and naming services, and another focuses on commands and libraries. These teams act as bridges among core developers, who build newer versions of the OS while the engineering service group focuses on customer needs. There are approximately 65–70 engineers in the US, 32–33 in the UK and 32 in India. These teams comprise a senior staff member, one or two technical leads and technical staff.
The projectized nature of working, with a high degree of visibility of success or failure, stimulated the emergence of networks as engineers, relying on their connections, exploring the presence of domain experts in their centres and trying to avoid reinventing the wheel. Unfamiliar issues from different customer’s needs include product-centric knowledge and customer’s industry centric expertise, which is rarely embodied in a single individual or team in a GDITP. Each country centre has witnessed the emergence of technical experts and domain experts, embraced in multiple working relationships. As recounted by one of the solution developers,
Here, we are supported by sponsor. Unless each activity is carried out as per the process bible, I can refuse to move ahead. Earlier project manager would pressurize, arguing customers cannot be kept waiting and so on. Then, my supervisor would ask me to, you know, bypass the processes and deliver something. That would put the fire down temporarily but would create bigger problems down the road. Except for me, no one would know what I had done.
The format and the details of project management tools were not enforced from the top. The role of the sponsor remained confined to ensure a participative and organic emergence, more aligned to the ever-changing requirements of the community. The process bible and project management tools evolved from being just formal tools; they emerged as materially significant artefacts, bringing into the community their personage and influence.
Knowledge Continuity
The relay-race format of working requires a shared worldview and resolution approach for solving a problem. The worst-case scenario would be when a centre that initiated the solution receives a version inconsistent with the initial thought process, as different centres adopted different worldviews to understand the problem and work accordingly.
Continuity of work requires either formal knowledge management tools or a community working informally through video conferences. Our case had both. However, the CoP was stronger in its impact due to differences in the work experience of team members located in different locations. Thus, necessitating reaching out to other experts and ensuring hand-holding for successful project delivery. The nightmare of a solution development team, the initial team receiving a version completely distinct from the initial thought process, was disciplined by the hand-holding among actors through CoP, beyond the formal tools.
Sponsor’s influence in safeguarding these interactions was ever-present, as she had taken on the responsibility for ensuring the success of the India centre. Multiple interactions led to materialization of close ties, which would not have formalized without her continuous support.
PROJECT MANAGEMENT TOOLS AND PROCESS BIBLE AS CULTURALLY ACCEPTED ARTEFACTS
The IEC in Bangalore became a key site for technology development for the company worldwide. The IEC was slated to grow to a core engineering site with 3,000–5,000 employees to handle worldwide projects. The sponsor, the Director of Stern Sustenance Group, was appointed by the top leadership to focus on quality and rapid delivery. The director was very clear about how she wanted to spread uniform culture across multiple locations. As reminisced by Bhaskar, a development manager:
Among the initial things she did was get some people from U.S. to come here and work with the team here in the initial stages of IEC. This was done so that a rapport was built…. Initially we had people traveling either way quite frequently to get to know each other. So, these things really helped, otherwise if it was only a team sitting here and working over emails and phone calls it wouldn’t have come to this level. This led to blending of the Indian team with rest of the team all over the world.
Additionally, phone and video calls were not permitted during working hours. Therefore, documented processes were put in place. Prior to shifting part of the work to India, documented processes were not required, because most engineers in the U.K. office had worked in the U.S. office prior to. Hence, they were familiar with the processes. Processes used in the U.S. and U.K. development centres were documented. Subsequently, some new processes were added to increase transparency. The team head in Bangalore said,
So, we kind of used this opportunity to put documented processes in place and then it started spreading all over the other offices in U.K. and U.S. So, in this way we had influenced other teams to contribute in development of these documented processes and following them. A ‘Process Bible’ was created, which anyone could go and have a look in case one doesn’t know what to do next.
A key team member involved in the development of the process bible shared how the exercise was carried out:
I picked up seven or eight guys from the teams in India. All of us together created the process bible; after it was done, we took it to the global team. As the activities done at different offices were same everywhere, therefore it was applicable to the whole global team. So, now this book is sustained by voluntary effort from all over the globe and not just the team here. We have cut down the team maintaining that bible to two people here and we have two three people in Europe and two three people in US and they all together sustain the book. Sustain implies that with time some of our processes change and some time we get new processes and some time we remove old processes…so we must keep the Process Bible correct.
Problem Solving and Evolution of the Tools
Different tools enabling formalization, tracking and analyses were suggested and developed by the sustenance group. Tools ranging from bug trackers, efficiency trackers, status–report generators, etc., allowed 24×7 visibility of different issues at multiple locations, along with data-driven reviews, audit trails and code walkthroughs. As one of the managers told us,
Earlier, we used to have lot of heated arguments because no group wanted to own the problem. There was lot of buck passing among the different groups viz., hardware driver group, application group or OS group. …now Scopus (part of the Project Management tools) allows us to do a great amount of post mortem analysis. We look at the means and the medians of the phases, we look at the trends where all we are doing well where all we are not doing well and what we need to address. After documentation…of probable causes associated with probable probabilities was started…things started to change. Engineers knew that problem could have been interjected because of somebody’s else fault or it was their own fault. Either way there is now visibility in the system of the problem creator and problem solver.
The development of processes, technologies and expertise in the teams has been a self-sustaining virtuous cycle. Improvements in both arenas have led to increased effectiveness of the sustenance team, with people displaying high maturity in rejecting what does not work. One of the engineers said,
It is an ongoing process…you develop expertise and then you say…this process is not needed…you knock it off or you would say this is where we are going wrong; we need a new process for that or something like that. Whatever work we are doing there are two aspects to it…one is the process that we follow and second is the expertise in that domain.
Eliminating what does not work ensures actors stick to their proposed solutions. Being data-driven, with project goals as the driving factor, the focus of all involved members is on a solution that works and meets quality requirements.
DISCUSSION
Our case study has explored a rarely researched field of product-based project companies successfully delivering global service projects through dispersed teams, engaging as a CoP. Our research also points out how CoPs operated with varying degrees of formalization: Mature CoPs possessing a critical mass of interacting members were formalized via governance structures of sponsors and community-created tools, while nascent CoPs coexisted as informal interactions. Bridging research on global IT projects and successful CoP, our paper presents a ‘revelatory case’ (Yin, 2003, 43), providing an understanding of hitherto a relatively under-researched phenomenon and a potentially valuable counter case to studies researching failures.
First, our research supports negotiated controlling by system architects, committed to preserving product-architecture and ensuring product resilience (Aanestad & Jensen, 2016), working in parallel with project managers committed to delivering multiple project charters, bound by uniform project architecture. The advantage of meeting multiple project charters, despite each charter being unique, via a uniform architecture has been identified by previous research (e.g., Klessova et al., 2020, 301). However, our paper has extended the existing research by bringing to the fore the possibility of negotiated coexistence of local adaptations of the product and fidelity to product-version-trajectory through product architecture.
The second contribution of our research, which can be extended to knowledge-based projectized organizations/industries, is to demonstrate how projectized communities, with a high degree of customer focus, foster the formation of projectized networks, deepening connections within the community. While knowledge sharing has been widely known to exist in social networks, such sharing was often limited to industries associated with physical interactions or face-to-face social networks, for example, in manufacturing (Al Saifi et al., 2016) or in agriculture (Pratiwi & Suzuki, 2017). Our study indicates that excessive emphasis on ‘trust-enabling structures and interactions’ (e.g., Xu et al., 2020) has ignored the impact of projectivization. Failures of CoP due to lack of engagement (Haas et al., 2020) lend support to the proposition that strong project-based organizations would be able to actualize and benefit from CoPs better due to project-enforced engagement. The dynamism of community is manifested by events, artefacts and engaged actors piloted by customer-oriented project rhythm (Wenger et al., 2002), compared to non-projectized communities (e.g., Symon et al., 2020).
Organizational practices and processes play a significant role in unearthing and formalizing social networks that exist at the peripheries of formal organization. This transformation into formalized CoPs provides visibility to the networks, which provide valuable knowledge creation, sharing and use. The sponsor and the process bible, operating as culturally embedded artefacts, brought in governance and accountability. The accountability was reinforced due to customer problems acting as trigger events and fulfilling an integrating role (Lawrence & Lorsch, 1967) spanning coordinating actors across the community.
Evolution of CoP is a contingent outcome, determined not only by the properties of product architect and project management but also by the dynamic interplay of convergent and contested interests of actors linked in complex networks. It is only when these isolated actors get connected and enmeshed in multiple networks, instinctively engaging in ‘specialization within’ and ‘specialization through’, that is, integrating different specialized knowledge (Carlile & Rebentisch, 2003), do we witness the emergence of a project-synchronized community of practice. A ‘practice-driven’ and a multiple networks-based approach allows redundancies and accommodates diverse knowledge-sharing needs and preferences (Pan & Leidner, 2003).
Projectification of an organization destroys existing boundaries and redistributes political power (Bredin & Soderlund, 2006; Midler, 1995). Isolated employees engaged in related work in a seemingly fertile ‘learning landscape’ (Prencipe & Tell, 2001) tend to be akin to a community-in-practice, conceptually and empirically different from CoP. We identify the presence of the sponsor as a compelling reason for the successful implementation of the project management tools and process bible. Together, these three functioned as tools for both community governance (Klijn, 2008) and project governance (Abednego & Ogunlana, 2006; Joslin & Müller, 2016). Without these, the interactions among multiple community members represent potential conflicts, as actors limit their understanding to their respective worldviews (e.g., see ul Musawir et al., 2020).
Projectification intensifies actors’ interests in the improvement of individual competencies and in moving beyond departmental boundaries (Bredin & Soderlund, 2006). While not the focus of our paper, our research highlights the paradoxical role of an increase in employee engagement by those seeking better opportunities outside the organization. The intense learning opportunity, facilitated by the projectized collegiate environment, proves to be an asset in a competitive labour market.
A projectized CoP seems to provide a higher level of collective mindfulness, resulting in superior organizational sensemaking (Aanestad & Jensen, 2016), allowing multiple social interactions fostering the emergence of common protocol and language (Sablis et al., 2021). Nurtured by leadership, it creates a virtuous spiral of gainful collaborations, recognition and trust (Lee & Choi, 2003), attracting employees to engage further and developing the right social ecology as identified by Gupta and Govindarajan (2000). Operating with process tools that bring invaluable visibility, traceability and accountability to numerous interactions between ‘serving’ and ‘served’ actors (Yeo, 2002), prevents a descent into chaos.
Despite the underlying complexity of multiple members and their relationships, the psychological empowerment fostered by the sponsor has harmonized the functioning of these informal networks driving successful projects and innovation. Transitioning from sponsor-driven governance to participant-driven governance (Provan & Kenis, 2008) was, we believe, a demonstrated and intentional shift of power by the sponsor to the community.
CONCLUSION
Contribution
This study provides important empirical evidence towards increasing the understanding of a successfully working globally distributed team, overcoming static formalism and protocols. Our case study illustrates how beneath apparent chaos lies an emergent process with its own logic of social values and power. Projectized communities function via distributed teams, or individual experts, taking ownership of problems. They resolve problems through intense coordination with other domain experts, starting off as informal interactions that subsequently mature to formal processes. These interactions, while seemingly complex, do not overwhelm the organizational processes and existing project management tools. Publicly visible dashboards and forums facilitate coordination. The communal knowledge of ownership leads to community engaging as an appreciative audience or, in case of non-performance, a harsh jury. These practices prevent the breakdown of the invisible threads of coordination and control. Despite multiple constraints and multiple teams, formal protocols were continually superseded by their adaptations, enabling community members to work within and modify the protocols, and share knowledge rapidly, a counter case to ‘safeguarding behaviour’ (Xu et al., 2020).
Our research provides strong evidence of the phenomenon of successful emergent social norms and structures guiding people towards organizational goals. The case study emphasizes the significance of tools, processes, and informal networking backed by strong leadership in the successful emergence and development of a vibrant community of practice.
IMPLICATIONS AND FUTURE RESEARCH DIRECTIONS
Our case study has several important implications for project-based organizations. The case study illustrates CoP as a potential buffer providing organizational resilience against attrition-induced knowledge loss and loss of continuity. The community perspective highlights the dynamic capacity and capability (Volberda et al., 2010) of an organization.
Project managers’ technical competence is inherently limited to projects and towards products/systems (Rennstam & Kärreman, 2020). How project managers embed themselves deep enough into the community to understand the current situation as the community evolves with its own language and cultural nuances is an unexplored area. This challenge extends to organizational leaders as well. What would be a leader’s position—embedded in the CoP or outside? Which one would be advisable, and in what contexts? We believe answers to these questions would have a significant bearing on leadership’s decisions to establish a CoP within an organization.
Footnotes
DECLARATION OF CONFLICTING INTERESTS
The authors declared no potential conflicts of interest with respect to the research, authorship and/or publication of this article.
FUNDING
The authors received no financial support for the research, authorship and/or publication of this article.
email:
email: