Abstract
Introduction
Organizations face distinctive challenges in attempting to coordinate innovation processes. Innovation requires collaboration among groups possessing specialized expertise but this poses the challenge of coordinating such collaborative work across the boundaries of expert groups (Bruns, 2013; Carlile, 2004; Leonardi, 2011). It also involves the development of knowledge during the process, which poses the challenge of coordinating work in the face of emergent and under-specified goals (Bødker, 1998). These challenges highlight a need to re-examine long-standing theoretical concerns about the relationship between a dynamic and unpredictable innovation process and the forms of coordination used to organize such a process (Burns & Stalker, 1961; Van de Ven, 1999). Conventional forms of coordination, involving the application of norms and standards, and the modularization of activities, are often found wanting in the face of these challenges (Adler, 2005). This has motivated a broad theoretical concern centred on ‘how emergent action coordinates work in organizations’ (Okhuysen & Bechky, 2009, p. 481).
One important strand in responding to that concern focuses on the idea that objects – which may take both symbolic and material forms – are central to coordinating activities in such settings (Bechky, 2003; Carlile, 2002). Contributions from scholars have done much to illuminate the role of different types of object in coordinating innovation processes (Fujimura, 1992; Ewenstein & Whyte, 2009). Thus ‘boundary objects’ address the challenge of coordinating collaborative tasks across different functional or disciplinary domains by allowing expert groups to represent their knowledge and dependencies more effectively (Barrett & Oborn, 2010; Carlile, 2002; Star & Griesemer, 1989). Other studies have highlighted the role of so-called ‘epistemic objects’ in motivating and coordinating the work of experts in pursuit of open-ended scientific and technical goals (Knorr Cetina, 1997; Rheinberger, 1997).
These studies have focused on the coordinative role which objects may perform in relation to particular inter-group collaborative tasks; mobilizing certain groups in pursuit of new knowledge, or enabling disciplinary or functional teams to share and transform their knowledge more effectively. However, innovation processes encompass a number of such tasks, with their number increasing according to the complexity and scale of the innovation (Newell, Goussevskaia, Swan, Bresnen, & Obembe, 2008). Importantly, these tasks cannot be pursued independently but must be closely interrelated as groups work together to convert an initial idea and under-defined goals into a defined and marketable output. Inevitably, such interdependence creates tensions both among different tasks, and between the creative autonomy of developer groups and the time and resource constraints of the process (Tschang & Szczypula, 2006). At the level of the whole innovation process then (i.e. encompassing multiple collaborative tasks), coordination involves overcoming these tensions by linking the emerging contributions of different groups to each other, and also to the wider organizational goals and temporal constraints which define the process.
Previous work on objects has been relatively silent on their role in addressing this third challenge; that is, coordinating the innovation process as a whole. Instead, studies have focused on the variety of objects which may be involved in this process, and have identified the complementary character of the roles which they may play in supporting particular tasks. Thus, in an integrative account of this literature, Nicolini, Mengis and Swan (2012) show how a ‘hierarchy’ of different types of object address coordinative challenges within an R&D project, with boundary objects supporting work between expert groups, and epistemic objects helping to motivate interdisciplinary collaboration. What is not addressed in the existing literature, however, is how these different objects interact, and are mobilized to coordinate the multiple tasks for which they play such an important role. Addressing this gap requires a shift in focus away from the close entanglement of objects within collaborative tasks, and towards a relational view of their role in coordinating collective work over time and across multiple tasks. Such a view builds on the relational thinking which underpins much of the recent, practice-oriented research on objects; i.e. that social groups and the objects they use only develop their properties in relation to other groups and objects (Osterlund & Carlile, 2003). It allows us to extend theorization beyond the role of objects in discrete tasks, towards exploring their role in linking multiple tasks across the innovation process and over time (Carlile, 2002; Fujimura, 1987).
In this paper, we address this theoretical topic through a study of the innovation process in the computer games sector. This is an industrial sector which is itself of great and growing economic importance (Aoyama & Izushi, 2003), but which also creates extreme challenges and incentives for the pursuit of innovation through the interlinking of often very diverse practices (Nandhakumar, Panourgias, & Scarbrough, 2013). Though innovation is a pervasive feature of the development process, it has to be pursued under significant pressures of cost reduction and efficiency (Tschang, 2007). To advance our understanding of the way in which objects helped to coordinate the wide array of collaborative tasks involved in games development, we focused on the objects, and relations between objects, which were central to coordinating the innovation process. We find that developer groups and managers dedicate significant effort to securing alignment between the shared objects used in the innovation process. Situating objects in this way helps to provide a theoretical contribution centred not on the coordinative capacities of particular objects alone, but on the way in such capacities are interrelated within an unfolding but temporally constrained process of innovation (Van de Ven, 1999). Our relational view is able to shed new light on the important role played by objects at the process level of coordination, highlighting the coordinative capacity which emerges from an ‘assemblage’ or system of objects (Leonardi & Kallinikos, 2012).
The Role of Objects in the Coordination of Innovation
Innovation has been defined as ‘a temporally and episodically structured, highly iterative design and decision process involving the creation, diffusion, blending and implementation of new ideas and knowledge at different stages’ (Van de Ven, 1999, p. 23). As noted above, this creates a number of challenges for coordination. For one, the ‘blending’ of new ideas and knowledge involves expert groups or communities collaborating to accomplish specific tasks (Brown & Duguid, 2001). Here, a number of studies have highlighted the role of ‘boundary objects’ in coordinating work on such collaborative tasks. Such objects are ‘plastic enough to adapt to local needs and the constraints of the several parties employing them, yet robust enough to maintain a common identity across sites’ (Star & Griesemer, 1989, p. 393). In a study of product development in the auto industry, Carlile (2002) shows how certain objects helped to bridge the boundaries between expert groups by allowing them to represent their expertise to each other, and thus develop shared understandings of the problems at hand.
In addition, the collective ‘creation…of new ideas and knowledge’ within the innovation process has been addressed in studies of ‘epistemic objects’ (Rheinberger, 1997; Knorr Cetina, 1997, 1999). These are objects which embody what is not yet known, and provide a motivation for the creation of new knowledge. In a study of an architectural design project, Ewenstein and Whyte show how certain objects performed this epistemic role such that their ‘lack and incompleteness’ (Ewenstein & Whyte, 2009, p. 9) stimulated the development of new knowledge by design teams.
The importance of these different objects for innovative endeavours has been further elaborated through studies of their use in practice. This work promotes a view of objects not as static and fixed, but as unfolding and dynamic, demonstrating ‘plasticity’ (Barrett & Oborn, 2010), and ‘openness or closedness’ in enabling different forms of coordination over time (Ewenstein & Whyte, 2009). They are also seen as changing their coordinative roles over time (Star, 2010), for example, from acting as epistemic objects to becoming boundary objects (McGivern & Dopson, 2010), depending on the way in which they are used (Levina & Vaast, 2005).
This growing appreciation of the multi-faceted and dynamic character of the use of objects in practice has been summarized in the work of Nicolini et al. (2012) who, drawing on Wartofsky (1979) and Engestrøm, Miettinen and Punamäki-Gitai (1999), propose a three-level hierarchy of the roles played by objects, as follows: ‘tertiary’ objects represent the infrastructures (e.g. email systems, physical spaces) that make collaboration possible; ‘secondary’ objects are boundary objects (e.g. blueprints, models) which facilitate collaboration; and ‘primary’ objects (e.g. scientific problems, design concepts), which encompass epistemic objects and activity objects, provide a motivation and focus for collaboration. As their study of a multidisciplinary R&D project shows, objects which operate as ‘primary objects’ at one point in time may equally be transformed in status to operate as secondary or even infrastructural objects at other times (and vice versa).
These studies of the role of objects emphasize their contribution to coordinating collaborative tasks encompassing different expert groups. As noted earlier, however, innovation processes encompass a range of coordination challenges. In particular, as Strauss puts it, an overall project is made up of multiple tasks or ‘sub-projects’ and it is necessary to ‘articulate’ the work of each sub-project or task to each other, and to the primary project (Strauss, 1988). It follows that coordinative work is not only performed within specific collaborative tasks, but also between such tasks. As Bruns (2013) observes, this involves attending to the way expert groups have to ‘link emerging contributions across temporal and domain differences’ (Bruns, 2013, p. 63). This suggests that in discussing the role of objects, we need to differentiate between the different settings or levels of coordination practices supported by their use, including: within the expert practices of a particular group; supporting particular collaborative tasks between groups; and, at the level of the whole project or process, coordinating multiple collaborative tasks or sub-projects (Ewenstein & Whyte, 2009).
Coordination at the process level, as we term it here, is challenged by the emergent and unpredictable character of innovation. The autonomy of developer practices needed for innovative outputs are often in tension with the time and resource constraints imposed by organizations (Adler, 2005), and progress towards the completion of tasks is difficult to estimate and assess (Girard & Stark, 2003; Kraut & Streeter, 1995; Tschang, 2007; Zackariasson, Walfisz, & Wilson, 2006). As Kellogg, Orlikowski and Yates (2006) point out, coordination across the ‘parallel work’ of different expert groups in such settings is an ongoing achievement rather than a fixed structure.
Some of the practices which enable such an achievement have been highlighted by Bruns in her study of a cross-functional scientific research project. Here, coordination across parallel work activities was enabled by a practice which she termed ‘joint assessment and consultation’. This involved the members of different expert groups coming together ‘in conferences, weekly meetings, and project meetings to discuss findings from expert practice and to solicit feedback’ (Bruns, 2013, p. 68). In these meetings, they would establish a shared interpretation of preliminary contributions and link this interpretation to specific possibilities of expert practice.
Only a limited amount of attention has been given to the objects which support the kinds of coordinative practice described by Bruns (2013). One relevant study is research on creative projects in web development (Kellogg et al., 2006). This study found that the objects used to coordinate such projects conformed to a defined ‘project genre’. Such genres ‘structure members cross-boundary communication by providing a repertoire of socially recognized and legible templates enabling them to represent their community-specific ideas and issues to each other without requiring general translation or collective agreement’ (Kellogg et al., 2006, p. 38). The sharing of objects – timelines, status reports – conforming to the project genre enabled expert groups to ‘coordinate both their distinctive as well as their parallel areas of project work’ (p. 38).
Further, Yakura’s (2002) study of a consultancy firm found that one such object – the project timeline – operated as a ‘temporal boundary’ object. The prospective nature of the timeline and the possibility of frequent changes provided interpretive flexibility and ‘plasticity’ across groups. Equally, though, timelines coordinated collective action in ‘complicated’ projects where ‘schedules must be set, tasks must be coordinated, and performance must be measured… Time is integral to deadlines, budgets, and other critical measures of success and performance’ (Yakura, 2002, p. 958). Timelines thus help to ‘impose order onto an otherwise incoherent (nameless) set of activities’ (p. 958). Yakura’s study finds that these features help to explain timelines’ ‘central importance as artifacts for scheduling, allocating, and synchronizing’ (p. 964).
One implication of Yakura’s work, however, is that the ‘central importance’ of process-oriented objects such as timelines may derive not only from their own boundary-crossing capacity but also from their links to other objects such as budgets and weekly reports. She observes that the timelines in her study were not ‘self-explanatory’, that they incorporated references to financial and staffing budgets, and needed to be read in conjunction with other items including task lists to make sense of a project’s progress. These relations between objects have also been identified in previous empirical studies (e.g. Barrett & Oborn, 2010). The implication of this previous work, then, is that the process level of coordination is dependent not only on the use of particular project- or process-oriented objects, but also on their links with other design-oriented objects (Ewenstein & Whyte, 2009).
The possible theoretical significance of such links between objects has been broached in references to the linked or systemic character of objects (Latour, 1996; Orlikowski & Scott, 2008). In existing literature on the organizing role of objects, Nicolini et al. (2012) observe that ‘the specific role objects play in supporting collaborative efforts results from relations with other objects and other aspects of the activity and does not derive from some assumed essential characteristic of the object itself’ (Nicolini et al., 2012, p. 626). In a similar vein, Carlile makes reference to the ‘portfolio effect’ produced by the interaction of different categories of object (Carlile, 2002, p. 452).
However, while the small number of studies outlined above have acknowledged the importance of the relations between objects, this has not been a central focus of previous work. Instead, this has been on the coordinative work performed by objects within particular collaborative tasks and the transformations that allow them to perform different roles over time. As a result, we only have a limited understanding of how the coordinative roles played by different types of objects interact, and how the relations between objects help coordinate multiple collaborative tasks at the level of the innovation process.
To address this research need, our study sought to address the broad question of how the use of objects helped to address the distinctive coordinative challenges of the innovation process. This encompasses two further related questions: how the coordinative roles of individual objects interacted to advance the innovation process over time; and how the relations between objects themselves supported coordination of that process.
Research Design and Methods
Our empirical study of innovation in computer games was conducted between September 2008 and January 2010. The study involved fifteen separate visits to three games development companies in this period to investigate the way in which work was coordinated among different groups in the course of developing computer games products. The selection of the computer games sector fieldwork setting was based on its relevance to theory development on the role of objects in coordination (Eisenhardt, 1989). The computer games sector is a particularly relevant arena since a number of issues relating to new challenges in the coordination of collaborative work come together in digital games development (Nandhakumar et al., 2013; Stacey & Nandhakumar, 2009). Games development involves rapidly changing digital technologies (Yoo, Henfridsson, & Lyytinen, 2010), decentralized and distributed ways of collaborating, and an emphasis on continuous innovation, creativity and novel user experiences (Nandhakumar et al., 2013). As a result, identifying interdependencies between different pieces of work is often uncertain or challenging. Further, goals in digital games development projects are difficult to specify, progress is difficult to ascertain, and the innovation process demands coordination across diverse areas of specialized expertise including computer programming, art, graphic and dramaturgic design, and 3D animation (Zackariasson et al., 2006).
The three organizations were chosen as appropriate sites because they had evolved sophisticated work processes and management practices, as reflected in their long-run records of operation in a volatile and highly competitive sector (Roberto & Carioggia, 2003). We therefore anticipated that they would provide insights into persistent and recurring mechanisms of coordination within this sector. They were also organizations committed to new product development encompassing a range of computer games and users. While the size of computer games firms in terms of number of employees is generally closely linked to project life cycles, these three firms were all of similar size (around 250 employees). They have been labelled as follows (using pseudonyms to preserve company confidentiality): Quipp, PetName and Dredd. A summary description of each organization follows.
Since its foundation in 1990, Quipp has grown into a leading independent multi-platform developer comprising five distinct divisions: family games; mature titles; serious games; downloadable games; and games technology. The company develops games under its own brands, as well as on behalf of external publishers and intellectual property rights holders.
Formed in 1997, PetName has developed a series of commercially successful, critically acclaimed and award-winning strategy, action role-playing and simulation games. The company develops its own titles, almost exclusively for the Xbox console, with dedicated teams moving from one release of the title to work on the next release in quick succession.
Since its establishment in 1992 Dredd has grown significantly through the acquisition of other UK studios. The company produces games both under its own brand and for third-party clients, and has enjoyed significant commercial success. It is now a multi-platform and multi-genre developer operating out of four different locations around the UK.
While the inclusion of multiple sites helped to ensure that our findings were more deeply grounded in empirical evidence (Eisenhardt & Graebner, 2007), variance across organizations was not a central focus of our study. Rather, we were particularly concerned in our data-gathering to locate the use of objects within an unfolding innovation process. This concern reflected the studies described above which have highlighted the importance of the particular work process and context in which objects are situated, and also the shifting roles and functions of objects over time (Barrett & Oborn, 2010). As outlined in previous work, such a focus involves the use of fieldwork methods that entail ‘observing individuals in practice and focusing on the objects they work with and the ends that they pursue’ (Carlile, 2002, p. 446).
The primary sources of data included twenty-five interviews, and 60 hours of observations. Informants for the interviews were selected to provide a cross-sectional view of the groups involved in the work process. Their roles thus ranged across different levels of management (development managers, commissioners, heads of design and programming), different functional groups (game engine, weapons, animations, and so on) and different levels of technical expertise (team leaders and team members). Interviews were conducted both in the formal settings of managerial offices and, less formally, with informants in the games development workspace. The emphasis on observation and interviews reflects our concern to address the meanings and practices of developer groups and managers in the fieldwork sites (Walsham, 1993).
The observational material was recorded primarily in note form during the time at the studios, usually contemporaneously, or very soon after a certain event or encounter of interest. To reflect the material dimension of our research focus, attention was also given to gathering secondary forms of data. This included: project management documentation; sketches drawn by the developers as they explained something, either to the researcher or to each other; printouts of key documents used in the development process; screen grabs of computer applications and displays; some photographs taken at one of the studios during observations; and sketches done by the researcher. We also made efforts to collect or examine many of the objects involved in coordinating the innovation process at the three sites. Our data on these objects was supplemented by fieldwork notes on their use in developer practices. This was to ensure that their role in coordination would be understood not in terms of their intrinsic technical features but as being embedded in the practices of the groups using them (Levina & Vaast, 2005).
While our sample of organizations displayed some differences in structure and strategy, we found that they also shared a number of important organizational characteristics, which seemed to reflect the norms and practices within the wider industrial setting (Monteiro, Jarulaitis, & Helpsø, 2012; Tschang, 2007). This setting has been described as a hyper-competitive environment characterized by a constant demand for novelty and new experiences and features in games (Roberto & Carioggia, 2003). These were project-based organizations in which operational decision-making was decentralized, and the work process was advanced by work teams of shifting composition (cf. Kellogg et al., 2006).
Data analysis
The initial analysis of interview transcripts and observation notes involved identifying key aspects of the development process for new games across the three studios by tracing the interplay between and among developer groups and the work process, and the appearance and effects of different objects within that process over time (Langley, 1999). By employing a recursive process of refinement and comparison among the authors, we sought to relate the analysis of interview transcripts to the observational and documentary materials acquired from our fieldwork settings. Here we acknowledge the difficulties of analysing process data which are often complex and eclectic in form (Langley, 1999). As Langley notes, however, such analysis may be crucial to making sense of practices and activities and, in this case, it allows us to make sense of the coordinative capacities of objects by situating them within a complex development process. Through this initial analysis we were able to assemble a stylized composite overview of the process of computer games development, highlighting tasks, objects and coordination. This approach is proposed as a way of dealing with the difficulties of collecting and analysing process data (Langley, 1999).
In the next stage of analysis we moved to axial coding (Strauss & Corbin, 1998), focusing on identifying first-order categories by clustering similar kinds of coordination challenges (cf. Okhuysen & Bechky, 2009) identified from the assembled stylized versions of work process of computer games development and the objects within this process, together with the informants for different phases of that process across all three of the studios. These are presented in Table 1. As we ‘zoomed in’ (Nicolini, 2009) on episodes of coordination challenges where particular objects were important in coordination, and within these episodes, we were able to explore not only the use of objects, but also the meanings being applied to their use within the local and temporal context of the work process. The aim of analysing the empirical material in this way was to build up a rich texture of relationships centred on the ‘axis’ of the category in view (Strauss & Corbin, 1998).
The Development Process of Computer Games: Phases, Tasks, Groups and Objects.
The final stage of analysis focused on integrating first-order categories identified into higher-order, researcher-induced themes pertaining to the emerging relationships between coordination challenges and shared objects, and also between tasks over time within the innovation process across all three of the studios. We sought to carry this out by tracing statements denoting how they were related to each other and looking for cues in the material (Strauss & Corbin, 1998), with subsequent focusing of the emerging themes through our theoretical concern with the changing role of objects.
One important finding from these analyses was a high level of commonality (minor differences in terminology aside) in the structuring of the innovation process across all three of the research sites, including the expert groups and practices involved, and the objects in play. In presenting the findings from our empirical study, therefore, we have chosen not to present materials on an organization by organization basis. Instead, to foreground our theoretical concerns, we present our findings in three sections which draw on data from all the fieldwork sites. Such an overview necessarily involves some abstraction from actual practices, and risks presenting an overly ‘neat’ view of the work process. To address this concern, and to ensure an appropriate ‘interplay between induction and deduction’ (Strauss & Corbin, 1998), in the empirical section we focus in more detail on particular episodes in the innovation process. These highlight the relations between objects over time, and how this enabled coordination to address the challenges posed by the innovation process.
The Innovation Process in Computer Games
In shorthand terms, the development of new games in our research sites involved an original idea or concept being progressively translated into digital objects, referred to as ‘assets’, which were assembled together using game editing tools to form the game world within which the game takes place. This game world is made up ‘characters’ that act and interact with each other and with the ‘environments’ they inhabit. The resulting ensemble is then translated into computer code that can be executed on purpose-built game consoles or on personal computers. When this code ‘runs’, the so-called ‘game engine’ – i.e. the software that interacts with the target platform’s hardware (e.g. console, PC) – enables the game’s assets to be processed through the hardware to provide the game experience for the player.
While the groups involved in games development did not map exactly across the three organizations, they were typically structured along the disciplinary lines of art, design, programming, and production, with each group being organized by a manager and a senior specialist, such as a ‘head of programming and a ‘lead programmer’ or ‘head of art’ and a ‘lead artist’. In Table 1, we provide an overview of the game development process in which these groups collaborated. It is not intended to reflect an exact chronological ordering, as there is considerable iteration and contingency, but it does allow us to identify common features of the innovation process across the three studios, together with key coordinative challenges.
The first step in the journey of a computer game from concept to executable code takes the form of a short text outline of the proposed game and its key features. As a senior producer at Dredd explained; ‘We’ll boil the game down to five pages and we’ll basically tell them that in those five pages is exactly what they can expect from us.’ Once this outline has been finalized, work begins on developing what was referred to as the ‘concept book’ or ‘concept document’, which is then presented to either an internal group of managers or an external group of clients for approval or ‘green lighting’ (Table 1). Once the project has been approved, contracts are signed, broad delivery milestones are agreed, and resources are committed through producing more formal and precise specifications for the game and its components. These specifications are written into certain design-oriented objects, the main one being the ‘game design document’ (GDD), which is composed of various sub-documents that relate to particular scenes and quests in the game. The initial versions of these documents are drawn on by production managers and team leaders to develop the detailed ‘milestone schedule’ for the project.
The initiation of production tasks is triggered by the formulation of an agreed milestone schedule. Different work teams are then tasked with developing deliverables as these are specified in the GDD and the technical and art design documents that accompany it. The production tasks themselves centre on the development of the locations, quests, characters and levels that define the game world. These are developed first by the art team drawing and digitizing entities, objects, characters and environments using digital art software packages, then by animators using animation software for specific scenes, while artificial intelligence programmers develop algorithms that control non-playable characters in the game. At the same time as these elements are being produced and assembled, the level designers – sometimes also referred to as ‘scripters’ – are using specialist software packages to build the locations and quests specified in the GDD. The integration of assets into the finished code of the game (known as the ‘build version’) takes place throughout the development process and involves a number of different groups. The coordination of the work outputs of the developer groups towards inclusion into this ‘build version’ is a major managerial concern. This so-called ‘pipeline’ of assets is then ‘compiled’ within a game engine and integrated into the software of the game product itself (Arnaud, 2010).
The production phase is interspersed by milestone review meetings that took place at regular intervals, typically every five or six weeks. In addition to checking progress on the delivery of outputs agreed for that period, they also provided a forum for a detailed ‘show and tell’ meeting of all developer teams in which different teams make presentations on their previous and planned work activities. The teams participating in these meetings would use their own game console – sometimes more than one – with those presenting plugging in their console to the audiovisual system of the meeting room and demonstrating the objects of the task being assessed and reviewed as they were in the game. Central to the discussions in the meeting were the printouts of the milestone schedule that participants collected as they came into the room. This helps to highlight existing and also possible future interdependencies between deliverables and teams.
By enabling the collective viewing of the layout and features of existing locations and levels in the current build version of the game, the review meeting supports collective discussion of the alignment of their disparate outputs with the emerging content and look and feel of the game. Once particular dependencies have been reviewed and agreed within such meetings, subsequent actions and, if necessary, resource commitments are specified, and changes made in the GDD and accompanying documentation and milestone schedule. In addition, senior production managers and internal or external project funders will review the various deliverables that comprised the milestone under consideration and, after signing off on those that meet expectations, will make a judgement regarding whether the milestone has been achieved and further tranches of funding should be released.
Key Objects in the Innovation Process
As described above, a number of objects were involved in the innovation process. Taking our definition of ‘objects’ as ‘something people act toward and with’ (Star, 2010, p. 603), we focus our attention in this section on a small number of these objects that were found to be central to the coordination of the process. In doing so, we are not seeking to abstract them from the practices of the games developers themselves, but to observe how they are constructed and used by actors ‘as they make sense, name, stabilize, represent and enact foci for their actions and activities’ (Engestrøm & Blackler, 2005, p. 310). As other writers have emphasized, a range of objects, artefacts and infrastructures are involved in the performance of work practices (Nicolini et al., 2012; Orlikowski, 2006).
As the last row of Table 1 shows, a wide range of objects were indeed involved in supporting the development process. In this section, however, we are not addressing the part which all these objects played. We focus instead on
The significance of these shared objects was identified both through our analysis of interviews and during observations and was based on their prevalence in use in all of the three studios studied, across different expert groups, and also at critical decision-making points. These objects are the concept book, the design documents (art, technical and game design) and the milestone schedule.
Concept book
This was a key shared object in enabling the coordination of group work practices in moving from conceptualization of the game to specification of game elements. A PetName development manager described this object as follows:
It has pictures and varied descriptions of the story and plots and who the main characters are, biographies of who these people are, what they look like; it covers all aspects of the game. It is usually a 70- to 80-page document which encapsulates what the game is going to be – what we intend it to be, anyway – and tries to cover all the risks, all the areas we are going to have to look at, the story, the core technologies, even a budget section at the end, the staff plan, with the end date, the start date and the phases and all the markers in between. It tries, at a high level, [to] encapsulate the whole game, how long it’s going to take, and what it’s going to be.
A number of concept books were examined at the three studios. They were aesthetically engaging, book-like documents, each one styled in accordance with the theme of the proposed game. For example, the concept book for a science fiction game had covers made out of shiny metal and shaped like a spaceship hatch. Likewise, the concept book for a medieval adventure game had the look and feel of an old musty book and had been dampened and left in a basement for some time to give it the required smell. We found that this object was important in enabling members of different developer groups to interrelate their diverse interpretations of the abstract concept of the proposed game and the entities that would constitute it. Its coordinative role emerged when initially diverse interpretations became gradually aligned as different groups populated the object with text, textures, drawings, photographs, tables and spreadsheets describing the game to be developed.
The concept book was also used beyond the immediate development process to exchange ideas with other project stakeholders, such as clients, internal commissioning committees and external collaborators. Stakeholders were thus able to exchange their views not only on the high-level functional specification of the game but also on its ‘look’, ‘feel’, ‘atmosphere’ and other intangible and subjective aspects. Once agreed and approved, the concept book also prompted senior managers’ and team leads’ detailed planning of the development process by providing the basis for initial calculations of the resources and time needed. It thus provided a key reference point for the ‘project agreement’ with either external or internal commissioners through which milestones were agreed and resources and funds committed.
Design documents (game design, technical design, art design)
The development director of Quipp outlined the crucial role of what was referred to as the game design document (GDD), as follows:
The aim at the beginning of each project is to create a ‘game design document’ [which] will contain everything that is in the game. It will classify all the characters, all their moves, all the mechanics, all the animations needed, all the pickups, all the weapons, all the locations, all the mechanics. That will grow to at least a couple of hundred pages for just that.
Across the three sites, this document specified the key elements of the game to be developed and how these related to each other. These included the levels, locations and quests that make up the immersive game world. This document also specified how these elements fit into the storyline of the game, and how that storyline in turn relates the different game levels to each other. It was stored on – and available from – the shared servers of the development teams, and was frequently materialized in the form of printouts for use in both ad hoc and more formal meetings.
The GDD was part of a set of design documents that also included the art design document (ADD) and a technical design document (TDD). In the former, art-related assets, such as entities encountered by the player in the game, and environments were specified in much more detail. In the latter, detailed technical specifications for all the elements specified in the GDD (levels, tasks, characters, environments, etc.) were defined. The TDD was important in specifying the ‘budgets’ for computer memory and CPU (central processing unit) use for a range of different kinds of scenes. It also specified the number of polygons that could be used in every scene. Polygons are the base element used to compose all other more complex shapes in a computer game. This detail was important because it highlighted the dependencies between, for example, the number of characters that could be displayed at any one time and what these characters could do.
During the fieldwork, we observed how components of the design documents participated in the interactions between the developer teams. For example, when assets were passed between teams, the game, art and technology design documents would be used to check whether both sides of the handover were satisfied with the exchange. Members of the design team involved in the conceptualization of the game would check with the concept and 2D artists that the 2D static drawings corresponded to what was specified in the GDD. This artwork would then be passed on to the ‘riggers’, who converted these drawings into 3D and developed ‘meshes’ that made possible the digital manipulation necessary to animate them.
The design documents were important not only in supporting the transfer of assets between groups, but were also directly referenced by groups (e.g. the riggers) in their work. This is because the design and implementation of the 3D ‘meshes’ described above are interdependent with other game features and the tasks associated with their realization, including the polygon count and fidelity of the scene, computer memory and CPU budget for it, and the playing experience. The riggers therefore use the design documents and other objects (e.g. models) to identify all the relevant limitations and dependencies in their work. Figure 1 shows this use of multiple objects through a photo of one of the riggers at work.
A rigger at work.
This photograph shows how a rigger draws on multiple outputs from other teams in his work. He is developing a 3D character (on the left screen) while using as resources the concept art and some of the other 2D drawings from the GDD (right screen) together with a physical model of the character (on his work table).
As recorded by our observations of meetings, the design documents were central to coordination between teams. An example of this came from our observation of a meeting of art and design teams regarding initiating work on new ‘regions’ to be developed for a game. Here, we found that the discussions between the two teams centred on the 2D plans of some of the key locations in the ‘region’ (see scanned images in Figure 2), and the accompanying concept art and external visual references for them. These were included in the game and art design documents that were either pored over on the meeting table, or passed around from one team member to another as the teams pondered how to go about the task of developing that ‘region’.
Two-dimensional plans of locations in a game design document (GDD).
The design documents served to represent the dependencies not only between the groups involved in the task, but also between the other tasks in the development process (e.g. the development of other ‘regions’ in the game world, or with the storyline of the concept book) and contributed to their alignment.
Milestone schedule
The milestone schedule established the temporal ordering and sequencing of the elements of the game. It typically took the form of a large tabular matrix which related the high-level goals of the project to key work areas such as ‘[Game] Engine’, ‘Gameplay’, ‘Characters & Creatures’ and ‘Regions’. Within the document these areas are subdivided into tasks and outputs, which are allocated to individuals and teams along with specific time allocations and commentary on outcomes or problems. Finally there are columns that relate to signing off development tasks. Every milestone specified for the game’s development would be accompanied by such a schedule, covering the timeframe between review meetings.
One of the central roles of the milestone schedule was to associate the game, art and technical design documents to the temporal ordering of the work process by scheduling all the deliverables specified in those documents. This temporal ordering of the development of the ‘assets’ specified in the design documents made visible key dependencies in the innovation process. This is illustrated by the following observation from a development manager at PetName:
We’ve had problems with dependencies. Say the scripters who are implementing the story and the quest, saying: ‘we need this character – oh, but that character is not ready’. The art animation, therefore, was not ready, and with the script, they hadn’t had enough time to put into their script for that milestone.
The milestone schedule also drew on elements from other objects to specify how different deliverables would be produced. For example, the schedule incorporated elements from the studio’s staff plan maintained by the production team, to identify particular individuals or groups as responsible for a certain feature of the game in the milestone schedule. Explaining the link between the staff plan and the milestone schedule, the production team lead manager at PetName explained:
We have a staff plan. We know who’s available from when to where. We work out the costs, we know the dates; we work out when we want it to be in the street, and we work backwards from that. We fiddle with the numbers and make sure we have the right number of people and have a plan for when we can recruit them and what kind they are going to be.
The milestone schedule was also linked to the timeline and budget for the game as initially outlined in the concept document and formalized through the project agreement or contract. In this way the milestone schedule linked the features defined initially in the concept book and then, in more detail, in the GDD to the payments and financial resources available for the project. It was through the milestone schedule and the progressive signing off of the constituent milestones that payments from clients or internal commissioning entities were made available. As the development director at Quipp put it; ‘if we hit the milestone, then we get paid’.
Relations between Shared Objects in the Innovation Process
As outlined above, the innovation process in our case settings was coordinated not only through the use of a variety of objects, but also through the complex links maintained between these objects. A central focus for maintaining these links at process level was the milestone schedule, and in Table 2 we outline how the various components of this object, as described above, were linked to other key objects deployed within the innovation process.
Components and Links of the Milestone Schedule.
These links were traced through the analysis of multiple sources of data, including the examination of milestone schedules themselves from the three fieldwork sites, interview materials (especially with senior production coordination managers) and observational data, particularly from a milestone review meeting. The links outlined in Table 2 are thus a focal point of the wider set of relations which helped to ensure that changes made in one object were speedily relayed to others. This table demonstrates how, through its component parts, the milestone schedule brought together organizational goals and concerns on the use of resources, and the unfolding progress of groups engaged in different collaborative tasks, and integrated them within a defined timeline of games development.
To better convey how the changes to one key object related to other objects, we present two illustrative episodes where such changes were encountered during the development process and where both the production and use of the shared objects were observable. These relate to situations in which unplanned changes occurred to a previously defined aspect of the development project, creating a need for action to re-establish coordination. Such situations are particularly prevalent in computer games development because of the difficulty of specifying goals that relate to the affective dimensions of the game (Nandhakumar et al., 2013; Zackariasson et al., 2006).
The first illustrative episode centres on a milestone review meeting at PetName. Review meetings in this studio took place every six weeks. In this particular meeting, the design team made a presentation to the other developer groups of a newly developed ‘quest’. This had implications for locations, and characters within the game, and other objects including the art and technical design documents. In response to concerns voiced by other teams, the ‘lead’ manager of the design team conceded that the quest was currently ‘unsatisfactory’ and needed further development. He then outlined the implications which different courses of action would have for other parts of the process (e.g. abandon and remove the ‘quest’ from the game or redevelop it with a different approach and design), each of which would affect the game’s narrative, game world and characters. He further highlighted possible constraints on the scope of any redesign in terms of time and resources. Eventually, he proposed that the design team should explore a more modest ‘tweaking’ of the stage/quest that could be accommodated within existing temporal and financial constraints without creating a major need for renegotiation and re-coordination of those aspects of the development process. When the meeting participants eventually agreed on the ‘tweak’ approach, the lead design manager together with senior production team members began immediately to undertake the necessary revisions to the milestone schedule and relevant GDD entries so that the cross-disciplinary team working on that quest could start working on the changes ahead of the next milestone meeting in six weeks’ time.
Our second example is drawn from the case study of Dredd where a team had been charged with developing a game based on a popular TV cartoon series. The coordination issue in this case arose when it was belatedly found that the 2D drawing style of the cartoon characters in the TV series could not be translated into the 3D version that would be used in the game. If resolved using a software script that could ‘distort’ the 3D version to look like the 2D cartoons, it could be treated, in the words of the lead developer, as ‘a fairly simple, do it by the numbers kind of job’, but if this could not be done, it would become a major resource-intensive task. This alternative would require ‘a small army of animators to do it all by hand’.
When the script approach seemed not to be working, the lead developer was faced with a difficult problem:
Three months down the line we realized this has gone very badly wrong, and the only recourse I had at that point was to go back through time to plan that arduous ‘by-hand’ route out, and then just basically see where my cut-off point was … I had to turn around to the team and say, ‘listen lads, if we haven’t got it in two weeks’ time, then we cut, and we ditch, and move for this plan B, because otherwise we won’t get it done’.
Eventually, the software scripting approach was successfully implemented, avoiding the more costly alternative. In order to implement this solution, however, it was necessary to introduce changes to the sequencing and specification of certain game design tasks while staying within the overall timeline and financial constraints established for the game. To do this, specific interdependent elements of shared objects such as the milestone schedule and art and technical design documents had to be revised by the lead developers.
This kind of work was facilitated by several features of the shared objects themselves. By conforming, for example, to a well-understood template, these objects were readily shared and comprehensible across groups – they did not have to be created anew with each new project.
As outlined in Table 3, these relations were maintained in a variety of ways. Since these objects were made up of multiple components, many of which were common to several documents (budget statements, design tasks, etc.), simply maintaining a shared identity across these components helped to secure coordination across multiple tasks by providing a common definition of time and resource constraints. Thus, concept books and milestone schedules drew on shared statements of financial resources. However, as the innovation process unfolded, groups would seek to interrelate their emerging outputs or development problems in the setting of a milestone review meeting. In these instances – exemplified by the milestone review at PetName discussed above – negotiations of changes in design or the sequencing of tasks would surface process-level interdependencies. These would involve managers and lead developers working through the implications of changes to existing plans via the revision of the relations between objects.
Maintaining Relations between Design Objects and the Milestone Schedule.
In summary, as outlined in Tables 2 and 3, we found that the capacity of the shared objects in our study to support coordination over time, and across multiple collaborative tasks, emerged not from their use independently, but rather from the routine way in which shared objects were interrelated and cross-referenced, with changes in one object prompting work to revise and update other objects. By maintaining these relations, the process-level coordination of work activities could be achieved, even in the face of an uncertain and emergent innovation process.
Analysis and Discussion
The innovation process in computer games development involves a tightly time-bounded arena in which multiple interdependent tasks need to be coordinated. Of the three major coordination challenges for innovation outlined earlier, existing work on the role of objects has focused primarily on the challenges of coordinating collaborative tasks across expert groups, and of motivating the development of knowledge among such groups. Our study provides further evidence of how objects can help to address these challenges by acting as ‘boundary’ and ‘epistemic’ objects within the collaborative tasks undertaken across expert groups.
Our analysis thus shows how the concept books in our games studios acted as epistemic objects. Their content was culturally evocative but incomplete, thereby inspiring collaborative work across the different developer groups of art, design and programming even in the face of under-specified goals. Meanwhile, the design documents acted primarily as boundary objects, supporting commonly understood representations of practices and product features. As with the meeting between art and design groups described earlier, these objects enabled different expert groups to identify interdependencies and develop a shared understanding on design issues.
The roles performed by these objects were not static, however, but evolved over time to support the ‘emergent action’ involved in coordinating an unfolding innovation process (Okhuysen & Bechky, 2009). This evolution can be illustrated with reference to the concept book in our study. Initially, the book played an epistemic role in motivating collaborative tasks centred on the specification of the game’s overarching theme and narrative. Over time, however, it came to provide an ‘objectification’ (Yakura, 2002) of the shared intellectual and aesthetic understandings of the developers. This enabled it to act as a boundary object (Star & Ruhleder, 1996), both between the developers involved in its shaping, but also with other groups such as the funders. Eventually, the specifications of the concept book become an accepted reference point for development work, providing content (narrative structure, list of characters and locations, concept art) for other objects (project agreement, GDD, ADD, milestone schedule), thus taking on an infrastructural quality (Nicolini et al., 2012). Importantly, the example of the concept book shows that it is the changes in role rather than the properties of the object itself that are central to advancing the innovation process across its development phases.
This is not to say that these transformations in the role of objects followed a smooth linear sequence. In our example of the game episode at Dredd, objects which were effectively ‘infrastructural’ (Nicolini et al., 2012) – the standard tools of 3D digital art development – were problematized. This prompted ‘imaginative action’ which enabled an effective solution in terms of aesthetics and the accessing of ‘possible worlds’ (Wartofsky, 1979, p. 207).
This evidence of the multiplicity of roles played by objects adds to previous work on the ‘hierarchy’ of objects (Nicolini et al., 2012). However, our study extends this previous work by showing how the relations between objects, and not objects alone, helped to address the third challenge posed by the innovation process in our study, namely, that of coordinating multiple collaborative tasks towards an innovative outcome. Here our analysis centres on the importance of the milestone schedule to the innovation process in our study. Previous work has highlighted the ‘centrality’ of such schedules and timelines as process-oriented objects which specify temporal and resource constraints. However, their coordinative role has primarily been viewed as that of a boundary object between groups (Barrett & Oborn, 2010; Yakura, 2002). In our study, however, we observed that the milestone schedule’s centrality was not confined to its specific capacity to act as a boundary object, but was also the result of links (as highlighted in Tables 2 and 3) to other shared design-oriented objects. As Bruns (2013) puts it, these relations enabled the groups working on different collaborative tasks of art, production and so on to ‘work alone together’ by linking their emerging contributions to those of other groups, and to the process as a whole.
The importance of such relations to the unfolding of the innovation process is illustrated by the game development episode from Dredd. In that we can see how, initially, the aesthetic elements of the concept book helped the studio’s developers and the game’s funders jointly develop an understanding of the need to be faithful to the original artwork of the TV series. This understanding then became part of the more formal specification of the game and the ‘assets’ that made it up as defined in the GDD and accompanying art and technology design documents. Subsequently, the relations between the art and technology design documents and the milestone schedule enabled the different groups to identify and more effectively resolve the tensions between possible development options – i.e. between software and art-based solutions to the 2D-3D character art translation problem – in light of the time and resources available. The coordination of the innovation process as a whole was thus able to advance from an open ‘epistemic’ form of collaboration which characterized the initial phases of work towards the infrastructural features needed for the development of the end product. This further suggests that changes in the roles of objects, be it from ‘epistemic’ to ‘infrastructural’ (Nicolini et al., 2012) or ‘epistemic’ to ‘technical’ (Ewenstein & Whyte, 2009), can take place not only through changes in their use and interpretation (Bijker et al., 1987) but also as a result of their interactions with other shared objects.
The work of maintaining these relations between objects was carried out by the developer groups themselves or by lead developers and managers. One of the main mechanisms for the groups to be involved in this work was through milestone review meetings, which can be viewed as analogous to the practice of ‘joint assessment and consultation’ described in the Bruns (2013) study. They enabled groups to review and align the emerging contributions (or lack of contributions) from their parallel work activities (cf. Kellogg et al., 2006). Importantly, however, as illustrated by the PetName review, the output from these meetings went beyond the sharing of informal understandings between groups, and also involved the work of revising, checking and updating shared objects. A less observable, but nonetheless important, part of the work of maintaining these relations between objects was thus carried out by responsible individuals revising documents.
This work was facilitated by features of the shared objects themselves. They conformed to a defined ‘project genre’ which readily supported sharing across the practices of different groups without ‘requiring general translation’ (Kellogg et al., 2006), but also supported links with other objects. In addition, however, since these objects were made up of multiple components, many of which were common to several documents (budget statements, design tasks etc.), maintaining the shared identity of these components helped ensure a common definition of time and resource constraints was shared across tasks.
In our study, these links between shared objects did not impose fixed plans or standards in a top-down fashion, but enabled process-level coordination to respond to, and accommodate, the contingencies and changes in direction of the innovation process. By the same token, however, as is clear from Tables 2 and 3, the relationship between the milestone schedule and design documents was not the unidirectional one of timelines and budgets being adjusted to accommodate development needs or problems. Rather, maintaining these links with the milestone schedule – which specified ‘sign offs’ for resources and ‘deliverables’ against time – exerted a subtle influence of its own on the use of these other shared objects, thereby introducing temporal and resource constraints into the collective work of developer groups. This influence was well illustrated by the design episode at Dredd, where the lead developer sought to work through the implications of a possible ‘plan B’ by navigating through the required changes in the design and milestone documents. Similarly, in the milestone review meeting at PetName, changes to the game design were directly traceable to their resource and temporal implications via links between the GDD and the milestone schedule, these implications being a major focus of discussion, and the revision of these links being a major outcome of that discussion.
Developing a relational view
By developing a relational view of the role of objects our study makes several contributions to existing theory and provides a platform for further research. One important contribution from our analysis is that our understanding of the coordinative role of objects needs to be carefully attuned to the level of coordination involved. At the process level of coordination, the uncertainties of the innovation process have to be reconciled with organizational concerns to do with time and resources. This aspect of coordination has received less attention in previous work, possibly because a number of studies have focused more narrowly on boundary objects, or on the practices of cross-disciplinary groups faced with a relatively open-ended science or R&D-based project. In contrast, our study of what can be termed a ‘tightly coupled’ innovation process (Sanchez & Mahoney, 1996), within the fast-moving computer games sector, has shown how maintaining the relations between process and design-oriented objects creates a ‘system’ or ‘assemblage’ of objects which supports coordination at this process level (Nicolini et al., 2012; Star, 2010).
From a theoretical standpoint, the coordinative capacity that emerges from linking objects in this way helps to address the question of how process-level coordination can be reconciled with the emergence and needs for autonomy which characterize the practices of innovating expert groups (Adler, 2005; Tschang, 2007), as exemplified by the developer groups in our study. To the extent that objects play important roles – either as boundary objects or epistemic objects – in coordinating the collective work of these groups, maintaining relations between them and process-oriented objects such as the milestone schedule allows their various endeavours to be aligned with each other, and with the goals or constraints of the wider innovation process.
This relational view of objects also has important implications for further research in this area. One such implication comes from our observation of the heterogeneous make-up of shared objects in our study, and the extent to which their components drew on other objects. This suggests a need for future work to bring into sharper focus the way objects are constructed in relation to other objects within particular settings and practices. This need is underlined by a recent study which concludes that the capacity of certain objects to act as boundary objects is determined by ‘the whole socio-technical network’ within which they are placed (Lainer-Vos, 2013, p. 529). As this study notes, this brings into the question the ‘boundaries of boundary objects’ (p. 527).
A second implication of our study has to do with the capacity of a system of objects (Star, 2010) to support process level coordination and hence to ‘orchestrate other practices’ (Bruns, 2013, p. 79). Where previous work has emphasized the role of objects in supporting collaborative tasks between groups, this finding from our study points towards the possible role of objects in the organizational control of work practices. This possibility has been explored in one recent study which finds that objects may contribute to the ‘enabling control that is often linked with knowledge work’ (Rennstam, 2012, p. 1084), positing such a form of ‘object-control’ as particularly relevant to the study of knowledge-intensive settings.
Conclusions
Our study contributes to a growing interest in the emergent action needed to organize certain processes by developing a relational view of the role of objects in coordinating innovation. We found that the relations between objects played an important role in coordinating the multiple, interdependent tasks of a complex innovation process. This role has not been addressed in previous work which has focused more on the capacities of different types of object within specific collaborative tasks. In contrast, our study highlights the way in which the relations between objects ‘orchestrate’ the tasks of multiple groups. Likewise, extending previous work on the plurality of objects involved in innovation (Nicolini et al., 2012), we found that the relations between objects were an established and systemic feature of the innovation process, and were important in delivering a product within time and resource constraints. Our analysis therefore highlights how a